ICE: Type parameter out of range when substituting

[joshlf]

When running cargo test on this code (in particular, patch set 18), I get the following error:

error: internal compiler error: librustc/ty/subst.rs:479: Type parameter `HwAddr/#1` (HwAddr/1) out of range when substituting (root type=Some(wire::arp::ArpBody<HwAddr, ProtoAddr>)) substs=[wire::arp::ArpBody<HwAddr, ProtoAddr>]

Thread stack and query stack:

```text thread 'main' panicked at 'Box', librustc_errors/lib.rs:499:9 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace 1: std::sys_common::backtrace::print 2: std::panicking::default_hook::{{closure}} 3: std::panicking::default_hook 4: rustc::util::common::panic_hook 5: std::panicking::rust_panic_with_hook 6: std::panicking::begin_panic 7: rustc_errors::Handler::span_bug 8: rustc::session::opt_span_bug_fmt::{{closure}} 9: rustc::ty::context::tls::with_opt::{{closure}} 10: rustc::ty::context::tls::with_context_opt 11: rustc::ty::context::tls::with_opt 12: rustc::session::opt_span_bug_fmt 13: rustc::session::span_bug_fmt 14: as rustc::ty::fold::TypeFolder<'gcx, 'tcx>>::fold_ty 15: as core::iter::traits::FromIterator<::Element>>::from_iter 16: rustc::ty::fold::TypeFoldable::fold_with 17: rustc::ty::structural_impls:: for &'tcx rustc::ty::TyS<'tcx>>::super_fold_with 18: as rustc::ty::fold::TypeFolder<'gcx, 'tcx>>::fold_ty 19: as core::iter::traits::Extend<::Element>>::extend 20: rustc::ty::fold::TypeFoldable::fold_with 21: rustc::traits::codegen::>::subst_and_normalize_erasing_regions 22: >::resolve 23: rustc_mir::interpret::step::>::step 24: rustc_mir::interpret::const_eval::eval_body_using_ecx 25: rustc_mir::interpret::const_eval::const_eval_provider 26: rustc::ty::maps::__query_compute::const_eval 27: rustc::ty::maps:: for rustc::ty::maps::queries::const_eval<'tcx>>::compute 28: rustc::ty::context::tls::with_context 29: rustc::dep_graph::graph::DepGraph::with_task_impl 30: rustc::ty::context::tls::with_related_context 31: rustc::ty::maps::plumbing::>::force_query_with_job 32: rustc::ty::maps::plumbing::>::get_query 33: rustc::ty::maps::>::const_eval 34: rustc_mir::transform::const_prop::ConstPropagator::eval_constant 35: as rustc::mir::visit::Visitor<'tcx>>::visit_terminator_kind 36: ::run_pass 37: rustc_mir::transform::optimized_mir::{{closure}} 38: rustc_mir::transform::optimized_mir 39: rustc::ty::maps::__query_compute::optimized_mir 40: rustc::ty::maps:: for rustc::ty::maps::queries::optimized_mir<'tcx>>::compute 41: rustc::ty::context::tls::with_context 42: rustc::dep_graph::graph::DepGraph::with_task_impl 43: rustc::ty::context::tls::with_related_context 44: rustc::ty::maps::plumbing::>::force_query_with_job 45: rustc::ty::maps::plumbing::>::get_query 46: rustc::ty::>::instance_mir 47: rustc_mir::monomorphize::collector::collect_items_rec 48: rustc_mir::monomorphize::collector::collect_items_rec 49: rustc_mir::monomorphize::collector::collect_items_rec 50: rustc_mir::monomorphize::collector::collect_items_rec 51: rustc_mir::monomorphize::collector::collect_items_rec 52: rustc_mir::monomorphize::collector::collect_crate_mono_items 53: rustc::util::common::time 54: rustc_codegen_llvm::base::collect_and_partition_mono_items 55: rustc::ty::maps:: for rustc::ty::maps::queries::collect_and_partition_mono_items<'tcx>>::compute 56: rustc::ty::context::tls::with_context 57: rustc::dep_graph::graph::DepGraph::with_task_impl 58: rustc::ty::context::tls::with_related_context 59: rustc::ty::maps::plumbing::>::force_query_with_job 60: rustc::ty::maps::plumbing::>::get_query 61: rustc_codegen_llvm::base::codegen_crate 62: ::codegen_crate 63: rustc::util::common::time 64: rustc_driver::driver::phase_4_codegen 65: rustc_driver::driver::compile_input::{{closure}} 66: rustc::ty::context::tls::enter_context 67: >::with 68: rustc::ty::context::TyCtxt::create_and_enter 69: rustc_driver::driver::compile_input 70: rustc_driver::run_compiler_with_pool 71: >::set 72: >::set 73: syntax::with_globals 74: as core::ops::function::FnOnce<()>>::call_once 75: __rust_maybe_catch_panic 76: rustc_driver::run 77: rustc_driver::main 78: std::rt::lang_start::{{closure}} 79: std::panicking::try::do_call 80: __rust_maybe_catch_panic 81: std::rt::lang_start_internal 82: main query stack during panic: #0 [const_eval] const-evaluating `>::PACKET_LEN` #1 [optimized_mir] processing `>::serialize` #2 [collect_and_partition_mono_items] collect_and_partition_mono_items end of query stack ```

Misc

• rustc 1.28.0-nightly (a805a2a5e 2018-06-10) running on x86_64-apple-darwin
• compiler flags: -C debuginfo=2 -C incremental

That's the const propagator again. Might be a regression but should be easy to fix.

[oli-obk]

I remember I tried reproducing this a while ago but failed to figure out how to use your version control ui.

Can you provide me with a commit id and a link I can paste into git clone?

[joshlf]

Disclaimer: I just tried this with nightly 2018-09-28, and the bug doesn't happen. In case this is still useful to you, though, here's how you can get it set up. Unfortunately this is going to be pretty complicated, but it's a lot less complicated than using our custom version control system.

$ git init
$ git fetch https://fuchsia.googlesource.com/garnet refs/changes/98/160698/18 && git checkout FETCH_HEAD
$ rm .cargo/config # Remove a Cargo config that only works if you've got the whole project checked out

Create the file public/rust/crates/zerocopy/Cargo.toml with the following contents:

[package]
name = "zerocopy"
version = "0.0.0"

Create the file bin/recovery_netstack/Cargo.toml with the following contents:

[package]
name = "recovery_netstack"
version = "0.0.0"

[dependencies]
zerocopy = { path = "../../public/rust/crates/zerocopy" }
byteorder = { version = "1.2.6", features = ["i128"] }
failure = "*"
rand = "0.4"

Then:

$ cd bin/recovery_netstack
$ cargo test

[oli-obk]

Oh wow, that's a mouth full. Since this seems fixed, I'll just close this issue.

Thanks for the guidelines, I bookmarked this for if/when I run into gerrit again

[joshlf]

I wouldn't take that as general-purpose advice. On any Gerrit page, there's a "Download" button that will give you some useful options. For a single-repo project, it should be very straightforward. Fuchsia is silly and uses a) a custom tool to manage and sync our multiple Git repos and, b) a GN build system which means that we don't have Cargo.toml files in our source.