[cfe-commits] r86962 - /cfe/trunk/tools/clang-cc/clang-cc.cpp
dgregor at apple.com
Thu Jan 7 16:21:30 PST 2010
On Nov 12, 2009, at 5:38 PM, Chris Lattner wrote:
> On Nov 12, 2009, at 4:29 PM, Douglas Gregor wrote:
>>>> So perhaps we should turn -fixit into an action instead of
>>>> relying on
>>>> users not to do anything stupid with it.
>>> I think that this is a serious problem with a different fix. Fixits
>>> for warnings should be to 'make the warning go away without changing
>>> the semantics of the code' not 'change my code to make the warning
> Another way of putting it is that fixits should always agree with
> the way the compiler recovers. In the case of a warning, this
> should be how it actually parsed the code.
>>> In this case, the fixit should insert:
>>> i & (1 == 0)
>>> No? Maybe there should be two modes for fixits: semantic preserving
>>> ones that can always be safely applied vs potential bugs?
>> I like the idea of tagging those fix-its that actually change
>> behavior. They should not be automatically applied by the -fixit
>> We could even provide multiple alternatives via different nodes:
>> note: to silence this warning, insert paretheses around the ==
>> (show 1 == 0 underlined with the fixit adding ( and ) around it.
>> this fixit doesn't change behavior)
>> note: to evaluate the & first, insert parentheses around the &
>> (show i & 1 underlined with the fixit adding ( and ) around it.
>> this fixit does change behavior)
> I think this is a great idea. Both "answers" should be attached to
> the same diagnostic, then a UI could provide "two buttons" or
Implemented here via notes:
More information about the cfe-commits