[Development Experience] Non standard C++23

[YandiBanyuKarimaWaly]

Compiles just fine

As stated on the title, this is a DX issue. Everything compiles just fine and working as intended. It's just the red squiggly line that annoys me during development.

tl;dr: Some constexpr is non-standard and rely on implementation details

• OS: x86 Arch Linux
• IDE/Editor: VSCode
• Extension: CMake Tools + clangd
• Build: CMake + Ninja + GCC14 arm-none-eabi
• Target Board: Weact F411

Some of you might've noticed the problem (mixing clang and GCC). I've configured VSCode to use clangd intellisense since I prefer it and after some rough start (including manually copying the required cmsis_clang header), it all works fine. However, when I tried to use encoder driver, I encountered this error from clangd intellisense: clang(non_constant_constraint_expression). Apparently std::pow<T, U> is not a constexpr in C++23. Here is the offending line:

requires (std::numeric_limits<DeltaType>::max() < std::pow(2, 31))

clangd flags:

"clangd.arguments": [
  "--query-driver=/usr/bin/*"
]

Since clangd complained that the compilation has unknown flags, I've removed it on the .clangd file:

CompileFlags:
  Remove: [-fno-move-loop-invariants, -fno-split-wide-types, -fno-tree-loop-optimize]

Anyways, I tried to change the CMSIS header since maybe it will help resolve the issue somehow, but nope. My current hack is just replacing the value directly to remove the red squiggly line.

Edit: I just realized I forgot to ask the question. So my question is, does modm has any plan to support using clangd?

[salkinium]

Paging our C++ expert @chris-durand…

Our reference compiler is GCC12 from ARM which comes with a libstdc++ (we also have our own for avr-gcc).
Generally if the CI fails on a PR then we check what's wrong, but clangd is not part of our CI, so this is the first time I'm hearing that std::pow not being constexpr could be a problem 😜.

So my question is, does modm has any plan to support using clangd?

It could be nice to have a better syntax check in our CI, however, since we're using GCC to compile, I'm not entirely sure how compatible a LLVM solution would be (as you discovered the compile flags are a little incompatible). If you can get it into our CI support for clangd will be enforceable, but if it involves too much manual labor, then probably not. We're just a small group of volunteers here, there's no corporate support behind modm.

I would support adding LLVM compiler support though! To my knowledge ARM does not actively develop on GCC anymore, only maintains upstream support. They put all their new fancy stuff into LLVM now.
In theory, a lot of the compiler specific things are at least somewhat encapsulated in modm, so it should be a limited effort. The official project for that is here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. It seems to actually have progressed a little since the last time I checked on it, so it might actually be usable now?

[YandiBanyuKarimaWaly]

Yeah, I figured that is the case since the docs mentions GCC installation but is worth asking lol. Anyway, thanks for the answer. Might need to specify in the docs tho that GCC is required since it has the compiler extension needed.