internal compiler error: ../src/librustc/ty/subst.rs:457: Type parameter `Self/#0` (Self/0) out of range when substituting (root type=Some(&Self)) substs=[]

[eholk]

A lot of our tests are showing this error after our latest nightly bump. Below is a representative stack trace.

test [run-compile-pass] tests/compile-pass/operators.rs ... test [compile-pass] tests/compile-pass/operators.rs ...
FAILED with exit code Some(101)
stdout: 

stderr: 
 error: internal compiler error: ../src/librustc/ty/subst.rs:457: Type parameter `Self/#0` (Self/0) out of range when substituting (root type=Some(&Self)) substs=[]

thread 'main' panicked at 'Box<Any>', ../src/librustc_errors/lib.rs:590
stack backtrace:
   1:     0x7fe4a6646173 - std::sys::backtrace::tracing::imp::write::h4b09e6e8c01db097
   2:     0x7fe4a6656d1d - std::panicking::default_hook::{{closure}}::h1d3243f546573ff4
   3:     0x7fe4a66553aa - std::panicking::default_hook::h96c288d728df3ebf
   4:     0x7fe4a66559a8 - std::panicking::rust_panic_with_hook::hb1322e5f2588b4db
   5:     0x7fe4aac2b328 - std::panicking::begin_panic::hb7c71bbc491f561c
   6:     0x7fe4aaed0935 - rustc::session::opt_span_bug_fmt::{{closure}}::h6ad7caa20ac20c4b
   7:     0x7fe4aae29c85 - rustc::session::opt_span_bug_fmt::h38eb39636c07401c
   8:     0x7fe4aae29b14 - rustc::session::span_bug_fmt::heb3fdb6acac8d0c7
   9:     0x7fe4aae872de - <rustc::ty::subst::SubstFolder<'a, 'gcx, 'tcx> as rustc::ty::fold::TypeFolder<'gcx, 'tcx>>::fold_ty::h17c67c094233ff36
  10:     0x7fe4aae86f5a - <rustc::ty::subst::SubstFolder<'a, 'gcx, 'tcx> as rustc::ty::fold::TypeFolder<'gcx, 'tcx>>::fold_ty::h17c67c094233ff36
  11:     0x7fe4ab7bdbbf - rustc::ty::structural_impls::<impl rustc::ty::fold::TypeFoldable<'tcx> for &'tcx rustc::ty::TyS<'tcx>>::fold_with::h36c63211b891560a
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/structural_impls.rs:508
  12:     0x7fe4ab7cbe15 - <T as rustc::ty::subst::Subst<'tcx>>::subst_spanned::h1e2909ff760b6f53
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/subst.rs:352
  13:     0x7fe4ab7bfe8d - rustc::ty::subst::Subst::subst::h273373dc5ac91f64
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/ty/subst.rs:331
  14:     0x7fe4ab8195bf - mir2wasm::monomorphize::apply_ty_substs::hef3b5edb9ee9e940
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/monomorphize.rs:20
  15:     0x7fe4ab816492 - mir2wasm::trans::BinaryenFnCtxt::type_layout_with_substs::hcddbf3b0d36a58a0
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/trans.rs:1112
  16:     0x7fe4ab816433 - mir2wasm::trans::BinaryenFnCtxt::type_layout::h599f742f9b96d87d
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/trans.rs:1106
  17:     0x7fe4ab80dda1 - mir2wasm::trans::BinaryenFnCtxt::trans_assignment::hc4ecc00d5d562645
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/trans.rs:641
  18:     0x7fe4ab8073bb - mir2wasm::trans::BinaryenFnCtxt::trans::hfde2fbe142e22c3a
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/trans.rs:285
  19:     0x7fe4ab805cd8 - <mir2wasm::trans::BinaryenModuleCtxt<'v, 'tcx> as rustc::hir::intravisit::Visitor<'v>>::visit_fn::h51bafc35e583b5f8
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/trans.rs:185
  20:     0x7fe4ab7c2911 - rustc::hir::intravisit::walk_trait_item::hb1ec63911b017ada
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/hir/intravisit.rs:662
  21:     0x7fe4ab7c3cbc - rustc::hir::intravisit::Visitor::visit_trait_item::hab873576703f59aa
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/hir/intravisit.rs:145
  22:     0x7fe4ab7c780f - rustc::hir::intravisit::walk_item::he9e3385587e0fc9d
                        at /usr/local/google/home/eholk/wasm/mir2wasm/<syntax macros>:2
  23:     0x7fe4ab7c394c - rustc::hir::intravisit::Visitor::visit_item::h1dc71540c0e4b486
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/hir/intravisit.rs:92
  24:     0x7fe4ab7c7af9 - rustc::hir::Crate::visit_all_items::hb6fdac0d00839bd9
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/librustc/hir/mod.rs:415
  25:     0x7fe4ab805215 - mir2wasm::trans::trans_crate::hb5f4874b54b7cb66
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/trans.rs:79
  26:     0x7fe4ab768379 - <mir2wasm::WasmCompilerCalls as rustc_driver::CompilerCalls<'a>>::build_controller::{{closure}}::h47f88d76f5b28e7e
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/bin/mir2wasm.rs:49
  27:     0x7fe4ab28a8d7 - rustc_driver::driver::compile_input::{{closure}}::hdf708031c67974d4
  28:     0x7fe4ab27bd55 - rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}::hcac3a2328cd9259a
  29:     0x7fe4ab247695 - rustc_driver::driver::phase_3_run_analysis_passes::h9865057b323cad0e
  30:     0x7fe4ab238793 - rustc_driver::driver::compile_input::hc0edbed7edb3eb18
  31:     0x7fe4ab264626 - rustc_driver::run_compiler::h22d678d32fb7c300
  32:     0x7fe4ab7678d1 - mir2wasm::main::h79208956a14bce2e
                        at /usr/local/google/home/eholk/wasm/mir2wasm/src/bin/mir2wasm.rs:137
  33:     0x7fe4a6664046 - __rust_maybe_catch_panic
  34:     0x7fe4a6654961 - std::rt::lang_start::haaae1186de9de8cb
  35:     0x7fe4ab768493 - main
  36:     0x7fe4a5a7bf44 - __libc_start_main
  37:     0x7fe4ab732e88 - <unknown>
  38:                0x0 - <unknown>

[lqd]

Yeah this looks like one of the issues about substs/generics/monomorphization I mentioned before https://github.com/brson/mir2wasm/issues/17#issuecomment-236712595 (like this stack trace seems to show). Substs need to be tracked for the current BinaryenFnCtxt, at least so that type_size() and type_layout() can use the current substs (and not empty substs), and trans_assignment() in this stack trace can pass the correct substs to get the layout like so let dest_layout = self.type_layout_with_substs(dest_ty, self.substs); instead of https://github.com/brson/mir2wasm/blob/master/src/trans.rs#L648 and so on.

I had worked on this very thing (eg part of this commit https://github.com/lqd/mir2wasm/commit/837eda704cba422eeccdd55382df3b9dbe7d3cfa but it also built upon temporary previous work, a hacky branch to try and compile libcore, so the code is not really usable as is unfortunately). IIRC, this was absolutely a required thing to do, and fixed some problematic cases on the previous nightly though, and would certainly fix some on the new nightly as well. At least the tests catch the problem now.

Another problematic case showed up with code similar to https://github.com/lqd/mir2wasm/blob/e5f4f6b56cd9906dbae0fdd5d8c555250ff7e018/rust-examples/option.rs and seemed less related to substs per se, compared to monomorphization/resolving trait methods, and there also is the substs-related "possible duplicated fns" from another bullet point in https://github.com/brson/mir2wasm/issues/17#issuecomment-236712595

[eholk]

Thanks for the investigation!

I opened this so we could have a tracking bug but go ahead and merge #39. Unfortunately, as soon as I did that I found another issue, which I mentioned at https://github.com/brson/mir2wasm/pull/39#issuecomment-248446874

[lqd]

I think we should be good here

[eholk]

Awesome. Are the tests that were failing still xfailed? If so, we should enable them again.

[lqd]

• 3 tests had been modified to not trigger the errors and I've modified them back since they work again
• 1 test was xfailed (moved to compile-fail actually) but this one still fails validation now (I think because of the i64.store16 of i32s I mentioned). It's not the problem of generics/substs passed to rustc this issue mentions anymore.

[eholk]

Sounds good. I'll close the bug.

As far as xfail versus compile-fail, I think of xfail as "these are tests that should work, but we know they don't and we'll fix them later." The tests in compile-fail are ones that are intentionally invalid and therefore we want to be sure they actually produce an error if you try to compile them. Is the test that got moved to compile-fail in this category?

[lqd]

No, this test is intended to compile and run, and we should really xfail it and move it back to the compile-pass folder. Let's do this when we can

[eholk]

Sounds good. Just to be sure, this was cmp.rs?

We should probably just remove the compile-fail directory, since this is all behavior that should have already been tested by rustc, unless we expected there to be things that by design do not work in mir2wasm even though they do in Rust.

[lqd]

yup, cmp.rs Yeah we can probably remove the directory. Some failures we'd expect to have in our tests would be probably run-fails eg panic! or assert! and not compile failures indeed