Open matteomeli opened 3 years ago
Can reproduce
Root source of the bug seems to be the recur-fn
crate: https://github.com/Jason5Lee/rust-recur-fn/blob/master/src/lib.rs
Reduced to:
pub trait RecurFn<Arg, Output> {
fn body(&self, recur: impl Fn(Arg) -> Output, arg: Arg) -> Output;
fn call(&self, arg: Arg) -> Output;
}
pub struct Closure<F>(F);
impl<Arg, Output, F> RecurFn<Arg, Output> for Closure<F>
where
F: Fn(&dyn Fn(Arg) -> Output, Arg) -> Output,
{
fn body(&self, recur: impl Fn(Arg) -> Output, arg: Arg) -> Output {
self.0(&recur, arg)
}
fn call(&self, arg: Arg) -> Output {
self.0(&|arg| self.call(arg), arg)
}
}
Seems to hang in chalk, not rust-analyzer.
cc @flodiebold
This hangs on a Implements(Closure<F>: RecurFn<?0.0, ?0.1>)
.
These closure goals are really hard to debug, with debug output like this:
[DEBUG hir_ty::traits::chalk] impl ImplId(9282): Closure<?0.2>: RecurFn<?0.0, ?0.1> where [for<> Implemented(^1.2: Fn<2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^3.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^3.0]>>>::Output = ^3.1)] + 'static), ?1 := ^1.0]>>), for<> AliasEq(<^1.2 as FnOnce<2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^3.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^3.0]>>>::Output = ^3.1)] + 'static), ?1 := ^1.0]>>>::Output = ^1.1)]
[DEBUG hir_ty::traits::chalk] impl_datum: ImplDatumBound { trait_ref: Closure<[?0 := ^0.2]> as RecurFn<^0.0, ^0.1>, where_clauses: [for<> Implemented(^1.2: Fn<2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^3.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^3.0]>>>::Output = ^3.1)] + 'static), ?1 := ^1.0]>>), for<> AliasEq(<^1.2 as FnOnce<2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^3.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^3.0]>>>::Output = ^3.1)] + 'static), ?1 := ^1.0]>>>::Output = ^1.1)] }
Yeah, and it's really annoying that we can't easily reproduce these in the Chalk test harness... Might this be rust-lang/chalk#688 again?
Yeah, and it's really annoying that we can't easily reproduce these in the Chalk test harness... Might this be rust-lang/chalk#688 again?
I was going to say no, but looking at it a bit more it does start creating longer goals:
(FnOnce::Output<[?0 := !0_3, ?1 :=
2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^2.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^2.0]>>>::Output = FnOnce::Output<[?0 := !0_3, ?1 :=
2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^4.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^4.0]>>>::Output = FnOnce::Output<[?0 := !0_3, ?1 :=
2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^6.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^6.0]>>>::Output = ^6.1)] + 'static), ?1 := ^4.0]>]>)] + 'static), ?1 := ^2.0]>]>)] + 'static), ?1 := ^0.0]>]> <: FnOnce::Output<[?0 := !0_3, ?1 :=
2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^2.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^2.0]>>>::Output = FnOnce::Output<[?0 := !0_3, ?1 :=
2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^4.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^4.0]>>>::Output = FnOnce::Output<[?0 := !0_3, ?1 :=
2<[?0 := (&'static dyn for<type> [for<> Implemented(^1.0: Fn<1<[?0 := ^6.0]>>), for<> AliasEq(<^1.0 as FnOnce<1<[?0 := ^6.0]>>>::Output = ^6.2)] + 'static), ?1 := ^4.0]>]>)] + 'static), ?1 := ^2.0]>]>)] + 'static), ?1 := ^0.0]>]>)
So it probably is another instance of the same problem.
It would be nice to get better debug output about the closure - closure kind, inputs/output getting lowered, upvars.
I'm actually looking into rust-lang/chalk#688 right now and having a hard time reproducing
It would be nice to get better debug output about the closure - closure kind, inputs/output getting lowered, upvars.
That's in the RustIrDatabase
callbacks, closure_inputs_and_output
and closure_upvars
, right? It doesn't look like those ever get called for this reproduction.
I ran into various issues while trying to use this crate. As soon as I import the crate and start using functions/types from it, RA gets stuck on formatting when trying to save the file. After that the extension becomes unusable, syntax highlighting is broken, formatting is broken, code navigation is broken, run/debug button don't work, etc. Tried to restart server but no luck, only way seems to be to close and restart VS Code, but same problem is encountered again as soon as the same file is edited and/or saved.
My guess is that the root of the problem might be related to recursive closures analysis, which fn-memo (and its dependency recur-fn) are about. But can't be sure.
Windows WSL2 Ubuntu rust-analyzer version: 2021-03-01 (5df3ee8) Cargo TOML:
Minimal example. A lib project only having lib.rs containing the following: