Need a way to provide system defines and system includes when compiler querying is disabled (with compilerPath of "").

It's possible to disable compiler querying (and disable fallback to a different compiler on failure) by specifying a compilerPath of "". This also works in combination with a custom configuration provider or compile_commands.json, to prevent use of the compiler they indicate (in case it's not cl.exe, gcc, or a gcc variant we can query). However, the defines and includes from c_cpp_properties.json are not currently getting merged into the configuration in those cases. Since no compiler will be queried, it seems necessary to support a way for the user to provide the missing system includes and systems defines.

This issue tracks merging in the includes and defines from c_cpp_properties.json when a compilerPath of "" is used in combination with a custom configuration provider or compile_commands.json.

Is this a regression according to the documentation https://code.visualstudio.com/docs/cpp/customize-default-settings-cpp#_system-include-pathdefines-resolution-strategies?

I think the step there that needs to change is 1.4: If compilerPath is "", use an empty array for system include path and defines.

If the compilerPath is "", we won't get system includes or defines from a compiler, so we should use system include paths and defines provided in c_cpp_properties.json instead of using 'an empty array'. (This is needed when using compile_commands.json or a custom config provider. Otherwise, includes and defines from c_cpp_properties.json are being used).

This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog.

Can this be resurrected, it seem to be relative simple way to support other compilers than gcc/clang?
#6931 is maybe more general, but requires further format specifications while this is something I expect to be simple.

I would have expected 1.4 to be the same behavior as 2.3 (from the documentation), though it is not written the same. Do we really not use the includePath and defines from c_cpp_properties.json for 1.4? I think the documentation and the behavior should be updated. This sounds more like a bug (which won't be auto-closed by the bot) than a feature request to me.

(I am still interested in seeing this in an upcoming release, not forgotten.)

I would have expected 1.4 to be the same behavior as 2.3 (from the documentation), though it is not written the same. Do we really not use the includePath and defines from c_cpp_properties.json for 1.4? I think the documentation and the behavior should be updated. This sounds more like a bug (which won't be auto-closed by the bot) than a feature request to me.

I may have been missing some context or read the doc wrong when I wrote that. I did not intend to say that the includePath and defines should be merged in when compileCommands or configurationProvider are in use.

With the PR that's out now though, I can see the value of allowing this for unsupported compilers. C_Cpp.default.systemIncludePath was supposed to address this but we never added the companion setting: C_Cpp.default.systemDefines. There may even be a json file format our code would support now due to the work that was done to support Linux in Visual Studio.

For the record, I think allowing compilerPath to be set to "" to turn off the probing was a mistake (my mistake). I think it would have been better to add a separate property to make it explicit. If we ever wanted to bump the c_cpp_properties.json version, that would be a worthy change to include in the "upgrade" logic.

C_Cpp.default.systemIncludePath was supposed to address this but we never added the companion setting: C_Cpp.default.systemDefines.

Would it maybe make more sense to follow that pattern then and add systemDefines, systemIncludePath, and systemForcedInclude to c_cpp_properties.json? That might make more sense than the mergeConfigurations property I proposed.

I can also look at handling compile_commands.json — we’re using CMake Tools so that wasn’t a requirement for us.

Digging into the code a little more this morning, it looks to me like the compile_commands.json file is accessed by the closed-source language server directly. I therefore can't extend this to compile_commands.json without Microsoft support.

Assuming this still isn't a priority for the Microsoft team, I think the current approach in #8174 may be the best approach; it at least provides a path where CMake Tools + IAR/Keil/etc can be used in VSCode with accurate intellisense.

I didn't think systemForcedInclude was a thing. Is it? I might have seen something like that with Arduino though it's been a long while. One of the reasons I think we held back on systemDefines is because this list can be huge and we didn't expect folks to get this 100% correct -- which can cause other problems. Ideally, we would add extensibility into the open source part of the extension to support the unrecognized compilers, but we haven't started work on that yet. Not all of these compilers are programmatically queryable, and some also support non-standard language extensions that we don't (e.g. Keil).

And yes, compile_commands.json is currently processed internally. We haven't started a discussion as to whether we could port that to TypeScript and make it open source.

One of the reasons I think we held back on systemDefines is because this list can be huge and we didn't expect folks to get this 100% correct -- which can cause other problems

At least for IAR, generating some files suitable for a systemForcedInclude is straightforward. The first includes all the system defines and can be generated by running the following command:

iccarm.exe --IDE3 --NCG <a dummy input file> --predef_macros iar_predefined_macros.h <compile flags>

This generates a header file with all the system defines- see https://gist.github.com/willson556/3d36c21100a473f75f2e87d0398188ff for a sample.

The other trick is to use the contents of <IAR_INSTALL>/arm/config/syntax_icc.cfg, which has contents like:

__arm
__thumb
__interwork
__swi
__irq
__fiq
__ramfunc
__no_init
__root
__nested
__task
__noreturn
__absolute 
__big_endian 
__little_endian 
__packed 
__stackless 
__weak 
__nounwind

and generating a header file like:

#define __arm
#define __thumb
#define __interwork
#define __swi
#define __irq
#define __fiq
#define  __ramfunc
#define __no_init
#define __root
#define __nested
#define __task
#define __noreturn
#define __absolute
#define __big_endian
#define __little_endian
#define __packed
#define __stackless
#define __weak
#define __WEAK
#define __nounwind
#define __intrinsic

This lets intellisense ignore the IAR language extensions.

Not sure what the situation looks like for Keil and other unsupported compilers, but at least for IAR there's a reasonable path for the user (or in the future cpptools) to generate a reasonable list of defines.

To answer the other questions:

I didn't think systemForcedInclude was a thing. Is it?

It's not, just a hypothetical that could be useful for the above use case.

Ideally, we would add extensibility into the open source part of the extension to support the unrecognized compilers, but we haven't started work on that yet.
...
And yes, compile_commands.json is currently processed internally. We haven't started a discussion as to whether we could port that to TypeScript and make it open source.

Performance issues or other potential blockers notwithstanding, it seems like having as much of the "configuration" logic in the open-source part of the extension as possible would be advantageous. If there was a good structure in place for adding compilers, I'd expect the community would be able to step in and support the various niche/proprietary compilers that are used in embedded development rather than Microsoft needing to procure licenses, etc for all of them.

Performance issues or other potential blockers notwithstanding, it seems like having as much of the "configuration" logic in the open-source part of the extension as possible would be advantageous. If there was a good structure in place for adding compilers, I'd expect the community would be able to step in and support the various niche/proprietary compilers that are used in embedded development rather than Microsoft needing to procure licenses, etc for all of them.

This is the goal of #6931

For your example, I would think we'd implement it without forced includes, but the end result would be the same: support as many compilers as we can, and let the community help where possible.

This issue is still tracking support for providing system includes and defines when using compile_commands.json, which is not addressed by #8174 .

Just upvoting this as a vital feature. This would let take a number workarounds in game.

Navigation Menu

Repository navigation

Need a way to provide system defines and system includes when compiler querying is disabled (with compilerPath of ""). #6909

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Need a way to provide system defines and system includes when compiler querying is disabled (with compilerPath of ""). #6909

Description

Activity

michelleangela commented on Feb 5, 2021

Colengms commented on Feb 5, 2021

github-actions commented on Apr 7, 2021

gerhardol commented on Apr 8, 2021

bobbrow commented on Apr 8, 2021

7 remaining items

gerhardol commented on Jun 21, 2021

bobbrow commented on Sep 20, 2021

willson556 commented on Sep 20, 2021

willson556 commented on Sep 21, 2021

bobbrow commented on Sep 21, 2021

willson556 commented on Sep 23, 2021

willson556 commented on Sep 23, 2021

bobbrow commented on Sep 23, 2021

Colengms commented on Oct 5, 2021

tolezk commented on Mar 26, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions