[cfe-dev] Source information for types

[Argyrios Kyrtzidis]

Hi Enea,

On Aug 8, 2009, at 1:11 AM, Enea Zaffanella wrote:

> Hello.
>
> Argyrios Kyrtzidis wrote:
>> Hi clang community,
>> I'd like to make a proposal for keeping source location  
>> information  for types in the AST, to allow functionality like  
>> "find the source  locations where this typedef is used".
> [...snip...]
>> TypeSpecifier will replace the QualType fields in the Decls. For   
>> example, ValueDecl will contain a TypeSpecifier instead of a plain   
>> QualType.
>> "QualType ValueDecl::getType()" will delegate to  
>> TypeSpecifier::getType () (ValueDecl::getType() will still return a  
>> QualType).
>> TypeSpecifier will also be contained in Exprs that deal with type-  
>> specifiers, like SizeOfAlignOfExpr.
> [...]
>
> As clang users, we would be really interested in such a proposal (or  
> a functionally equivalent one) and hence we would like to know if  
> there have been progresses ... or there are plans in this respect.

Yes, I quite recently started working on this feature.

>
> Right now, we are facing problems when trying,
> e.g., to distinguish the following two cases:
>
> void foo() {
>    /* ... */
>    int a[sizeof(struct S*)];
>    int b[sizeof(struct S {int a;}*)]
>    /* ... */
> }
>
> from
>
> void bar() {
>    /* ... */
>    int a[sizeof(struct S {int a;}*)]
>    int b[sizeof(struct S*)];
>    /* ... */
> }
>
> That is, by looking at the AST only it is quite difficult  
> (impossible?) to understand whether the `struct S' was defined  
> inside the declaration of `a' or that of `b'. Unless I am missing  
> something, both pointer types have no associated location info and  
> refer to the very same RecordDecl node. Even though the example  
> above doesn't look really interesting, variations can be built that  
> are relevant, e.g., for applications that need to check strict  
> adherence to user-defined coding standards.

This is exactly the kind of information we want to encode in type  
source info.

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

>
> As yet another example, we would like to be able to distinguish  
> between
>  void (*pf)(int left_is_array[], int* right_is_pointer);
> vs
>  void (*pf)(int* left_is_pointer, int right_is_array[]);
>
> [Note: since pf is a pointer to function, there are no parameters,  
> hence we cannot keep track of the parameter names nor we can  
> retrieve the original type from OriginalParmVarDecl].
>
> In our opinion, re-lexing the type specifier is not an option.

We will definitely handle this. The way I see it, you'll be able to  
get at the parameters through the type source info (and look into the  
parameter's type info too).

-Argiris