[cfe-dev] Proposal: Add diagnostic enumeration to libclang

[David Blaikie]

Hmm, I didn't realize the requirement was that strict. How can we
recover with a matching ast when the fixit has inserted code? the
inserted code has no source locations to refer to.

(Chandler and i have discussed this before & he mentioned this
generally works ok for the current very small fixits - even though we
don't have source locations for inserted code, it usually comes out as
intended if multiple fixits are applied one after the other in the
order they were found. Still scares me a bit)

(not to detail this even further but it seems a bit of a pity that high
value warnings end up noisier than you'd expect (by having to have the
reasonable/likely fixit in a note instead of the warning) because of
this rule)
From: Richard Smith
Sent: 1/5/2012 6:46 AM
To: Dave Abrahams
Cc: David Blaikie; cfe-dev at cs.uiuc.edu
Subject: Re: [cfe-dev] Proposal: Add diagnostic enumeration to libclang
On Thu, January 5, 2012 12:21, Dave Abrahams wrote:
> on Thu Jan 05 2012, David Blaikie <dblaikie-AT-gmail.com> wrote:
>> The rules are there to protect -fixit behavior - a fixit hint on an
>> error or warning cannot change the semantics of the program
>
> What are the semantics of a program that doesn't compile?

The relevant rule for fixits on warnings and errors is that the AST must
reflect the syntax of the fixed code. For warnings, this means that the fixit
must not change semantics. For errors, it means that if all errors have
fixits, we can (hopefully reliably) assume that all (error and optionally
warning) fixits can be simultaneously applied and all errors will be fixed. In
principle, we could even go on to produce object code in the same compilation
pass if all errors have fixits -- but sadly many of the fixits predate this
rule and do not yet recover correctly.

Fixits on notes don't have these restrictions, since they're not automatically
applied by -fixit.

- Richard