Difficultuies using `clangd`

[diggit]

Hi,
I am using clangd extension in the vscode, because it is OSS, but mainly is can handle large projects with good performance.

First issue is that modm copies only gcc related cmsis sources, because only those are listed in here https://github.com/modm-io/modm/blob/develop/ext/arm/core.lb

There also an issue with partial template specialization, but that could be clang issue llvm/llvm-project#156242
(According to GH copilot, the code is not valid, but GCC is permissive. Offered solution is not complex, but I am not sure how modm feels about LLM generated code...)

Then there is a collision of modm __atomic_is_lock_free and clangs builtin function.
Why does modm have to re-implement from standard library anyway? Is that because of AVRs? I've been using standard library for quite some on cortex-m device without issues.

modm iostream compilation fails on operator re-declaration. It looks like this statement is not true with clang: https://godbolt.org/z/br9db9n6a

this could be a solution

	template<bool enable = not std::is_same_v<int, int32_t>>
	inline std::enable_if_t<enable, IOStream>& operator << (const int& v)
	{ writeIntegerMode(static_cast<int32_t>(v)); return *this; }
	template<bool enable = not std::is_same_v<unsigned int, uint32_t>>
	inline std::enable_if_t<enable, IOStream>& operator << (const unsigned int& v)
	{ writeIntegerMode(static_cast<uint32_t>(v)); return *this; }

[salkinium]

Clang and its related tools are sadly not supported. There are no quick fixes for your problems other than to make the entire code base compatible with LLVM and its standard C++ library implementation.

For a long time LLVM did not have the same features as GCC for embedded C++ development, so we never supported it. But I see now that the Arm Toolchain for Embedded has been merged into the main toolchain repo and is ≥v20. It seems doable to migrate from GGC to LLVM, but I'm currently not motivated to do so, since GCC works fine (mostly) and we would also have to support AVR somehow.

[salkinium]

See also this discussion, which also tried to use LLVM tools

[salkinium]

Why does modm have to re-implement from standard library anyway?

These are all compiler instrinsics, they have nothing to do with C or C++.
They add support for atomics on AVR and Cortex-M0/M0+/M23, which both lack load/store exclusive instructions, and also adds support for atomics larger than 8-bit (AVR) and 32-bit (Cortex-M) by disabling interrupts.

This is not generally implemented by the compiler, as it doesn't know the details of the device well enough. For example, for RP2040 with a dual-core Cortex-M0 setup, both cores must disable interrupts, thus you must sync control flow in both cores somehow.

[diggit]

Clang and its related tools are sadly not supported. There are no quick fixes for your problems other than to make the entire code base compatible with LLVM and its standard C++ library implementation.

Fixing those mentioned in the first post solved the problem for me, for now.

Well, that builtin re-declaration error still confuses me. Is GCC just ok with that? (and my current "fix" was just deleting that function)

Would you consider merging at least some llvm compatibility fixes? Full support for llvm is not needed to have at least clangd working...

[salkinium]

Is GCC just ok with that?

Yes, GCC requires that function. LLVM implements different intrinsics for Cortex-M.

Would you consider merging at least some llvm compatibility fixes? Full support for llvm is not needed to have at least clangd working...

If it's not too many, it's fine. But you're using llvm for code completion and still compiling with gcc, so the code needs to work for both.