diff options
| author | Dylan DPC <99973273+Dylan-DPC@users.noreply.github.com> | 2022-08-30 16:56:07 +0530 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-08-30 16:56:07 +0530 |
| commit | 9cfd161cd5b2e3b53c488086f8000aea0c21b0b2 (patch) | |
| tree | 1a05c18d4790c085dcab0deb7a156a2a632291ad /compiler/rustc_codegen_gcc | |
| parent | 548ed409af7fc161859ffd864cedacd7af8748d6 (diff) | |
| parent | fb12f40f3b157b0f7dafe393b09bbdcf2e156c11 (diff) | |
| download | rust-9cfd161cd5b2e3b53c488086f8000aea0c21b0b2.tar.gz rust-9cfd161cd5b2e3b53c488086f8000aea0c21b0b2.zip | |
Rollup merge of #99928 - compiler-errors:issue-99914, r=oli-obk
Do not leak type variables from opaque type relation The "root cause" is that we call `InferCtxt::resolve_vars_if_possible` (3d9dd681f520d1d59f38aed0056cf9474894cc74) on the types we get back in `TypeError::Sorts` since I added a call to it in `InferCtxt::same_type_modulo_infer`. However if this `TypeError` comes from a `InferCtxt::commit_if_ok`, then it may reference type variables that do not exist anymore, which is problematic. We avoid this by substituting the `TypeError` with the types we had before being generalized while handling opaques. This is kinda gross, and I feel like we can get the same issue from other places where we generalize type/const inference variables. Maybe not? I don't know. Fixes #99914 Fixes #99970 Fixes #100463
Diffstat (limited to 'compiler/rustc_codegen_gcc')
0 files changed, 0 insertions, 0 deletions