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

[Rafael Espíndola]

Now with the patch :-(

On 4 April 2013 21:20, 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.
>
> Cheers,
> Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 4567 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130404/0d95ad0b/attachment.obj>