Cross-compiling Rust to s390x yields a faulty toolchain

[Jakob-Naucke]

Code

I tried this code on s390x:

trait T1: {}
trait T2: {
    type Foo: T1; 
}
trait T3<T>: {
    fn f(&self) -> T::Foo where T: T2; 
}
fn main() {}

(originally discovered in and derived to make an MWE from gimli) with all of the following:

• rustup toolchains 1.50 (current beta) and 1.51 (current nightly)
• https://static.rust-lang.org/dist/2020-12-30/rust-beta-s390x-unknown-linux-gnu.tar.gz which is used as stage0 when compiling Rust
• Rust cross-compiled from the Git repository on master with DEPLOY=1 ./src/ci/docker/run.sh dist-s390x-linux on x86_64 and installed on s390x

I expected to see this happen: a successful compiler run, as is on x86_64

Instead, this happened:

error[E0220]: associated type `Foo` not found for `T` 
 --> demo.rs:6:23
  |
6 |     fn f(&self) -> T::Foo where T: T2; 
  |                       ^^^ associated type `Foo` not found

error: aborting due to previous error

For more information about this error, try `rustc --explain E0220`.

Furthermore, when building Rust with x.py on s390x after the switch to the aforementioned 2020-12-30 stage0 (introduced in fe031180), an ICE is claimed:

Output

$ RUST_BACKTRACE=1 ./x.py build
Updating only changed submodules
Submodules updated in 0.02 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s
Building stage0 std artifacts (s390x-unknown-linux-gnu -> s390x-unknown-linux-gnu)
   Compiling core v0.0.0 (/home/fedora/rust/library/core)
error: internal compiler error: compiler/rustc_privacy/src/lib.rs:500:25: item Item { ident: #0, hir_id: HirId { owner: DefId(0:472 ~ core[5990]::num::flt2dec::{misc#0}), local_id: 0 }, attrs: [], kind: Use(Path { span: library/core/src/num/flt2dec/mod.rs:125:9: 125:70 (#0), res: Err, segments: [PathSegment { ident: self#0, hir_id: Some(HirId { owner: DefId(0:472 ~ core[5990]::num::flt2dec::{misc#0}), local_id: 1 }), res: Some(Err), args: None, infer_args: false }, PathSegment { ident: decoder#0, hir_id: Some(HirId { owner: DefId(0:472 ~ core[5990]::num::flt2dec::{misc#0}), local_id: 2 }), res: Some(Def(Mod, DefId(0:478 ~ core[5990]::num::flt2dec::decoder))), args: None, infer_args: false }] }, ListStem), vis: Spanned { node: Inherited, span: library/core/src/num/flt2dec/mod.rs:125:9: 125:9 (#0) }, span: library/core/src/num/flt2dec/mod.rs:125:1: 125:71 (#0) } with DefKind Struct

thread 'rustc' panicked at 'Box<Any>', compiler/rustc_errors/src/lib.rs:958:9
stack backtrace:
   0: std::panicking::begin_panic
   1: rustc_errors::HandlerInner::bug
   2: rustc_errors::Handler::bug
   3: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
   4: rustc_middle::ty::context::tls::with_opt::{{closure}}
   5: rustc_middle::ty::context::tls::with_opt
   6: rustc_middle::util::bug::opt_span_bug_fmt
   7: rustc_middle::util::bug::bug_fmt
   8: rustc_privacy::EmbargoVisitor::update_macro_reachable_def
   9: rustc_privacy::EmbargoVisitor::update_macro_reachable
  10: rustc_privacy::EmbargoVisitor::update_macro_reachable_def
  11: rustc_privacy::EmbargoVisitor::update_macro_reachable
  12: rustc_privacy::EmbargoVisitor::update_macro_reachable_def
  13: rustc_privacy::EmbargoVisitor::update_macro_reachable
  14: <rustc_privacy::EmbargoVisitor as rustc_hir::intravisit::Visitor>::visit_macro_def
  15: rustc_privacy::privacy_access_levels
  16: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::privacy_access_levels>::compute
  17: rustc_query_system::dep_graph::graph::DepGraph<K>::with_eval_always_task
  18: rustc_data_structures::stack::ensure_sufficient_stack
  19: rustc_query_system::query::plumbing::get_query_impl
  20: rustc_query_system::query::plumbing::ensure_query_impl
  21: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  22: __rust_try.llvm.16454507701973609965
  23: rustc_session::utils::<impl rustc_session::session::Session>::time
  24: rustc_interface::passes::analysis
  25: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::analysis>::compute
  26: rustc_query_system::dep_graph::graph::DepGraph<K>::with_eval_always_task
  27: rustc_data_structures::stack::ensure_sufficient_stack
  28: rustc_query_system::query::plumbing::get_query_impl
  29: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  30: rustc_span::with_source_map
  31: rustc_interface::interface::create_compiler_and_run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.50.0-beta.1 (05b602367 2020-12-29) running on s390x-unknown-linux-gnu

note: compiler flags: -Z macro-backtrace -Z binary-dep-depinfo -Z force-unstable-if-unmarked -C opt-level=3 -C embed-bitcode=no -C debuginfo=0 -C link-args=-Wl,-rpath,$ORIGIN/../lib -C prefer-dynamic --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [privacy_access_levels] privacy access levels
#1 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error

error: could not compile `core`

To learn more, run the command again with --verbose.
command did not execute successfully: "/home/fedora/rust/build/s390x-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "s390x-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "4" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/home/fedora/rust/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101
failed to run: /home/fedora/rust/build/bootstrap/debug/bootstrap build
Build completed unsuccessfully in 0:00:06

Rust compiled on s390x natively (immediately prior to that introduction) does not have this issue.

Since the Rust dists are built through cross-compilation for Tier 2 architectures, I believe that there is a problem specific to the cross-compilation with an s390x target.

Versions it worked on

It most recently worked on:

• rustup toolchain 1.49 (current stable)
• https://static.rust-lang.org/dist/2020-11-18/rust-beta-s390x-unknown-linux-gnu.tar.gz, the previous stage0
• Rust cross-compiled from the Git repository on tag 1.49.0

Versions with regression

e.g.

$ rustc --verbose --version
rustc 1.50.0-beta.5 (ff5998292 2021-01-05)
binary: rustc
commit-hash: ff59982926d98c8508008f0559f8a055260ac05e
commit-date: 2021-01-05
host: s390x-unknown-linux-gnu
release: 1.50.0-beta.5

Backtrace

no additional info for code example, ICE output had backtrace enabled

@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged

[rylev]

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[cuviper]

I believe that there is a problem specific to the cross-compilation with an s390x target.

This has come up before when some part of the crate metadata is accidentally written in native-endian order -- so x86_64 rustc writes some little-endian data in the standard library rlibs, and s390x rustc reads that as big-endian.

[cuviper]

I can reproduce this on RHEL 7 s390x, but not ppc64, so it would seem to be something other than endian order.
I will try to bisect this.

[camelid]

I believe that there is a problem specific to the cross-compilation with an s390x target.

This has come up before when some part of the crate metadata is accidentally written in native-endian order -- so x86_64 rustc writes some little-endian data in the standard library rlibs, and s390x rustc reads that as big-endian.

I know you said based on testing it doesn't seem to be endian order that's causing this issue, but in general can't we just standardize on either little-endian or big-endian somehow?

[cuviper]

searched nightlies: from nightly-2020-10-01 to nightly-2021-01-08
regressed nightly: nightly-2020-12-04
searched commits: from f4db9ff to 5be3f9f
regressed commit: b4def89

bisected with cargo-bisect-rustc v0.6.0

Host triple: s390x-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start 2020-10-01 --end 2021-01-08 -- check

---

That's the merge for #79637, a revert, which doesn't really make sense to me...
cc @spastorino @nikomatsakis @Mark-Simulacrum

[camelid]

Since this may be an rlib-related issue, did you have cargo-bisect-rustc run clean in between each toolchain run? Not sure if that could be the issue.

[cuviper]

@camelid

I know you said based on testing it doesn't seem to be endian order that's causing this issue, but in general can't we just standardize on either little-endian or big-endian somehow?

I think we do normalize to/from little endian, but it's possible something was missed.

[cuviper]

did you have cargo-bisect-rustc run clean in between each toolchain run?

Doesn't it use a new target dir by default? That seems implied by the option to --preserve-target anyway.

[camelid]

I think you're right – I forgot about that :)

[spastorino]

searched nightlies: from nightly-2020-10-01 to nightly-2021-01-08
regressed nightly: nightly-2020-12-04
searched commits: from f4db9ff to 5be3f9f
regressed commit: b4def89
bisected with cargo-bisect-rustc v0.6.0

That's the merge for #79637, a revert, which doesn't really make sense to me...
cc @spastorino @nikomatsakis @Mark-Simulacrum

Sorry, I don't have time right now to check this properly but a quick answer I can give you now is:
Could be that this was "tested" between my original PR was merged and the revert was merged and that's the reason why this "regressed"?. If so, it's not really a regression, my original PR fixed a very old issue and this revert, reverted it because it uncovered a different bug. In that case, #80732 will fix the issue again, maybe try the compiler generated for that PR and see what happens.