[clang-tools-extra] d2c9c91 - Move from a long list of checkers to tables

[Alexander Kornienko via cfe-commits]

On Wed, Jan 8, 2020 at 2:45 PM Sylvestre Ledru <sledru at mozilla.com> wrote:

> Le 08/01/2020 à 14:14, Alexander Kornienko a écrit :
> > [adding the list back]
> >
> > This list is one of the places that would be quite boring and
> error-prone to update manually. I'd strongly prefer to have an automatic
> way of updating it. Detecting whether a check has a fix might be not an
> easy task though. Maybe the script could use some simple heuristic to
> detect obvious ways
> > to add a fix (e.g. search for /FixItHint::Create.*\(|fixit::create.*\(/
> - maybe in non-comment lines, if it turns out to be feasible - in the
> check's source files) and mark these checks as having fixes, the ones that
> don't have the word "fix" most probably don't generate a fix, the rest are
> > "unknown" (and these should be fixed by hand). WDYT?
>
> This is basically what I have done (greping the code to see if there is an
> autofix).
>
> But I missed modernize-make-unique as it doesn't contain any reference to
> fixit :/
>
> (I could just update modernize/MakeUniqueCheck.cpp to add a comment)
>

This is one option. An alternative is to add new checks with an "unknown"
value in this column in the table, which could then be fixed manually. The
first option would allow the `add_new_check.py --update-docs` to work more
similarly to how it does now. However, for new checks we'll probably have a
manual step before sending a patch anyway, since the first run of
add_new_check.py only generates a template that will be changed to either
generate a real fix or not.


>
> Cheers,
>
> Sylvestre
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200108/f41da4bd/attachment.html>