C/C++ invalid macro definitions with V1.9.7 and newer

[JulianMaV]

Bug Summary:
I use a self-created microcontroller board based on a Renesas controller and the IAR development environment. With the IAR extension for VS Code, it is possible that Intellisense can properly connect all paths, defines, types, etc. and everything works nicely. As of extention version 1.9.7 of C/C++, a command line error is always displayed that a macro definition is invalid, although this is not the case! If you jump back to version 1.8.4 everything is ok.

Steps to reproduce:

• Install the latest extension c/c++ and the latest IAR For Visual Studio Code from pluyckx.iar-vsc

• Download the attached file bug_on_vs_code.zip

• Unpack the files an open the VSC-WS file in the .vscode folder

• browse in VS Code to the file: r_bsp_config_reference and then you get the command line error. this is just one example of this behavior from the C/C++ extension.

• If you now downgrade the c/c++ version to 1.8.4 and restart vs code, the error disappear

VS Code Version:

Example of macro definition error:

[sean-mcmanus]

That project seems to be configured with another configuration provider. Are you able to create a repro that doesn't use that configuration provider? If you run C/C++: Log Diagnostics, does the output appear to show correct data being provided by the configuration provider?

What does that error say in English? It sounds like it's saying the __STDC_VERSION__ is invalid?

[JulianMaV]

Hi @sean-mcmanus your guess is correct. The configuration provider is the extension "IAR For Visual Studio Code"(iar-vsc) from pluyckx. Without this it is actually not possible for me to create a working setup.

The Error Massage in English: Command line error: Invalid macro definition: STDC_VERSION=199901L
However, this definition is not changed and therefore can't be invalid when the versions of c/c++ are changed.

And here is the log file from C/C++: Log Diagnostics (Version 1.10.5): V1.10.5.txt

[JulianMaV]

later I completely deleted the defines for testing and looked at the error reactions of the different C/C++ versions with active IAR extension of pluyckx.

C/C++ Version 1.8.4:

C/C++: Log Diagnostics:

-------- Diagnostics - 14.6.2022, 10:48:43
Version: 1.8.4
Current Configuration:
{
"name": "IAR",
"defines": [],
"includePath": [],
"forcedInclude": [],
"cStandard": "c99",
"cppStandard": "c++14",
"compilerPath": "",
"intelliSenseMode": "msvc-x64",
"configurationProvider": "pluyckx.iar-vsc",
"compilerPathIsExplicit": true,
"cStandardIsExplicit": true,
"cppStandardIsExplicit": true,
"intelliSenseModeIsExplicit": true,
"compilerArgs": [],
"mergeConfigurations": false,
"browse": {
"path": [
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": true
}
}
Custom configurations:
[ C:\Users\JulianVeith\Desktop\bug_on_vs_code\r_bsp_config_reference.h ]
{
"compilerPath": "",
"defines": [
"_Pragma(x)=",
"__eeprom=",
"__flash=",
"__no_init=",
"__root="
],
"includePath": [],
"forcedInclude": [],
"intelliSenseMode": "msvc-x64",
"standard": "c99"
}
Translation Unit Mappings:
[ C:\Users\JulianVeith\Desktop\bug_on_vs_code\r_bsp_config_reference.h ]:
C:\Users\JulianVeith\Desktop\bug_on_vs_code\r_bsp_config_reference.h
Translation Unit Configurations:
[ C:\Users\JulianVeith\Desktop\bug_on_vs_code\r_bsp_config_reference.h ]:
Process ID: 29984
Memory Usage: 15 MB
Defines:
_Pragma(x)=
__eeprom=
__flash=
__no_init=
__root=
Standard Version: ms_c17
IntelliSense Mode: windows-msvc-x64
Other Flags:
--header_only_fallback
Total Memory Usage: 15 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 14
Number of files parsed: 1

C/C++ Version 1.10.5:

Error in English: Command line error: Invalid macro definition: _Pragma(x)=

C/C++: Log Diagnostics:

-------- Diagnostics - 14.6.2022, 10:47:08
Version: 1.10.5
Current Configuration:
{
"name": "IAR",
"defines": [],
"includePath": [],
"forcedInclude": [],
"cStandard": "c99",
"cppStandard": "c++14",
"compilerPath": "",
"intelliSenseMode": "msvc-x64",
"configurationProvider": "pluyckx.iar-vsc",
"compilerPathIsExplicit": true,
"cStandardIsExplicit": true,
"cppStandardIsExplicit": true,
"intelliSenseModeIsExplicit": true,
"compilerArgs": [],
"mergeConfigurations": false,
"browse": {
"path": [
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": true
}
}
Custom configurations:
[ C:\Users\JulianVeith\Desktop\bug_on_vs_code\r_bsp_config_reference.h ]
{
"compilerPath": "",
"defines": [
"_Pragma(x)=",
"__eeprom=",
"__flash=",
"__no_init=",
"__root="
],
"includePath": [],
"forcedInclude": [],
"intelliSenseMode": "msvc-x64",
"standard": "c99"
}
Translation Unit Mappings:
[ C:\Users\JulianVeith\Desktop\bug_on_vs_code\r_bsp_config_reference.h ]:
C:\Users\JulianVeith\Desktop\bug_on_vs_code\r_bsp_config_reference.h
Translation Unit Configurations:
[ C:\Users\JulianVeith\Desktop\bug_on_vs_code\r_bsp_config_reference.h ]:
Process ID: 26680
Memory Usage: 12 MB
Defines:
_Pragma(x)=
__eeprom=
__flash=
__no_init=
__root=
Standard Version: ms_c17
IntelliSense Mode: windows-msvc-x64
Other Flags:
--header_only_fallback
Total Memory Usage: 12 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 14

Test summary:
In the logs, the default defines stand out, from where I still do not know why they were inserted. But what is striking here is that in the latest version of C/C++ the first define is marked as error, although this is not used at all in the r_bsp_config_reference.h file.

Does anyone have a guess where this error could come from?

[Colengms]

Hi @JulianMaV . It looks like our IntelliSense parser (which is based on EDG) is complaining about (any of) the following defines:

                "__STDC_VERSION__=199901L",
                "__EDG_VERSION__=410",
                "__EDG_SIZE_TYPE__=unsigned long",
                "__EDG_PTRDIFF_TYPE__=long",
                "_Pragma(x)="

I can repro the issue by placing these directly in a simple c_cpp_properties.json. I suspect the issue is because these same defines are generated internally by IntelliSense, based on the values of intelliSenseMode and cStandard. Though, despite the error messages, IntelliSense seems to work properly.

I'll follow up with an IntelliSense engineer internally. It's unclear to me whether these defines should take precedence over intelliSenseMode and cStandard settings, or vice versa.

[Colengms]

Curiously, the issue only repros when using an msvc intelliSense mode. That configuration provider is returning:

"intelliSenseMode": "msvc-x64",

The defines provided (from the IAR compiler) do not indicate that it supports MSC extensions. If your environment is not intended to compile MSVC or Windows headers, you might want to contact the author of pluyckx.iar-vsc and suggest they provide a non-msvc IntelliSenseMode instead.

[HampusAdolfsson]

Hi, I am a developer on the iarsystems.iar-build extension, which is built on pluyckx.iar-vsc.

This error seems to occur when the provider gives a conflicting definition of one of the macros you listed above.
The reason some intelliseSense modes work is that they happen to define the same __EDG_VERSION__ as recent IAR compilers, but using older IAR compilers gives the same error regardless of the intelliSense mode.

For __STDC_VERSION__ it is probably the extension's fault if there is a conflict, since that means it didn't set the cStandard intelliSense field correctly. However, for example for __EDG_VERSION__ I think an extension should be allowed to override it, since it is more interesting what version the compiler uses, than what version the intelliSense engine uses internally.

[Colengms]

Hi @HampusAdolfsson . I noticed that your custom configuration extension is providing the msvc-x64 IntelliSense mode. That mode is specific to the MSVC cl.exe compiler. Unfortunately, cpptools does not currently have a compiler agnostic intellisense mode, which might be the ideal solution for compilers that aren't directly supported.

Could you check if you get acceptable IntelliSense behavior if your extension provides gcc-x64 as the IntelliSense mode instead? I believe the 'invalid macro' errors are only reported if using an MSVC IntelliSense mode, so changing it to gcc-x64 may address this issue entirely.

The 'invalid macro' errors are actually ignorable, and do not interfere with IntelliSense. The values you are providing should indeed be used. (The error is actually originating in code tries to specify values for these defines, and fails because they were already explicitly set by the configuration.)

Another potential issue here is that the standard your extension is providing does not appear to be used. This may be due to using an MSVC IntelliSense mode, as cl.exe does not support specifying c99 as the standard and defaults to c17. If this issue persists when specifying a non-MSVC IntelliSense mode, we can likely address it. Unfortunately, setting the value of __STDC_VERSION__ is not sufficient to configure IntelliSense to match that version of the standard.

[JulianMaV]

Hello each other,

What can I do now to make these errors disappear until there is a solution? Is there an ignore list for errors, because working with constant error messages and red marks can be a bit annoying?

How else can I help you to solve this error case?

[HampusAdolfsson]

Hi @Colengms.
Sorry, I wasn't being very clear. Our extension (iarsystems.iar-build) uses clang-arm. pluyckx.iar-vsc uses msvc-x64, but it will be deprecated soon.

I get this error regardless of the intellisenseMode, including with gcc-x64. When I wrote my first comment, the gcc and clang modes defined __EDG_VERSION__=602, which is the same as the latest IAR compilers, and which I believe is why they didn't give this error. However, now they all seem to use 603 (i.e. a different value from IAR compilers), so all intelliseSense modes now give this error.

Even if the EDG version used by IAR compilers is upgraded, it is quite common for our users to use older compilers, so we cannot expect the compiler's EDG version to match what the intellisenseMode wants to define.

Another potential issue here is that the standard your extension is providing does not appear to be used.

iarsystems.iar-build has been improved so that it sets both the standard and __STDC_VERSION__ to the correct (and equivalent) value. I hope this (and using clang-arm) would address the issue?

[Colengms]

I get this error regardless of the intellisenseMode, including with gcc-x64

Hi @HampusAdolfsson . To clarify, this warning should not occur with a non-MSVC IntelliSenseMode. Could you please check again? Looking at the code, there is a flag that imposes a requirement on these defines, and that flag is specific to the MSVC mode, specific to the version of MSVC we are emulating, and specific to how we conform to C11 and C17. If not an MSVC mode, the flag that triggers this warning should not be set, and I am unable to repro the error message with non-MSVC IntelliSense modes. My suggestion would be to ensure you are not providing msvc-x64 as the IntelliSenseMode in a custom configuration for any non-MSVC compiler. If you can reproduce an issue in which this error message still occurs despite providing a non-MSVC IntelliSense mode, please provide a self-contained repro that we could use to investigate further. Based on an inspection of the code, I don't see how use of a non-MSVC IntelliSense mode could trigger that error message.

[HampusAdolfsson]

@Colengms
I am on vacation until mid-august, but I will re-check the error when I get back, and send you a repro if I can in fact produce the error with non-msvc modes.

[HampusAdolfsson]

@Colengms

I've created a minimal example here, with a very simple provider:
https://github.com/HampusAdolfsson/Cpptools-9435-repro
You should be able to npm install, launch the extension and then open any C file to see the error.

[Colengms]

Hi @HampusAdolfsson . The problem is that IntelliSense is itself is an EDG front-end. EDG can be configured to emulate GCC, Clang and CL, and emulate the differences between certain versions of GCC and Clang, but it continues to represent itself as EDG (via system defines) and does not provide a way to emulate different versions of EDG itself. It also disallows redefinition of the compiler defines that it uses internally. That is what you are seeing.

The error is reported because the defines we are providing EDG take precedence over its own values. It's reporting the error as it tries to assign its own values and discovers that values are already present. So, your changes are being applied, which you can confirm by hovering over a __EDG_VERSION__ in your repro. However, this can lead to incorrect behavior. EDG does not (fully) configure itself based on incoming defines. Setting defines without also specifying an equivalent IntelliSense mode (which we translate into the appropriate args to EDG, such as --clang, --clang_version=, --gcc, --g++, --gnu_version=, and various other feature-specific args) can cause some mismatches that result in IntelliSense errors.

For now, we could suppress the error from being reported if the define was part of a custom configuration. But that would not prevent other aspects of IntelliSense from failing due to internally inconsistent state in EDG. The ideal fix would be for us to determine the proper internal args to configure EDG with to most closely match the compiler, address features gaps needed to support that compiler, and provide an IntelliSense mode for it. (Does this issue properly track that for your compiler? )

[HampusAdolfsson]

Hi @Colengms, thanks for your reply, that explanation lines up with my observations of the error.

At the moment we are working around the error by removing any EGD-related defines from configurations before sending them to cpptools. However, this means that IntelliSense will use its own values for these defines, not the compiler's values, so suppressing the error on your end would be a better fix.

I agree that the ideal solution is specific support for IAR compilers (not just for the sake of this error, but also for e.g. keyword support as mentioned in the issue you linked). If this is something you want to go for, we at IAR would be available for e.g. answering questions about our compilers. Just tag me here on GitHub or send an email to Micael.Borgefeldt@iar.com (@micaelbo), and we'll work something out.

[sean-mcmanus]

@HampusAdolfsson We're tracking adding support for IAR compilers at #7653 (oops, I just noticed Colen already linked to that). The VS team worked with NVIDIA to add NVCC compiler support -- I'm looking into if there's someone you can contact about that...

[sean-mcmanus]

The macro redefinition errors are fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.13.2