-
Notifications
You must be signed in to change notification settings - Fork 0
obfd: could not resolve upvar #197
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
Labels
from-crater
A regression found via a crater run, not part of our test suite
Comments
Non-defining revealing recursive use: use std::pin::Pin;
async fn walk_dir<C>(cb: &C)
where
C: Fn() -> Pin<Box<dyn Future<Output = ()> + 'static>>,
{
async move {
walk_dir(cb).await;
}
.await
}
fn main() {} This is expected to result in a infinite/recursive/cyclical opaque error, but not an ICE. Unfortunately it would also be very interesting to understand why this code does not ICE: use std::pin::Pin;
async fn walk_dir<C>(cb: &C)
where
C: Fn() -> Pin<Box<dyn Future<Output = ()> + 'static>>,
{
async move {
Box::pin(walk_dir(cb)).await; // <- box pin!
}
.await
}
fn main() {} |
lmao: async fn walk_dir(cb: &()) {
let fut = walk_dir(cb);
}
fn main() {} |
Zalathar
added a commit
to Zalathar/rust
that referenced
this issue
May 6, 2025
…in-upvar, r=lcnr Be a bit more relaxed about not yet constrained infer vars in closure upvar analysis See the writeup in `tests/ui/closures/opaque-upvar.rs`. TL;DR is that this has to do with the fact that the recursive revealing uses, which have not yet been constrained from the defining use by the time that closure upvar inference is performed, remain as infer vars during upvar analysis. We don't really care, though, since anywhere we structurally match on a type in upvar analysis, we already call `structurally_resolve_type` right before `.kind()`, which would emit a true ambiguity error. Fixes rust-lang/trait-system-refactor-initiative#197 r? lcnr
Zalathar
added a commit
to Zalathar/rust
that referenced
this issue
May 6, 2025
…in-upvar, r=lcnr Be a bit more relaxed about not yet constrained infer vars in closure upvar analysis See the writeup in `tests/ui/closures/opaque-upvar.rs`. TL;DR is that this has to do with the fact that the recursive revealing uses, which have not yet been constrained from the defining use by the time that closure upvar inference is performed, remain as infer vars during upvar analysis. We don't really care, though, since anywhere we structurally match on a type in upvar analysis, we already call `structurally_resolve_type` right before `.kind()`, which would emit a true ambiguity error. Fixes rust-lang/trait-system-refactor-initiative#197 r? lcnr
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 6, 2025
Rollup merge of rust-lang#140678 - compiler-errors:dont-ice-on-infer-in-upvar, r=lcnr Be a bit more relaxed about not yet constrained infer vars in closure upvar analysis See the writeup in `tests/ui/closures/opaque-upvar.rs`. TL;DR is that this has to do with the fact that the recursive revealing uses, which have not yet been constrained from the defining use by the time that closure upvar inference is performed, remain as infer vars during upvar analysis. We don't really care, though, since anywhere we structurally match on a type in upvar analysis, we already call `structurally_resolve_type` right before `.kind()`, which would emit a true ambiguity error. Fixes rust-lang/trait-system-refactor-initiative#197 r? lcnr
fixed by rust-lang/rust#140678 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://github.com/The-Noah/obfd/tree/32ba2512d01b2e45b61cba55cd172450dd8aef0a
https://crater-reports.s3.amazonaws.com/pr-133502-9/try%232bef413807188d2b84cd7cc67c6e5bc4a5952d95/gh/The-Noah.obfd/log.txt
The text was updated successfully, but these errors were encountered: