Re: [cfe-commits] r126459 - in /cfe/trunk: include/clang/AST/ include/clang/Frontend/ include/clang/Serialization/ lib/AST/ lib/Sema/ lib/Serialization/ test/Index/ tools/libclang/

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-commits] r126459 - in /cfe/trunk: include/clang/AST/ include/clang/Frontend/ include/clang/Serialization/ lib/AST/ lib/Sema/ lib/Serialization/ test/Index/ tools/libclang/

Craig Silverstein
} Update UsingDecl, UnresolvedUsingTypenameDecl, and
} UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than
} the extremely-lossy NestedNameSpecifier/SourceRange pair it used to
} use,

How is this conversion coming along?  I was looking at
RecursiveASTVisitor and it seems like it's using
VisitNestedNameSpecifier() in a lot of places it could be using
VisitNestedNameSpecifierLoc() instead.  Any objection to me changing
those uses (assuming all tests still pass)?

It looks like the only place where we still can't use
NestedNameSpecifierLoc is QualifiedTemplateName/DependentTemplateName.
While there's still some work to make some of the other types
loc-aware -- TemplateSpecializationType only provides access to
TemplateArgument, not TemplateArgumentLoc, for instance -- we're
getting ever-closer to the day when RecursiveASTVisitor will be
entirely loc-aware!  I'm excited.

craig
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-commits] r126459 - in /cfe/trunk: include/clang/AST/ include/clang/Frontend/ include/clang/Serialization/ lib/AST/ lib/Sema/ lib/Serialization/ test/Index/ tools/libclang/

Douglas Gregor

On Mar 23, 2011, at 9:24 PM, Craig Silverstein wrote:

> } Update UsingDecl, UnresolvedUsingTypenameDecl, and
> } UnresolvedUsingValueDecl to use NestedNameSpecifierLoc rather than
> } the extremely-lossy NestedNameSpecifier/SourceRange pair it used to
> } use,
>
> How is this conversion coming along?

It's basically done.

>  I was looking at
> RecursiveASTVisitor and it seems like it's using
> VisitNestedNameSpecifier() in a lot of places it could be using
> VisitNestedNameSpecifierLoc() instead.  Any objection to me changing
> those uses (assuming all tests still pass)?

Please go ahead.

> It looks like the only place where we still can't use
> NestedNameSpecifierLoc is QualifiedTemplateName/DependentTemplateName.
> While there's still some work to make some of the other types
> loc-aware -- TemplateSpecializationType only provides access to
> TemplateArgument, not TemplateArgumentLoc, for instance -- we're
> getting ever-closer to the day when RecursiveASTVisitor will be
> entirely loc-aware!  I'm excited.


TemplateSpecializationType doesn't have a nested-name-specifier in it; there will be an ElaboratedType around the TemplateSpecializationType to capture the nested-name-specifier.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-commits] r126459 - in /cfe/trunk: include/clang/AST/ include/clang/Frontend/ include/clang/Serialization/ lib/AST/ lib/Sema/ lib/Serialization/ test/Index/ tools/libclang/

Craig Silverstein
} It's basically done.

Are there any immediate plans to move QualifiedTemplateName and
DependentTemplateName to expose NestedNameSpecifierLoc instead of
NestedNameSpecifier, or will that wait for sometime later?

} > It looks like the only place where we still can't use
} > NestedNameSpecifierLoc is QualifiedTemplateName/DependentTemplateName.
} > While there's still some work to make some of the other types
} > loc-aware -- TemplateSpecializationType only provides access to
} > TemplateArgument, not TemplateArgumentLoc, for instance -- we're
} > getting ever-closer to the day when RecursiveASTVisitor will be
} > entirely loc-aware!  I'm excited.
}
} TemplateSpecializationType doesn't have a nested-name-specifier in it; there will be an ElaboratedType around the TemplateSpecializationType to capture the nested-name-specifier.

Sorry if I wasn't clear -- I had changed the subject in the second
paragraph a bit to talk about other location-aware types.  For
TemplateSpecializationType, it's TemplateArgumentLoc (right now, TST
only exposes TemplateArgument).

There are a few other places that we don't have access to the *Loc()
variant of a structure (Type, TemplateArgument,
NestedNamespaceSpecifier), but not that many!

craig
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-commits] r126459 - in /cfe/trunk: include/clang/AST/ include/clang/Frontend/ include/clang/Serialization/ lib/AST/ lib/Sema/ lib/Serialization/ test/Index/ tools/libclang/

Douglas Gregor

On Mar 23, 2011, at 11:07 PM, Craig Silverstein wrote:

> } It's basically done.
>
> Are there any immediate plans to move QualifiedTemplateName and
> DependentTemplateName to expose NestedNameSpecifierLoc instead of
> NestedNameSpecifier, or will that wait for sometime later?

Later, or more likely, QualifiedTemplateName and DependentTemplateName will just go away. They tend to be redundant now.

> } > It looks like the only place where we still can't use
> } > NestedNameSpecifierLoc is QualifiedTemplateName/DependentTemplateName.
> } > While there's still some work to make some of the other types
> } > loc-aware -- TemplateSpecializationType only provides access to
> } > TemplateArgument, not TemplateArgumentLoc, for instance -- we're
> } > getting ever-closer to the day when RecursiveASTVisitor will be
> } > entirely loc-aware!  I'm excited.
> }
> } TemplateSpecializationType doesn't have a nested-name-specifier in it; there will be an ElaboratedType around the TemplateSpecializationType to capture the nested-name-specifier.
>
> Sorry if I wasn't clear -- I had changed the subject in the second
> paragraph a bit to talk about other location-aware types.  For
> TemplateSpecializationType, it's TemplateArgumentLoc (right now, TST
> only exposes TemplateArgument).

That's intended, and will not change.

> There are a few other places that we don't have access to the *Loc()
> variant of a structure (Type, TemplateArgument,
> NestedNamespaceSpecifier), but not that many!

Not everything is supposed to have access to a *Loc. Once you've gone into a QualType, for example, and left the TypeLoc behind, you're not expected to get back to type-location information. The intended is that RecursiveASTVisitor shouldn't ever need to visit anything to available in a *Loc.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-commits] r126459 - in /cfe/trunk: include/clang/AST/ include/clang/Frontend/ include/clang/Serialization/ lib/AST/ lib/Sema/ lib/Serialization/ test/Index/ tools/libclang/

Craig Silverstein
} Once you've gone into a QualType, for example, and left the TypeLoc behind,
} you're not expected to get back to type-location information.

Ah of course.  For some reason it slipped my mind that a TST is not a TSTLoc.
:-/  So I think we're *really* close...

craig
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev