You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// foo.rsexternmod bar;fnmain(){let a = bar::bar();let b = bar::foo::<int>();println!("{} {}",*a,*b);}
$ rustc --lib bar.rs
warning: missing crate link meta `name`, using `bar` as default
warning: missing crate link meta `vers`, using `0.0` as default
warning: no debug symbols in executable (-arch x86_64)
$ rustc foo.rs -L.
warning: no debug symbols in executable (-arch x86_64)
$ ./foo
5 4
Here's what's happening (to the best of my knowledge):
When compiling bar.rs, the same symbol name, N, is generated for both statics. LLVM will silently rename the second to N1, so we have N = 4, N1 = 5. Note that both statics are walked through because this is a generic function, meaning that we still walk the statics to emit them into this crate (may have to do that for inner functions as well).
The function bar is resolved in-crate, and because the symbol names have already been generated, N1 will be returned (5).
When compiling foo.rs, the function bar::foo is again instantiated, but this time we have our clever optimization which ignores the first block of the if statement, hence only one of the statics is translated. In this case, it's declared with the name N.
When linking is done, the version of bar::foo in bar returns N1, and the version of bar::foo in foo returns N, hence the difference.
There's a lot of things going wrong here, and I'm not entirely sure why, but I think that this would all be fixed if inner statics had different symbol names (no silent renamings from LLVM).
The text was updated successfully, but these errors were encountered:
While they may have the same name within various scopes, this changes static
names to use path_pretty_name to append some hash information at the end of the
symbol. We're then guaranteed that each static has a unique NodeId, so this
NodeId is as the "hash" of the pretty name.
Closes#9188
Turns out this is not only inconvenient, but also a serious problem.
Here's what's happening (to the best of my knowledge):
bar.rs
, the same symbol name, N, is generated for both statics. LLVM will silently rename the second to N1, so we have N = 4, N1 = 5. Note that both statics are walked through because this is a generic function, meaning that we still walk the statics to emit them into this crate (may have to do that for inner functions as well).bar
is resolved in-crate, and because the symbol names have already been generated,N1
will be returned (5).foo.rs
, the functionbar::foo
is again instantiated, but this time we have our clever optimization which ignores the first block of theif
statement, hence only one of the statics is translated. In this case, it's declared with the name N.bar::foo
inbar
returns N1, and the version ofbar::foo
infoo
returns N, hence the difference.There's a lot of things going wrong here, and I'm not entirely sure why, but I think that this would all be fixed if inner statics had different symbol names (no silent renamings from LLVM).
The text was updated successfully, but these errors were encountered: