This extension is now obsolete and won't be maintained. The C/C++ extension has implemented a more stable and faster semantic highlighter (as of June available in C/C++ Insiders update channel). I hope that people still found this extension useful in the meantime. :)
Clang highlighter for C++
Before
After
- Python 3
- LLVM
After installing, simply go to the settings and change C++ Recolored > Libclang Path (cppRecolored.libclangPath) to the path to the LLVM dynamic library on your system (libclang.dll/so/dylib). Note on Windows; this should be LLVM 32-bit.
It is also recommended that you change the highlighting color to match your theme (C++ Recolored > Type Color or cppRecolored.typeColor).
Expect this extension to become obsolete when either an API for VSCode semantic highlighting is implemented or when the LSP implements semantic highlighting, both of which give the C/C++ extension an opportunity to seamlessly implement this feature.
Can I use a compilation database to provide flags?
Yes, in fact C++ Recolored automatically looks for compile_commands.json in the build directory of your project (this directory can be changed in the settings).
Can I manually provide flags?
Yes, in the case where C++ Recolored cannot find compile_commands.json in the specified directory, it will use fallback flags (cppRecolored.fallbackFlags) instead, which can be project specific by using the workspace settings.json.
Why aren't header files being highlighted?
Make sure you're using the latest version of LLVM (which adds the functionality of automatically finding corresponding header file flags in a compilation database).
IF you're using an older version of LLVM; this is usually because the header file is not defined in the compilation_database.json and there are no fallback flags specified. More specifically, if the header file ends in .h and cppRecolored.fallbackFlags does not contain ["-x", "c++"], it will be treated as a C header.
Why isn't it instant?
To provide true semantic highlighting C++ Recolored utilizes libclang, which parses the file from the perspective of a compiler. So far, to maximize performance, compilation database flags are cached, libclang re-parses, and existing highlights are retained for each file in memory.
Why do I need to save to see highlighting changes?
This is so that it is not parsed unnecessarily (for example when a line is incomplete and therefore contains invalid syntax). However, the libclang API does support in-memory (unsaved file buffer) parsing, which may be implemented in the future.
- Libclang header/source switcher to provide flags for headers using complementing source file
- Unsaved file support
- Move to advanced highlighting API (if it is ever implemented, right now the Decorations API is used, which is rather unsuitable for this sort of use)