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

[FluxPower42]

Hi @vincent_grenet 

thanks for the update.
I can confirm that the --query-driver entry starm-clang++.exe is no longer removed.

Unfortunately, however, I am (still) experiencing the following issue:
The clangd is NOT using the correct paths for the system includes.

I use here the NUCLEO-H753ZI board with STARM_NEWLIB setting. The following paths should be the right:

• C files:
  c:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\newlib\arm-none-eabi\armv7m_hard_fpv5_d16\include
  
  
• C++ files:
  c:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\newlib\arm-none-eabi\armv7m_hard_fpv5_d16\include\c++\v1

But if I hover the mouse over the plain C #include “pwd.h”, I see this path:
C:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\arm-none-eabi\armv4t_exn_rtti\include\pwd.h

Similarly, the path is incorrect when I hovering over the C++ #include <vector>:
C:\Users\[user]\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\lib\clang-runtimes\arm-none-eabi\armv4t_exn_rtti\include\c++\v1\vector

To be absolutely sure that this is NOT the correct path, I can open these headers by clicking the blue Follow link and insert an #error “Test” at the beginning of the file. After this I perform a >CMake: Clean Rebuild , but the build is still error-free. This means: this file is not used for the build but clangd is using this. If I insert now the same #error line into the vector header file in the correct path, the build aborts as expected.

To test this easily, the attached ZIP file contains a very simple project with an application.cpp file.

The following changes/additions have been made:

./nucleo-h753zi-simple.ioc (via STM32CubeMx)
- NUCLEO-H753ZI board file error corrected: LD2 pin changed from PB7 to PE1 (ST: please correct the NUCLEO-H753ZI board file).
- Toolchain/IDE = CMake
- Default compiler/linker = Starm-Clang

./Application
- application.cpp added
- application.hpp added

./Core/Src/main.c
- #include “application.hpp” added to line 24.
- Call appMain(); added to line 95.

./cmake/starm-clang.cmake
- Line 28 set to: set(STARM_TOOLCHAIN_CONFIG “STARM_NEWLIB”)

./CMakeLists.txt
- File application.cpp added to target_sources.
- Directory Application added to target_include_directories.

To use this, you have to generate the files with the STM32CubeMX and open the folder with VSCode (with installed STM32Cube for VSCode extension).


Additional:
It is not clear to me why clangd does not use the correct path.
If I add --log=verbose and "stm32cube-ide-clangd.trace”: “clangd_trace.json” to settings.json,  it is possible to check what information clangd gets.
If I search for "vector" string I get lines with the correct path (in a "message" node):

but also with the wrong path:

@vincent_grenet 
Can you explain me this behaivior and how can I fix this?

[vincent_grenet]

@FluxPower42, thanks for confirming that the first fix is okay with you.

The second issue has been reproduced and confirmed.

For now, I’m able to solve the issue by hacking the .clangd file.

This may help in the short term while we work on a more solid fix. Please confirm.

I will update you once it’s fully resolved.

[unsigned_char_array]

---

@FluxPower42 wrote:

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

---

I tried this, but it failed initially:

[build] Parse error. Expected a command name, got unquoted argument with text
[build] "ÔÇï".

It turns out there is an invisible non-ascii character(Zero Width Space) after your closing parenthesis! Removing it fixed it for me. Can you please update your code so it won't fail for others too?

This is the corrected line:

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

This is what I have.

set(FPU_FLAGS "-mfpu=fpv4-sp-d16 -mfloat-abi=hard")
set(CPU_FLAGS "--target=armv7m-none-eabi -mcpu=cortex-m4")
set(TARGET_FLAGS "${CPU_FLAGS} ${FPU_FLAGS}")

[FluxPower42]

Hi @vincent_grenet 

How is the issue status of the incorrect path for clangd when
set(STARM_TOOLCHAIN_CONFIG "STARM_NEWLIB")
is set in the file ./cmake/starm-clang.cmake ?

I have updated my demo project (https://github.com/TimoEngelmann/nucleo-h753zi-threadx-demo) by using the current versions:
- STM32CubeMX v6.17.0
- STM32CubeIDE for Visual Studio Code v3.8.0.

Unfortunately, there is still a mismatch:

• For a C++ #include <vector> (see application.cpp file in my demo)
  • clangd uses this file:
    D:\dev\Tools\ST\STM32CubeRepo\bundles\st-arm-clang\21.1.1+st.7\lib\clang-runtimes\arm-none-eabi\include\c++\v1\vector
  • However, the Clang compiler uses this file:
    D:/dev/Tools/ST/STM32CubeRepo/bundles/st-arm-clang/21.1.1+st.7/bin/../lib/clang-runtimes/newlib/arm-none-eabi/include/c++/v1/vector
    
    
• For a C #include <stdbool.h> (see main.c file in my demo)
  • clangd uses this file:
    D:\dev\Tools\ST\STM32CubeRepo\bundles\st-arm-clangd\21.1.0+st.2\lib\clang\21\include\stdbool.h
  • However, the Clang compiler uses this file:
    D:/dev/Tools/ST/STM32CubeRepo/bundles/st-arm-clang/21.1.1+st.7/lib/clang/21/include/stdbool.h

  
If I switch to set(STARM_TOOLCHAIN_CONFIG "STARM_PICOLIBC")
the C++ include is now correct handled. But the C include not!
 
I think there are two issues:

1. the special path for newlib is not handled by clangd.
2. the different versions of st-arm-clang and st-arm-clangd in 
   STM32CubeIDE for Visual Studio Code:
   

Can you please check this?

Best regards,
Timo