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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
