[cfe-dev] Alternative FixItHints

[Ben Jackson via cfe-dev]

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 :)

> On 1 Jun 2016, at 11:19, Manuel Klimek <klimek at google.com> wrote:
> 
>> On Wed, Jun 1, 2016 at 5:14 PM Piotr Padlewski <piotr.padlewski at gmail.com> wrote:
>> Sound like a killer feature for YouCompleteMe!
> 
> +ben jackson, who said claimed that ycm is well prepared for this in principle.
>  
>> 
>> 2016-06-01 16:43 GMT+02:00 Manuel Klimek via cfe-dev <cfe-dev at lists.llvm.org>:
>>>> On Wed, May 25, 2016 at 5:24 PM Benjamin Kramer via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>>> Hi all,
>>>> 
>>>> one of the longer-term goals for the include fixer tool is integration
>>>> into the editor. This could piggy-back on the existing support for
>>>> FixIts but there is one big missing feature. It is often not perfectly
>>>> clear what #include a user wants or if it's just a typo that needs
>>>> correcting, we cannot express that with the current FixIts. A Clang
>>>> diagnostic can have multiple FixIts but they are meant to be applied
>>>> together, for this case we'd need alternative groups of FixIts.
>>> 
>>> 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).
>>> 
>>>> There's also a fair number of existing clang warnings that could
>>>> benefit from this, typo correction is an obvious one but there's also
>>>> a bunch of disambiguation warnings that can have fix-its in both
>>>> directions, for example '= in if statement' (turn into '==' or add
>>>> double parens) or '&& within ||' where parens can be added both ways.
>>>> The functionality-preserving FixIt is the canonical one for those
>>>> warnings but having an alternative would be useful, too.
>>> 
>>> Given the complexity of the current typo correction code (yikes!), introducing this for an alternative warning might be a good idea.
>>>  
>>>> Of course this won't work on the terminal. FixIts are already hardly
>>>> usable there, so this will be a feature for IDEs, code review tools
>>>> etc.
>>>> 
>>>> My current plan is:
>>>>   1. Have DiagnosticEngine and friends keep a vector of vector of
>>>> FixItHint instead of a flat FixIt vector
>>>>   2. Thread the change through clang, using alternative '0' in most
>>>> places to avoid breaking existing functionality.
>>>>   3. Add methods to add alternative FixItHints to a diagnostic
>>>>   4. Expose this via a new libclang API. Any diagnostic rendering code
>>>> in clang will stay the same.
>>>> 
>>>> There's interest from YouCompleteMe for providing an interface for
>>>> this that lets the user pick a fix out of multiple ones, and I guess
>>>> other IDEs can put it to great use too.
>>>> 
>>>> Any input on this approach or concerns?
>>> 
>>> An open question is: 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
>>> 
>>>  
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160601/79d52174/attachment.html>