r178741 - Add hasExternalLinkageUncached back with the test that Richard provided, but

[Richard Smith]

On Thu, Apr 4, 2013 at 6:45 AM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> > Add hasExternalLinkageUncached back with the test that Richard provided,
> but
> > keep the call at the current location.
>
> I was trying to figure out what these hidden decl are. My
> understanding so far is:
>

Since you asked for comments on this bit...


> * Modules are handle liked a unit, so loading a module semantically
> loads all sub modules, but they can be hidden.
> * An external variable/function in a hidden sub module still conflicts
> with an external variable/function in the TU importing the module. Is
> this is some form of ODR for modules?
>

Yes, the model which Doug and I discussed on IRC is this: when you import
any part of a module, all of that module is included in your program, but
only the part you actually imported is included in your translation unit
[*]. So we can perform ODR checking against external-linkage hidden
declarations, and we do so where possible.

My desire when discussing the model for submodules was that they be as much
like #includes as we can reasonably get (with the proviso that importing
any part of a module implies that the program as a whole contains all of
the module).


> * An internal variable/function in a hidden sub module doesn't
> interfere with the TU importing the module.
>

Right, by the above model, things in unimported submodules aren't part of
the current translation unit, so internal linkage functions aren't relevant.


> * An external variable/function in a hidden sub module doesn't
> interfere with a hidden variable/function in the TU importing the
> module.
>

There are no hidden variables/functions in the importing TU. But an
external-linkage hidden declaration doesn't interfere with internal linkage
declarations in the TU, in the same way that an external-linkage
declaration in a header which you haven't #included doesn't interfere with
an internal linkage declaration (even if you know that header is included
somewhere else in the program).


> This last item I find surprising if the objective is really some form
> of ODR. In particular, I would expect an error for f1 and v1 in
> Modules/linkage-merge.m. I would also expect an error in the peculiar
> case Richard mentioned last night:
>
> hidden sub module:
> -------------------------
> extern const int foo;
> ------------------------
> TU importing the module:
> ----------------------------
> const int foo = 32;
> -------------------------
>
> but currently they are not linked and we accept it.
>

These are separate entities (one is an external linkage entity, not part of
the current TU, and the other is an internal linkage entity within the TU).
Therefore the ODR does not apply. C++ core issue 426 tightens up the rules
here (see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#426),
but even then it's still OK to have the same name and scope be used for an
internal linkage entity and an external linkage entity if they're not
declared in the same TU.


[*] We need a more finessed way of saying this than just that unimported
submodules are not part of the TU. Consider this:

module m.a:
  int f();
  static int n = f();
module m.b:
  import m.a;
  int *p = &n;
x.cc:
  import m.b; // do not import m.a
  int *x = p;
y.cc:
  import m.b;
  int *y = p;
main.cc:
  extern int *x, *y;
  int main() { return x == y; }

Presumably main() here should return 0, because x.cc and y.cc each get
their own copy of ::n, but that requires the hidden declaration ::n to be
part of the respective TUs. (We'd also presumably expect to see f() being
run twice on startup.) And if we allow this, we can have two internal
linkage symbols of the same name in the same scope which are not merged
because they come from unimported submodules of different modules -- and
yet we still have to emit code for both of them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130404/eae1cedd/attachment.html>