[ICE] Encountered errors resolving bounds after type-checking

[tesuji]

The below content was posted by @bkchr, I moved it into a separated issue to keep track of the ICE.

---

Hey, so I tried porting our code to compile with latest nightly and I almost got it working but ultimately it ended with an internal compiler error:

error: internal compiler error: compiler/rustc_trait_selection/src/traits/codegen/mod.rs:121:9: Encountered errors `[FulfillmentError(Obligation(predicate=TraitPredicate(<dyn sc_client_api::PrunableStateChangesTrieStorage<sp_runtime::generic::Block<sp_runtime::generic::Header<u32, sp_runtime::traits::BlakeTwo256>, sp_runtime::OpaqueExtrinsic>> as sp_state_machine::changes_trie::Storage<sp_runtime::traits::BlakeTwo256, u32>>), depth=0),Unimplemented)]` resolving bounds after type-checking

thread 'rustc' panicked at 'Box<Any>', compiler/rustc_errors/src/lib.rs:945:9
note: run with `RUST_BACKTRACE=1` environment variable to display a 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.49.0-nightly (98edd1fbf 2020-10-06) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type lib

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

error: aborting due to previous error

error: could not compile `node-testing`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

I created a branch that fails with this or a similar ICE when you run cargo test --all. You can find it here: https://github.com/paritytech/substrate/tree/bkchr-fix-for-latest-nightly

Originally posted by @bkchr in #77638 (comment)

@rustbot modify labels: regression-from-stable-to-nightly E-needs-mcve A-associated-items

[spastorino]

@rustbot ping cleanup

Would be nice to find the regression and an MCVE.

[rustbot]

Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @AminArria @camelid @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @JamesPatrickGill @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @shekohex @sinato @smmalis37 @spastorino @Stupremee @tamuhey @turboladen @woshilapin @yerke

[apiraino]

Assigning P-critical as per linked issue, Prioritization Working Group discussion, removing I-prioritize.

[steffahn]

This repository is huge (almost 1000 crates to compile including the dependencies, wow) - I’m working on reducing the code currently. I can also do a bisection once it’s a bit smaller. This comment is just to save duplicate work on reduction efforts.

[Stupremee]

Can you try the same regression as in #77656? Just two versions to see if it has regressed in the same commit

[steffahn]

I’m still having the dependency on a having WASM target installed. I wouldn’t know how to get those installed from/for the build artifacts that bisection uses. I can test the relevant nightlies though to get a less fine-grained result. I can also build rustc myself. For now I’ll test the two nightlies around #77656 and leave the rest until my reduction is further and I (hopefully) got rid of the WASM stuff.

[bkchr]

@steffahn if you use SKIP_WASM_BUILD=1 cargo whatever it will skip the wasm compilation.

[steffahn]

@steffahn if you use SKIP_WASM_BUILD=1 cargo whatever it will skip the wasm compilation.

Okay, interesting. It currently gives me an error though (FYI, I’m not building on top-level but reducing my way through the workspace members)

error: couldn't read [...]/substrate/client/service/target-bisector-ci-5849a7eca90582ee59b67eb09548a2aa424d7f52-x86_64-unknown-linux-gnu/debug/build/node-runtime-b5ec2a55671b02f8/out/wasm_binary.rs: No such file or directory (os error 2)
  --> bin/node/runtime/src/lib.rs:95:1
   |
95 | include!(concat!(env!("OUT_DIR"), "/wasm_binary.rs"));
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

---

For the time being, I confirmed that it regresses with

nightly-2020-10-07
rustc 1.49.0-nightly (98edd1fbf 2020-10-06)

Which should be the one containing #77656 (I think..)

[bkchr]

@steffahn if you use SKIP_WASM_BUILD=1 cargo whatever it will skip the wasm compilation.

Okay, interesting. It currently gives me an error though (FYI, I’m not building on top-level but reducing my way through the workspace members)

error: couldn't read [...]/substrate/client/service/target-bisector-ci-5849a7eca90582ee59b67eb09548a2aa424d7f52-x86_64-unknown-linux-gnu/debug/build/node-runtime-b5ec2a55671b02f8/out/wasm_binary.rs: No such file or directory (os error 2)
  --> bin/node/runtime/src/lib.rs:95:1
   |
95 | include!(concat!(env!("OUT_DIR"), "/wasm_binary.rs"));
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Ahh sorry 🙈 BUILD_DUMMY_WASM_BINARY=1 is the correct one.

[steffahn]

Ahh sorry BUILD_DUMMY_WASM_BINARY=1 is the correct one.

I see, that works.

@Stupremee I can confirm, it’s the same regression, 08e2d46.

[matthewjasper]

Small example that I think is the same issue. And an ICE on stable.

trait Proj {
    type S;
}

trait Base<T> {
    fn is_base(&self);
}
trait Der<B: Proj>: Base<B::S> {
    fn is_der(&self);
}

fn f<P: Proj>(obj: &dyn Der<P>) {
    // Uncomment for ICE on stable
    // obj.is_base();
    obj.is_der();
}

impl Proj for () {
    type S = ();
}

pub fn main() {
    let x: fn(_) = f::<()>;
}

[camelid]

For matthewjasper's example:

searched nightlies: from nightly-2019-01-01 to nightly-2020-10-08
regressed nightly: nightly-2020-05-03
searched commits: from 7f65393 to f05a524
regressed commit: dae90c1

bisected with cargo-bisect-rustc v0.5.2

Host triple: x86_64-apple-darwin
Reproduce with:

cargo bisect-rustc --preserve --regress=ice --start=2019-01-01 

EDIT: This is the second ICE in the example, with the line uncommented.

[smmalis37]

That would make it potentially related to #75961

[camelid]

I think the ICE from matthewjasper's example is actually different from the one for this issue:

thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorReported', src/librustc_mir/monomorphize/collector.rs:731:84
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

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.47.0 (18bf6b4f0 2020-10-07) running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

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

warning: 1 warning emitted

error: internal compiler error: Encountered error `Unimplemented` selecting `Binder(<dyn Der<()> as Base<()>>)` during codegen
  |
  = note: delayed at src/librustc_trait_selection/traits/codegen/mod.rs:65:32

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:369:17
stack backtrace:
   0:        0x10b3c5754 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd4b962ed89f71a03
   1:        0x10b42d2e0 - core::fmt::write::h94ae1e793baa7a00
   2:        0x10b3b700b - std::io::Write::write_fmt::h5c716758fdc3057f
   3:        0x10b3ca075 - std::panicking::default_hook::{{closure}}::hc6119c7d16548caf
   4:        0x10b3c9db7 - std::panicking::default_hook::heae8b62897b351dc
   5:        0x10bc00ee8 - rustc_driver::report_ice::h4c5f6debea1a3bdd
   6:        0x10b3ca73d - std::panicking::rust_panic_with_hook::hc36596b4257bea99
   7:        0x11013573d - std::panicking::begin_panic::{{closure}}::ha531c012d8ea503d
   8:        0x1101353c8 - std::sys_common::backtrace::__rust_end_short_backtrace::h81cde96df7db3e51
   9:        0x11057f2ee - std::panicking::begin_panic::h8547fa8f4ce5bdf8
  10:        0x110101cf2 - <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop::hd0f245604385b2c4
  11:        0x10bc39fea - core::ptr::drop_in_place::he23c867c5bdbde24
  12:        0x10bc3f2c8 - <alloc::rc::Rc<T> as core::ops::drop::Drop>::drop::he8bd6e057da40850
  13:        0x10bbcd422 - core::ptr::drop_in_place::h5ba472cc3f0eeee2
  14:        0x10bbc6921 - rustc_span::with_source_map::he14c41eca1fb99da
  15:        0x10bc1f421 - rustc_interface::interface::create_compiler_and_run::ha27975ab759bd229
  16:        0x10bc04463 - scoped_tls::ScopedKey<T>::set::ha597f9a01cfb0fbb
  17:        0x10bc13070 - std::sys_common::backtrace::__rust_begin_short_backtrace::hec10f7c8c3dfd9bb
  18:        0x10bbb2dbc - core::ops::function::FnOnce::call_once{{vtable.shim}}::h4702140ae68aebcd
  19:        0x10b3d8e5d - std::sys::unix::thread::Thread::new::thread_start::hd4805e9612a32deb
  20:     0x7fff727bb109 - __pthread_start

error: internal compiler error: unexpected panic

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.47.0 (18bf6b4f0 2020-10-07) running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

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

thread panicked while panicking. aborting.
error: could not compile `rust-issue-77653-matthewjasper`.

Caused by:
  process didn't exit successfully: `rustc --crate-name rust_issue_77653_matthewjasper --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=781d53d2f99ed599 --out-dir /Users/user/rust-issue-77653-matthewjasper/target/debug/deps -C incremental=/Users/user/rust-issue-77653-matthewjasper/target/debug/incremental -L dependency=/Users/user/rust-issue-77653-matthewjasper/target/debug/deps` (signal: 4, SIGILL: illegal instruction)

Should we open a new issue?

EDIT: This is the second ICE in the example, with the line uncommented.

[steffahn]

For matthewjasper's example:

searched nightlies: from nightly-2019-01-01 to nightly-2020-10-08
regressed nightly: nightly-2020-05-03
searched commits: from 7f65393 to f05a524
regressed commit: dae90c1

bisected with cargo-bisect-rustc v0.5.2

Just to clarify in case there was a misunderstanding, @matthewjasper provided an example that ICEs in two different ways. With the line left commented out, it does regress with 08e2d46, too. (Just tested that.) Only with the line uncommented, @camelid ’s bisection applies.

[camelid]

Oops, thank you for catching that! I didn't notice there were two ICEs in the example :)

I edited my comments to reflect that.