[cfe-commits] [Request for approval] Added basic source locations to Elaborated and DependentName types.

[John McCall]

On May 14, 2010, at 7:55 AM, Abramo Bagnara wrote:

> Il 13/05/2010 22:43, John McCall ha scritto:
>> On May 13, 2010, at 2:09 AM, Abramo Bagnara wrote:
>>> The attached patch improves support for locations inside Elaborated
>>> and DependentName types.
> 
> I've committed the fixed patch in r103770.

I notice that you didn't include the SourceRange for the NestedNameSpecifiers
like I asked.  Without this, your calculation of the source ranges for these
TypeLocs is incorrect, particularly because you're consistently assuming that
KeywordLoc is a real source location — it's meaningless for ETK_None,
which is possible for both ElaboratedType and DependentNameType.

Please fix this.

>> DependentNameType needs to be able to situationally store a
>> TemplateSpecializationTypeLoc as its NextTypeLoc.  This is not going
>> to be very clean.  The best solution would be to split
>> DependentNameType in two, so that we have both DependentNameType
>> (typename A<T>::foo) and DependentTemplateSpecializationType
>> (A<T>::template B<int>).  If you're willing to do that refactor, that
>> would be awesome;  otherwise, let me know and we'll get to it
>> eventually.
> 
> There is something we do not fully understand and we would like to hear
> an informed opinion, since probably we are missing some details of the
> overall design and issues.
> 
> Even now, as far as we understand, an ElaboratedType can contain a
> dependent type (correct?).

Yes;  the distinction is between resolved and unresolved types.  This is
an important distinction;  there are a lot of clients that can work with
dependent types but (obviously) not with unresolved ones.

> So, why wouldn't it be possible (or reasonable) to create some sort of
> UnresolvedType node and let it be the inner node of an ElaboratedType?

Types should "stand alone":  a type's meaning shouldn't be determined by
how it's referenced.  So this UnresolvedType would need to carry information
equivalent to DependentNameType, because none of that information is
optional when resolving the type.

It's also very convenient for ElaboratedType to be pure "sugar" in the type
system, in the sense that its canonical type is always guaranteed to be the
canonical type of its inner type.

>>> The next step should be adding source location to
>>> NestedNameSpecifier.
>> 
>> I'm not sure this is the right approach;  I think it might be better
>> to use a TypeLoc-like solution.  But we should talk about this
>> separately.
> 
> I believed that NNS was a pure syntactic thing, do you think it's wrong
> to store locations there?

I don't know what you mean by a "pure syntactic thing".  They carry
semantic information, have canonical forms, etc.

John.