Skip to content

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

Closed
lcnr opened this issue May 5, 2025 · 3 comments · Fixed by rust-lang/rust#140678
Closed

obfd: could not resolve upvar #197

lcnr opened this issue May 5, 2025 · 3 comments · Fixed by rust-lang/rust#140678
Assignees
Labels
from-crater A regression found via a crater run, not part of our test suite

Comments

@lcnr
Copy link
Contributor

lcnr commented May 5, 2025

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

[INFO] [stdout] error: internal compiler error: compiler/rustc_mir_build/src/builder/expr/as_place.rs:260:67: could not resolve upvar: LocalVarId(HirId(DefId(0:17 ~ obfd[57aa]::walk_dir).9)) + [Deref]
[INFO] [stdout]   --> src/main.rs:72:39
[INFO] [stdout]    |
[INFO] [stdout] 72 | async fn walk_dir<'a, C>(path: &Path, cb: &C)
[INFO] [stdout]    |                                       ^^
[INFO] [stdout] 
@lcnr lcnr added the from-crater A regression found via a crater run, not part of our test suite label May 5, 2025
@compiler-errors
Copy link
Member

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() {}

@compiler-errors
Copy link
Member

lmao:

async fn walk_dir(cb: &()) {
    let fut = walk_dir(cb);
}

fn main() {}

@lcnr lcnr moved this from unknown to in progress in -Znext-solver=globally May 5, 2025
@compiler-errors compiler-errors self-assigned this May 5, 2025
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
@lcnr
Copy link
Contributor Author

lcnr commented May 6, 2025

fixed by rust-lang/rust#140678

@lcnr lcnr closed this as completed May 6, 2025
@lcnr lcnr moved this from in progress to done in -Znext-solver=globally May 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
from-crater A regression found via a crater run, not part of our test suite
Projects
2 participants