interpret: fix CheckedBinOp behavior when overflow checking is disabled #98888
Conversation
rustbot
added
the
T-compiler
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
rust-highfive
added
the
S-waiting-on-review
|
Uh, ConstProp is not happy with this... |
RalfJung
force-pushed
the
interpret-checked-bin
branch
from
735da63
to
ecf6f4f
Compare
|
I don't think CTFE should change the behaviour based on the options from the session. This would risk introducing cross-crate non-determinism in the execution. Conceptually I was considering CTFE to simply have overflow checking enabled, and so already in agreement with wording from #98738, but I can make this explicit. |
This comment has been minimized.
This comment has been minimized.
You specified MIR behavior to depend on the session options. CTFE should accurately implement MIR behavior. If this is fine for codegen, then why not for CTFE? |
|
FWIW I would much prefer if CheckedBinOp would just always check for overflow. Also note that the code here is not just for CTFE, it is also for Miri. I don't understand these CI failures though, ConstProp does not even call this function, it directly calls |
I guess it does mean that the same query executed in different crates can have different results. Which indeed sounds bad. Also is it really so easy to break the query system? I have no idea if our other accesses to |
Oh, these are not actually lints. Those are const-evaluations that used to fail because we always overflow-check arithmetic in I suppose I could add a machine flag to control this, so Miri can behave like codegen and CTFE can behave like before. |
|
☔ The latest upstream changes (presumably #98627) made this pull request unmergeable. Please resolve the merge conflicts. |
RalfJung
force-pushed
the
interpret-checked-bin
branch
from
ecf6f4f
to
3c69cbc
Compare
|
rustfmt doesn't like you again ^^ (I run all my commands as |
|
r=me with CI happy |
I wasn't referring to the determinism in context of a query system and I don' see any immediate issue there since overflow checking is controlled by tracked options. I was referring to the determinism as a fundamental property that CTFE should have. It would be rather bad if non-deterministic computation is lifted into the type system and different crates have a different view of what the types are. In the specific case of overflow checking, maybe there is some argument to be made that given how MIR is built the only other behaviour would be an evaluation error ... The proposed changes looks good to me. Thanks for updating this. |
RalfJung
force-pushed
the
interpret-checked-bin
branch
from
3c69cbc
to
2f6e996
Compare
|
@bors r=oli-obk |
|
📌 Commit 2f6e996 has been approved by |
bors
added
S-waiting-on-bors
…li-obk interpret: fix CheckedBinOp behavior when overflow checking is disabled Adjusts the interpreter to rust-lang#98738. r? ``@oli-obk``
…askrgr Rollup of 6 pull requests Successful merges: - rust-lang#98860 (adjust dangling-int-ptr error message) - rust-lang#98888 (interpret: fix CheckedBinOp behavior when overflow checking is disabled) - rust-lang#98889 (Add regression test for rust-lang#79467) - rust-lang#98895 (bootstrap.py: Always use `.exe` for Windows) - rust-lang#98920 (adapt issue-37945 codegen test to accept any order of ops) - rust-lang#98921 (Refactor: remove a redundant mutable variable) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
fix typo in function name I don't know what I was doing when I named that function... follow-up to rust-lang#98888 r? `@oli-obk`
Adjusts the interpreter to #98738.
r? @oli-obk