[PATCH] D51747: [clangd] Implement deprecation diagnostics with lower severity.
Ilya Biryukov via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 10 06:29:02 PDT 2018
ilya-biryukov added a comment.
> I also agree with you regarding options. A pattern I've observed (in some infamous large codebase ;) is that warnings for deprecated symbols are disabled in the compile command as they can introduce too much noise during build, although it would make sense to show these warnings when user edits the code (most of the time). I think there can be other diagnostics that are more desirable as editor diagnostics than as compiler warnings/errors.
What kind of option are we talking about? (1) A flag to clangd or (2) a completely different way to expose deprecated methods (i.e. **not** diagnostics)?
If (1), users already have a way to enable this by adding this flag when producing `compile_commands.json`. Not sure if adding a flag to clangd for tampering with one special-cased clang arg carries its weight, however produces `compile_commands.json` can set the flags they care about.
(2) does seem useful and https://reviews.llvm.org/D51724 is a good example of it. As we have discussed recently, we could expose this as a form of semantic syntax highlighting (not available in clangd or LSP currently).
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D51747
More information about the cfe-commits
mailing list