diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2022-12-22 19:36:13 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-12-22 19:36:13 +0100 |
| commit | 548d49c7897e91ff6f703c00b3a2ff269b894fdc (patch) | |
| tree | ede72316e486c7f220b87e692b4330b7a4a83f01 /compiler/rustc_codegen_gcc | |
| parent | 17b3b97e08e3266e8e2ce0e0c0b2e6f19267f610 (diff) | |
| parent | c1181e12243f078b1cc562249569e6766d90f8f6 (diff) | |
| download | rust-548d49c7897e91ff6f703c00b3a2ff269b894fdc.tar.gz rust-548d49c7897e91ff6f703c00b3a2ff269b894fdc.zip | |
Rollup merge of #105847 - compiler-errors:issue-104396, r=oli-obk
Ensure param-env is const before calling `eval_to_valtree`
Other queries call `ParamEnv::with_const` *inside* of the query itself (e.g. `const_eval_global_id_for_typeck`), so this could alternatively be moved into the provider of `eval_to_valtree` instead. I don't have a particularly strong opinion, though *theoretically* caching is better if we make the query keys more constrained.
I'm not exactly sure how this is an effect of the `-Zmir-opt-level=3` flag. Maybe something about the inliner causes us to inline an unevaluated const into a body where it can be evaluated, but where it has not yet been normalized.
This seems likely, since we're inlining `from_fn_1::<{ N / 2 }, _>` in `from_fn_2`, which means that we will need to evaluate that constant during the const prop pass after inlining.
Fixes #104396
Diffstat (limited to 'compiler/rustc_codegen_gcc')
0 files changed, 0 insertions, 0 deletions
