Eclipse CDT is perfect for embedded developing, with no real competitor. Given the compilation command line output, its buildin parser can understand very large code base (the linux kernel, chrome browser et) efficiently and precisely, long before llvm-based tools appeared.
No need to configure tons of vim plugins, you have tons of powerful features in the default settings, like type hierarchy, call hierarchy, debugging etc.
You may have heard that Eclipse CDT didn't work out of the box. To make it work, you only need to understand how its parser work and how to properly set it up. It can support all build system, only if the build system can output the build command line output. It worked for almost every project I have encountered in the past nine years.
> Eclipse CDT is perfect for embedded developing, with no real competitor.
ugh, having used cdt a bit, it is terrible when compared to qt creator. It's pretty easy to make, say, an AVR-GCC toolchain and use it with CMake, which will then work ootb with QtC like any other C/C++ project.
A large portion of problems of using Eclipse CDT is that the Language Setting Provider is NOT properly set. See the MDN article mentioned in another comment for more on this. CDT parser is NOT bound to any build system. You can make it work with almost any build system, provided the build system had legitimate command line output. And CDT's performance is better than most of the LLVM/LSP-based tools. LSP based solution has not matured enough to be a real competitor.
I remembered that around 2011 I've tried Qt Creator, and it was a bad experience since I did know how to cope with several build systems. I've no idea how QtCreator's multiple build system support is now. For the same reason, CLion is not good enough to compete with CDT.
LLVM/LSP/Vscode/CLion, these are all exciting and have a lot of fans. Unfortunately, none of them is good enough in this subfield.
No need to configure tons of vim plugins, you have tons of powerful features in the default settings, like type hierarchy, call hierarchy, debugging etc.