carlosgalvezp wrote: > that it is kept for future deprecations (and would therefore need to be > general enough)
Yes, that was my thought, some general-purpose mechanism for deprecation warnings, for example `--disable-deprecation-warnings`, `--no-deprecation-warnings`, etc. The use case I have in mind is when e.g. a 3rd-party .cpp file is pulled in via the compilation database, normally it will be analyzed via its own .clang-tidy file that normally one doesn't have control over. One could however argue that one should probably only analyze own source files, not 3rd-party ones. One probably also doesn't want to disable deprecation warnings globally just because a 3rd-party triggers them - it'd be better to filter out such 3rd-party code from analysis. Perhaps we can just land this as is for now and introduce the escape hatch if we get feedback indicating it's needed? https://github.com/llvm/llvm-project/pull/121057 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
