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.