[cfe-dev] clang-tidy FixItHint::CreateRemoval -- trailing semicolon stays

[Piotr Dziwinski via cfe-dev]

On 04/02/16 18:28, Tim Halloran wrote:
> On Thu, Feb 4, 2016 at 11:37 AM, Piotr Dziwinski <piotrdz at gmail.com 
> <mailto:piotrdz at gmail.com>> wrote:
>
>     Yes, you can add many fix it hints for a given diagnostic. For
>     example:
>
>       auto Diagnostic = diag(Loc, "diagnostic");
>       Diagnostic.AddFixItHint(FixItHint::CreateInsertion(/*...*/));
>       Diagnostic.AddFixItHint(FixItHint::CreateRemoval(/*...*/));
>
>     This can also be achieved through overloaded operator<< which is
>     just a wrapper for the same function calls.
>
>
> This works during the same call to "check"  However if I stash the 
> pointer to the "Diagnostic" variable (e.g., in a map) and lookup and 
> use the reference later I'm getting a core dump. I'm guessing that is 
> because the object created by "diag()" call is not intended to be stashed.

As far as I know, diagnostics are meant to be generated on the fly and 
pushed out to the diagnostics handler as soon as possible.
I don't know if it's possible to store any long-lived reference to them.

> Is there a way to get a clang::DiagnosticBuilder object that can be 
> safely stashed?
>
> What I am doing is first removing somthing like
>
> using namespace sl;
>
> from the code
>
> then adding qualifiers for each use, e.g., "foo" becomes "sl::foo"
>
> so the "add qualifier" part gets identified in later calls to "check"

As a workaround, you can try a different approach - store additional 
state in your check class and update it on each check() call.
Then, once you have complete context information about the code you want 
to change, create a full diagnostic with all needed data.

This is actually what I do in some of my checks, especially the 
localizing variables check that I'm still working on:
https://github.com/piotrdz/clang-tools-extra/blob/master/clang-tidy/readability/LocalizingVariablesCheck.cpp

Best regards,
Piotr Dziwinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160204/4e80d5fb/attachment.html>