I am having problems getting VS Code’s Intellisense for C++ to work.
I am using Windows 10, g++ and gdb. I have installed the extensions C/C++ for Visual Studio Code and the C/C++ Extension Pack.
If I write msg, for example, main, mitl, module and mutable will appear, but that’s it - essentially, I get a partial list. The subsequent ‘s’ and ‘g’ of msg produce nothing nor does the normally triggering dot or full stop after msg (msg.) Even the simplest printf produces only private, protected, and pragma, but printf is never an option.
I have uninstalled and reinstalled VS Code to no avail. I have also deleted all extensions and reinstalled them as per Completely uninstall VS Code extensions, again, without success. A simple piece of code compiled without issue, but when I changed the source code file for something a little more complicated the following messages appeared.
Please update #include errors detected. Please update your includePAth. IntelliSense features fro this translation unit(C/NOTES/Programming/VSCODE/helloworld.cp) will be provided by the tag parser
*[2/1/2023, 10:54:07 PM] For C++ source files, IntelliSenseMode was changed from "windows-gcc-x64" to "windows-msvc-x64" based on compiler args and querying compilerPath: "C:\ghcup\ghc\9.2.5\mingw\bin\gcc.exe"
[2/1/2023, 10:54:07 PM] For C source files, IntelliSenseMode was changed from "windows-gcc-x64" to "windows-msvc-x64" based on compiler args and querying compilerPath: "C:\ghcup\ghc\9.2.5\mingw\bin\gcc.exe"*
Is it a case of IntelliSense looking at the C compiler (gcc.exe) and not the C++ compiler (g++.exe) and if so how can I change that?
Related
Prolog: I am using STM32 CubeIDE to develop embedded application for STM32 Microcontrollers, like the F1 Series, the F4 Series, the G0 series and some others with C.
What happened:
Today morning the automatic update feature suggested me to update to STM CubeID Version 1.9.0 and i accepted. After the updater had finished, I opened my current project and changed one variable in a typedef struct and hit the "build" button. All of a sudden the linker reported lots of "multiple definition" and "first defined here" errors. This project was compiling perfectly without any issues yesterday with CubeIDE Version 1.8
After searching an hour or two, where I could have missed a semicolon or something in that direction, which could mess up the whole code, I came to the conclusion, that the upgrade from CubeIDE 1.8.0 to 1.9.0 might be the root cause for this errors.
So I decided to uninstall CubeIDE 1.9.0 and reinstall Version 1.8.0, rolled back the project to the last working version from yesterday evening (compiled with 1.8.0), made the same changes, and Voila! - anything worked well again.
For me it looks like STM messed something up with the linker. Can anyone confirm this behavior, or was only me affected?
This is due to compiler update. From the release notes of STM32CubeIDE:
GCC 10 support by default
From GCC 10 release notes:
GCC now defaults to -fno-common. As a result, global variable accesses
are more efficient on various targets. In C, global variables with
multiple tentative definitions now result in linker errors. With
-fcommon such definitions are silently merged during linking.
This page has futher explanation and a workaround:
A common mistake in C is omitting extern when declaring a global
variable in a header file. If the header is included by several files
it results in multiple definitions of the same variable. In previous
GCC versions this error is ignored. GCC 10 defaults to -fno-common,
which means a linker error will now be reported. To fix this, use
extern in header files when declaring global variables, and ensure
each global is defined in exactly one C file. If tentative definitions
of particular variables need to be placed in a common block,
__attribute__((__common__)) can be used to force that behavior even in code compiled without -fcommon. As a workaround, legacy C code where
all tentative definitions should be placed into a common block can be
compiled with -fcommon.
In Project > Properties > C/C++ build > Settings > gcc compiler > miscellaneous > Other flags, try adding -fcommon as shown below to avoid the 1k+ linker error issue with STM CubeIDE 1.9.
Basically this:
I created a fresh project in Visual Studio 2019 using the VSX c# template.
I moved a bunch of files from an older VSX project (for VS 17).
I compiled and ran the project - errors started emerging.
I addressed one error, ran the project - got another error.
I started addressing the second error and in the process of fixing it I noticed that now VS is for some reason compiling an unknown external project whenever I run my project. I realized it because once the program hit the error and instead of jumping into my code and showing me the line, it showed me this message: "The source file is different from when the module was built. Would you like the debugger to use it anyway?" Also whenever I changed something in my code files now - the changes never apply. Moreover, the first error (which I have already fixed) resurfaced again, and when the debugger tried showing me the place of the error - it clearly used the new file, thinking that it's an old one (even if I change the new file to have empty space in the line where the error was, the debugger will still stand on that empty line, talking about the error).
Now whenever I create a new VSX project, even an empty one, and compile/run it - the studio runs that unidentified external project (I have absolutely no clue where that project is, even the files that the debugger uses have no influence on that project.
UPDATE: I deleted Visual Studio cache folders (C:\Users\xxx\AppData\Local\Microsoft\VisualStudio\16.0_xxxx) as well as reset the experimental Visual studio with the start menu prompt "Reset Visual Studio 2019 Experimental Instance". Now, when I compile my VSX projects, a clean and empty Visual Studio instance is launched - my extension code is ignored.
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
Why do I have the same suggestions while typing expression?
Example:
I had exactly the same problem. After a week or so, it get really annoying.
basically, as the comments hint to, there are probably multiple linting or intelisense tools. In my case (for python) i had the pylance extension added.
When i disabled this, the problem went away, but features were missing. So i added it back...
For some reason (i dont know why), this fixed the problem !!!
I can only hypothesise that in some way the extension was corrupted. Nevertheless, it worked.
EDIT:
I can also confirm that unchecking this setting appears to work:
Jupyter: Pylance Handles Notebooks
My current system is Windows 11, with python 3.10.
Final edit (8 Dec 2022):
This is resolved here:
Please could you install VS Code 1.74 and the latest Jupyter, PyLance and Python extension and confirm this still exists.
Visual Studio Code provides an API so third-party extensions and built-in modules can contribute suggestions for auto-completion pop-ups. The system is currently designed so suggestions are merely appended—there's no duplicate detection or removal (perhaps because extensions can also take care of sorting suggestions and such algorithm would get on the way). That means that if you have more than one extension or module for a given language you can easily get duplicate entries.
Having several extensions for PHP is not necessarily a bad idea since they can address different needs (for instance, PHP DocBlocker just creates annotations, it doesn't provide auto-completion suggestions) but you have at least two extensions (PHP Intelephense and PHP Intellisense) that do exactly the same things. That's likely to hurt performance (all your workspace files will be scanned several times) and just adds noise.
I suggest you read the extension descriptions carefully to learn what they do exactly and then figure out which ones you need. Remember that extensions can be enabled/disabled in a per-workspace basis.
The following is just my own totally subjective opinion. Among the PHP extensions that provide code intelligence only two of them seem mature enough:
PHP Intelephense
PHP Intellisense
I've tried both. PHP Intelephense works best for me than PHP Intellisense so that's the one I've kept. I've also disabled php.suggest.basic following the installation instructions because basic suggestions didn't add any value to me (they were blind string matching):
Turn off the php.suggest.basic setting for best results.
... as well as taming builtin Emmet support, which was providing really dumb suggestions:
"emmet.showExpandedAbbreviation": "inMarkupAndStylesheetFilesOnly"
YMMV.
TLDR; Installing pre-release version of Jupyter solves (v2022.11...)
Ok, so after some more extensive experimentation I think I found what's causing this in my case. After looking at the processes I noticed that there were two Pylance processes running, and consistently this would only be a problem if I was working in a session with a jupyter notebook open or one that had been opened.
saun89 17740 37.3 0.3 1008004 199492 ? Sl 20:58 0:22 /home/saun89/.vscode-server-insiders/bin/fef85ea792f6627c83024d1df726ca729d8c9cb3/node /home/saun89/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2022.11.32/dist/server.bundle.js --cancellationReceive=file:9178e897a2b78b36bfd167f79b36c3bdad2931d71b --node-ipc --clientProcessId=17651
saun89 18743 257 0.7 1304584 382288 ? Sl 20:59 0:20 /home/saun89/.vscode-server-insiders/bin/fef85ea792f6627c83024d1df726ca729d8c9cb3/node /home/saun89/.vscode-server-insiders/extensions/ms-python.vscode-pylance-2022.11.32/dist/server.bundle.js --cancellationReceive=file:8744a321767eed92821fd737be4dc7dcfb728284e5 --node-ipc --clientProcessId=17651
Pylance basically spins up a service for the workspace, and then spins up a separate service for the notebook.
Output from "Python Language Server" logs:
Disabling Jupyter removes the duplication, and after installing an earlier version of the extension (v2022.4) this appears to have fully resolved the issue. I'm going to go ahead and log the extension bug once I have something reproducible.
As of 11/30/22, Jupyter Extension Pre-Release version v2022.11.1003281132 is the latest version fixes this issue. Click the gear icon next to the extension and you should see "install another version..." Then you can select version v2022.11.1003281132.
I have already set up build and debug environment for Object Pascal inside Visual Studio Code via FPC and GDB, but I just made build process work for programs containing only 1 .pas file via
"command": "fpc",
"args": [ "-g", "-Px86_64", "helloWorld.pas" ],
Now, I need to build quite big Delphi project group (something like solution?) and it contains main project file .groupproj.
Is there a way to build the .groupproj via FPC somehow?
Or at least some workaround like conversion to .lpi and then build via FPC?
Or at least call Delphi compiler/builder from VS Code and build the whole project group via it? (but I don't like this option, because I prefer to not use Delphi)
To get some facts straight for other people that might stumble on this:
FPC supports Delphi source files (.lpr/.dpr, .pp/.pas and .inc). Not Delphi meta information (.dproj/.dof/.bpg/.cfg/.groupproj) which is Delphi version dependent anyway.
Lazarus conversion tool also converts .dfms. Basically it is a .dfm cleaner and Uses clause enhancer, just like some conversion tools between Delphi versions. It by default however also does substitutions that change Delphi code (that works in FPC's Delphi (-Sd) mode) into the objfpc dialect (-S2 mode) preferred by Lazarus . Always make a backup before trying, and check the configuration of the conversion tool thoroughly.
FPC and Delphi commandline parameters are different.
FPC does not support Lazarus metadata formats like .lpi. The Lazarus utility Lazbuild however does support building Lazarus projects from the commandline.
But luckily the basics are the same
a main program or library file files)
a set of unit (.pas files) and include directories (.inc files). FPC differentiates between the two, delphi doesn't.
autocreated forms must be added to the project.
any additional commandline switches like defines to set, range checking optimization options.
So in worst case, examine the Delphi projects (either in IDE or texteditor) for directories and switches and create either a manual buildscript or a lazarus (.lpi) project.
However it is vital to keep in mind that the default FPC mode is NOT Delphi mode, so always when executing FPC make sure you manually enable Delphi mode (-Sd)
Group project support within Lazarus is very new (as in months), and afaik not even in stable versions yet. Though if you create a bunch of .lpis, a batch file/shellscript with a sequence of lazbuild commands on .lpis might do it.
P.s. throw the VSCode under the bus and use Lazarus.