Detect cyclic subtypes during generalization in the new solver#157786
Detect cyclic subtypes during generalization in the new solver#157786PrazwalR wants to merge 1 commit into
Conversation
|
changes to the core type system cc @lcnr |
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @mati865 (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
Why was this reviewer chosen?The reviewer was selected based on:
|
|
Hi, thank your for your PR. I have a question regarding LLM tools: Was and how LLMs been used to create this PR? |
|
Yes, I used Claude Code to help with this PR. It helped me navigate the relevant code paths and understand how sub_unification_table relates to the generalizer's occurs check, drafting the fix and tests based on my reading of #140375 and #119989,I reviewed and validated everything myself ran the full UI test suite and confirmed the MCVEs produce expected diagnostics. The core insight (sub-unification root equality implies a cyclic type, safe to check only under next_trait_solver()) came from lcnr's comment in #140375; Claude helped me turn that into working code. |
The generalizer's occurs check only catches the case where the type variable being instantiated occurs directly in the instantiated type. If the two are merely related via subtyping (e.g.
?a <: &?bwhere?aand?bwere already sub-unified), each fulfillment round grows the inferred type by one level until the recursion limit is hit. The resulting overflow is then reported on whichever unrelated obligation trips the limit first, with a misleading span and message: