Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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=[] #40

Closed
eholk opened this issue Sep 20, 2016 · 9 comments
Closed

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=[] #40

eholk opened this issue Sep 20, 2016 · 9 comments
Labels
bug

Comments

@eholk
Copy link
Collaborator

eholk commented Sep 20, 2016

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>
@eholk eholk added the bug label Sep 20, 2016
@lqd
Copy link
Collaborator

lqd commented Sep 20, 2016 •
edited
Loading

Yeah this looks like one of the issues about substs/generics/monomorphization I mentioned before #17 (comment) (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 lqd@837eda7 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 #17 (comment)

@eholk
Copy link
Collaborator Author

eholk commented Sep 20, 2016

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 #39 (comment)

joshuawarner32 added a commit to joshuawarner32/mir2wasm that referenced this issue Sep 20, 2016
@joshuawarner32
xfail cmp.rs test, since it uses both default trait methods and gener…
5c65677 
…ic impls (side-step issue brson#40)
lqd added a commit to lqd/mir2wasm that referenced this issue Oct 1, 2016
@lqd
Don't translate generic default trait methods.
6b22ce7 
I think Self was in the fn's type_scheme.generics.types in the old nightly.

This fixes the 3 examples exhibiting the brson#40 behavior, so I also added the default methods back to the tests that were created from those examples.

(The cmp example and test are still failing, but it's surely because of substs/monomorphization problems)
lqd added a commit to lqd/mir2wasm that referenced this issue Oct 1, 2016
@lqd
Don't translate generic default trait methods.
577a922 
I think Self was in the fn's type_scheme.generics.types in the old nightly.

This fixes the 3 examples exhibiting the brson#40 behavior, so I also added the default methods back to the tests that were created from those examples.

(The cmp example and test are still failing, but it's surely because of substs/monomorphization problems)
@lqd lqd mentioned this issue Oct 1, 2016
Merged
@lqd
Copy link
Collaborator

lqd commented Oct 3, 2016

I think we should be good here

@eholk
Copy link
Collaborator Author

eholk commented Oct 6, 2016

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

@lqd
Copy link
Collaborator

lqd commented Oct 6, 2016

  • 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
Copy link
Collaborator Author

eholk commented Oct 6, 2016

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?

@eholk eholk closed this as completed Oct 6, 2016
@lqd
Copy link
Collaborator

lqd commented Oct 6, 2016

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
Copy link
Collaborator Author

eholk commented Oct 6, 2016

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
Copy link
Collaborator

lqd commented Oct 6, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@eholk @lqd