diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2023-03-16 08:57:07 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-03-16 08:57:07 +0100 |
| commit | f0205d55ced197fbbee099ef682d5d9503bbb30d (patch) | |
| tree | 91ae4badf5de77ed71ed1d44d0bbb0eb4df7e221 /compiler/rustc_incremental/src | |
| parent | 36b82373e0e62201133c0287e33a7bf3172d4cb3 (diff) | |
| parent | d2b7604db9d3262fd9fe9ab39efb60652e252448 (diff) | |
| download | rust-f0205d55ced197fbbee099ef682d5d9503bbb30d.tar.gz rust-f0205d55ced197fbbee099ef682d5d9503bbb30d.zip | |
Rollup merge of #109166 - lcnr:define_opaque_types-explicit, r=oli-obk
make `define_opaque_types` fully explicit based on the idea of #108389. Moved `define_opaque_types` into the actual operations, e.g. `eq`, instead of `infcx.at` because normalization doesn't use `define_opaque_types` and even creates it's own `At` with a different `define_opaque_types` internally. Somewhat surprisingly, coherence actually relies on `DefineOpaqueTypes::Yes` for soundness which was revealed because I've incorrectly used `DefineOpaqueTypes::No` in `equate_impl_headers`. It feels concerning that even though this is the case, we still sometimes use `DefineOpaqueTypes::No` in coherence. I did not look into this as part of this PR as it is purely changing the structure of the code without changing behavior in any way. r? ```@oli-obk```
Diffstat (limited to 'compiler/rustc_incremental/src')
0 files changed, 0 insertions, 0 deletions
