Make it possible to define custom compiler keywords

[denis-shienkov]

Type: LanguageService

Right now the intellisence fails at highliting of a custom compiler keywords, like __data, data, __xdata and so forth,
which are used, e.g. for 8051 (aka MCS51) architecture:

• https://www.keil.com/support/man/docs/c51/c51_le_keywords.htm :

• http://mvtool.co.kr/hb/data/pds/EW8051_CompilerReference.pdf :

and so forth.

BTW, similar keywords also are exists and in many other compilers with different MCU architectures.

So, it would be good to allow to define the custom keywords in some VSCode API.

[Colengms]

Hi @denis-shienkov . Thanks for suggesting this. We will consider this for a future milestone.

[denis-shienkov]

Guys,

1. as I understand, I can inject the required compiler keywords, using the grammars entry in the package.json file: https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide

Someting like this:

== package.json ==

    "grammars": [
      {
        "scopeName": "iar-keywords.injection",
        "path": "./syntaxes/iar-c-cpp.tmLanguage.json",
        "injectTo": [
          "source.c",
          "source.cpp"
        ]
      }
    ],

== iar-c-cpp.tmLanguage.json ==

{
    "scopeName": "iar-keywords.injection",
    "injectionSelector": "L:source.c, L:source.cpp",
    "patterns": [
        {
            "name": "keyword.c",
            "match": "(__aapcs_core)\\s"
        },
}

But, here I'm have a problem is that I need to do it dynamycally, e.g. I need to inject the appropriate keywords only for a specified compiler/architecture.

For example, I will have a set of *.tmLanguage.json files for a different toolchains. But, seems, it is impossible to use
the concrete *.tmLanguage.json file, because the grammars field has not any condition property, e.g. as when.

Also, I can't to specify all *.tmLanguage.json files, because it is wrong.

2. I found out a some additional API, called DocumentSemanticTokensProvider : https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#semantic-token-provider

But, here also it is unclear, how to use this provider to inject some additional compiler keywords to the document. F.e. I don't want to re-implement whole semantic features for every toolchain.

I need only in ability to inject some additional compiler keywords depending on the current toolchain. Let's say, that I can detect the current used toolchain, it is not a problem here. A problem here is in injection...

Guys, could you please point me, is it possible todo dynamically ?

[sean-mcmanus]

FYI, those grammars will only affect lexical colorization, which is not implemented by our C/C++ extension, but by https://github.com/jeff-hykin/cpp-textmate-grammar (that might be a better place to file an issue like this). The IntelliSense parser won't have knowledge of the extra keywords and might generate error squiggles, which might be worked around via using something like

#ifdef __INTELLISENSE__
#define __bdata
#endif

in some file specified by the forcedInclude setting.

[denis-shienkov]

Hi @sean-mcmanus ,

will only affect lexical colorization

Ohh.. ok, clear, thanks.

which might be worked around via using something like

I have checked it already, and this does not work too. The intelliSence marks this keywords (with all expression) as error.

Is there are other right way to insert a new keywords to the IntelliSense? Because this #ifdef is not soo good way...

UPD: So, as I understand, is it not enough just to use the TextMate feature? I need also implement an additional steps and for the IntelliSense? Maybe is it possible to add some new API to the intelliSence, e.g. a new property which is an array of additional keywords or something else?

[sean-mcmanus]

Can you give an example of IntelliSense giving an error with the keyword used? I'm not seeing an error:

Another alternative is to add the keywords to the "defines" section, like

Our IntelliSense engine doesn't currently have an extensibility model for adding keywords.

[denis-shienkov]

Can you give an example of IntelliSense giving an error with the keyword used? I'm not seeing an error:

Yes, of course:

Anyway, it is not an option to add the fake defines for that, because then the compilation can fails (and using the additional #ifdef __INTELLISENSE__ in many places is not good also.

Also, how to define the @ symbol?

Another alternative is to add the keywords to the "defines" section, like

Could you please point me, what is a file with this section?

Our IntelliSense engine doesn't currently have an extensibility model for adding keywords.

That's a bad, bad, bad. ;) It would be good to have this feature (even better if it was possible to change dynamically from the typescript code.)

[denis-shienkov]

UPD: Yes, many thanks, for some compilers it will work:

But for other - will not work... Because there are impossible to use a fake defines for that (e.g. previous example with the @ symbol).

[denis-shienkov]

Also, it fails for the following combination:

[sean-mcmanus]

The "@" case isn't part of the C++ standard language. Our compiler is currently only scoped to handle compilers based on gcc, clang, cl.exe, and EDG compilers that support the standard C++ language features (e.g. https://en.cppreference.com/w/cpp/compiler_support ). You would have to replace all @ occurrences with a macro that defines nothing if __INTELLISENSE__ is defined and uses @ otherwise. Our IntelliSense parser is based on https://www.edg.com/c -- so support for Keil extensions would need to originate from them, and from the list of customers at https://www.edg.com/customers, it looks like the Keil compiler is implemented using EDG as well, so the Keil team would need to somehow push their compiler changes back to the EDG team so other uses of EDG could benefit.

The "defines" section I'm referring to is in c_cpp_properties.json or C_Cpp.default.defines.

For the srf case, you would need to define it to something like "int" that would compile.

We had a request to add Keil support, but it got closed due to not enough votes: #3222 ...you could file another request and we could see if it gets more votes.