Should cbuild setup also create .clangd for setting up Intellisense?

[ReinhardKeil]

The Problem To Be Discussed
Currently cbuild setup generates compile_commands.json for Intellisense in the tmp directory for the related context.

In VS Code using the CLang intellisense engine, there is also a file in the project root named .clangd. In some cases this file seems to contain define settings that communicate architecture specific defines. Such defines are used in CMSIS header files, so it is likely that intellisense fails without it.

For example a project targeting a Cortex-M85 contains in clangd this:

CompileFlags:
  CompilationDatabase: c:\Test\Test2\TestM85\tmp\Project\SSE-310-MPS3_FVP\Release
  Add:
    - '-D_ILP32=1'
    - '-D_USE_STATIC_INLINE=1'
    - '-D__APCS_32__=1'
    - '-D__ARMCC_VERSION=6210000'
    - '-D__ARMCOMPILER_VERSION=6210000'
    - '-D__ARMEL__=1'
    - '-D__ARM_32BIT_STATE=1'
    - '-D__ARM_ACLE=200'
    - '-D__ARM_ARCH=8'
    - '-D__ARM_ARCH_8_1M_MAIN__=1'
    - '-D__ARM_ARCH_EXT_IDIV__=1'
       :

My questions are therefore:

• should the file .clangd generated by the cbuild setup?
• is .clangd working across the different intellisense engines?
• are settings in file .clangd compiler specific?

[mcgordonite]

The .clangd files are generated by the Csolution VS Code Extension. There is a setting to disable this feature if the user isn't using the Clangd extension.

Clangd config files are documented here: https://clangd.llvm.org/config. They are read by the clangd language server to configure intellisense in the containing folder and its children. They are not considered by other intellisense engines, such as the Microsoft C/C++ extension. The Csolution extension also integrates to C/C++ via a VS Code extension API.

The extension creates one .clangd file per project with two fields:

• CompilationDatabase: points to the compile_commands.json for the context selected for the given project.
• Add: additional compiler flags only applied if the user is using AC6. This is a workaround in place until an AC6 version of clangd is available, with knowledge of Arm Compilers specific defines. They are determined by querying the compiler with -dM -E.

should the file .clangd generated by the cbuild setup?

Thoughts:

• Is this too specific to Clangd? Would we need to add support for other language servers, such as ccls and Microsoft's C/C++ extension?
• If we add this feature, it should be optional in case the user isn't using clangd.
• The Add field will likely go away when armclangd builds are available, so it's not worth adding that here now.

[CareyJWilliams]

In some cases this file seems to contain define settings that communicate architecture specific defines. Such defines are used in CMSIS header files, so it is likely that intellisense fails without it.

I should probably note that a lot of the flags you'll see in the .clangd are superfluous. clangd should already be aware of most of them, like the architectural ones (MS C/C++ too has its own method of querying a toolchain for such). The important defines are the armclang specific ones (e.g. ARMCOMPILER_LIBCXX, ARMCOMPILER_VERSION etc.). But seeing as we don't have an exact/complete list of those, we currently play it safe and add everything armclang gives us back.

It's not perfect, but as Matt notes, this is in theory just a short term workaround.

[jkrech]

Do we need to generate .clangd file with tool-box for compiler version dependency?
Or do we ship clangd as part of the compiler distribution
Can this be fixed in CMake using the toolchain to find internal macros
Review in the timeline for CMSIS-Toolbox 2.4.0

[jkrech]

Is this a priority for 2.4.0?

[Eplankton]

In some cases this file seems to contain define settings that communicate architecture specific defines. Such defines are used in CMSIS header files, so it is likely that intellisense fails without it.

I should probably note that a lot of the flags you'll see in the .clangd are superfluous. clangd should already be aware of most of them, like the architectural ones (MS C/C++ too has its own method of querying a toolchain for such). The important defines are the armclang specific ones (e.g. ARMCOMPILER_LIBCXX, ARMCOMPILER_VERSION etc.). But seeing as we don't have an exact/complete list of those, we currently play it safe and add everything armclang gives us back.

It's not perfect, but as Matt notes, this is in theory just a short term workaround.

Can we directly get that .clangd file? I don't use keil-studio-pack for vscode, but i wish to use clangd lsp on vim instead.

[jkrech]

@Eplankton, I am currently not aware of any way that would generate the .clangd file including the AC6 specific internal defines for you but it looks simple enough for you to write a script doing that.
You can have armclang print out the #define statements of all predefined macros e.g.

  armclang -E -dM dummy.c --target=arm-arm-none-eabi -mcpu=cortex-??

Note: you need to use your default command line options to match your circumstances.