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

[Abramo Bagnara]

Il 15/03/2011 07:39, John McCall ha scritto:
> 
> On Mar 13, 2011, at 3:06 PM, Abramo Bagnara wrote:
> 
>> 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.
> 
> Having precise source locations is certainly a desirable goal, but it does
> need to be balanced against other goals like keeping memory usage
> reasonable.  For example, we could theoretically store the locations of
> semicolons and commas, but we don't, because we assume it's possible to
> discover them by re-lexing from a known location.

... this is a big surprise for me. In the general case how you'd cope
with macro expansion?

>> 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 would be quite expensive for C++, which uses unelaborated class
> types a lot — in addition to the obvious uses, recall that we store a
> TypeLoc for every constructor or destructor name.

Ok, then.

We will proceed according your guidelines. I resume it here to be sure
to have not equivocated:

- use ElaboratedType also for C
- obtain source range of ElaboratedType using the keyword location
stored in ElaboratedTypeLoc and the name location available in RecordTypeLoc