-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Add simpler entry points to const eval for common usages. #66877
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
Add simpler entry points to const eval for common usages. #66877
Conversation
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
19a0666 to
da16058
Compare
src/librustc/mir/interpret/mod.rs
Outdated
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.
Why are these added in this file, as opposed to next to const_eval or so?
Scrolling over this file, the only coherent description of it that I can come up with is "random stuff".^^
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.
They need to be within librustc as they are used inside it. I'm not sure where the best place is.
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.
maybe just put them into a submodule of this module. queries could work as a name.
da16058 to
15dbbe1
Compare
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.
Maybe rename the query to const_eval_global_id (or if it is unused except forin the three wrappers, name it const_eval_internal and leave a comment on it suggesting the use of the wrappers).
I worry that otherwise we'll just reintroduce calls to it that manually do all the boilerplate
15dbbe1 to
88af3a9
Compare
|
I introduced another wrapper |
This comment has been minimized.
This comment has been minimized.
88af3a9 to
150f5a9
Compare
|
So we have |
|
Ping from Triage: Hi @Skinny121 - any updates? |
150f5a9 to
f84e972
Compare
|
@RalfJung I have added to the doc comments explaining the difference between both of these queries. |
|
☔ The latest upstream changes (presumably #67202) made this pull request unmergeable. Please resolve the merge conflicts. |
f84e972 to
8707e98
Compare
8707e98 to
c010d84
Compare
|
@bors r+ |
|
📌 Commit c010d84 has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 100, this pull request will be tested once the tree is reopened |
…r=oli-obk Add simpler entry points to const eval for common usages. I found the `tcx.const_eval` API to be complex/awkward to work with, because of the inherent complexity from all of the different situations it is called from. Though it mainly used in one of the following ways: - Evaluates the value of a constant without any substitutions, e.g. evaluating a static, discriminant, etc. - Evaluates the value of a resolved instance of a constant. this happens when evaluating unevaluated constants or normalising trait constants. - Evaluates a promoted constant. This PR adds three new functions `const_eval_mono`, `const_eval_resolve`, and `const_eval_promoted` to `TyCtxt`, which each cater to one of the three ways `tcx.const_eval` is normally used.
…r=oli-obk Add simpler entry points to const eval for common usages. I found the `tcx.const_eval` API to be complex/awkward to work with, because of the inherent complexity from all of the different situations it is called from. Though it mainly used in one of the following ways: - Evaluates the value of a constant without any substitutions, e.g. evaluating a static, discriminant, etc. - Evaluates the value of a resolved instance of a constant. this happens when evaluating unevaluated constants or normalising trait constants. - Evaluates a promoted constant. This PR adds three new functions `const_eval_mono`, `const_eval_resolve`, and `const_eval_promoted` to `TyCtxt`, which each cater to one of the three ways `tcx.const_eval` is normally used.
…r=oli-obk Add simpler entry points to const eval for common usages. I found the `tcx.const_eval` API to be complex/awkward to work with, because of the inherent complexity from all of the different situations it is called from. Though it mainly used in one of the following ways: - Evaluates the value of a constant without any substitutions, e.g. evaluating a static, discriminant, etc. - Evaluates the value of a resolved instance of a constant. this happens when evaluating unevaluated constants or normalising trait constants. - Evaluates a promoted constant. This PR adds three new functions `const_eval_mono`, `const_eval_resolve`, and `const_eval_promoted` to `TyCtxt`, which each cater to one of the three ways `tcx.const_eval` is normally used.
Rollup of 8 pull requests Successful merges: - #66877 (Add simpler entry points to const eval for common usages.) - #67299 (Add `ImmTy::try_from_(u)int` methods) - #67487 (Rustdoc mutability removal) - #67499 (Misc MIR building cleanups) - #67506 (Remove iter_private.rs) - #67508 (Fix typo in path parser name) - #67519 (Document why Any is not an unsafe trait) - #67525 (Utilize rust-lang/rust commit hashes in toolstate) Failed merges: r? @ghost
Rustup to rust-lang/rust#66877 changelog: none
I found the
tcx.const_evalAPI to be complex/awkward to work with, because of the inherent complexity from all of the different situations it is called from. Though it mainly used in one of the following ways:This PR adds three new functions
const_eval_mono,const_eval_resolve, andconst_eval_promotedtoTyCtxt, which each cater to one of the three waystcx.const_evalis normally used.