[cfe-dev] Alternative FixItHints

[Manuel Klimek via cfe-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160601/9cb62124/attachment.html>