-
Notifications
You must be signed in to change notification settings - Fork 0
Description
The issue is that hitting the recursion limit of the proof tree visitor results in the incorrect behavior. https://github.com/rust-lang/rust/blob/f21b4c0888ca6a388fcf9365fc0044fa0642ab98/compiler/rustc_trait_selection/src/solve/inspect/analyse.rs#L443-L450
My understanding from https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/crater.20triage.20.3A3/near/572970037 is the following, but not confident here:
We check whether the reason unsized coercions fail is due to a failing where-clause of a Unsize or CoerceUnsized impl iirc. This should only matter in case the coercion is actually required, and is purely for diagnostics. Using the coercion is otherwise always wrong.
However, if we encounter the recursion limit of the ProoTreeVisitor during this check, we incorrectly emit a failiing Coerce goal even though the coercion is not necessary.
Need to either expose a way to decide what to do when hitting the recursion limit, or change the structure of this visitor is some other way. This issue feels fairly easy to solve, doing so in a nice way seems potentially challenging or non-trivial.
Affects gl_engine and multiple other users of glium apparently :>
Metadata
Metadata
Assignees
Labels
Type
Projects
Status