-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure param-env is const before calling eval_to_valtree
#105847
Conversation
r? @estebank (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
self.ctfe_query(span, |tcx| tcx.eval_to_valtree(self.param_env.and(cid)))? | ||
.unwrap_or_else(|| bug!("unable to create ValTree for {uv:?}")) | ||
self.ctfe_query(span, |tcx| { | ||
tcx.eval_to_valtree(self.param_env.with_const().and(cid)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the eval_to_valtree query is just missing a remap_constness
rust/compiler/rustc_middle/src/query/mod.rs
Line 1013 in cbc70ff
query eval_to_valtree( |
I'll be so happy when the constness field is finally gone
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oli-obk doesn't remap_env_constness
set the param-env constness to not const?
Also, none of the other eval-like queries use remap_env_constness
.
I don't think I should be using @rustbot ready |
@bors r+ rollup |
…i-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 rust-lang#104396
…i-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 rust-lang#104396
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#105567 (KCFI test: Also support LLVM 16 output) - rust-lang#105847 (Ensure param-env is const before calling `eval_to_valtree`) - rust-lang#105983 (Add a missing early return in drop tracking `handle_uninhabited_return`) - rust-lang#106027 (rustdoc: simplify CSS and DOM for more-scraped-examples) - rust-lang#106035 (Migrate search tab title color to CSS variable) - rust-lang#106037 (Add regression test for rust-lang#94293) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…i-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 rust-lang#104396
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#105567 (KCFI test: Also support LLVM 16 output) - rust-lang#105847 (Ensure param-env is const before calling `eval_to_valtree`) - rust-lang#105983 (Add a missing early return in drop tracking `handle_uninhabited_return`) - rust-lang#106027 (rustdoc: simplify CSS and DOM for more-scraped-examples) - rust-lang#106035 (Migrate search tab title color to CSS variable) - rust-lang#106037 (Add regression test for rust-lang#94293) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
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 ofeval_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 }, _>
infrom_fn_2
, which means that we will need to evaluate that constant during the const prop pass after inlining.Fixes #104396