[cfe-dev] Alternative FixItHints

[Piotr Padlewski via cfe-dev]

Sound like a killer feature for YouCompleteMe!

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