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

[John McCall]

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.

> 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.

You don't see changing the assumption, made throughout the compiler,
that a TagType is always canonical as having any cost?

> 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.

John.