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

[Douglas Gregor]

On Apr 5, 2013, at 2:20 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

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

The patch looks good to me. I agree that this is the right direction.

	- Doug