Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of rust-lang#17882 - ShoyuVanilla:issue-17866, r=lnicola
fix: Panic while canonicalizing erroneous projection type Fixes rust-lang#17866 The root cause of rust-lang#17866 is quite horrifyng 😨 ```rust trait T { type A; } type Foo = <S as T>::A; // note that S isn't defined fn main() { Foo {} } ``` While inferencing alias type `Foo = <S as T>::A`; https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer.rs#L1388-L1398 the error type `S` in it is substituted by inference var in L1396 above as below; https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer/unify.rs#L866-L869 This new inference var's index is `1`, as the type inferecing procedure here previously inserted another inference var into same `InferenceTable`. But after that, the projection type made from the above then passed to the following function; https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/traits.rs#L88-L96 here, a whole new `InferenceTable` is made, without any inference var and in the L94, this table calls; https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer/unify.rs#L364-L370 And while registering `AliasEq` `obligation`, this obligation contains inference var `?1` made from the previous table, but this table has only one inference var `?0` made at L365. So, the chalk panics when we try to canonicalize that obligation to register it, because the obligation contains an inference var `?1` that the canonicalizing table doesn't have. Currently, we are calling `InferenceTable::new()` to do some normalizing, unifying or coercing things to some targets that might contain inference var that the new table doesn't have. I think that this is quite dangerous footgun because the inference var is just an index that does not contain the information which table does it made from, so sometimes this "foreign" index might cause panic like this case, or point at the wrong variable. This PR mitigates such behaviour simply by inserting sufficient number of inference vars to new table to avoid such problem. This strategy doesn't harm current r-a's intention because the inference vars that passed into new tables are just "unresolved" variables in current r-a, so this is just making sure that such "unresolved" variables exist in the new table
- Loading branch information