clangd config for ide integration

[relzp]

adds files (compile_flags.txt, .clangd) to configure clangd so that the clangd extension can be used in vscode (or anywhere with clangd support) for code highlighting, code completion, etc.
the config also does the following:

1. suppresses warnings about unused includes, since:

• we use includes like module.c -> module.h, where module.h includes the symbols that both the header and source need
• the stm32 library also uses includes like this, for example we define the modules we want and then include stm32h7xx_hal.h, instead of each individual module (e.g stm32h7xx_hal_spi.h)

2. suppresses errors from the stm32 libraries (under Drivers/)

currently, it uses the default compiler installed on the user's machine, not the target architecture (arm) compiler, for simplicity and so that each user doesn't have to install the cross-compiler

[Claegtun]

Do these files only affect vscode, not the actual compiling of the binary in CubeIDE?

[Claegtun]

Does this file affect or influence the parent .clang files, i.e. .clang-format and .clang-tidy?

[relzp]

Nope, .clangd is only used by clangd, .clang-format is only used by clang-format, .clang-tidy is only used by clang-tidy, and they don't have any connection to each other

clang-format formats files, clang-tidy lints code to detect errors, whereas clangd is a language server used to integrate code into an IDE with code completion, compile errors, etc.

I'm not sure if there's any reason to use clang-tidy if using clangd, clangd seems to provide a superset of clang-tidy's functionality, as well as proper IDE integration

[relzp]

Correction, the vscode clangd extension actually embeds both: clang-format (reads .clang-format) providing formatting, and clang-tidy (reads .clang-tidy) which

provides extra hints about code problems: bug-prone patterns, performance traps, and style issues.

[Claegtun]

As long as the extension doesn't override those parent files or do something silly, then it should be fine.

[relzp]

Do these files only affect vscode, not the actual compiling of the binary in CubeIDE?

Yeah, both .clangd and compile_flags.txt are files specific to clangd (the language server, not to be confused with clang, the compiler)

[JohanneMontano]

adds files (compile_flags.txt, .clangd) to configure clangd so that the clangd extension can be used in vscode (or anywhere with clangd support) for code highlighting, code completion, etc. the config also does the following:

1. suppresses warnings about unused includes, since:


* we use includes like module.c -> module.h, where module.h includes the symbols that both the header and source need

* the stm32 library also uses includes like this, for example we define the modules we want and then include stm32h7xx_hal.h, instead of each individual module (e.g stm32h7xx_hal_spi.h)


2. suppresses errors from the stm32 libraries (under Drivers/)

currently, it uses the default compiler installed on the user's machine, not the target architecture (arm) compiler, for simplicity and so that each user doesn't have to install the cross-compiler

I dont like the idea of suppressing errors. They should be addressed, rather than being ignored. Either leave them alone or actually solve the errors. If something actually goes wrong and the error messages could have told us something about it, it could lead people to waste lots of time

[relzp]

I definitely agree, and I'm glad you mentioned it actually, because when I wrote those it was giving me a bunch of errors that seemed unavoidable due to not being in the stm32cubeide environment, but I've tried removing the lines just now, and I'm not getting any errors at all, so I think I actually solved the errors in a later commit by providing the proper defines in compile_flags.txt (specifically STM32H753xx).
I'll remove the error suppressing stuff