kadircet added a comment. In https://reviews.llvm.org/D51747#1229066, @sammccall wrote:
> 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"? I agree with checking for -Werror and then providing -Wno-error as well, if -Wdeprecated was not added already. Then keeping it as warnings shouldn't be too much of a problem except the case you mentioned, if user wants to see all diagnostics as a list suddenly they will get deprecations in that list as well :(. 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
