You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To support compilers cpptools does not know how to query for system includes and system defines, perhaps the compiler querying logic could be separated out into user-serviceable definition files. Users with unsupported compilers would have the option of composing their own compiler-query-definition file, and provide all of the necessary information to query the compiler for system include paths and system defines, and translate args for defines and includes, as well as args that should influence how the IntellIiSense process is configured (language standard, IntelliSenseMode).
I'm not sure what the "definition files" would be. One current workaround is to provide a compiler or script that mimics the output we except from gcc/clang compilers.
In addition to needing a way to query unknown compilers for system includes and system defines, there is also the fact that scanning the command line for user includes and defines may fail due to an unknown command line syntax. I guess I'm proposing making both the compiler querying and command line arg parsing logic 'data driven' rather than hard-coded, and providing a way for users to add support for additional compilers by composing their own data to drive those operations.
As of moment of writing this feature request is in Backlog. Are there any plans to start working on it? When tentatively?
It will be really cool to have it implemented so that users will be able to configure currently unsupported compilers without your support. This is especially true for different proprietary compilers that require special licenses or NDAs.
I'm not sure what the "definition files" would be. One current workaround is to provide a compiler or script that mimics the output we except from gcc/clang compilers.
Sean McManus (@sean-mcmanus), since this feature is still not available yet it would be awesome if you could provide more information about the workaround you mentioned. Especially the script part would be interesting, since this already looks like the initial feature request of this issue.
This is really a huge and painful issue for the embedded development world.
Furthermore the requested feature should not be that hard to implement, imho.
Please correct me if I'm wrong.
This seems to be the compiler query process in my use case:
I don't know if there's more magic going on that isn't visible, but if not, a simple solution might look like this:
Step 1:
Introduce a new setting to the extension which provides the option to select to use a local configuration file for compiler configuration or use the actual default detection mechanism (default).
Step 2:
Publish a json schema which must be fulfilled by the user if he want to provide the compiler configuration by himself.
Step 3:
You are done and have satisfied dozens of users.
I really don't understand why such a crucial feature is still not implemented three years later.
Does no one develop embedded systems that use a microcontroller these days?
Robert Stone (@rjstone) Could you provide more info? Our existing querying should work for querying clang/gcc-compatible compiler for C. I assume you mean other embedded C compilers that are not queryable currently.
UPDATE: I just saw your other post about the SDCC compiler (so I think that answers my question).
Sean McManus (@sean-mcmanus) I looked into faking the output that the extension expects, but it looks like all that will do is cause it to think that whatever compiler you have configured is actually gcc, etc,
The main problem is: a bunch of specialized compilers (for which gcc etc aren't alternatives due to lack of target support) aren't following strict standards and using #pragma for all their extensions.
For example, compilers for embedded systems and "retro" computers tend to have non-standard type qualifiers/keywords like these examples from ARM's compiler. Same exact thing for SDCC, Keil, etc, and the different compiler products don't even agree on what keywords to use for exactly the same purpose even when targeting exactly the same architecture.
I'm not even sure how many of these different compilers there are, but there are enough of them that it probably doesn't make sense to support any particular one, or try to make sense of their keywords, but some sort of setting like an "ignore" array of type keywords or type qualifiers, would be useful for anyone using one of these "odd" compilers.
Related: #7146#6677#2499 and probably others I haven't found.
(One thing in particular that's bugging people right now is that PlatformIO, a popular embedded development extension and build system, has vscode-cpptools as a hard dependency which makes it difficult to substitute other C/C++ language services in vscode while still using PlatformIO. https://github.com/platformio/platformio-vscode-ide)
Is it possible for a new extension to somehow modify the language services provided by an existing extension without breaking stuff? I didn't spend very long trying to figure out the provider pattern in the code yet.
For the non-standard type qualifiers/keywords, I've always just added entries to the defines list of my configuration in c_cpp_properties.json. I can't think of any scenario I've come across where the intellisense behavior from this is undesirable.
Activity
sean-mcmanus commentedon Feb 9, 2021
I'm not sure what the "definition files" would be. One current workaround is to provide a compiler or script that mimics the output we except from gcc/clang compilers.
Colengms commentedon Feb 10, 2021
In addition to needing a way to query unknown compilers for system includes and system defines, there is also the fact that scanning the command line for user includes and defines may fail due to an unknown command line syntax. I guess I'm proposing making both the compiler querying and command line arg parsing logic 'data driven' rather than hard-coded, and providing a way for users to add support for additional compilers by composing their own data to drive those operations.
github-actions commentedon Feb 17, 2021
This feature request has received enough votes to be added to our backlog.
ytsarko commentedon Jul 27, 2022
Hi Sean McManus (@sean-mcmanus) and Colen Garoutte-Carson (@Colengms),
As of moment of writing this feature request is in Backlog. Are there any plans to start working on it? When tentatively?
It will be really cool to have it implemented so that users will be able to configure currently unsupported compilers without your support. This is especially true for different proprietary compilers that require special licenses or NDAs.
sean-mcmanus commentedon Jul 28, 2022
If/when we have a tentative plan we would add it to specific milestone.
bobbrow commentedon Feb 28, 2024
Tagging a few compiler issues that may benefit from this feature. #11852 #7653 #7146 #6798 #6677 #6642 #3222 #2499
KnoerleMaTLS commentedon Apr 23, 2024
Sean McManus (@sean-mcmanus), since this feature is still not available yet it would be awesome if you could provide more information about the workaround you mentioned. Especially the script part would be interesting, since this already looks like the initial feature request of this issue.
This is really a huge and painful issue for the embedded development world.
KnoerleMaTLS commentedon Apr 23, 2024
Furthermore the requested feature should not be that hard to implement, imho.
Please correct me if I'm wrong.
This seems to be the compiler query process in my use case:

I don't know if there's more magic going on that isn't visible, but if not, a simple solution might look like this:
Step 1:
Introduce a new setting to the extension which provides the option to select to use a local configuration file for compiler configuration or use the actual default detection mechanism (default).
Step 2:
Publish a json schema which must be fulfilled by the user if he want to provide the compiler configuration by himself.
Step 3:
You are done and have satisfied dozens of users.
I really don't understand why such a crucial feature is still not implemented three years later.
Does no one develop embedded systems that use a microcontroller these days?
rjstone commentedon Jun 3, 2025
+1
Hard to believe there isn't enough demand for this. Nobody uses vscode for C?
sean-mcmanus commentedon Jun 3, 2025
Robert Stone (@rjstone) Could you provide more info? Our existing querying should work for querying clang/gcc-compatible compiler for C. I assume you mean other embedded C compilers that are not queryable currently.
UPDATE: I just saw your other post about the SDCC compiler (so I think that answers my question).
rjstone commentedon Jun 4, 2025
Sorry about that, yes I meant SDCC. I'm looking into the option you mentioned about creating a script that mimics the expected output from gcc.
rjstone commentedon Jun 28, 2025
Sean McManus (@sean-mcmanus) I looked into faking the output that the extension expects, but it looks like all that will do is cause it to think that whatever compiler you have configured is actually gcc, etc,
The main problem is: a bunch of specialized compilers (for which gcc etc aren't alternatives due to lack of target support) aren't following strict standards and using
#pragmafor all their extensions.For example, compilers for embedded systems and "retro" computers tend to have non-standard type qualifiers/keywords like these examples from ARM's compiler. Same exact thing for SDCC, Keil, etc, and the different compiler products don't even agree on what keywords to use for exactly the same purpose even when targeting exactly the same architecture.
I'm not even sure how many of these different compilers there are, but there are enough of them that it probably doesn't make sense to support any particular one, or try to make sense of their keywords, but some sort of setting like an "ignore" array of type keywords or type qualifiers, would be useful for anyone using one of these "odd" compilers.
Related: #7146 #6677 #2499 and probably others I haven't found.
(One thing in particular that's bugging people right now is that PlatformIO, a popular embedded development extension and build system, has vscode-cpptools as a hard dependency which makes it difficult to substitute other C/C++ language services in vscode while still using PlatformIO. https://github.com/platformio/platformio-vscode-ide)
Is it possible for a new extension to somehow modify the language services provided by an existing extension without breaking stuff? I didn't spend very long trying to figure out the provider pattern in the code yet.
vannaka commentedon Jun 28, 2025
For the non-standard type qualifiers/keywords, I've always just added entries to the
defineslist of my configuration inc_cpp_properties.json. I can't think of any scenario I've come across where the intellisense behavior from this is undesirable.sean-mcmanus commentedon Jul 1, 2025
Robert Stone (@rjstone) You can set C_Cpp.intelliSenseEngine to "disabled" to use another language service provider.