sammccall added a comment. In https://reviews.llvm.org/D51747#1228919, @ilya-biryukov wrote:
> > Most of the value of adding an option is: if someone complains, we can tell > > them to go away :-) One possible corollary is: we shouldn't add the option > > until someone complains. I'm not 100% sure about that, though - not totally > > opposed to an option here. > > Any thoughts on tampering with provided compile args in the first place? Is > it fine for clangd to be opinionated about the warnings we choose to always > show to the users? > E.g. I'm a big fan of various uninitialized warnings, but nevertheless don't > think clangd should force them on everyone. A few thoughts here: - does CDB describe user or project preferences? unclear. - "show this warning for code I build" is a higher bar than "show this warning for code I edit". So CDB probably enables too few warnings. - Some warnings play well with -Werror (like uninit warnings), some don't (like deprecated). -Werror projects often disable interesting warnings. I'm not sure we should strictly follow the CDB, but the bar to override it should probably be high. Maybe the (default) behavior here should be "add -Wdeprecated -Wno-error=deprecated if -Werror is set"? 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
