-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
infinite recursion with TAIT and replace_opaque_types_with_inference_vars
in project
#109268
Comments
We already do this though, unless you meant something different-- rust/compiler/rustc_trait_selection/src/traits/fulfill.rs Lines 118 to 128 in c50c62d
|
Ah, but |
This now reports an overflow instead of freezing rustc or otherwise crashing. It's still wrong, but easier to debug |
seems this does not hang anymore |
Originally regressed (no hang -> hang) in cargo-bisect-rustc outputRegression in nightly-2022-08-19 fetching https://static.rust-lang.org/dist/2022-08-18/channel-rust-nightly-git-commit-hash.txt
ERROR: no CI builds available between 9c20b2a and 0b79f75 within last 167 days unregressed (hang -> no hang) in |
this causes rustc to freeze. This is similar to
rust/tests/ui/type-alias-impl-trait/issue-53398-cyclic-types.rs
Lines 1 to 10 in c50c62d
The only reason that this test does not hang is the following hack in fulfillment
rust/compiler/rustc_trait_selection/src/traits/fulfill.rs
Lines 711 to 733 in c50c62d
because of this hack we only try to prove
<Foo as FnOnce<()>>::Output == Foo
usingevaluate_obligation
which usesDefiningAnchor::Bubble
instead of theDefiningAnchor::Bind
used by typeck and fulfill directly.The reason this breaks when using
DefiningAnchor::Bind
is the following:we call
project_and_unify_type
for<Foo as FnOnce<()>>::Output == Foo
which normalizes<Foo as FnOnce<()>>::Output
toFoo
.The issue is that we then replace
Foo
with a new inference variable (if we useDefiningAnchor::Bind
)?n
and add the item bounds ofFoo
as obligations on that new inference variable:rust/compiler/rustc_trait_selection/src/traits/project.rs
Lines 280 to 286 in c50c62d
This adds a new obligation
<?n as FnOnce<()>>::Output == Foo
to the fulfillment context, even though?n
was already constrained toFoo
again. The easiest fix is to resolve inference variables in obligations before adding them to the fulfillment context.The text was updated successfully, but these errors were encountered: