![]() I always feared that using clang instead of our hand-written parser would lead to abysmal performance. switches for plain C, Objective-C support.more advanced code completion: implement function, override virtual function, ….assistants: rename, add type, synchronize signature, ….embedding of clang diagnostics, even supporting navigation between nested diagnostics.basic code completion, including macros. ![]() parsing of full projects, supporting all C++ features that clang supports.We can actually concentrate on making our IDE shine instead of playing catchup with the compiler. Sure, if you count the lines of code in clang/LLVM this won’t stand anymore, but from a maintenance point of view this is a blessing. Add a bit more than 600 lines of tests and you are still a magnitude below our current C++ plugin. status quoĬurrently, the kdev-clang plugin consists of ca. So after the hard work was done, I started contributing by playing the plumber who massages the output of clang-c into the existing KDevelop framework. After some failed attempts in getting clang to parse medium- sized projects at reasonable speeds, he eventually found the magic flags and options. The big advantage is that the latter comes with an API/ABI guarantee which is important for us as a consumer. In his initial prototyping he experimented with the C++ API to clang but eventually found that the clang-c API suffices for our needs. So Olivier started hacking on kdev-clang. Its the magic bullet which we waited for, and which did not exist back when KDevelop 4.0 was started initially. It promises an API for third-party tools to steer a C/C++/Objective-C compiler to their needs. So instead of doing that, my colleague Olivier JG started looking into using clang of LLVM fame instead. The current codebase is big (~55k sloc) and adding support for complicated features such as variadic templates or constexpr is extremely hard and fragile. And indeed, with C++11 and the wealth of changes it came with our language simply fails in many areas. It should not surprise anyone that this is a maintenance nightmare. We have our own C++ parser, we have our own implementation of the C++ template mechanism, we have our own share of “compiler bugs”, …. KDevelop’s current C++ pluginīut a bit of history first: KDevelop’s current C++ language plugin can pull off what it does by essentially implementing (parts of) the C++ standard. Q* that classes have implementations that directly or indirectly depend on host functionality cannot be used in this context.Nested clang diagnostics with browsing support.Long term, most QString uses for file names should be replaced by Utils::FileName, most notably anything involving "Tools" like debugger, profiler and build systems. ![]() This is similar to the concept of an URL, but without some of the syntactic and semantic restrictions URLs have. Utils::FilePath is a wrapper API for a triple of QStrings, a "protocol", a "host" and a "path", enabling us to refer to items that are not bound to the local machine. Use Utils::FilePath instead of QStrings for file names and directory names Exceptions are possible for processes that are clearly always bound to the local development machine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |