Add simpler entry points to const eval for common usages.#66877
Add simpler entry points to const eval for common usages.#66877bors merged 1 commit intorust-lang:masterfrom
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.
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.
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.
maybe just put them into a submodule of this module. queries could work as a name.
da16058 to
15dbbe1
Compare
oli-obk
left a comment
There was a problem hiding this comment.
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.