[cfe-dev] Alternative FixItHints

[David Blaikie via cfe-dev]

I think the general idea in Clang has been that fixits on a warning must be
behavior-preserving (because we must recover from errors (and warnings can
be errors) as if the fixit were applied, so that downstream
diagnostics/fixits are applicable). We use notes to express other fixit
alternatives (or any non-behavior preserving fixits if there's no
behavior-preserving fixit we care to give). Should we not be using notes as
alternatives in the include fixer tool? Is there some semantic information
missing from multiple notes with fixits that we could improve instead?
(that would maintain/improve the existing command line usability) to
accurately describe which notes form the set of alternative solutions? (so
that an IDE, etc, could collapse/render them differently, perhaps?)

On Wed, May 25, 2016 at 8:24 AM, 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.
>
> 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.
>
> 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?
> _______________________________________________
> 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/ef9876c1/attachment.html>