<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 1, 2016 at 11:46 AM, Manuel Klimek via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Wed, Jun 1, 2016 at 6:59 PM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think the general idea in Clang has been that fixits on a warning must be behavior-preserving</div></blockquote><div><br></div></span><div>Typo-correction is not behavior preserving, though?</div></div></div></blockquote><div><br></div><div>We do not issue typo-correction FixItHints on warnings. (Well, actually, I think we have a single warning that does this, but it's a bug.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> (because we must recover from errors (and warnings can be errors) as if the fixit were applied, so that downstream diagnostics/fixits are applicable). We use notes to express other fixit alternatives (or any non-behavior preserving fixits if there's no behavior-preserving fixit we care to give). Should we not be using notes as alternatives in the include fixer tool?</div></blockquote></div></div></div></div></blockquote><div><br></div><div>+1</div><div><br></div><div>This is our usual approach for the case where there are multiple possible fixes: one note per possible approach, with the FixItHints for that approach attached to that note. Is there some reason why this doesn't apply in your case?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is there some semantic information missing from multiple notes with fixits that we could improve instead? (that would maintain/improve the existing command line usability) to accurately describe which notes form the set of alternative solutions? (so that an IDE, etc, could collapse/render them differently, perhaps?)</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 8:24 AM, Benjamin Kramer via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
one of the longer-term goals for the include fixer tool is integration<br>
into the editor. This could piggy-back on the existing support for<br>
FixIts but there is one big missing feature. It is often not perfectly<br>
clear what #include a user wants or if it's just a typo that needs<br>
correcting, we cannot express that with the current FixIts. A Clang<br>
diagnostic can have multiple FixIts but they are meant to be applied<br>
together, for this case we'd need alternative groups of FixIts.<br>
<br>
There's also a fair number of existing clang warnings that could<br>
benefit from this, typo correction is an obvious one but there's also<br>
a bunch of disambiguation warnings that can have fix-its in both<br>
directions, for example '= in if statement' (turn into '==' or add<br>
double parens) or '&& within ||' where parens can be added both ways.<br>
The functionality-preserving FixIt is the canonical one for those<br>
warnings but having an alternative would be useful, too.<br>
<br>
Of course this won't work on the terminal. FixIts are already hardly<br>
usable there, so this will be a feature for IDEs, code review tools<br>
etc.<br>
<br>
My current plan is:<br>
1. Have DiagnosticEngine and friends keep a vector of vector of<br>
FixItHint instead of a flat FixIt vector<br>
2. Thread the change through clang, using alternative '0' in most<br>
places to avoid breaking existing functionality.<br>
3. Add methods to add alternative FixItHints to a diagnostic<br>
4. Expose this via a new libclang API. Any diagnostic rendering code<br>
in clang will stay the same.<br>
<br>
There's interest from YouCompleteMe for providing an interface for<br>
this that lets the user pick a fix out of multiple ones, and I guess<br>
other IDEs can put it to great use too.<br>
<br>
Any input on this approach or concerns?<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>