Skip to content

Extensible compiler querying #6931

Open

Description

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).

Activity

  1. sean-mcmanus commented on Feb 9, 2021

    @sean-mcmanus
    Contributor

    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.

  2. Colengms commented on Feb 10, 2021

    @Colengms
    ContributorAuthor

    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.

  3. modified the milestones: Triage, Backlog on Feb 17, 2021
  4. github-actions commented on Feb 17, 2021

    @github-actions

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

  5. ytsarko commented on Jul 27, 2022

    @ytsarko

    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.

  6. sean-mcmanus commented on Jul 28, 2022

    @sean-mcmanus
    Contributor

    If/when we have a tentative plan we would add it to specific milestone.

  7. bobbrow commented on Feb 28, 2024

    @bobbrow
    Contributor

    Tagging a few compiler issues that may benefit from this feature. #11852 #7653 #7146 #6798 #6677 #6642 #3222 #2499

  8. KnoerleMaTLS commented on Apr 23, 2024

    @KnoerleMaTLS

    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.

  9. KnoerleMaTLS commented on Apr 23, 2024

    @KnoerleMaTLS

    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:
    image

    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?

  10. added this to cpptools and removed this from On Deckon Aug 29, 2024
  11. rjstone commented on Jun 3, 2025

    @rjstone

    +1
    Hard to believe there isn't enough demand for this. Nobody uses vscode for C?

  12. sean-mcmanus commented on Jun 3, 2025

    @sean-mcmanus
    Contributor

    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).

  13. rjstone commented on Jun 4, 2025

    @rjstone

    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.

  14. rjstone commented on Jun 28, 2025

    @rjstone

    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.

  15. vannaka commented on Jun 28, 2025

    @vannaka

    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.

  16. sean-mcmanus commented on Jul 1, 2025

    @sean-mcmanus
    Contributor

    Robert Stone (@rjstone) You can set C_Cpp.intelliSenseEngine to "disabled" to use another language service provider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    • Status
      No status

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions