<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hopefully it isn't just bluster. We're very keen for refactoring etc. tools and more developer utilities in YCM so I've sort of promised to implement it if it goes into libclang :)</div><div><br>On 1 Jun 2016, at 11:19, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br><br></div><blockquote type="cite"><div><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>
</div></blockquote></body></html>