-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
Gather CTFE support code in const_eval and cleanup that file #67316
Copy link
Copy link
Closed
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)C-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Metadata
Metadata
Assignees
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)C-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Follow-up to #66866: @oli-obk agreed to move
eval_const_fn_calltoconst_eval.rs. Generally I propose thatinterpshould not contain code that is only needed by CTFE. We haveintern.rsandsnapshot.rsin there are they need some very deep access to Miri engine internals, but at least those are separate modules.Also,
const_eval.rshas grown pretty messy, and it does not seem like the order of definitions in that file follows any principle. We could split the file into two similar to what I did with Miri:const_eval/engine.rsfor implementing the machine trait and defining everything that is needed during CTFE execution, andconst_eval/eval.rsfor defining the setup functions and all the glue that connects CTFE with the rest of the compiler.