Implement constant support in MIR. by eddyb · Pull Request #33130 · rust-lang/rust

eddyb · 2016-04-21T13:04:45Z

All of the intended features in trans::consts are now supported by mir::constant.
The implementation is considered a temporary measure until miri replaces it.

A -Z orbit bootstrap build will only translate LLVM IR from AST for #[rustc_no_mir] functions.

Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-const functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.

The improved checking comes at the cost of four [breaking-change]s:

repeat counts must contain a constant expression, e.g.:
let arr = [0; { println!("foo"); 5 }]; used to be allowed (it behaved like let arr = [0; 5];)
dereference of a reference to a static cannot be used in another static, e.g.:
static X: [u8; 1] = [1]; static Y: u8 = (&X)[0]; was unintentionally allowed before
the type of a staticmust be Sync, irrespective of the initializer, e.g.
static FOO: *const T = &BAR; worked as &T is Sync, but it shouldn't because *const T isn't
a static cannot wrap UnsafeCell around a type that may need drop, e.g.
static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));
was previously allowed based on the fact None alone doesn't need drop, but in UnsafeCell
it can be later changed to Some(String) which does need dropping

The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating UnsafeCell from constants is unstable, so users can just enable the feature gate.

rust-highfive · 2016-04-21T13:04:50Z

r? @arielb1

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

oli-obk · 2016-04-21T13:20:09Z

I don't understand the reason for the existance of ce084d5

Won't all of that code go away once miri does the interpretation?

eddyb · 2016-04-21T13:22:50Z

Yes it would, I thought it was going to be less code. I just wanted to make sure that we can work independently of old trans, no matter what happens with miri integration.

arielb1 · 2016-04-21T14:00:08Z

Shouldn't you .subst(param_env.free_substs)?

It's the same code as before, just moved around.

that's the Correct way

nikomatsakis · 2016-04-21T14:25:03Z

cc @rust-lang/compiler

nikomatsakis · 2016-04-21T14:25:34Z

I'd like to sign off one this before it is r+'d. Will try to look today.

nagisa · 2016-04-24T00:19:52Z

MIR errors while building while the test expects an error emitted during lint-checking (but not suppressible AFAICT), and the driver stops on errors somewhere in between.

Should add a FIXME comment to return to the original code once it is possible (i.e. the current consteval code is removed).

bors · 2016-04-24T23:18:22Z

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

nikomatsakis · 2016-04-27T17:01:12Z

Crater run: https://gist.github.com/nikomatsakis/c2c7ecdac8437dc8056b6629ec7e9f83

4063 crates tested: 2631 working / 1322 broken / 3 regressed / 0 fixed / 107 unknown.

eddyb · 2016-04-27T17:41:57Z

@nikomatsakis one is a timeout, one is a non-Syncstatic (I... didn't do anything intentional there, how could that have escaped checking before?) and one (odbc) is a true regression:

src/raw/sqlconsts.rs:272:48:272:71 error: cannot refer to other statics by value,use the address-of operator or a cons
tant instead [E0394] src/raw/sqlconsts.rs:272 pub staticSQL_MAXIMUM_USER_NAME_LENGTH:u16 = *&SQL_MAX_USER_NAME_LEN; ^~~~~~~~~~~~~~~~~~~~~~~

Followed by 22 more of these, which appear to be aliases (use could've worked!) of other statics which should also be const instead.
I consider this to be pathological abuse of a lack of rigor in our checking and I don't think there's a way to have a warning cycle - besides, it can't compile with MIR trans.

I will personally try to fix these two crates, I hope we can merge this soon, since it's blocking both miri and some of my other 'tcx-related work.

eddyb · 2016-04-27T18:16:19Z

Actually, the misuse of static from obdc was easy to fix, see Koka/odbc-rs#1 (already merged).

However, the non-Syncstatic from dispatch is worse, because it is a regression, one I have not considered:

staticFOO:*consti32 = &0;

We allow this only because we look at the unadjusted initializer type, which is &'static T.
This type isn't even available in the MIR, so I don't see a point in trying to keep this working, but I'll add it to the list in the PR description.

bors · 2016-05-07T23:42:57Z

⌛ Testing commit 3001626 with merge 6c7f924...

bors · 2016-05-08T01:12:57Z

💔 Test failed - auto-win-msvc-64-opt-rustbuild

eddyb · 2016-05-08T01:18:43Z

Actual failure.

eddyb · 2016-05-08T07:17:08Z

@bors r=nikomatsakis

@alexcrichton Remind me to bug you about enabling LLVM assertions on the test bots, something that should've been caught by an assertion ended up in a successful compile (but the resulting program crashed in an edge condition).
This seems very dangerous to have around, as we keep fiddling with trans.

bors · 2016-05-08T07:17:08Z

📌 Commit 3b0e27c has been approved by nikomatsakis

bors · 2016-05-08T07:31:40Z

⌛ Testing commit 3b0e27c with merge 1ec2217...

Implement constant support in MIR. All of the intended features in `trans::consts` are now supported by `mir::constant`. The implementation is considered a temporary measure until `miri` replaces it. A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions. Furthermore, almost all checks of constant expressions have been moved to MIR. In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion). Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes. The improved checking comes at the cost of four `[breaking-change]`s: * repeat counts must contain a constant expression, e.g.: `let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`) * dereference of a reference to a `static` cannot be used in another `static`, e.g.: `static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before * the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g. `static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't * a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g. `static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));` was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell` it can be later changed to `Some(String)` which *does* need dropping The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated. However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.

bors · 2016-05-08T09:41:47Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-32cross-opt, auto-linux-64-cargotest, auto-linux-64-cross-armhf, auto-linux-64-cross-armsf, auto-linux-64-cross-freebsd, auto-linux-64-cross-netbsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild

alexcrichton · 2016-05-08T17:29:45Z

@eddyb oh yeah I'd be fine enabling LLVM assertions, we'd just want to time it and ensure it doesn't regress cycle time too much. If it's just a few minutes that's fine though as it's some good testing.

I thought we already did this but apparently not! Looks like we only enable LLVM assertions on nightly.

@nikomatsakis

Fix several -Z orbit crater blockers. Fixes 3 of the issues found by @nikomatsakis' crater run with `-Z orbit` forced on: https://gist.github.com/nikomatsakis/6688c30a0e5d3fed07cc1ebd4efb1412 Two of the regressions seemed to be fixed by #33130 and the remaining two are timeouts.

Ryman · 2016-05-13T15:25:38Z

The following seems to have regressed, but I'm unsure if that's intentional or not? (also not entirely sure if this is the correct PR but it looks most related)

pubstaticmut freelist:[&'staticmut[u8];16] =
[&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[],&mut[]];

Runs on stable and beta, fails on nightly: https://is.gd/9tUBN8

This is in the wild but not on crates.io, dropbox/rust-alloc-no-stdlib#1 which is a dependency for https://github.com/dropbox/rust-brotli-no-stdlib

eddyb · 2016-05-13T16:16:17Z

@Ryman That is supposed to be allowed, but I can't see how it happens, because it's supposed to be whitelisted based on the type.

eddyb · 2016-05-13T19:34:09Z

@Ryman Should be fixed in #33620.

rust-highfive assigned arielb1 Apr 21, 2016

This was referenced Apr 21, 2016
RFC - Allow Drop types in statics/const functions rust-lang/rfcs#1440
Merged
generate MIR for constants and statics #33106
Closed
Tracking issue for MIR (RFC #1211) #27840
Closed

eddyb force-pushed the mir-const branch 2 times, most recently from 0f3c6aa to 17da918Compare April 21, 2016 13:45

arielb1 reviewed Apr 21, 2016
View reviewed changes

eddyb force-pushed the mir-const branch from 17da918 to 479a95dCompare April 22, 2016 11:34

nagisa reviewed Apr 24, 2016
View reviewed changes

eddyb force-pushed the mir-const branch from 479a95d to 56b1699Compare April 26, 2016 02:02

eddyb added the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Apr 26, 2016

eddyb force-pushed the mir-const branch 3 times, most recently from f9a4c18 to f68fcafCompare April 27, 2016 02:03

eddyb mentioned this pull request Apr 27, 2016
Replace statics with constants. Koka/odbc-rs#1
Merged

eddyb mentioned this pull request Apr 27, 2016
Don't place a raw pointer in a static. SSheldon/rust-dispatch#5
Closed

eddyb force-pushed the mir-const branch from f68fcaf to a34b4f3Compare April 27, 2016 18:31

eddyb removed the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Apr 27, 2016

eddyb mentioned this pull request May 7, 2016
Fix several -Z orbit crater blockers. #33488
Merged

eddyb force-pushed the mir-const branch from da77cf7 to 3001626Compare May 8, 2016 01:53

trans: handle string literal reborrows.
3b0e27c

bors merged commit 3b0e27c into rust-lang:masterMay 8, 2016

eddyb deleted the mir-const branch May 9, 2016 00:08

alexcrichton mentioned this pull request May 10, 2016
Spurious rbml failure in incremental tests #33435
Closed

eddyb added the relnotes Marks issues that should be documented in the release notes of the next release. label May 12, 2016

Ryman mentioned this pull request May 13, 2016
Fails to build tests on latest nightly dropbox/rust-alloc-no-stdlib#1
Closed

indiv0 mentioned this pull request May 14, 2016
Fix lazy_static Usage rusoto/rusoto#260
Merged

kennytm mentioned this pull request Jun 24, 2016
RFC: const-dependent type system. rust-lang/rfcs#1657
Closed

durka mentioned this pull request Sep 11, 2016
Regression in beta: unsafe-free, pure Rust pgm. with no deps segfaults #36401
Closed

elinorbgr mentioned this pull request Nov 13, 2016
Tracking issue for static_recursion#29719
Closed

Uh oh!

Uh oh!

Conversation

eddyb commented Apr 21, 2016• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Apr 21, 2016

Uh oh!

oli-obk commented Apr 21, 2016

Uh oh!

eddyb commented Apr 21, 2016

Uh oh!

arielb1Apr 21, 2016• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eddybApr 21, 2016

Choose a reason for hiding this comment

Uh oh!

arielb1Apr 21, 2016

Choose a reason for hiding this comment

Uh oh!

nikomatsakis commented Apr 21, 2016

Uh oh!

nikomatsakis commented Apr 21, 2016

Uh oh!

nagisaApr 24, 2016

Choose a reason for hiding this comment

Uh oh!

eddybApr 24, 2016

Choose a reason for hiding this comment

Uh oh!

nagisaApr 24, 2016

Choose a reason for hiding this comment

Uh oh!

bors commented Apr 24, 2016

Uh oh!

nikomatsakis commented Apr 27, 2016• edited by eddyb Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eddyb commented Apr 27, 2016

Uh oh!

eddyb commented Apr 27, 2016

Uh oh!

bors commented May 7, 2016

Uh oh!

bors commented May 8, 2016

Uh oh!

eddyb commented May 8, 2016

Uh oh!

eddyb commented May 8, 2016

Uh oh!

bors commented May 8, 2016

Uh oh!

bors commented May 8, 2016

Uh oh!

bors commented May 8, 2016

Uh oh!

alexcrichton commented May 8, 2016

Uh oh!

Ryman commented May 13, 2016

Uh oh!

eddyb commented May 13, 2016

Uh oh!

eddyb commented May 13, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

eddyb commented Apr 21, 2016•
edited
Loading

arielb1Apr 21, 2016•
edited
Loading

nikomatsakis commented Apr 27, 2016•
edited by eddyb
Loading