rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const #115972
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
|
r? @oli-obk
the |
This comment has been minimized.
This comment has been minimized.
|
(why did triagebot not ping me for the cg_clif changes?) |
|
It didn't ping anyone for the interpreter changes either. rustbot just entirely missed this PR in terms of pinging people. |
RalfJung
force-pushed
the
const-consistency
branch
from
1ef572a to
5f773d2
Compare
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 This PR changes MIR cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras This PR changes Stable MIR cc @oli-obk, @celinval, @spastorino Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes might have occurred in exhaustiveness checking cc @Nadrieril Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
RalfJung
changed the title
Done that.
I went with |
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
const-consistency
branch
from
5f773d2 to
c94410c
Compare
|
@bors r+ p=1 bitrotty |
bors
added
S-waiting-on-bors
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Sep 21, 2023
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... `@oli-obk` any ideas?
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 21, 2023
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#104385 (Raise minimum supported Apple OS versions) - rust-lang#115936 (Prevent promotion of const fn calls in inline consts) - rust-lang#115972 (rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const) - rust-lang#116007 (Call panic_display directly in const_panic_fmt.) - rust-lang#116019 (Delete obsolete `--disable-per-crate-search` rustdoc flag) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 21, 2023
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#115257 (Improve invalid UTF-8 lint by finding the expression initializer) - rust-lang#115936 (Prevent promotion of const fn calls in inline consts) - rust-lang#115972 (rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const) - rust-lang#116007 (Call panic_display directly in const_panic_fmt.) - rust-lang#116019 (Delete obsolete `--disable-per-crate-search` rustdoc flag) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 21, 2023
Rollup merge of rust-lang#115972 - RalfJung:const-consistency, r=oli-obk rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... ``@oli-obk`` any ideas?
|
FWIW smir still uses the old names, I was not sure what the process was for changing those. We should align them with the new internal names eventually, I hope. |
|
Yea, we'll clean up on the SMIR side ourselves |
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Sep 25, 2023
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... ``@oli-obk`` any ideas?
bjorn3
pushed a commit
to bjorn3/rust
that referenced
this pull request
Oct 9, 2023
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... ``@oli-obk`` any ideas?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Also, be more consistent with the
to/eval_bitsmethods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is calledbits_for_ty.Turns out that
ty::Const/mir::ConstKindcarry their type with them, so we don't need to even pass the type to thoseeval_bitsfunctions at all.However this is not properly consistent yet: in
tywe have most of the methods onty::Const, but inmirwe have them onmir::ConstKind. And indeed those two types are the ones that correspond to each other. Somir::ConstantKindshould actually be renamed tomir::Const. But what to do withmir::Constant? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited forsyntax.rsthanconsts.rs, but the bigger question is, which name should it get if we want to align themirandtytypes?ConstOperand?ConstOp?Literal? It's not a literal but it has a field calledliteralso it would at least be consistently wrong-ish...@oli-obk any ideas?