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

Replace all const evaluation with miri #46882

Merged
merged 110 commits into from Mar 8, 2018

Conversation

Projects
None yet
@oli-obk
Contributor

oli-obk commented Dec 20, 2017

  • error reporting in constants prints a stacktrace through all called const fns
  • Trivial constant propagation and folding in MIR (always active, irrelevant of the optimization level)
  • can now use floating constants in patterns (previously only floating point literals were allowed)
    • the future compat lint is still produced for both cases
  • can index into constant arrays during const eval (previously feature gated)
  • can create a constant union value with field a and read from field b
  • can dereference references into constants
  • can create references inside constants (const X: &u32 = &22)
  • Tuple struct constructors can be used in constants
  • regression in const eval errors spans (some of these need improvements in mir debug info)
  • can cast floats to ints and vice versa (in constants, and even nan/inf constants)
  • Mir dump prints false/true instead of 0u8/1u8
  • 1i8 >> [8][0] does not lint about exceeding bitshifts anymore.
    • Needs const propagation across projections
  • foo[I] produces a const eval lint if foo: [T; N] and N < I
    • Essentially all builtin panics produce lints if they can be statically proven to trigger at runtime. This is on a best effort basis, so there might be some complex cases that don't trigger. (The runtime panic stays there, irrelevant of whether the lint is produced or not)
  • can use unions to implement transmute for Copy types in constants without a feature gate. With all the greatness and nasal demons that come with this.
  • can convert integers to &'static T in constants (useful for embedded)

fixes #34997 (stack overflow with many constants)
fixes #25574 (deref byte strings in patterns)
fixes #27918 (broken mir ICE)
fixes #46114 (ICE on struct constructors in patterns)
fixes #37448 (SomeStruct { foo } as SomeStruct)
fixes #43754 (return in const fn)
fixes #41898 (tuple struct constructors)
fixes #31364 (infinite recursion with const fn, fixed by miri's recursion limit)
closes #29947 (const indexing stabilization)
fixes #45044 (pattern matching repeat expressions)
fixes #47971 (ICE on const fn + references)
fixes #48081 (ICE on cyclic assoc const error)
fixes #48746 (nonhelpful error message with unions)

r? @eddyb

even though 1k loc are added in tests, this PR reduces the loc in this repository by 700

@oli-obk oli-obk changed the title from WIP: add more boosters to miri... to WIP: add more boosters 🚀 to miri... Dec 21, 2017

@oli-obk oli-obk force-pushed the oli-obk:miri3 branch 2 times, most recently from 7de6a56 to ef9043b Dec 21, 2017

value: cx.tcx().mk_const(ty::Const {
val: if cx.tcx().sess.opts.debugging_opts.miri {
let inst = ty::Instance::new(def_id, substs);
let ptr = cx.tcx()

This comment has been minimized.

@oli-obk

oli-obk Dec 22, 2017

Contributor

@eddyb help! I'm not sure where to start touching the hair in order to get these 'gcx and 'tcx lifetimes satisfied:

error[E0623]: lifetime mismatch
   --> src/librustc_mir/hair/cx/expr.rs:603:38
    |
584 | fn method_callee<'a, 'gcx, 'tcx>(cx: &mut Cx<'a, 'gcx, 'tcx>,
    |                                           ------------------ this parameter and the return type are declared with different lifetimes...
...
587 |                                  -> Expr<'tcx> {
    |                                     ----------
...
603 |                         let ptr = cx.tcx()
    |                                      ^^^ ...but data from `cx` is returned here

error: aborting due to previous error

error: Could not compile `rustc_mir`.

@oli-obk oli-obk force-pushed the oli-obk:miri3 branch from f3fe013 to d7928a1 Dec 28, 2017

@bors

This comment has been minimized.

Contributor

bors commented Dec 28, 2017

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

@oli-obk oli-obk force-pushed the oli-obk:miri3 branch from 9cb239a to 625820f Dec 28, 2017

@bors

This comment has been minimized.

Contributor

bors commented Dec 28, 2017

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

@alexreg

This comment has been minimized.

Contributor

alexreg commented Dec 31, 2017

Great work on this, @oli-obk! I was just playing around with it myself, and was wondering on the state of it. Specifically, I seem to still be getting errors indicating that if expressions and loops are still not supported. Is this the case?

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Dec 31, 2017

This PR does not enable much new stuff. That's not the point of it. We can enable more things after this PR. All I'm trying to do is to make it work on all code that worked before, without adding anything that we want to talk about in RFCs. That said, a few things will work after this PR.

  1. Const indexing
  2. Float patterns that go through constants (emitting the future compat lint about floats in patterns)
  3. Dereferencing and referencing things in constants
  4. Tuple struct construction in constants

Also I haven't pushed everything yet.

@alexreg

This comment has been minimized.

Contributor

alexreg commented Dec 31, 2017

@oli-obk Oh, I see. Thanks for the clarification.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Jan 4, 2018

@oli-obk this is currently tagged as waiting-on-author, but did you want to start getting an early review?

@alexreg

This comment has been minimized.

Contributor

alexreg commented Jan 4, 2018

FWIW, @eddyb and I have been expanding on this significantly over the last few days. He's encouraging me to submit a PR, though I don't know if it's going to be against oli-obk's branch, or rust-lang:master.

@oli-obk oli-obk force-pushed the oli-obk:miri3 branch from d07e8e6 to 3fac474 Jan 8, 2018

@bors

This comment has been minimized.

Contributor

bors commented Jan 9, 2018

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

@oli-obk oli-obk force-pushed the oli-obk:miri3 branch from a199c77 to d10b896 Jan 9, 2018

.expect("miri alloc not found");
Ok(global_initializer(ccx, alloc))
}
impl<'a, 'tcx> MirContext<'a, 'tcx> {
// Old version of trans_constant now used just for SIMD shuffle
pub fn remove_me__shuffle_indices(&mut self,
pub fn remove_me_shuffle_indices(&mut self,

This comment has been minimized.

@eddyb

eddyb Jan 9, 2018

Member

LOL this wasn't a typo, I meant it to be an ugly name like that.

This comment has been minimized.

@alexreg

alexreg Jan 9, 2018

Contributor

My bad. I got an error for non-snake-case names, and fixed it by removing the _ instead of adding a deny attribute. :-P

This comment has been minimized.

@eddyb

eddyb Jan 10, 2018

Member

Ah if it triggered the lint then no worries! I didn't know it cared.

This comment has been minimized.

@alexreg

alexreg Jan 10, 2018

Contributor

Yep, it's picky.

@oli-obk oli-obk force-pushed the oli-obk:miri3 branch from 5fd4cb8 to 38023e4 Jan 14, 2018

@eddyb

This comment has been minimized.

Member

eddyb commented Jan 15, 2018

Just wanted to note that 1. the PR description should include all changes 2. this will need a crater run.

@oli-obk oli-obk changed the title from WIP: add more boosters 🚀 to miri... to WIP: Replace all const evaluation with miri Jan 15, 2018

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Jan 15, 2018

I am now getting

thread 'rustc' panicked at 'Found unstable fingerprints for MirOptimized(main[317d]::main[0])', librustc/ty/maps/mod.rs:82:1

Which very likely results from the fact that AllocIds are generated on the fly when loading from the incremental cache, but we hash the AllocId's integer value. I can solve this by hashing the actual allocation, which obviously should never change. But there's an issue with that: Allocations can refer to themselves either directly or transitively. So hashing an allocation might require hashing the very same allocation, ....

Any clues how to solve this?

cc @nikomatsakis

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Jan 15, 2018

cc @michaelwoerister

You removed the TyCtxt from StableHashingContext in d5b1fee#diff-c990dbfd90d57ef3911c819878ba7213
Is there any reason for this besides minimality?

I'm going to need access to the miri allocation interner to be able to hash AllocIds in a stable manner

@michaelwoerister

This comment has been minimized.

Contributor

michaelwoerister commented Jan 15, 2018

@oli-obk, yes, we are creating StableHashingContexts before the TyCtxt is created:

let hir_map = time(sess.time_passes(),

This could be solved by some refactoring, I think. @eddyb wanted to move HIR lowering to after the tcx is created a while ago.

There might also be another way of hashing AllocIds in a stable way? How are the integer ids generated? Are they in a "global address space" or per const?

@eddyb

This comment has been minimized.

Member

eddyb commented Jan 15, 2018

We could have an AllocId -> (ParamEnvAnd<GlobalId>, usize) mapping to record which evaluation an allocation came from, with an evaluation-local index.
Oh and you can use TLS_TCX to get around limitations with missing tcx.

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Jan 15, 2018

During lowering we won't have any AllocIds. So I could simply add an Option<TyCtxt> to StableHashingContext.

Won't just hashing the ID be problematic if recompiling changes the value of a static?

@michaelwoerister

This comment has been minimized.

Contributor

michaelwoerister commented Jan 15, 2018

Won't just hashing the ID be problematic if recompiling changes the value of a static?

That depends. Can you access the contents of an allocation via an AllocId directly? The contents of an allocation have to hashed at some point.

Is there a write up somewhere what these AllocIds are exactly?

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Jan 15, 2018

Nope no writeup. I'll add one though

In short :

AllocIds are used to identify interned Allocations. Serialization serializes the allocation instead of the allocid and deserialization generates a new allocid on the fly to keep them unique

@michaelwoerister

This comment has been minimized.

Contributor

michaelwoerister commented Jan 15, 2018

Is there one graph of allocations per ParamEnvAnd<GlobalId> that does not overlap with the graph of any other ParamEnvAnd<GlobalId>?

@BatmanAoD

This comment has been minimized.

BatmanAoD commented Mar 8, 2018

🎆 Wooooo! Congratulations, everyone!

SimonSapin added a commit to SimonSapin/rust that referenced this pull request Mar 8, 2018

@bdrewery

This comment has been minimized.

Contributor

bdrewery commented Mar 9, 2018

Getting a weird build crash on FreeBSD after this merge #48888

SimonSapin added a commit to SimonSapin/rust that referenced this pull request Mar 17, 2018

@solson solson referenced this pull request Mar 20, 2018

Closed

upstream to rustc #105

bors added a commit that referenced this pull request Apr 9, 2018

Auto merge of #49673 - ollie27:stab, r=sfackler
Correct a few stability attributes

* `const_indexing` language feature was stabilized in 1.26.0 by #46882
* `Display` impls for `PanicInfo` and `Location` were stabilized in 1.26.0 by #47687
* `TrustedLen` is still unstable so its impls should be as well even though `RangeInclusive` was stabilized by #47813
* `!Send` and `!Sync` for `Args` and `ArgsOs` were stabilized in 1.26.0 by #48005
* `EscapeDefault` has been stable since 1.0.0 so should continue to show that even though it was moved to core in #48735

This could be backported to beta like #49612
@ur0

This comment has been minimized.

ur0 commented Apr 16, 2018

I'm sorry if this isn't the right place, but are tuple struct constructors available in the latest stable build (2018-03-25)?

@oli-obk

This comment has been minimized.

Contributor

oli-obk commented Apr 16, 2018

This is as good a place as any other ;)

No they're not in the current stable. they'll be in the next stable (so they are in the current beta)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment