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.

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

ICE: panic adding warp::trace::request() combinator #108721

Closed
phlip9 opened this issue Mar 4, 2023 · 7 comments · Fixed by #108754
Closed

ICE: panic adding warp::trace::request() combinator #108721

phlip9 opened this issue Mar 4, 2023 · 7 comments · Fixed by #108754
Assignees
Labels
C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-critical Critical priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@phlip9
Copy link
Contributor

phlip9 commented Mar 4, 2023

Overview

While trying to upgrade rustc to the latest nightly, I stumbled across a Rust compiler panic. Here's a repo that contains a minimum-reproducible test case (well, reasonably compact): https://github.com/phlip9/rustc-warp-ice.

From my brief investigation, it appears that adding the warp::trace::request() combinator causes recent rustc nightly's to panic.

I've bisected the recent nightly versions; nightly-2023-02-09 is the first that starts panicking. Running with nightly-2023-02-08 builds successfully.

To reproduce the bug, just run cargo build. Running cargo check doesn't panic, though, since it seems to be codegen related.

Code

use std::convert::Infallible;
use std::net::SocketAddr;

use futures::future;
use hyper::service::make_service_fn;
use warp::Filter;

fn main() {
    let svc = warp::service(
        warp::path::end()
            .map(|| "Hello, world")
            // Try commenting out this line to make the program compile again.
            // vvvvvvvvvvvvvvvvvvvvvvvvvvv
            .with(warp::trace::request()),
    );
    let make_svc = make_service_fn(move |_| future::ok::<_, Infallible>(svc.clone()));
    let addr = SocketAddr::from(([127, 0, 0, 1], 0));
    tokio::spawn(hyper::Server::bind(&addr).serve(make_svc));
}

Meta

rustc --version --verbose:

rustc 1.69.0-nightly (ef934d9b6 2023-02-08)
binary: rustc
commit-hash: ef934d9b632b8ac00276558824664c104b92b5f0
commit-date: 2023-02-08
host: aarch64-apple-darwin
release: 1.69.0-nightly
LLVM version: 15.0.7

Error output

rustc-warp-ice$ cargo build
   Compiling rustc-warp-ice v0.1.0
error: internal compiler error: compiler/rustc_monomorphize/src/collector.rs:1076:22: unexpected unsized tail: hyper::server::server::new_svc::State<hyper::server::conn::AddrStream, futures::future::Ready<std::result::Result<warp::filter::service::FilteredService<warp::trace::internal::WithTrace<[closure@warp::trace::request::{closure#0}], warp::filter::map::Map<warp::filter::FilterFn<[closure@warp::path::end::{closure#0}]>, [closure@src/main.rs:11:18: 11:20]>>>, std::convert::Infallible>>, warp::filter::service::FilteredService<warp::trace::internal::WithTrace<[closure@warp::trace::request::{closure#0}], warp::filter::map::Map<warp::filter::FilterFn<[closure@warp::path::end::{closure#0}]>, [closure@src/main.rs:11:18: 11:20]>>>, hyper::common::exec::Exec, hyper::server::server::NoopWatcher>

thread 'rustc' panicked at 'Box<dyn Any>', /rustc/ef934d9b632b8ac00276558824664c104b92b5f0/compiler/rustc_errors/src/lib.rs:1644:9

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.69.0-nightly (ef934d9b6 2023-02-08) running on aarch64-apple-darwin

note: compiler flags: --crate-type bin -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=2 -C incremental=[REDACTED]

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

query stack during panic:
#0 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: could not compile `rustc-warp-ice`
Backtrace

thread 'rustc' panicked at 'Box<dyn Any>', /rustc/ef934d9b632b8ac00276558824664c104b92b5f0/compiler/rustc_errors/src/lib.rs:1644:9
stack backtrace:
   0: std::panicking::begin_panic::<rustc_errors::ExplicitBug>
   1: std::panic::panic_any::<rustc_errors::ExplicitBug>
   2: <rustc_errors::HandlerInner>::bug::<&alloc::string::String>
   3: <rustc_errors::Handler>::bug::<&alloc::string::String>
   4: rustc_middle::util::bug::opt_span_bug_fmt::<rustc_span::span_encoding::Span>::{closure#0}
   5: rustc_middle::ty::context::tls::with_opt::<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}
   6: rustc_middle::ty::context::tls::with_context_opt::<rustc_middle::ty::context::tls::with_opt<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}, !>
   7: rustc_middle::util::bug::opt_span_bug_fmt::<rustc_span::span_encoding::Span>
   8: rustc_middle::util::bug::bug_fmt
   9: rustc_monomorphize::collector::find_vtable_types_for_unsizing
  10: rustc_monomorphize::collector::find_vtable_types_for_unsizing
  11: <rustc_monomorphize::collector::MirNeighborCollector as rustc_middle::mir::visit::Visitor>::visit_rvalue
  12: rustc_monomorphize::collector::collect_neighbours
  13: rustc_monomorphize::collector::collect_items_rec
  14: rustc_monomorphize::collector::collect_items_rec
  15: rustc_monomorphize::collector::collect_items_rec
  16: rustc_monomorphize::collector::collect_items_rec
  17: rustc_monomorphize::collector::collect_items_rec
  18: rustc_monomorphize::collector::collect_items_rec
  19: rustc_monomorphize::collector::collect_items_rec
  20: rustc_monomorphize::collector::collect_items_rec
  21: rustc_monomorphize::collector::collect_items_rec
  22: rustc_monomorphize::collector::collect_items_rec
  23: rustc_monomorphize::collector::collect_items_rec
  24: rustc_monomorphize::collector::collect_items_rec
  25: rustc_monomorphize::collector::collect_items_rec
  26: rustc_monomorphize::collector::collect_items_rec
  27: rustc_monomorphize::collector::collect_items_rec
  28: rustc_monomorphize::collector::collect_items_rec
  29: rustc_monomorphize::collector::collect_items_rec
  30: rustc_monomorphize::collector::collect_items_rec
  31: rustc_monomorphize::collector::collect_items_rec
  32: rustc_monomorphize::collector::collect_items_rec
  33: rustc_monomorphize::collector::collect_items_rec
  34: rustc_monomorphize::collector::collect_items_rec
  35: rustc_monomorphize::collector::collect_items_rec
  36: rustc_monomorphize::collector::collect_items_rec
  37: rustc_monomorphize::collector::collect_items_rec
  38: rustc_monomorphize::collector::collect_items_rec
  39: rustc_monomorphize::collector::collect_items_rec
  40: <core::panic::unwind_safe::AssertUnwindSafe<rustc_data_structures::sync::par_for_each_in<alloc::vec::Vec<rustc_middle::mir::mono::MonoItem>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure#0}>::{closure#0}::{closure#0}> as core::ops::function::FnOnce<()>>::call_once
  41: <rustc_session::session::Session>::time::<(), rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}>
  42: rustc_monomorphize::collector::collect_crate_mono_items
  43: rustc_monomorphize::partitioning::collect_and_partition_mono_items
  44: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::with_task::<rustc_middle::ty::context::TyCtxt, (), (&rustc_data_structures::unord::UnordSet<rustc_span::def_id::DefId>, &[rustc_middle::mir::mono::CodegenUnit])>
  45: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::collect_and_partition_mono_items, rustc_query_impl::plumbing::QueryCtxt>
  46: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::collect_and_partition_mono_items
  47: rustc_codegen_ssa::base::codegen_crate::<rustc_codegen_llvm::LlvmCodegenBackend>
  48: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  49: <rustc_session::session::Session>::time::<alloc::boxed::Box<dyn core::any::Any>, rustc_interface::passes::start_codegen::{closure#0}>
  50: rustc_interface::passes::start_codegen
  51: <rustc_interface::passes::QueryContext>::enter::<<rustc_interface::queries::Queries>::ongoing_codegen::{closure#0}::{closure#0}, core::result::Result<alloc::boxed::Box<dyn core::any::Any>, rustc_errors::ErrorGuaranteed>>
  52: <rustc_interface::queries::Queries>::ongoing_codegen
  53: <rustc_interface::interface::Compiler>::enter::<rustc_driver_impl::run_compiler::{closure#1}::{closure#2}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_errors::ErrorGuaranteed>>
  54: rustc_span::with_source_map::<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#1}>::{closure#0}::{closure#0}>
  55: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

@phlip9 phlip9 added C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 4, 2023
@workingjubilee workingjubilee added the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label Mar 4, 2023
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Mar 4, 2023
@compiler-errors compiler-errors added the E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc label Mar 4, 2023
@compiler-errors
Copy link
Member

searched nightlies: from nightly-2023-02-01 to nightly-2023-03-04
regressed nightly: nightly-2023-02-09
searched commit range: bd39bbb...ef934d9
regressed commit: b082e80

bisected with cargo-bisect-rustc v0.6.5

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

cargo bisect-rustc --start=2023-02-01 --regress=ice

Regressed in #107688, cc @lukas-code @jackh726

@compiler-errors compiler-errors removed the E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc label Mar 4, 2023
@compiler-errors
Copy link
Member

I have (a couple of) fixes for this PR, but I really need this minimized :/

@apiraino
Copy link
Contributor

apiraino commented Mar 7, 2023

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical +E-needs-mcve

@rustbot rustbot added E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example P-critical Critical priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 7, 2023
@Noratrieb
Copy link
Member

I'll work on minimizing it in the meantime

@Noratrieb
Copy link
Member

I've started some work I https://github.com/Nilstrieb/icefun but it's extremely miserable because of hypers internal highly entangled generic mess

@Noratrieb
Copy link
Member

I tried some more and I'm convinced that this ICE here cannot be minimized in a reasonable amount of time. The ICE is very brittle and disappears with seemingly random changes and the codebase is huge and highly generic with many bounds.
I'll leave the label here, but I don't recommend anyone working on this (unless you hate fun and want to waste your time).

@Noratrieb Noratrieb removed their assignment Mar 7, 2023
JohnTitor added a commit to JohnTitor/rust that referenced this issue Mar 8, 2023
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous

Fixes rust-lang#108721

The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See:

https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606

... Compared to the analogous loop in the new solver:

https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512

To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context.

--

Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/

r? types
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 8, 2023
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous

Fixes rust-lang#108721

The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See:

https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606

... Compared to the analogous loop in the new solver:

https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512

To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context.

--

Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/

r? types
JohnTitor added a commit to JohnTitor/rust that referenced this issue Mar 8, 2023
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous

Fixes rust-lang#108721

The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See:

https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606

... Compared to the analogous loop in the new solver:

https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512

To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context.

--

Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/

r? types
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 8, 2023
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous

Fixes rust-lang#108721

The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See:

https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606

... Compared to the analogous loop in the new solver:

https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512

To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context.

--

Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/

r? types
@bors bors closed this as completed in 9408af9 Mar 9, 2023
@Noratrieb
Copy link
Member

We don't have a test, but given that we won't get a test from this report, keeping it open doesn't seem useful.

MaxFangX pushed a commit to lexe-app/lexe-public that referenced this issue Mar 14, 2023
* Now that <rust-lang/rust#108721> is landed
  on rust master, we can push the nightly version to bleeding edge again
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Apr 8, 2024
…errors

Restore `pred_known_to_hold_modulo_regions`

As requested by `@lcnr` in rust-lang#123275 (comment) this PR restores `pred_known_to_hold_modulo_regions` to fix that "unexpected unsized tail" beta regression.

This also adds the reduced repro from rust-lang#123275 (comment) as a sub-optimal test is better than no test at all, and it'll also cover rust-lang#108721. It still ICEs on master, even though https://github.com/phlip9/rustc-warp-ice doesn't on nightly anymore, since rust-lang#122493.

Fixes rust-lang#123275.

r? `@compiler-errors` but feel free to close if you'd rather have a better test instead
cc `@wesleywiser` who had signed up to do the revert

Will need a backport if we go with this PR: `@rustbot` label +beta-nominated
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 8, 2024
Rollup merge of rust-lang#123578 - lqd:regression-123275, r=compiler-errors

Restore `pred_known_to_hold_modulo_regions`

As requested by `@lcnr` in rust-lang#123275 (comment) this PR restores `pred_known_to_hold_modulo_regions` to fix that "unexpected unsized tail" beta regression.

This also adds the reduced repro from rust-lang#123275 (comment) as a sub-optimal test is better than no test at all, and it'll also cover rust-lang#108721. It still ICEs on master, even though https://github.com/phlip9/rustc-warp-ice doesn't on nightly anymore, since rust-lang#122493.

Fixes rust-lang#123275.

r? `@compiler-errors` but feel free to close if you'd rather have a better test instead
cc `@wesleywiser` who had signed up to do the revert

Will need a backport if we go with this PR: `@rustbot` label +beta-nominated
phlip9 added a commit to lexe-app/lexe-public that referenced this issue Nov 26, 2024
* Now that <rust-lang/rust#108721> is landed
  on rust master, we can push the nightly version to bleeding edge again
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-critical Critical priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants