<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Just following up on this thread: Yes it totally makes sense.</div><div class=""><br class=""></div><div class="">Previously we were ignoring any fixit hints attached to “child” diagnostics (in libclang parlance). I’ve made a quick change to YCM which:</div><div class=""> - extracts fixit hints from chid diagnostics (typically notes)</div><div class=""> - provides a UI in Vim to select between them when multiple fixits are available for a given diag.</div><div class=""><br class=""></div><div class="">It works nicely for the case you mention below: <a href="https://files.gitter.im/Valloric/YouCompleteMe/l6FD/YCM-fixit-multiple-choice2.gif" class="">https://files.gitter.im/Valloric/YouCompleteMe/l6FD/YCM-fixit-multiple-choice2.gif</a>. Incidentally, this also improves the workflow when there are multiple diagnostics on the line.</div><div class=""><br class=""></div><div class="">With regard to Manuel’s question about who should be responsible for choosing the insertion location for, say includes, I’d be keen for clang to make that decision, as it has better knowledge about code than the IDE (consider objective-c vs. c vs…). It also requires less work from each client implementation.</div><div class=""><br class=""></div><div class="">That said, in YCM we already have some stuff for working out where to put automatically generated import declarations for c-sharp, and we even provide hooks for the user to tune to their taste, so there is an argument that where the decision is arbitrary, the client should offer the user more flexibility.</div><div class=""><br class=""></div>On 2 Jun 2016, at 12:00, Benjamin Kramer <<a href="mailto:benny.kra@gmail.com" class="">benny.kra@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="">Ben, would it make sense for YCM to provide the user with choice when<br class="">there are notes attached to a diagnostic? You can see this in action<br class="">for -Wparentheses:<br class=""><br class="">$ cat t.c<br class="">void f(int foo, int bar) {<br class=""> if (foo = bar) {}<br class="">}<br class=""><br class="">$ clang t.c<br class="">t.c:2:11: warning: using the result of an assignment as a condition without<br class=""> parentheses [-Wparentheses]<br class=""> if (foo = bar) {}<br class=""> ~~~~^~~~~<br class="">t.c:2:11: note: place parentheses around the assignment to silence this<br class=""> warning<br class=""> if (foo = bar) {}<br class=""> ^<br class=""> ( )<br class="">t.c:2:11: note: use '==' to turn this assignment into an equality comparison<br class=""> if (foo = bar) {}<br class=""> ^<br class=""> ==<br class=""><br class="">On Wed, Jun 1, 2016 at 8:59 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" class="">richard@metafoo.co.uk</a>> wrote:<br class=""><blockquote type="cite" class="">On Wed, Jun 1, 2016 at 11:46 AM, Manuel Klimek via cfe-dev<br class=""><<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">On Wed, Jun 1, 2016 at 6:59 PM David Blaikie via cfe-dev<br class=""><<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">I think the general idea in Clang has been that fixits on a warning must<br class="">be behavior-preserving<br class=""></blockquote><br class=""><br class="">Typo-correction is not behavior preserving, though?<br class=""></blockquote><br class=""><br class="">We do not issue typo-correction FixItHints on warnings. (Well, actually, I<br class="">think we have a single warning that does this, but it's a bug.)<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">(because we must recover from errors (and warnings can be errors) as if<br class="">the fixit were applied, so that downstream diagnostics/fixits are<br class="">applicable). We use notes to express other fixit alternatives (or any<br class="">non-behavior preserving fixits if there's no behavior-preserving fixit we<br class="">care to give). Should we not be using notes as alternatives in the include<br class="">fixer tool?<br class=""></blockquote></blockquote><br class=""><br class="">+1<br class=""><br class="">This is our usual approach for the case where there are multiple possible<br class="">fixes: one note per possible approach, with the FixItHints for that approach<br class="">attached to that note. Is there some reason why this doesn't apply in your<br class="">case?<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">Is there some semantic information missing from multiple notes with<br class="">fixits that we could improve instead? (that would maintain/improve the<br class="">existing command line usability) to accurately describe which notes form the<br class="">set of alternative solutions? (so that an IDE, etc, could collapse/render<br class="">them differently, perhaps?)<br class=""><br class="">On Wed, May 25, 2016 at 8:24 AM, Benjamin Kramer via cfe-dev<br class=""><<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">Hi all,<br class=""><br class="">one of the longer-term goals for the include fixer tool is integration<br class="">into the editor. This could piggy-back on the existing support for<br class="">FixIts but there is one big missing feature. It is often not perfectly<br class="">clear what #include a user wants or if it's just a typo that needs<br class="">correcting, we cannot express that with the current FixIts. A Clang<br class="">diagnostic can have multiple FixIts but they are meant to be applied<br class="">together, for this case we'd need alternative groups of FixIts.<br class=""><br class="">There's also a fair number of existing clang warnings that could<br class="">benefit from this, typo correction is an obvious one but there's also<br class="">a bunch of disambiguation warnings that can have fix-its in both<br class="">directions, for example '= in if statement' (turn into '==' or add<br class="">double parens) or '&& within ||' where parens can be added both ways.<br class="">The functionality-preserving FixIt is the canonical one for those<br class="">warnings but having an alternative would be useful, too.<br class=""><br class="">Of course this won't work on the terminal. FixIts are already hardly<br class="">usable there, so this will be a feature for IDEs, code review tools<br class="">etc.<br class=""><br class="">My current plan is:<br class=""> 1. Have DiagnosticEngine and friends keep a vector of vector of<br class="">FixItHint instead of a flat FixIt vector<br class=""> 2. Thread the change through clang, using alternative '0' in most<br class="">places to avoid breaking existing functionality.<br class=""> 3. Add methods to add alternative FixItHints to a diagnostic<br class=""> 4. Expose this via a new libclang API. Any diagnostic rendering code<br class="">in clang will stay the same.<br class=""><br class="">There's interest from YouCompleteMe for providing an interface for<br class="">this that lets the user pick a fix out of multiple ones, and I guess<br class="">other IDEs can put it to great use too.<br class=""><br class="">Any input on this approach or concerns?<br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""><br class=""></blockquote><br class=""></blockquote></div></div></blockquote></div><br class=""></body></html>