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
While narrowing down to a small test case for #14421 , I encountered the following issue:
A library might want to have a single private struct that is only exposed via a named type for that struct (*).
But it seems like this causes a link failure for clients of that library. (Probably because some dead-code elimination pass is relying on accurate results from the reachability analysis, which is breaking in this scenario as described in #14421.)
(I keep wondering if I'm missing some obvious explanation for this in my code, but I have reviewed the test a couple times and cannot find a reason to explain this except a hypothetical rustc bug.)
% ./x86_64-apple-darwin/stage2/bin/rustc --version
rustc 0.11.0-pre (e402e75 2014-05-22 13:31:24 -0700)
host: x86_64-apple-darwin
% ./x86_64-apple-darwin/stage2/bin/rustc --out-dir /tmp /tmp/bug_lib.rs
/tmp/bug_lib.rs:20:13: 20:62 warning: code is never used: `foo`, #[warn(dead_code)] on by default
/tmp/bug_lib.rs:20 pub fn foo(&mut self) { println!("called foo"); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
% ./x86_64-apple-darwin/stage2/bin/rustc -L /tmp/ /tmp/bug_client.rs
error: linking with `cc` failed: exit code: 1
note: cc '-m64' '-L' '/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib' '-o' 'bug_client' 'bug_client.o' '-lmorestack' '-nodefaultlibs' '-Wl,-dead_strip' '/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/libnative-1fb5e2c0-0.11.0-pre.rlib' '/private/tmp/libbug_lib-ef5c9cd9-0.0.rlib' '/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/libstd-59beb4f7-0.11.0-pre.rlib' '/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/liballoc-1085c790-0.11.0-pre.rlib' '/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/libcore-c5ed6fb4-0.11.0-pre.rlib' '/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/liblibc-4f9a876d-0.11.0-pre.rlib' '-L' '/tmp' '-L' '/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/.rust' '-L' '/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt' '-lSystem' '-lpthread' '-lc' '-lm' '-Wl,-rpath,@loader_path/x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib' '-Wl,-rpath,/Users/pnkfelix/opt/rust-dbg/lib/rustlib/x86_64-apple-darwin/lib' '-lcompiler-rt'
note: ld: warning: directory not found for option '-L/Users/pnkfelix/Dev/Mozilla/rust.git/objdir-dbgopt/.rust'
Undefined symbols for architecture x86_64:
"src::hidden_core::A::foo::h874f4919cda4bfc2Aaa::v0.0", referenced from:
main::hea3b2ec4fbc3f438haa::v0.0 in bug_client.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: aborting due to previous error
%
(*) Who knows why, perhaps the library designer doesn't like the names chosen by a fellow developer, but does not want to go through the effort of alpha-renaming. In any case, if #14421 works then this case seems like it should work as well.
The text was updated successfully, but these errors were encountered:
pnkfelix
changed the title
method on priv struct callable via re-exported type alias leads to link failure
method on non-parametric priv struct callable via re-exported type alias leads to link failure
May 25, 2014
pnkfelix
changed the title
method on non-parametric priv struct callable via re-exported type alias leads to link failure
method on non-generic priv struct callable via re-exported type alias leads to link failure
May 25, 2014
This ensures that a public typedef to a private item is ensured to be public in
terms of linkage. This affects both the visibility of the library's symbols as
well as other lints based on privacy (dead_code for example).
Closesrust-lang#14421Closesrust-lang#14422
This ensures that a public typedef to a private item is ensured to be public in
terms of linkage. This affects both the visibility of the library's symbols as
well as other lints based on privacy (dead_code for example).
Closes#14421Closes#14422
While narrowing down to a small test case for #14421 , I encountered the following issue:
A library might want to have a single private struct that is only exposed via a named type for that struct (*).
But it seems like this causes a link failure for clients of that library. (Probably because some dead-code elimination pass is relying on accurate results from the reachability analysis, which is breaking in this scenario as described in #14421.)
(I keep wondering if I'm missing some obvious explanation for this in my code, but I have reviewed the test a couple times and cannot find a reason to explain this except a hypothetical rustc bug.)
bug_lib.rs
bug_client.rs
transcript
(*) Who knows why, perhaps the library designer doesn't like the names chosen by a fellow developer, but does not want to go through the effort of alpha-renaming. In any case, if #14421 works then this case seems like it should work as well.
The text was updated successfully, but these errors were encountered: