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

[steve naroff]

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

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:-)

> 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). 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).

snaroff

> Comments? Concerns?
>
> 	- Doug
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev