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

[Rafael Espíndola]

> 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.

Thanks a lot. The "include in the program" X "included in the TU"
distiction makes things a lot easier to understand.

>> * 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.

Sorry, yes. I meant internal.

> 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).

Yes, it makes a lot more sense with this mental model.

> [*] 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.

nasty :-(
looks like you and Douglas will have a nice chat over beer :-)

In any case, I now understand what we are trying to do and it makes
sense. The attached patch just avoids the hasExternalLinkageUncached
function.

Cheers,
Rafael