[PATCH] D7895: Anonymous namespaces are missing import DW_TAG_imported_module.

[David Blaikie via llvm-commits]

On Mon, Aug 17, 2015 at 7:07 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

> DWARF describes a mapping from source to object.  It tries to use
> language-neutral mechanisms to do this.  "Namespace" is not a C++-specific
> notion.  "Importing" a name or set of names from one scope to another is
> not a C++-specific notion.  Emitting an artificial import seems like a
> perfectly natural way to translate the C++ language-specific rule about
> anonymous namespaces into a language-neutral DWARF description.
>
>
>
> This is not about how to let a user identify an entity available within a
> scope; this is about what entities are available within the scope in the
> first place.
>

I'm not sure I really understand the distinction, or perhaps how it applies
here... The entities within an anonymous namespace are not /in/ the outer
namespace, they're able to be found there (those are different things - see
the recent discussion around how to make an equivalent std::copy in LLVM
without breaking existing calls due to ADL - putting a name in another
namespace, then importing it from that namespace has different ADL effects)


> The artificial import gives you that.  Failing to provide the import
> imposes a *requirement* on the client to understand language-specific
> scope-munging rules, in order for the client to even know what entities are
> available.  DWARF tries hard not to impose that kind of requirement.
> (DWARF does assume that inner scopes can see all entities in outer scopes,
> which is how most but not all languages work.  COBOL's data-visibility
> rules are really arcane.)
>

This seems like it would support my position - Your COBAL example tells me
that DWARF debuggers use language-specific knowledge to know to look in
outer scopes for names without qualification. We don't expect the frontend
to emit an imported module into each nested namespace that imports the
outer one to model the name lookup of C++ in this case.


>  Regarding ADL, it is not a DWARF-imposed requirement that every
> debug-info client understand all the C++-defined shorthand methods for
> identifying an entity.  While could be very user-friendly of the client to
> permit users to type in C++-like syntax to name things, and disambiguate
> them for you, that depends on the client's UI and at most is a
> quality-of-implementation issue for the client, not something assumed or
> imposed (and certainly not required) by DWARF.
>

Again, then the same logic applies to the imported name - it's a quality of
implementation issue for the client if it chooses not to implicitly look
into anonymous namespaces.


>  Regarding calling conventions, a lot of the relevant information is
> actually explicit in the DWARF, and (without having thought about it much)
> I expect what's implicit would be platform-dependent not
> language-dependent.
>

Sorry, I had in mind all the arcane rules about pass by value versus pass
by pointer depending on a type's trivial copyability. Also the rules about
which parameters are passed in registers (which is language-dependent to a
degree - see the ABI support in Clang - choosing how to lower C++ function
into LLVM functions to correctly communicate the ABI: splitting structs
into single variables if the struct is trivially copyable, etc). again for
(trivial and non-trivial) return values. It seems there's been a strong
push (as I hear it) not to encode the ABI (which, especially in C++'s case,
is certainly a language issue - see the Itanium ABI/cxx-abi project).
Granted that's changed a bit recently, if I hear correctly, that Richard's
arguments for triviality (upon finding a GCC bug where it incorrectly
computed triviality & messed up the calling convention/produced bad calls)
being impossible for consumers to compute correctly in a reliable manner
seems to have been heard/understood.


> Clients *are* expected to understand the target platform.
>

>
> To recap: An artificial import of a C++ anonymous namespace conforms to
> DWARF's intent, and having it be target-dependent is silly.
>


> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* Monday, August 17, 2015 6:16 PM
> *To:* reviews+D7895+public+7827be49c0b04087 at reviews.llvm.org; Robinson,
> Paul
> *Cc:* Romanova, Katya; Eric Christopher; Frédéric Riss; Duncan P. N. Exon
> Smith; llvm-commits
> *Subject:* Re: [PATCH] D7895: Anonymous namespaces are missing import
> DW_TAG_imported_module.
>
>
>
>
>
>
>
> On Mon, Aug 17, 2015 at 6:12 PM, Paul Robinson via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
> probinson added a comment.
>
> I don't think this should be PS4-special.  I know I was more wishy-washy
> about it before, but really DWARF-the-standard tries to be
> language-neutral.  Emitting an explicit import matches the intent of DWARF,
> and Clang should always do it.
>
>
>
> I don't quite see how "DWARF the standard tries to be language neutral"
> and "DWARF should model the source" are resolved here... the source is an
> anonymous namespace, without any using directive. In the same way that
> DWARF clients figure out calling conventions (and name lookup rules for
> other entities - including complex things like ADL) based on the language,
> so would this, I would think.
>
>
>
>
>
> http://reviews.llvm.org/D7895
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150817/9d13dc7a/attachment.html>