Open wxie7 opened 1 week ago
I can reproduce the hang without any of the provided compiler flags.
RUSTC_LOG=debug
, excerpt:
rustc_trait_selection::traits::fulfill::process_obligation
0ms DEBUG rustc_trait_selection::traits::fulfill pre-resolve, obligation=Obligation(predicate=Binder { value: TraitPredicate(<_ as std::marker::Sized>, polarity:Positive), bound_vars: [] }, depth=129)
rustc_trait_selection::traits::fulfill::process_trait_obligation trait_obligation=Obligation(predicate=Binder { value: TraitPredicate(<(&mut std::option::Option<_>, _, _) as std::marker::Sized>, polarity:Positive), bound_vars: [] }, depth=129)
rustc_trait_selection::traits::select::poly_select obligation=Obligation(predicate=Binder { value: TraitPredicate(<(&mut std::option::Option<_>, _, _) as std::marker::Sized>, polarity:Positive), bound_vars: [] }, depth=129)
rustc_trait_selection::traits::select::candidate_from_obligation stack=TraitObligationStack(Obligation(predicate=Binder { value: TraitPredicate(<(&mut std::option::Option<_>, _, _) as std::marker::Sized>, polarity:Positive), bound_vars: [] }, depth=129))
rustc_middle::ty::print::default_print_def_path def_id=DefId(2:45807 ~ core[add1]::option::Option), args=[?11t]
0ms DEBUG rustc_middle::ty::print key=DefKey { parent: Some(DefIndex(9544)), disambiguated_data: DisambiguatedDefPathData { data: TypeNs("Option"), disambiguator: 0 } }
rustc_middle::ty::print::default_print_def_path def_id=DefId(2:36054 ~ core[add1]::marker::Sized), args=[(&'?391 mut std::option::Option<?11t>, ?403t, ?403t)]
0ms DEBUG rustc_middle::ty::print key=DefKey { parent: Some(DefIndex(3424)), disambiguated_data: DisambiguatedDefPathData { data: TypeNs("Sized"), disambiguator: 0 } }
14ms DEBUG rustc_errors::diagnostic Created new diagnostic
rustc_middle::ty::print::default_print_def_path def_id=DefId(2:45807 ~ core[add1]::option::Option), args=[?11t]
0ms DEBUG rustc_middle::ty::print key=DefKey { parent: Some(DefIndex(9544)), disambiguated_data: DisambiguatedDefPathData { data: TypeNs("Option"), disambiguator: 0 } }
rustc_middle::ty::print::default_print_def_path def_id=DefId(2:45807 ~ core[add1]::option::Option), args=[?11t]
0ms DEBUG rustc_middle::ty::print key=DefKey { parent: Some(DefIndex(9544)), disambiguated_data: DisambiguatedDefPathData { data: TypeNs("Option"), disambiguator: 0 } }
rustc_middle::ty::print::default_print_def_path def_id=DefId(2:45807 ~ core[add1]::option::Option), args=[?11t]
0ms DEBUG rustc_middle::ty::print key=DefKey { parent: Some(DefIndex(9544)), disambiguated_data: DisambiguatedDefPathData { data: TypeNs("Option"), disambiguator: 0 } }
// repeats the two lines above ad infinitum
// ...
Minimized reproducer:
fn main() {
let z = Default::default();
let mut w = (z, z);
w = z;
}
Correctly gives an error on rust 1.77.0. Hangs on rust 1.78.0.
@rustbot label +regression-from-stable-to-stable
Another reproducer:
fn conjure<T>() -> T {
panic!()
}
fn require_same<T>(_: T, _: T) {}
fn main() {
let z = conjure();
require_same((z, z), z);
}
@rustbot labels -A-traits
Re-adding A-traits (trait system) cuz https://github.com/rust-lang/rust/issues/132673#issuecomment-2458746647 still hangs due to the trait solver. Just because you don't see any obvious trait bounds in the code doesn't mean it's not related to traits :P We still have implicit Sized
bounds. The solver still tries to process ?x: Sized
and (?y, ?y): Sized
.
From nightly-2024-02-23
. https://github.com/rust-lang/rust/compare/3406ada96f8e16e49e947a91db3eba0db45245fa...397937d812852f9bbeb671005cb399dbcb357cde
Not super clear what may be the culprit as we don't have PR artifacts anymore, but #119989 involved the trait system.
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-high
Not super clear what may be the culprit as we don't have PR artifacts anymore, but #119989 involved the trait system.
cc @lcnr for perhaps insights here
Caused by #119989 as we previously got an error when relating ?x <: ?y
and ?x <: wrapper<?y>
but now these two constraints cause infinite recursion and only error once they hit the recursion limit.
from what I can tell this hang does not occur in process_obligation
🤔 process_obligation
slowly increments the recursion depth. We then get ordinary overflow errors. However, we did exponentially grow the type size of the affected tuples, pretty much ending up with a type tuple_n = (tuple_n-1, tuple_n-1)
. We then get a hang when printing that type for diagnostics. Looking at the RUSTC_LOG
for the original example,we're just stuck in type printing.
Code
Affected release channels
Rust Version
rustc 1.84.0-nightly (bc5cf994d 2024-11-05) binary: rustc commit-hash: bc5cf994db9fb46712cefd89f78ad7fc51f184a2 commit-date: 2024-11-05 host: x86_64-unknown-linux-gnu release: 1.84.0-nightly LLVM version: 19.1.3
Current error output
No response
Backtrace
Anything else?