[cfe-dev] Source information for types

[Enea Zaffanella]

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.)
> 
> 
> Is re-lexing the type specifier a reasonable solution for this ?
> My concern is the impact on memory consumption for type source info. 
> Ideally memory usage for type source info should be reasonable enough to 
> consider having them on all the time.
> 
> -Argiris

Let us see: according to the C standard, you can freely reorder type 
specifiers and mix them with type qualifiers (which can occur several 
times) and storage class specifiers (which can occur only once).
So, the worst cases should look like the following:

void foo() {
   /* ... */
   const long const int extern const unsigned volatile long *p1;

   const long const int const unsigned typedef volatile long * PType;
   const PType p2 = p1;

   p1 = (int long const unsigned volatile long * restrict) p2;
}

Well, things would be easy, provided we can see the sequence of 
preprocessed tokens. Because the tokens above may be the result of 
(several levels of) macro expansions ... here is where I am afraid I am 
missing knowledge about the underlying clang infrastructure, so I need 
some help.

Is it possible to start the re-lexing from the source location of a 
particular token (e.g., the TypeSpecStartLoc of the declaration of p1 
above) so as to obtain the exact sequence of the preprocessed tokens?
Can you point me to some existing code snippet where such a re-lexing is 
done?

Thank you in advance for the help,
Enea.