[cfe-dev] RFC: Extra source location information for dependent types

[Douglas Gregor]

On Mar 31, 2009, at 1:44 PM, steve naroff wrote:

> Hey Doug,
>
> Some comments below...
>
> On Mar 31, 2009, at 3:16 PM, Douglas Gregor wrote:
>
>> I believe that we have to fix this problem, and to do so we're going
>> to need to introduce more source locations into our representation of
>> types. Unfortunately, adding source locations to types has some
>> serious downsides:
>>
>>  - The representation of each type gets larger
>>  - Since source locations will need to be part of each type's
>> profile, we'll be creating many more unique types
>>  - With more unique types, we'll spend more time in the type-
>> uniquing process.
>>
>
> Does this imply we could no longer compare two QualType's directly  
> (to test for equivalence)? If not, Sema performance might also be  
> effected. Since most types are never used, maybe this wouldn't be a  
> big deal...

No, we'll still be able to compare two (canonical) QualTypes directly.  
That's an extremely important aspect of our type system that we must  
not compromise.

> Since this info is only used for error diagnostics (for a small  
> percentage of types), it would be great if we could generate this  
> extra info lazily. This would still add some overhead to remember  
> all the type refs, however it's worth considering. Since PTH has all  
> the tokens & source locations pre-computed, maybe it could be  
> extended to do token caching in general (which would support the  
> lazy generation). Definitely not a quick hack:-)

Interesting. We'd have to be able to re-parse non-trivial types  
(within templates, nonetheless!) to get this information. Not a quick  
hack, but it could be a good solution.

>> For these reasons, I think we need to introduce source locations into
>> the type system in a few places as possible. In particular, I suggest
>> that source locations are only available in the dependent form of a
>> type. Thus, the type used to represent "typename MetaFun::template
>> apply<T>::type" will have source locations for the keyword  
>> "template",
>> the template name "apply", and the trailing type "type" only if the
>> types depend somehow on a template parameter. Hence, when we're
>> outside of a template we won't run into any of the downsides  
>> described
>> above.
>>
>
> As you probably know, we already have a couple types that aren't  
> unique (VariableArrayType and DependentSizedArrayType).

The latter of these will, eventually, need to be uniqued so that we  
can match template declarations, e.g.,

	template<int N> void foo(char (&str)[N]); // #1
	template<int M> void foo(char (&str)[N]) { ... } // #2

We need to be able to compare those DependentSizedArrayType nodes to  
realize that #2 matches #1.

> Both of these have SourceLocation info contained within their  
> expression. That said, what specific Type classes do you anticipate  
> adding source location information? If the classes are self- 
> contained and don't effect the semantics of the type system in  
> general, there may not be a need for any fancy infrastructure (or  
> sweeping changes).


We'll need to add SourceLocations to nearly every compound type,  
because you can build just about any type out of other, dependent  
types and we need the location information during template  
instantiation. This means everything from FunctionProtoTypes to  
PointerTypes would have SourceLocations.

	- Doug