interpret: move nullary-op evaluation into operator.rs #128697
Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri The Miri subtree was changed cc @rust-lang/miri |
| self.tcx.offset_of_subfield(self.param_env, layout, fields.iter()).bytes(); | ||
| ImmTy::from_uint(val, usize_layout()) | ||
| } | ||
| UbChecks => ImmTy::from_bool(self.tcx.sess.ub_checks(), *self.tcx), |
There was a problem hiding this comment.
The type isn't even used here... this makes me wonder whether we should remove the type from the Rvalue::NullaryOp and instead have it in NullaryOp::SizeOf etc?
Cc @scottmcm
There was a problem hiding this comment.
Sticking a type in NullaryOp probably complicates a bunch of places where they're lifetime-free and Copy, so I'm not enthusiastic about that.
TBH, if we're going to refactor stuff here, I'd love to just kill UnOp::SizeOf and UnOp::AlignOf entirely, and use associated consts on a magic trait, so it's just switchInt <T as Foo>::SIZE instead of needing pointless temporaries.
Since UbChecks is pretty weird -- it's a constant but it's not constant -- it might better to just split it out entirely since it works so differently from all the other UnOps...
There was a problem hiding this comment.
I would like to see an attempt to reimplement UbChecks as a const... Somehow. It would make a lot more sense.
There was a problem hiding this comment.
Sticking a type in NullaryOp probably complicates a bunch of places where they're lifetime-free and Copy, so I'm not enthusiastic about that.
NullaryOp already has a 'tcx lifetime and Ty<'tcx> is Copy, so it doesn't change anything in this regard.
There was a problem hiding this comment.
Since UbChecks is pretty weird -- it's a constant but it's not constant -- it might better to just split it out entirely since it works so differently from all the other UnOps...
I would like to see an attempt to reimplement UbChecks as a const... Somehow. It would make a lot more sense.
It's not a constant. It can have different values in different compilation units, that's its entire point. So I think a NullaryOp makes a lot more sense for it than trying to make it a constant.
This comment has been minimized.
This comment has been minimized.
|
r? compiler-errors @bors r+ rollup |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#122049 (Promote riscv64gc-unknown-linux-musl to tier 2) - rust-lang#128580 (Use `ParamEnv::reveal_all` in CFI) - rust-lang#128688 (custom MIR: add support for tail calls) - rust-lang#128694 (Normalize when equating `dyn` tails in MIR borrowck) - rust-lang#128697 (interpret: move nullary-op evaluation into operator.rs) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#128697 - RalfJung:nullary-op, r=compiler-errors interpret: move nullary-op evaluation into operator.rs We call it an operator, so we might as well treat it like one. :) Also use more consistent naming for the "evaluate intrinsic" functions. "emulate" is really the wrong term, this *is* a genuine implementation of the intrinsic semantics after all.
We call it an operator, so we might as well treat it like one. :)
Also use more consistent naming for the "evaluate intrinsic" functions. "emulate" is really the wrong term, this is a genuine implementation of the intrinsic semantics after all.