-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
var_universe invoked on bound variable when analysis-stating --with-deps #5495
Labels
A-ty
type system / type inference / traits / method resolution
Comments
Seems like we need to add |
Going wrong here. Minimized:
|
Nice minimization, thanks @detrumi! |
flodiebold
added a commit
to flodiebold/chalk
that referenced
this issue
Nov 6, 2020
This should fix rust-lang/rust-analyzer#5495. `unify_ty_ty` calls `normalize_ty_shallow` on both types and then assumes that they can't be bound variables. With integer type variables, this assumption was broken, because you could have a general type variable resolving to an integer type variable resolving to i32. To fix this, `normalize_ty_shallow` probes twice, to make sure to fully resolve the variable.
Found it, the minimization was helpful. It's a bug in Chalk's unification logic. |
bors
added a commit
to rust-lang/chalk
that referenced
this issue
Nov 8, 2020
… r=jackh726 Fix "var_universe invoked on bound variable" crash This should fix rust-lang/rust-analyzer#5495. `unify_ty_ty` calls `normalize_ty_shallow` on both types and then assumes that they can't be bound variables. With integer type variables, this assumption was broken, because you could have a general type variable resolving to an integer type variable resolving to i32. To fix this, `normalize_ty_shallow` probes twice, to make sure to fully resolve the variable.
@flodiebold is this fixed? |
In Chalk yes, but we don't have that Chalk version yet. |
Should be fixed now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Haven't tried to minimize this yet, but I don't think I've seen an error quite like this before:
cc @flodiebold
The text was updated successfully, but these errors were encountered: