-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
arithmetic-overflow checks during const-eval #23863
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
cc @eddyb (actually, I'd be happy to take a review from eddyb) Also, eddyb: You may be concerned about collisions here with your own const-fn work. Feel free to recommend some ordering on how the two PR's land, or suggest some other strategy to avoid unnecessary rebasing effort. |
As for the checks in trans: I did something else for div/rem: @nikomatsakis I wonder if recording "obligations" on constant evaluation would make sense - like |
if !oflo { Ok(const_uint(ret)) } else { signal!(e, SubuWithOverflow(a, b)) } | ||
|
||
pub_fn_checked_op!{ const_int_checked_add(a: i64, b: i64,.. IntTy) { | ||
int_arith_body overflowing_add const_int AddiWithOverflow(a, b) |
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.
Are the indentation levels here intentional?
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.
yeah it was so that the operator name (e.g. "add") would line up in both the method name and in the operator invocation.
Maybe I would have been better off using some well-placed calls to stringify!
...
r+ modulo the FIXME |
@nikomatsakis Should we open a discussion about the interactions between I personally prefer checking somewhere higher than It works for this PR, and it's not enough to stop it from merging (we need those checks in beta), but I hope we can find a cleaner solution. |
@bors r=nikomatsakis |
📌 Commit e40d0de has been approved by |
I just made this post on internals: http://internals.rust-lang.org/t/removing-const-eval-duplication-of-labor-between-librustc-and-librustc-trans/1786 so we can continue that conversation in a focused fashion there. |
ee14d46
to
7506c3d
Compare
☔ The latest upstream changes (presumably #23549) made this pull request unmergeable. Please resolve the merge conflicts. |
annoying: the error messages on some of my tests are different for 64-bit compile versus a cross-compiling 64-bit host/32-bit target. :( Update: Well, being forced to fix this may yield an overall code cleanup. :) |
…values. Moved such overflow checking into one place (in `rustc::middle::ty`, since it needs to be run on-demand during `const_eval` in some scenarios), and revised `rustc_typeck` accordingly. (Note that we only check for overflow if program did not provide a discriminant value explicitly.) Fix rust-lang#23030 Fix rust-lang#23221 Fix rust-lang#23235
…tch to target type.
…ant int. Add option-returning variants to `const_to_int`/`const_to_uint` that never assert fail. (These will be used for overflow checking from rustc_trans::trans::consts.)
The overflow-checking attempts to accommodate early evaluation where we do not have type information yet. Also, add fixme note about something that has been bothering me.
… 64-bit targets. See also rust-lang#23926.
4298dc5
to
2a9de1d
Compare
r=nikomatsakis ; @alexcrichton says he will merge into next rollup. |
@bors: r=nikomatsakis |
📌 Commit 2a9de1d has been approved by |
const_eval : add overflow-checking for {`+`, `-`, `*`, `/`, `<<`, `>>`}. One tricky detail here: There is some duplication of labor between `rustc::middle::const_eval` and `rustc_trans::trans::consts`. It might be good to explore ways to try to factor out the common structure to the two passes (by abstracting over the particular value-representation used in the compile-time interpreter). ---- Update: Rebased atop rust-lang#23841 Fix rust-lang#22531 Fix rust-lang#23030 Fix rust-lang#23221 Fix rust-lang#23235
I think this caused #23968: |
const_eval : add overflow-checking for {
+
,-
,*
,/
,<<
,>>
}.One tricky detail here: There is some duplication of labor between
rustc::middle::const_eval
andrustc_trans::trans::consts
. It might be good to explore ways to try to factor out the common structure to the two passes (by abstracting over the particular value-representation used in the compile-time interpreter).Update: Rebased atop #23841
Fix #22531
Fix #23030
Fix #23221
Fix #23235