[cfe-dev] A small proposal about TagType's and source ranges

[Abramo Bagnara]

Il 13/03/2011 19:59, John McCall ha scritto:
> 
> On Mar 13, 2011, at 12:38 AM, Abramo Bagnara wrote:
> 
>> Il 13/03/2011 05:34, John McCall ha scritto:
>>>
>>> On Mar 12, 2011, at 11:28 AM, Abramo Bagnara wrote:
>>>
>>>> Il 12/03/2011 20:10, John McCall ha scritto:
>>>>>
>>>>> On Mar 12, 2011, at 8:54 AM, Abramo Bagnara wrote:
>>>>>
>>>>>>
>>>>>> We are struggling to fix lack of proper source location range for
>>>>>> TagType's due to missing setting of both source location for tag keyword
>>>>>> and name.
>>>>>>
>>>>>> We'd like to propose the following simplification of current approach to
>>>>>> tag types and elaborated types storing:
>>>>>>
>>>>>> Currently clang uses (only in C++) an ElaboratedType whenever the type
>>>>>> has an explicit class/struct/union/enum keyword *or* a name qualifier.
>>>>>>
>>>>>> We propose to use an ElaboratedType *only* whenever there is a name
>>>>>> qualifier and to add to TagTypeLoc a (possibly invalid) tag keyword
>>>>>> location (removing the one now available in ElaboratedTypeLoc).
>>>>>
>>>>> How would we represent "struct A::B" in C++?
>>>>>
>>>>> It's also important to distinguish between A and struct A in C++.  If we don't have an elaborated type node, what remembers this distinction?
>>>>
>>>> On the syntactic side they can be distinguished in the TagTypeLoc using
>>>> the validity of tag keyword location. On the semantic side they can be
>>>> distinguished inheriting TagType from TypeWithKeyword.
>>>
>>>
>>> Adding non-canonical state to TagType is not really acceptable;  it's really,
>>> really nice right now that TagTypes are always canonical.
>>
>> If you prefer in this way the inheritance from TypeWithKeyword can be
>> avoided. Do we need to distinguish between "S" and "struct S" in places
>> where TypeLoc is not available?
> 
> Generally not, but I'd rather not rely on it.  Wouldn't the better solution
> to have some mode which enables ElaboratedTypes even in C?

Of course this is a possibility, but IMHO I don't think it is a good
idea to increase the memory footprint for a need that is not (or not
yet) materialized.

Let me do a little summary of presented alternatives:

C language:

Alternative 1: struct S is an ElaboratedType referring a RecordType, the
canonical type of both is that RecordType

Alternative 2a and 2b: struct S is a RecordType whose canonical type is
itself

C++ language:

Alternative 1: struct S is an ElaboratedType referring a Recordtype. the
canonical type of both is that RecordType

Alternative 2a: struct S is a RecordType whose canonical type is another
RecordType with tag kind bitfield set to None

Alternative 2b: struct S is a Recordtype whose canonical type is itself
and the only way to know if a tag keyword was present is to consult
RecordTypeLoc

I've to say that I don't see any benefits of 1 wrt 2.

About the differences between 2a and 2b I think they are not so
relevant: for C in 100% of cases the canonical type of a RecordType is
itself and for C++ this is true in 95% of cases.