arithmetic-overflow checks during const-eval

[pnkfelix]

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 #23841

Fix #22531

Fix #23030

Fix #23221

Fix #23235

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[pnkfelix]

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.

[pnkfelix]

r? @nikomatsakis

[eddyb]

const fn is pretty simple, really, there won't be much churn I would have to deal with (I don't think).

As for the checks in trans: I did something else for div/rem: check_const invokes const_eval for those binops on integers and errors if evaluation fails.
Sadly, that doesn't work well in the presence of const fn and associated constants.

@nikomatsakis I wonder if recording "obligations" on constant evaluation would make sense - like where clauses, but implicit and working on values (either arguments of const fns or associated constants on type parameters).

[eddyb]

Are the indentation levels here intentional?

[pnkfelix]

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!...

[nikomatsakis]

r+ modulo the FIXME

[eddyb]

@nikomatsakis Should we open a discussion about the interactions between trans::consts and const_eval somewhere else?

I personally prefer checking somewhere higher than trans, but in the end, what I am not particularly fond of is extracting values from LLVM for checking.

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.

[pnkfelix]

@bors r=nikomatsakis

[bors]

📌 Commit e40d0de has been approved by nikomatsakis

[pnkfelix]

@eddyb @nikomatsakis

Should we open a discussion about the interactions between trans::consts and const_eval somewhere else?

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.

[pnkfelix]

@bors r-

I want to check this in a cross-compiling environment, and perhaps land it in tandem with #23841 and perhaps a fix for #23890

[pnkfelix]

(I have now rebased this atop #23841, but I am pretty sure that it is going to conflict with other PR's in the queue, namely #23549, so I am still holding off on putting back the r+ until I see if that lands or not.)

[bors]

☔️ The latest upstream changes (presumably #23549) made this pull request unmergeable. Please resolve the merge conflicts.

[pnkfelix]

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. :)

[pnkfelix]

r=nikomatsakis ; @alexcrichton says he will merge into next rollup.

[alexcrichton]

@bors: r=nikomatsakis

[bors]

📌 Commit 2a9de1d has been approved by nikomatsakis

[andersk]

I think this caused #23968: !0u32/2 gives “error: attempted to divide with overflow in a constant expression [E0020]”.