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

[Romanova, Katya via llvm-commits]

Hello,

I don’t think we will reach the conclusion any time soon…
Maybe for right now, I should commit a patch that generates DW_TAG_imported_module for PS4 only? If  an agreement is ever reached, it will be very one line change to generalize this patch for all other platforms.
David, do I need to make any changes to the patch?
Thank you!

Katya.
P.S. DWARF is language independent standard. I wonder why a separate language dependent C/C++ DWARF spec  (which complies with general DWARF spec) is not created? It will solve a lot of the problem in the “grey” areas like the one we just encountered and it will help to resolve a lot of misunderstandings between debuggers and compilers…


From: Robinson, Paul
Sent: Wednesday, August 19, 2015 9:47 AM
To: David Blaikie
Cc: Eric Christopher; reviews+D7895+public+7827be49c0b04087 at reviews.llvm.org; Romanova, Katya; Frédéric Riss; Duncan P. N. Exon Smith; llvm-commits
Subject: RE: [PATCH] D7895: Anonymous namespaces are missing import DW_TAG_imported_module.

Perhaps I've misunderstood - how does [COBOL] pick which names are visible?
In traditional (1985 and previous) COBOL constructs, by default a data name is not visible to contained programs; however there is a source annotation to override this default.  Scoping otherwise (for names tagged as inward-visible in old-style programs, and for all names in nesting constructs defined post-1985) works like DWARF expects although the details aren't exactly what a C programmer would expect: names are available throughout their scope (and hence, if tagged as inward-visible, to all contained programs through the scope), not just lexically forward from the point of declaration.  I doubt anybody debugging a C program cares much about that last little detail of C visibility definition, and I'd be mildly surprised if any debugger actually implemented that detail (i.e., considered source coordinates in determining visibility) which is why I'm not fussed about the COBOL thing either.

I don't think the idea of searching outer namespaces is part of the DWARF spec, nor would it seem it should be...

Well, hmm, point.  DWARF says these names are declared in this scope, and scopes can nest, but doesn't assert anything else about the relationships of names across scopes.
But still, the whole point of imported_module is to make names from another scope available in the current scope, which (in the case of an anonymous namespace) they automatically are.

Given C++'s ADL, no consumer is going to be able to do language-agnostic consumption of C++ DWARF and get name lookup right, even if we patch this piece.

I reject the claim that "no consumer" can do it without implementing ADL. You are accustomed to consumers whose UIs have you type in C++-like syntax, and therefore those consumers must do an ADL-like step to resolve certain ambiguities.  That's really not the only possible solution.  It's entirely possible (I think I've mentioned this before) to construct the list of available entities (in a language-agnostic way) and let the user pick from the list—but only if each scope correctly specifies all available names. Which is why anonymous namespaces should be implicitly imported, because those names are available in the scope and thus need to be available as candidates for selection by the user.

But, clearly you won't accept doing the artificial import unconditionally, and I've burned more time than it's worth trying to persuade you otherwise.

It's already on my to-do list to plumb the debugger-tuning notion through Clang, and here we have something for it to apply to (rather than just pass through to LLVM).  I won't get to it right away but I will get to it.
--paulr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150820/13b7dacd/attachment-0001.html>