alexfh added a comment. In https://reviews.llvm.org/D36051#825428, @xazax.hun wrote:
> Maybe instead of a separate list, having this information like yes/no column > in a table in the original is more user-friendly. What the better format is would depend on for which purpose do we want to expose this information and how it will likely be used. Does anyone have a clear idea about this? Another point is that it would be much better if we come up with a reliable way to keep this information up-to-date. I currently see a few ways to find which checks are able to issue fix-its: 1. Analyze lit tests: each test contains the name of the check and most of them use the check_clang_tidy script and CHECK-FIXES prefix to verify fixes. This only works for checks that have lit tests, but the good thing is that we'll only list checks that have test for fixes ;) 2. Analyze checks' source code for the presence of FixItHint or utility functions that generate it. 3. Require checks to issue a specific call (or be registered with a certain flag) to enable fix-its. This way we'll have this information in runtime and will be able to expose it in -list-checks. 4. Analyze checks' documentation and require it to contain a certain pattern, if the check supports fixes. But first we need to answer the question on how this information is going to be used. https://reviews.llvm.org/D36051 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
