Platform/Architecture/Compiler agnostic IntelliSense modes

[d0ggie]

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.

[Colengms]

Hi @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-default or gcc-unspecified

[d0ggie]

How about we keep this around to track as a Feature Request for adding a platform-agnostic IntelliSense mode? i.e. gcc-default or gcc-unspecified

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]

Hi @d0ggie . FYI, the blocking issue ( #4657 ) should be addressed in 0.26.2-insiders3.

[github-actions]

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]

This feature request has received enough votes to be added to our backlog.

[sean-mcmanus]

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]

Upvote for this issue.
In lieu of this, allowing "mergeConfigurations": true to have an effect when using an automatically generated "compile_commands.json" - meaning things like includePath, forced includes, defines, etc - will take effect and work correctly.

[elaskavaia]

These are solutions I proposed on #11479 which was closed as dup of this one:

Proposed solutions (one of):

• provide intelliSenseMode NOT bound to host, i.e. other-gcc-x86 (etc) which does not define linux, max or windows macros
• provide intelliSenseMode common which does not define ANY additional defines (since it already exists maybe just allowing this to be used as value would solve this)
• provide "undefines" along "defines" in the c_cpp_properties
  allow "defines" to undefine vars some-how, i.e. !linux

[Zmmfly]

These are solutions I proposed on #11479 which was closed as dup of this one:

Proposed solutions (one of):

• provide intelliSenseMode NOT bound to host, i.e. other-gcc-x86 (etc) which does not define linux, max or windows macros
• provide intelliSenseMode common which does not define ANY additional defines (since it already exists maybe just allowing this to be used as value would solve this)
• provide "undefines" along "defines" in the c_cpp_properties
  allow "defines" to undefine vars some-how, i.e. !linux

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.