-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need a way to provide system defines and system includes when compiler querying is disabled (with compilerPath of ""). #6909
Comments
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 the |
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? |
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 |
@bobbrow I think the doc is accurate to the current behavior (and I assume was written later to articulate the current behavior, to make sense of it, as it's a rather complex matrix). Include path and defines from the base config are not merged in when a custom config (for a file or browse config) or entry from compile_commands.json are used. Rather, the base config is a fallback if the file is not present in compile_commands.json or the custom config provider does not provide a file config or any browse config. If you're saying this is a bug, are you saying the original intent was to merge includes and defines from the base config into these other configurations? The fact that an empty compilerPath in the base config modifies the behavior of compiler_commands.json or custom configs, is actually unusual, as it impacts use of the base config for falling back to. So, it seems we have 2 conflicting design decisions here. If the intent is to use the base config for fallback, it's not clear to me that it's a good idea to always merge from it (or allow a blank compilerPath in it to modify the other configs). |
It actually wasn't until version 1.2.1 that an empty compilerPath in c_cpp_properties.json would override the compiler specified by a custom config provider. Previously, that behavior was isolated to use of compile_commands.json. |
This feature request has received enough votes to be added to our backlog. |
The documentation currently states that C_Cpp.default.systemIncludePath is used if set, but I did not get that working with cpptools 1.2.0 (so that may be a bug). Also system defines cannot be set(?), so this is not working regardless. To summarize what I would like to see - this was discussed some in the issues.
This is working except that if compile_commands.json is set, base config including system defines/paths are ignored. The current workaround is to generate a superset of includes and defines in the base config. |
(I am still interested in seeing this in an upcoming release, not forgotten.) |
I may have been missing some context or read the doc wrong when I wrote that. I did not intend to say that the With the PR that's out now though, I can see the value of allowing this for unsupported compilers. For the record, I think allowing |
Would it maybe make more sense to follow that pattern then and add I can also look at handling |
Digging into the code a little more this morning, it looks to me like the 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 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. |
At least for IAR, generating some files suitable for a 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:
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:
It's not, just a hypothetical that could be useful for the above use case.
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. |
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 orcompile_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 fromc_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 acompilerPath
of""
is used in combination with a custom configuration provider orcompile_commands.json
.The text was updated successfully, but these errors were encountered: