clangd
[Feature request]Ability to switch between warning, hint & info VS Code linting channels for Clang-tidy checks and Clang -w warnings
So VS Code has several linting channels for language servers, errors, warnings, info & hints.
So it would be awesome if we could categorize the clang tidy checks and clang -w warnings (prefferably for both clang and clang-tidy separately or maybe even on a per warning basis?) to make better use of this system.
An example of what using a lot of clang-tidy checks would look like currently in vs code:
If you look at the problems section in the bottom right you can see that most of these warnings would probably be better off categorized as hints or info as the triggers arent necessarily prone to error or even poor code style.
Thanks for reading <3
I feel this is something that could be controlled via Config in a similar way to Diagnostics->Suppress
Diagnostics:
AGoodNameForAnOptionToLowerDiagnosticsToHintLevel:
- Wunused-parameter # clang warning flags
- performance-noexcept-move-constructor # clang-tidy warnings
I feel this is something that could be controlled via Config in a similar way to
Diagnostics->SuppressDiagnostics: AGoodNameForAnOptionToLowerDiagnosticsToHintLevel: - Wunused-parameter # clang warning flags - performance-noexcept-move-constructor # clang-tidy warnings
Yep, I think that would be the most optimal solution (and even more ideally if there were one subcategory of Diagnostics per channel, so one one for info & one for hint (and maybe also error?))
Almost the whole challenge here is somewhere defining a good mapping from diagnostic kinds to severity levels in a way that is reasonable to maintain. (There are hundreds of warnings and clang-tidy checks).
Punting this to the user by putting it in config is not a solution that will help a meaningful number of users.
Almost the whole challenge here is somewhere defining a good mapping from diagnostic kinds to severity levels in a way that is reasonable to maintain. (There are hundreds of warnings and clang-tidy checks).
Punting this to the user by putting it in config is not a solution that will help a meaningful number of users.
As listed on https://clang.llvm.org/extra/clang-tidy/ all clang tidy checks are categorised quite well out-of-the-box.
Perhaps one could decide which channel each clang-tidy check belongs to based on these groupings/categorizations as default (and then using the config.yaml/.clangd let the user make any changes he/she may like)?
As listed on https://clang.llvm.org/extra/clang-tidy/ all clang tidy checks are categorised quite well out-of-the-box.
They are (mostly) categorized by the domain of code they apply to, not by the "forcefulness" or something of the diagnostics provided.
Useful ways to make progress here:
- describe when you'd want a diagnostic categorized as warning vs hint vs info
- come up with some examples
- try to turn these examples into rules that can be generalized, so we have a scalable way to do this for all diagnostics
If we can't provide useful defaults, then a fine-grained customization point for this is not going to be worth maintaining.
As listed on https://clang.llvm.org/extra/clang-tidy/ all clang tidy checks are categorised quite well out-of-the-box.
They are (mostly) categorized by the domain of code they apply to, not by the "forcefulness" or something of the diagnostics provided.
Useful ways to make progress here:
- describe when you'd want a diagnostic categorized as warning vs hint vs info
- come up with some examples
- try to turn these examples into rules that can be generalized, so we have a scalable way to do this for all diagnostics
If we can't provide useful defaults, then a fine-grained customization point for this is not going to be worth maintaining.
Not sure if Im the right person to decide this, suggestions are welcome <3
Somebody over in the LLVM Discord suggested:
"clangd.clang-tidy.diagnosticSeverity": {
"bugprone*": "WARN",
"clang-analyze*": "WARN",
"concurrency*": "WARN",
"cppcoreguidelines*": false,
"modernize*": "INFO",
"performance*": "WARN",
"portability*": "INFO",
"readability*": "INFO"
}
}
As a potential default, so Im not the only one thinking these categories could be useful for defaults.
Again, to me this doesnt really seem like a large issue, one could use these generalized categories as a "base-plate" and then make smaller changes to it later on (and this is also something one could improve over time imo, nothing is perfect at first).
Alternatively if it would be too difficult implementing @njames93 suggestion I would still appreciate some simple settings like:
"clangd.diagnosticChannels.clang-tidy": "Info",
"clangd.diagnosticChannels.clang": "Warning",
or
"clangd.diagnosticChannels.clang-tidy.portability": "Info",
"clangd.diagnosticChannels.clang-tidy.modernize": "Info",
"clangd.diagnosticChannels.clang-tidy.bugprone": "Warning",
in the settings.json file or equallent settings in config.yaml (the latter of which is probably better option since it wouldnt require changes for each IDE)
Apologies for inconvenience, I do not have the capacity right now to implement this. If anyone is willing to propose a working solution without much complexity and maintenance cost I'd be happy to review it.
