Repository navigation
Platform/Architecture/Compiler agnostic IntelliSense modes #4653
Description
Hi.
As of #4644 -m32/m64 argument is now being added whenever compiler built-ins are probed. This change however breaks any GCC that does not actually target x86/x64 or certain other platforms that have those command line options available; E.g. ARM/AArch64 are among those that do not have such options.
It is not possible to ignore any unknown command line options (except for -Wno), so e.g. passing some other option thru compilerArgs to easily overcome this issue is not possible. Of course, it's always possible to do a wrapper kludge, which would modify command line arguments and only after that do the actual GCC call, but that's really pushing it too far and would not solve this issue for anyone else except me. I have no idea how Clang behaves on this matter, perhaps it has more relaxed command line argument parsing.
I wonder, if there could be some either some option to specify the command line options ("compilerArgsProbe") which are used for probing for any platform-specific (machine-depedent in GCC lingo) options, or better still, if there would be some other mode ("gcc-other") to inform that the compiler isn't really targetting x86/x64 and just some best effort style is to be expected, instead of completely bailing out and doing nothing.
I see that #4271 has a similar type of request (arm/arm64 intellSenseMode), and now after the change mentioned above that would do the job, too.
Activity
Colengms commentedon Nov 23, 2019
Hi Pekka Seppänen (@d0ggie) . Thanks for reporting this. I broke out #4657 to track the blocking issue when using a version of gcc/clang that does not support -m64 or -m32. How about we keep this around to track as a Feature Request for adding a platform-agnostic IntelliSense mode? i.e.
gcc-defaultorgcc-unspecifiedd0ggie commentedon Nov 25, 2019
Sure. While dedicated ARM/AArch64 target would get me covered as well, there are indeed many other embedded platforms (say, e.g. AVR) that would benefit from this.
While many of the chip vendors / licensors provide their own IDE (usually Eclipse based), sometimes it's easier to write the code with an another tool (VSCode in this case) and have a dedicated software for debugging. It might not seem the proper way for an IDE concept, but I like VSCode because it doesn't try too hard to be an one-size-fits-all tool. Just for code editing it provides much more than a simple text editor (and does not require an extensive setup), and if there's no need for integrated debugging or building one simply doesn't install an extension for those.
Colengms commentedon Nov 26, 2019
Hi Pekka Seppänen (@d0ggie) . FYI, the blocking issue ( #4657 ) should be addressed in 0.26.2-insiders3.
github-actions commentedon Oct 17, 2020
This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog.
github-actions commentedon Jan 26, 2021
This feature request has received enough votes to be added to our backlog.
[-]Platform-agnostic intelliSenseMode[/-][+]Platform/Architecture/Compiler agnostic IntelliSense modes[/+]sean-mcmanus commentedon Feb 13, 2023
FYI, a user was hitting a problem with configuring IntelliSense for the PowerPC platform (where linux is not defined, i.e. linux IntelliSense mode doesn't work): #10404
KB3HNS commentedon May 12, 2023
Upvote for this issue.
In lieu of this, allowing
"mergeConfigurations": trueto have an effect when using an automatically generated "compile_commands.json" - meaning things likeincludePath, forced includes, defines, etc - will take effect and work correctly.elaskavaia commentedon Jan 23, 2024
These are solutions I proposed on #11479 which was closed as dup of this one:
Proposed solutions (one of):
allow "defines" to undefine vars some-how, i.e. !linux
Zmmfly commentedon Jul 25, 2024
This is useful for intellisense on embedded projects (SOC/MCU) as they either use an RTOS or nothing at all, excluding MPUs as they tend to run custom Linux or Android.