<div dir="ltr"><div dir="ltr">On Wed, Jan 8, 2020 at 2:45 PM Sylvestre Ledru <<a href="mailto:sledru@mozilla.com">sledru@mozilla.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 08/01/2020 à 14:14, Alexander Kornienko a écrit :<br>
> [adding the list back]<br>
><br>
> 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 <br>
> 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 <br>
> "unknown" (and these should be fixed by hand). WDYT?<br>
<br>
This is basically what I have done (greping the code to see if there is an autofix).<br>
<br>
But I missed modernize-make-unique as it doesn't contain any reference to fixit :/<br>
<br>
(I could just update modernize/MakeUniqueCheck.cpp to add a comment)<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
<br>
Sylvestre<br>
<br>
<br>
</blockquote></div></div>