Skip to content
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
Merged

Replace all const evaluation with miri #46882

merged 110 commits into from
Mar 8, 2018

Conversation

oli-obk
Copy link
Contributor

@oli-obk 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

@kennytm kennytm added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 20, 2017
@oli-obk oli-obk changed the title WIP: add more boosters to miri... WIP: add more boosters 🚀 to miri... Dec 21, 2017
@oli-obk oli-obk force-pushed the miri3 branch 2 times, most recently from 7de6a56 to ef9043b Compare December 22, 2017 09:23
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()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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`.

@bors
Copy link
Contributor

bors commented Dec 28, 2017

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

@bors
Copy link
Contributor

bors commented Dec 28, 2017

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

@alexreg
Copy link
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
Copy link
Contributor Author

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
Copy link
Contributor

alexreg commented Dec 31, 2017

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

@alexcrichton
Copy link
Member

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

@alexreg
Copy link
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.

@bors
Copy link
Contributor

bors commented Jan 9, 2018

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

.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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, it's picky.

@eddyb
Copy link
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 WIP: add more boosters 🚀 to miri... WIP: Replace all const evaluation with miri Jan 15, 2018
@oli-obk
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

@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
Copy link
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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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

@BatmanAoD
Copy link
Member

🎆 Wooooo! Congratulations, everyone!

@bdrewery
Copy link
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
bors added a commit that referenced this pull request Apr 9, 2018
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
Copy link

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
Copy link
Contributor Author

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