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