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

[David Blaikie via llvm-commits]

On Tue, Aug 18, 2015 at 4:55 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Tue, Aug 18, 2015 at 4:40 PM, Robinson, Paul <
> Paul_Robinson at playstation.sony.com> wrote:
>
>>
>>
>> How is this goal (adding imported modules for anonymous namespaces)
>> consistent with the lack of imported modules for outer namespaces in nested
>> ones? These two scenarios seem quite the same to me.
>>
>>
>>
>> Sadly, the "lack of imported modules for outer namespaces in nested ones"
>> is nothing more than the normal way scoping works everywhere (with two
>> minor exceptions).
>>
>
> Given DWARF's desire to be language neutral (does the DWARF spec talk
> about name lookup at all? I don't think the idea of searching outer
> namespaces is part of the DWARF spec, nor would it seem it should be... ) I
> would be surprised if the DWARF spec baked in one choice of lookup like
> this.
>
>
>> Therefore the scenarios are far from the same.  Searching upward from the
>> current scope through the parents to the top is implicit and will remain
>> so.  Even COBOL does that; it just doesn't make _all_ names visible to the
>> inner scope.
>>
>
> Perhaps I've misunderstood - how does it pick which names are visible?
>
>
>>
>>
>> For COBOL, I deliberately pretended the funky rules didn't exist. As far
>> as DWARF is concerned, COBOL scoping works exactly like everything else.
>>
>
> Doesn't that break the user experience (in the same way that the user
> experience for anonymous namespaces is broken for clients consuming Clang's
> debug info and not explicitly accounting for unnamed namespaces in some
> way)/make it inconsistent with the way name lookup works when using the
> language directly?
>
>
>> For C++, adding explicit imports for anonymous namespaces means as far as
>> DWARF is concerned, C++ scoping work exactly like everything else.
>>
>>
>>
>> That is: What I want will make all languages behave simply and
>> consistently, for DWARF scoping purposes.
>>
>> Is that such an undesirable result?
>>
>
> It's not a desirable result to me. (the COBOL example still seems like
> it's a counterproof of this, even if it were a desirable goal)
>

I'll try to clarify/expound on this a bit: Scoping is only useful if you're
doing sometihng with it, like name lookup. 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.

So far as I can tell, based on my (albeit comparatively limited) experience
with DWARF is that DWARF itself offers a language agnostic encoding scheme
that producers and consumers can use to traffic in language-specific
information. Without knowing the language you're working with, DWARF is of
limited value as there's too much underspecified (intentionally so) in the
DWARF spec to make good use of the encoded information.

Yes, there are degrees of functionality that can be provided with degrees
of language-specific knowledge (including zero-or-close-to-zero
language-specific knowledge), but not much and it's not a hard line so far
as I can see.


>
>
>>  Still haven't heard anybody say what would *break* if we have explicit
>> imports.
>>
>
> We just add debug info where it's not needed. We usually try to avoid
> that, even if it's a small amount (which I'm sure it is), so far I don't
> agree with the motivation.
>
> - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150818/fc88d974/attachment.html>