Fix "var_universe invoked on bound variable" crash #649
Conversation
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.
|
So, I think this problem (or a related one) came up in the variance PR. (See this commit as a fix). I guess, I'm a little bit unsure on if the "root" variable also corresponds to the resolved type. In that commit, we're worried about always getting back the same inference var. For this PR, I guess I'm somewhat worried about the arbitrary normalize twice. This is definitely something I want @nikomatsakis to comment on, because I don't know enough about ena and the semantics of probing for variables. |
|
That's a different problem. The case in the commit you reference is that multiple inference variables of the same kind (i.e. general, or integer, or float) that don't have a value yet are unified. Here, it's about when e.g. an integer variable is unified with a general variable. That works differently: variables of different kind aren't simply unified as variables, but rather the general type variable's value is set to the integer variable (just like if we were unifying with a concrete type instead of an integer variable). That's why a general type variable can never resolve to another general type variable, but it can resolve to an integer or float variable. Here's the same code in rustc (it just recurses instead of normalizing twice, but the effect should be the same). |
|
Thanks for the clarification! @bors r+ |
|
📌 Commit f3b3156 has been approved by |
|
☀️ Test successful - checks-actions |
This should fix rust-lang/rust-analyzer#5495.
unify_ty_tycallsnormalize_ty_shallowon 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_shallowprobes twice, to make sure to fully resolve the variable.