r183563 - Re-commit r183466 with a fix to make the TypeLoc casting machinery work

Manuel Klimek klimek at google.com
Mon Jun 10 09:30:05 PDT 2013


On Mon, Jun 10, 2013 at 6:03 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Mon, Jun 10, 2013 at 8:39 AM, Manuel Klimek <klimek at google.com> wrote:
>
>> On Fri, Jun 7, 2013 at 10:31 PM, Eli Friedman <eli.friedman at gmail.com>wrote:
>>
>>> Author: efriedma
>>> Date: Fri Jun  7 15:31:48 2013
>>> New Revision: 183563
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=183563&view=rev
>>> Log:
>>> Re-commit r183466 with a fix to make the TypeLoc casting machinery work
>>> correctly in the presence of qualified types.
>>>
>>> (I had to change the unittest because it was trying to cast a
>>> QualifiedTypeLoc to TemplateSpecializationTypeLoc.)
>>>
>>
>> That did work before though... Why doesn't that work any more?
>>
>
> It essentially worked by accident: pretty much all the TypeLoc subclass
> inherit from UnqualTypeLoc, but they were forgetting to check that the
> TypeLoc was actually unqualified.
>
> If it's useful functionality, I guess I could modify the casting routines
> to implicitly strip qualifiers where appropriate.
>

Ha, I didn't even know that there was a QualifiedTypeLoc (I'd have expected
it to be called QualTypeLoc :P)
At least now I learned how I get to the qualifier location on type
locations :)

I'm not sure how often people already rely on the castAs working through
the boundaries. I think it's unfortunate enough that types have their own
casting mechanism.

Thanks for the info.
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130610/82eef2af/attachment.html>


More information about the cfe-commits mailing list