rust/compiler/rustc_mir_dataflow
Dylan DPC 828caa80a9
Rollup merge of #110930 - b-naber:normalize-elaborate-drops, r=cjgillot
Don't expect normalization to succeed in elaborate_drops

Fixes https://github.com/rust-lang/rust/issues/110682

This was exposed through the changes in https://github.com/rust-lang/rust/pull/109247, which causes more things to be inlined. Inlining can happen before monomorphization, so we can't expect normalization to succeed. In the elaborate_drops analysis we currently have [this call](033aa092ab/compiler/rustc_mir_dataflow/src/elaborate_drops.rs (L278)) to `normalize_erasing_regions`, which ICEs when normalization fails. The types are used to infer [whether the type needs a drop](033aa092ab/compiler/rustc_mir_dataflow/src/elaborate_drops.rs (L374)), where `needs_drop` itself [uses `try_normalize_erasing_regions`](033aa092ab/compiler/rustc_middle/src/ty/util.rs (L1121)).

~[`instance_mir`](https://doc.rust-lang.org/stable/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.instance_mir) isn't explicit about whether it expects the instances corresponding to the `InstanceDef`s to be monomorphized (though I think in all other contexts the function is used post-monomorphization), so the use of `instance_mir` in inlining doesn't necessarily seem wrong to me.~
2023-05-17 19:11:53 +05:30
..
src Rollup merge of #110930 - b-naber:normalize-elaborate-drops, r=cjgillot 2023-05-17 19:11:53 +05:30
Cargo.toml Add `rustc_fluent_macro` to decouple fluent from `rustc_macros` 2023-04-18 18:56:22 +00:00
messages.ftl Simplify message paths 2023-03-11 22:51:57 +01:00