[cfe-commits] r67823 - /cfe/trunk/lib/Sema/SemaType.cpp

[Chris Lattner]

On Mar 26, 2009, at 11:01 PM, Douglas Gregor wrote:

>
> On Mar 26, 2009, at 10:50 PM, Chris Lattner wrote:
>
>>
>> On Mar 26, 2009, at 10:10 PM, Douglas Gregor wrote:
>>
>>> Author: dgregor
>>> Date: Fri Mar 27 00:10:56 2009
>>> New Revision: 67823
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=67823&view=rev
>>> Log:
>>> Remove the code insertion hint for implicit int. Too often, we're  
>>> wrong about this hint, so it loses its usefulness. Maybe some day  
>>> we can make the hint smart enough to be useful.
>>
>> I don't get it, is the problem that the insertion point was wrong,  
>> or that this was the first of a series of errors and the parser was  
>> just confused?
>
> It's the first of a series of errors. I think the root of the  
> problem is that we emit the "implicit int" warning well before we've  
> actually done the rest of the type checking for this declarator.

Ok, well that's kind of the design of the fixit advice: theoretically  
and IDE would only show fixit advice if all generated errors had fix  
it's.  If any errors were produced without fixit advice, then we'd  
assume that error recovery got confused and that none of the fixit  
advice is trustworthy.

There is a problem here with the command line interface, in that we  
stream out diags as we see them.  We can't "unprint" fixit advice  
retroactively.

> That gives me an idea: why not just make a note that we're  
> potentially dealing with an implicit int, and then only emit this  
> warning/error after we've successfully processed the declarator?  
> Then, we omit the diagnostic for semantic disasters, and when we do  
> provide the diagnostic, the code insertion hint is likely to be right.

That would be nice refinement in any case, I guess, but the meta issue  
stands: fixit advice is only trustworthy when the front-end isn't  
hopelessly confused.

-Chris