[cfe-commits] Declarator::getSourceRange()

[Sebastian Redl]

Chris Lattner wrote:
> On Feb 9, 2009, at 12:23 AM, Sebastian Redl wrote:
>>
>> I'm 95% sure this is unspecified behavior. The compiler *could* take the
>> value of Loc for the second attribute before calling ParseAttributes(),
>> thus losing the update.
>> But I can change it to
>>
>> AttributeList *Attrs = ParseAttributes(&Loc);
>> D.AddAttributes(Attrs, Loc);
>
> Oh right, I guess you could also pass Loc by const& as a subtle and
> horrible workaround :)
Urgh! No.
>
>>> +  // FIXME: Since the return type isn't actually parsed, need some
>>> fake
>>> +  // location info for the declarator.
>>> +  ParamInfo.SetSourceRange(SourceRange(Tok.getLocation(),
>>> Tok.getLocation()));
>>>
>>> Does it make sense to just leave it as 'invalid'?
>>
>> No, this leads to extremely subtle bugs in error reporting, if something
>> then decides to actually use the source range. The location info
>> isn't as
>> fake as the comment makes it seem.
>
> What is a sensible location for a declspec that doesn't exist (e.g.
> implicit int)?  Shouldn't any diagnostics relating to empty declspecs
> be pointing to the decl itself?
Of course it should. I've updated the comment to more clearly say what's
going on. I've also hunted down the implicit int case and made it behave
correctly.

Sebastian