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

[Abramo Bagnara]

Il 13/03/2011 21:50, John McCall ha scritto:
> On Mar 13, 2011, at 1:10 PM, Abramo Bagnara wrote:
>> Il 13/03/2011 19:59, John McCall ha scritto:
>>> 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's be clear here:  the memory footprint is going to increase with this,
> just as it's increased with all the other source range changes you've made
> recently.  I expect that the increase in memory footprint from allocating
> a uniqued ElaboratedType per RecordType in C is going to be quite small
> when compared with storing all the extra source locations.  One of the nice
> things about a mode to enable ElaboratedTypes is that we have the
> option of disabling *both* of those costs.

To have precise source ranges is a design goal for clang (and a must for
several applications, ours included), so we try (as always done) to
achieve this trying to keep needed memory as small as possibile.

>> 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.
> 
> You don't see changing the assumption, made throughout the compiler,
> that a TagType is always canonical as having any cost?

I was under the impression that to get the canonical type of a type had
a negligible cost. Consider however that alternative 2b does not change
this assumption.

>> 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.
> 
> Something being usually true does not actually free us of the obligation
> of checking and compensating for the possibility that it is not.

Once read your preferences I can make another proposal:

Alternative 3:

C language: struct S is a RecordType (always canonical)

C++ language: struct S is an ElaboratedType (always non canonical) with
an inner RecordType (always canonical)

This would be exactly like it is now, but KeywordLoc would be  moved
from ElaboratedTypeLoc to RecordTypeLoc so to be available for both C
and C++.

This solution does not have minimal memory needs like 2b (that I confess
is still my pet ;-) but has the lowest impact wrt current
implementation, does it matches your expectations?