Now with the patch :-(
On 4 April 2013 21:20, Rafael Espíndola <[email protected]> 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
t.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
