[cfe-dev] Source information for types

[Enea Zaffanella]

Argyrios Kyrtzidis wrote:
> On Aug 9, 2009, at 7:21 AM, Enea Zaffanella wrote:
> 
>> Argyrios Kyrtzidis wrote:
>>> On Aug 8, 2009, at 2:38 AM, Enea Zaffanella wrote:
>>>>>> Another issue that could be solved by following this proposal is 
>>>>>> the ability to distinguish different syntactic representations of 
>>>>>> the same type; namely, distinguishing "unsigned" from "unsigned 
>>>>>> int" from "int unsigned" and the like.
>>>>> What are the use cases for this, do you also need it to check 
>>>>> adherence to coding standards ?
>>>>
>>>> Yes. (In this particular case, I suspect that coding standard 
>>>> checkers are the only application.)

[...]

> For the "adherence to coding standards" case, isn't it more appropriate 
> to see the tokens without macro expansion ? e.g
> 
> int unsigned x;
> COOL_MACRO y;
> 
> "COOL_MACRO" may expand to "int unsigned" but whether the compiler sees  
> "int" or "int unsigned" doesn't matter, we are really interested in what 
> the user wrote, right ?

Well, a colleague made me remember that coding standard (in their strict 
interpretation) are not the only application for this info.

Distinguishing between "int" and "signed int" is sometimes necessary to 
avoid implementation-defined behavior and hence it is important to 
ensure portability. This happens in the case of bitfields, whose 
signedness is implementation defined.

Anyway, we would like to better understand what you mean by
"memory usage for type source info should be reasonable enough".
We ask because, for the (qualified) _basic_ types mentioned in the 
C89/99 standards, the needed information can be extracted from the 
corresponding type specifiers and suitably encoded in 64 bits: rather 
than storing info about locations, we could encode the presence/absence 
of type specifiers and type qualifiers (and even storage classes), 
together with their textual ordering.

Would that be reasonable?

Cheers,
Enea Zaffanella.