[cfe-dev] Alternative FixItHints

[Manuel Klimek via cfe-dev]

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/fe945cca/attachment.html>