clangd assumes compiler target is 'x86_64-pc-windows-msvc' for .cpp files

[jostlowe]

Hi!

I have set up a project for the STM32H523RET6 using the following setup:

CubeMX: 6.15.0

STM32 vscode extension: 3.5.1

The project is configured to use starm-clang and starm-clang++ and the STARM_PICOLIBC toolchain

I have created a .cpp file () that i added to my build and updated my CMakeLists.txt with the following:

# Setup compiler settings
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS ON)

...

enable_language(C CXX ASM)

...

# Add sources to executable
target_sources(${CMAKE_PROJECT_NAME} PRIVATE
    Core/Src/myclass.cpp
    # Add user sources here
)

When building the project, it compiles fine, but clangd reports the following problem:

nsupported option '-mcpu=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)
Unsupported option '-mfpu=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)
Unsupported option '-mfloat-abi=' for target 'x86_64-pc-windows-msvc'clang(drv_unsupported_opt_for_target)

Is this a known issue?

For reference (or anyone having a similar issue) i managed to temporarily fix the issue by explicitly setting the target for clangd by changing the .clangd file from

CompileFlags:
  Add:
    - '-ferror-limit=0'
    - '-Wno-implicit-int'
  CompilationDatabase: build/Debug
Diagnostics:
  Suppress:
    - unused-includes
    - unknown_typename
    - unknown_typename_suggest
    - typename_requires_specqual

to

CompileFlags:
  Add:
    - '-ferror-limit=0'
    - '-Wno-implicit-int'
    - '-target'
    - 'thumbv8m.main-st-none-eabihf'
    - '-mfpu=fpv4-sp-d16'
    - '-fno-exceptions'
    - '-fno-rtti'
  CompilationDatabase: build/Debug
Diagnostics:
  Suppress:
    - unused-includes
    - unknown_typename
    - unknown_typename_suggest
    - typename_requires_specqual

[Cartu38 OpenDev]

@jostlowe sounds weird.

I've very same usage than you (STM32CubeMX project, ST ARM clang compiler & picolib usage) and works like a charm.

Are you pointing to right compilation database serving clangd ?

Have a look to:

[jostlowe]

Thanks for the quick response :) 

Checking that it point to the correct compilation database in the way you suggest i get the following:

I[14:07:40.019] Loaded compilation database from c:\my\path\project_folder\build\Debug\compile_commands.json

[Cartu38 OpenDev]

Ok ... and what if looking for 'clangd.exe' as part of filter of the very same output channel ?

Are you getting in real something like '<local path>\st-arm-clangd\19.1.2+st.3\bin\st-arm-clangd.exe' ?

Asking because you have to rely on ARM embedded LLVM utilities not PC ones.

[jostlowe]

 C:\Users\<username>\AppData\Local\stm32cube\bundles\st-arm-clangd\19.1.2+st.3\bin\starm-clangd.exe

Did what you suggested: Seems to be using the right utilities?

[Cartu38 OpenDev]

Yes it is. So ?

[jostlowe]

Still seeing the same errors. 

Its no biggie, as i got it to work with the fix in the .clangd file, but I thought it might be interesting for the devs of the STM32 VScode extension to have a look at

[vincent_grenet · Accepted solution]

@jostlowe Thanks for reporting here.
Already I can share we have a fix within our current code base about C++ support see https://community.st.com/t5/stm32cube-for-visual-studio-code/clangd-intellisense-issues-plugin-generated-query-driver/td-p/821738 . Will be shared Thanks next update planned already in coming weeks.

When it comes to your unsupported options we have to dig into more because not able to reproduce locally the pain.
Weird stuff is are highlighted by @Cartu38 OpenDev sounds you're not getting right toolchain invoked ... 

target 'x86_64-pc-windows-msvc'

 is ???

[FluxPower42]

Hi @vincent_grenet , @vincent_grenet , @Cartu38 OpenDev 

I have now spent some time on this issue and believe I have taken a small step toward a solution.

My Prerequisites

1. In the Cube32MX project (project-name.ioc)

• under 'Project Manager' / 'Project' / 'Toolchain / IDE'  = 'CMake'
• under 'Project Manager' / 'Project' / 'Default Compiler/Linker' = 'Starm-Clang'
• In the generated file 'cmake/starm-clang.cmake' in line 28
  'STARM_NEWLIB' is used instead of 'STARM_HYBRID':

set(STARM_TOOLCHAIN_CONFIG "STARM_NEWLIB")​

2. Minimum content of the '.clangd' file: 

CompileFlags:
  CompilationDatabase: build/Debug​

Now back to the clangd problem, or hopefully to the solution

In my opinion, the problem lies in the fact that clangd does not successfully query the clang(++) compiler about which intrinsic includes it uses.

Two things are necessary for a successful query:

1. Path to the clangd compiler:
The links to the compilers are stored in the 'settings.json' (or 'project-name.code-workspace') file:

“--query-driver=${env:CUBE_BUNDLE_PATH}/st-arm-clang/19.1.6+st.8/bin/starm-clang.exe”
“--query-driver=${env:CUBE_BUNDLE_PATH}/st-arm-clang/19.1.6+st.8/bin/starm-clang++.exe”​

Problem here:
The 'starm-clang++.exe' part is removed from the file shortly after each restart of the 'STM32Cube clangd VSCode Extension'. And therefore every time the project is opened in VSCode!
Solution:
You can either re-enter this path manually each time or run a script in the background that checks the contents after saving the settings.json (or project-name.code-workspace) file and adds the entry again if necessary (my solution until ST fixed this). 

2. Information about which target is used
The clangd now queries the clang(++) compiler for the intrinsic includes using the information stored in the CMake generated file '\build\Debug\compile_commands.json'.
Problem here:
Unfortunately, clangd cannot do anything with the stored  gcc standard 'TARGET-FLAGS' such as '-mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard'.
This can also be seen from the fact that clangd opens completely incorrect include files.
Solution:
If you now add the correct target via '--target=xyz' in line 37 of the file 'cmake/starm-clang.cmake'.
In my case:

# MCU specific flags
set(TARGET_FLAGS "--target=thumbv7em-st-none-eabihf -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard ${TOOLCHAIN_MULTILIBS}")​

Then: 

• deletes the build folder so that clangd no longer the cache
• and executes 'CMake: Delete Cache and Reconfigure' so that compile_commands.json is regenerated
  clangd works perfectly for me, even with C++ files.

If you like to test with a real project and if you have a NUCLEO-H753ZI board, you can try out my little demo:
https://github.com/TimoEngelmann/nucleo-h753zi-threadx-demo
(dont forget to add clang++ entry after open the project in VSCode)

Best regards,
Timo

[vincent_grenet]

Please be aware that stm32cube-ide-build-cmake-1.40.1.vsix has been released to address C++ concerns.