Replace all const evaluation with miri

[oli-obk]

• 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]

@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]

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

[bors]

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

[alexreg]

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 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]

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

[alexcrichton]

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

[alexreg]

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]

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

[eddyb]

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

[alexreg]

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

[eddyb]

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

[alexreg]

Yep, it's picky.

[eddyb]

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

[oli-obk]

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]

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]

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

rust/src/librustc_driver/driver.rs

Line 189 in 8ff449d

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]

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]

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]

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]

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]

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

[BatmanAoD]

🎆 Wooooo! Congratulations, everyone!

[bdrewery]

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

[ur0]

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