<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 5:14 PM Piotr Padlewski <<a href="mailto:piotr.padlewski@gmail.com">piotr.padlewski@gmail.com</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">Sound like a killer feature for YouCompleteMe!</div></blockquote><div><br></div><div>+ben jackson, who said claimed that ycm is well prepared for this in principle.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote">2016-06-01 16:43 GMT+02:00 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>:<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><div dir="ltr">On Wed, May 25, 2016 at 5:24 PM Benjamin Kramer 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">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></blockquote><div><br></div></span><div>Will be interesting to expose that in libclang. Given that it seems hard for an editor to decide how to insert #includes correctly (unless we somehow also expose clang-format).</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div></span><div>Given the complexity of the current typo correction code (yikes!), introducing this for an alternative warning might be a good idea.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div></span><div>An open question is: <span style="line-height:1.5">for more interesting replacements, like includes, where do we want the decision on how to format / where exactly to insert the #includes to be made; if we don't start with supporting #include insertion and instead focus on alternatives first, that might not actually be a problem, though</span></div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<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></span></div></div>
<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>
<br></blockquote></div><br></div>
</blockquote></div></div>