[Bug]: compile_macros.h causes many false errors from clangd for C++ codes

[chentang16]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

In CMSIS solution v1.68, compiler toolchain specific predefined macros are added to compile_macros.h and a .clangd file is generated to include this compile_macros.h when (re)loading a project.
However, macros defined in this compile_macros.h would cause many false syntax checking errors from clangd for C++ codes.

e.g. For some C++17 features testing code in the attached project,
When using AC6, the macros in the generated compile_macros.h are not sufficient. Adding an additional -D__ARMCOMPILER_LIBCXX=1 can resolve these false errors. (However, one user's real-world C++ project would still have many false errors for template classes and template functions.)

When using CLANG, the macros in the generated compile_macros.h would cause many false errors. Removing the entire compile_macros.h include can resolve all false errors. One user's opinion is that this compile_macros.h is completely unnecessary when using CLANG.

Since for now the compile_macros.h is global to entire project, instead of individually for each file, some macros like __STDC_VERSION__ do cause issues for C++ code for a project mixed with C and C++ code.

Blinky_AC6.zip
Blinky_CLANG.zip

Expected Behavior

No response

Steps To Reproduce

No response

Affected tools

• cbridge
• cbuild
• cbuild2cmake
• cpackget
• csolution
• packchk
• svdconv
• vidx2pidx

Affected operating systems

• all
• Windows amd64
• Windows arm64
• Linux amd64
• Linux arm64
• MacOS amd64
• MacOS arm64

Environment

No response

[brondani]

One thing that should be addressed is setting the -x option according to the context language when generating compile macros.
The impact on mixed-language projects needs to be investigated. It may also be worth considering an enablement setting, maybe disabled by default.

[mighty-micro]

1.) Redefining a macro or identifier starting with __ is ill formed (no diagnostics required) since about 1990!
2.a) There is no need to redfine macros that are already defined in upstream clang of clangd.
2.b) There is no need to define a macro that is nowhere used (neither in upstream clang nor *.h files).
2.c) There is no need to define armclang macros for upstream clang.

By including all defs that has been created by someone somewhere in time, adds to much noise. I tried to make a list. Checked it twice. It's hard to find out, whats naughty or nice.

An empty compiler_macro.h is all I need for clang (c++20, type traits, meta programming, templates, constexpr).

The compiler_macro.h for armclang seems to conflict with my projects settings: c++17, -fno-rtti, -fexceptions, -mtp=soft, -mno-unaligned-access, -Weverything, -Werror ...
__ARMCOMPILER_LIBCXX significantly reduces the number of errors but not all. Still a lot of false positive concerning templates.