<div dir="ltr">It was the plan from the beginning of the design of clang-tidy to eventually make tools like clang-modernize and checks like the redundant-cstr-check part of it.<div><br></div><div><div class="gmail_quote">On Fri Jan 30 2015 at 10:33:31 PM Mario Lang <<a href="mailto:mlang@delysid.org">mlang@delysid.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard <<a href="mailto:legalize@xmission.com" target="_blank">legalize@xmission.com</a>> writes:<br>
<br>
> Should remove-cstr-calls be migrated to a clang-tidy check?<br>
<br>
I've thought the same in the past, and I think yes.  It would fit clang-tidy.<br>
<br>
> What about clang-modernize?  Are the transformations there considered<br>
> to be of the lint variety?  Should those transformations be migrated<br>
> to clang-tidy as well?<br>
<br>
I think clang-modernize should stay separate, as it doesn't strictly<br>
search for programming errors of inefficiencies.  It is really a source-code upgrade<br>
tool, something you run once you've decided to switch your standard<br>
level.  One might argue that clang-modernize could be run as part of<br>
clang-tidy, if LangOpts specified CPlusPlus11, but I am not convinced.<br>
OTOH, the check-enabling syntax of clang-tidy makes it rather easy to<br>
run modernize as part of it... "clang-tidy -fix -checks=modernize"<br>
wouldn't be particularily hard to type.  But keep in mind that clang-modernize seems<br>
to be able to run without a compilation database, which doesn't apply to<br>
clang-tidy.<br>
<br>
--<br>
CYa,<br>
  ⡍⠁⠗⠊⠕<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div>