[cfe-dev] Questions on Accessing Fully Qualified Names

[Sterling Augustine via cfe-dev]

[I'm coming to this a bit late--I found it while browsing for something
unrelated]

You may
find llvm/tools/clang/lib/AST/QualTypeNames.cpp:getFullyQualifiedName
useful. It takes a qualtype (easily constructible from a decl), builds a
nested-name specifier--Manuel is right that the fully qualified name may
never have been explicitly written--and returns the string.

If you want names for objects and not types, it would take some adaptation.

Note though, that the element a fully qualified name names can change
depending on shadow-declarations, namespace rules, additional using
declarations and many other things. This functions works as one would refer
to an object at the end of a translation unit. Once past the preprocessor
(which is really its own language) C++ doesn't exactly deal with "files" as
such, but on translation units. As such, it is possible that the fully
qualified name is ambiguous at that point, or that a declared type is
unreferenceable from that point (such as private class members.)

On Thu, Jan 10, 2019 at 3:02 PM Brooks Moses <bmoses at google.com> wrote:

>
>
> ---------- Forwarded message ---------
> From: Manuel Klimek via cfe-dev <cfe-dev at lists.llvm.org>
> Date: Wed, Nov 14, 2018 at 11:23 PM
> Subject: Re: [cfe-dev] Questions on Accessing Fully Qualified Names
> To: Shyan Akmal <sakmal at g.hmc.edu>
> Cc: Clang Dev <cfe-dev at lists.llvm.org>, <google18 at cs.hmc.edu>
>
>
>
>
> On Thu, 15 Nov 2018, 01:56 Shyan Akmal <sakmal at g.hmc.edu wrote:
>
>> Thanks for your response.
>>
>> I worded my question very poorly, sorry about that. In 1, I meant to ask
>> *how* one can find the location of a name being declared (in the file
>> overall - included the expanded headers). This is because plan was to find
>> the declaration location, and then try to use getUnderlyingDecl() at that
>> node to figure out the full nested-name-specifier required for a fully
>> qualified name.
>>
>
> I'm a bit confused by this - there might not be a fqn ever spelled out.
> Perhaps if you give an example that would help :)
>
>
>> There could definitely be an alternate, better approach that I'm not
>> seeing though.
>>
>> Thanks for the suggestion - I'll look into printQualifiedName.
>>
>> - Shyan
>>
>> On Tue, Nov 13, 2018 at 1:00 AM Manuel Klimek <klimek at google.com> wrote:
>>
>>> On Tue, Nov 13, 2018 at 3:25 AM Shyan Akmal <sakmal at g.hmc.edu> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm working on a check for fully qualifying names in using
>>>> declarations.
>>>>
>>>> When creating an alias for an object outside the file, this just
>>>> involves prepending the global specifier, so that " using foo::f; " becomes
>>>> " using ::foo::f; ".
>>>>
>>>> However, this shouldn't work in general for objects declaring in the
>>>> existing file.
>>>>
>>>> For example, for code like
>>>>
>>>> namespace example {
>>>>
>>>> namespace util {
>>>>
>>>>
>>>>
>>>> namespace internal {
>>>>
>>>> enum Color {Red, Green, Blue};
>>>>
>>>> }
>>>>
>>>> using internal::Color;
>>>>
>>>>
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> I'd like to replace "internal::Color" with
>>>> "::example::util::internal::Color" instead of "::internal::Color".
>>>>
>>>> Given this motivation, I have two questions:
>>>>
>>>>    1. Given a name inside a using declaration, what's the best way to
>>>>    check if that name is declared in the current file?
>>>>
>>>>
>>> Why does that matter? Can't the same happen across files?
>>>
>>>>
>>>>    1. Given an object declaration, what is the recommended way of
>>>>    finding it's full nested-name-specifier? (I think getUnderlyingDecl()
>>>>    probably works here)
>>>>
>>>> I think printQualifiedName on the namedDecl is your best bet; I don't
>>> know how getUnderlyingDecl() would help?
>>>
>>> Cheers,
>>> /Manuel
>>>
>>>> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190110/705fc842/attachment.html>