turn on MIR construction unconditionally

[nikomatsakis]

I had to fix a few things. Notable changes:

1. I removed the MIR support for constants, instead falling back to the existing ConstVal. I still think we ought to reform how we handle constants, but it's not clear to me that the approach I was taking is correct, and anyway I think we ought to do it separately.
2. I adjusted how we handle bindings in matches: we now declare all the bindings up front, rather than doing it as we encounter them. This is not only simpler, since we don't have to check if a binding has already been declared, it avoids ICEs if any of the arms turn out to be unreachable.
3. I do MIR construction after check_match, because it detects various broken cases. I'd like for check_match to be subsumed by MIR construction, but we can do that as a separate PR (if indeed it makes sense).

I did a crater run and found no regressions in the wild: https://gist.github.com/nikomatsakis/0038f90e10c8ad00f2f8

[rust-highfive]

r? @pnkfelix

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

[nikomatsakis]

Oh, I meant to remove the "reachable" flags for matches. I can do that easily enough.

[nikomatsakis]

done.

[eefriedman]

Is v1.is_nan() && v2.is_nan() really what you mean, as opposed to transmute<f64, u64>(v1) == transmute<f64, u64>(v2)?

[nikomatsakis]

@eefriedman

Is v1.is_nan() && v2.is_nan() really what you mean, as opposed to transmute<f64, u64>(v1) == transmute<f64, u64>(v2)?

Hmm, interesting question. It's probably better to be more conservative, I agree.

[alexcrichton]

🎊

[nikomatsakis]

@alexcrichton huh, that confetti-ball renders looks more like an angry stormcloud to me. I was like "what did I do to make alex angry now?"

[alexcrichton]

😈

[pnkfelix]

Hmm, on a checkout from yesterday, the -Z always-build-mir is regressing rustc on this test case: playpen

#[derive(Copy, Clone, PartialEq, Eq, Debug)]
#[repr(usize)]
pub enum E { A = 0, B = 1 }

impl E {
    pub fn foo(x: usize) -> Self {
        use self::E::{A, B};
        const E_A: usize = A as usize;
        const E_B: usize = B as usize;
        match x {
            E_A => A,
            E_B => B,
            _ => panic!("no match"),
        }
    }
}

results in ICE:

/tmp/foo.rs:8:28: 8:38 error: internal compiler error: expression is not a valid constant Cast { source: Hair(expr(262: A)) }
/tmp/foo.rs:8         const E_A: usize = A as usize;
                                         ^~~~~~~~~~

@nikomatsakis

The crater run you did, I assume it wasn't including the -Z always-build-mir on the "before" step, right? I'm just a little surprised that you did not see examples of this pattern in use...

[pnkfelix]

(The reason that I point this out on this ticket is just to warn that we do not seem to have been testing this pattern internally, if -Z always-build-mir is always being passed ... but maybe its not being passed during the test suite runs? In any case, I have not confirmed that the above ICE persists after applying this PR; for all I know it might well fix the above noted bug.)

Update: and in fact the commit messages for the commit series on this PR gives me some hope that this problem is in fact addressed somewhere here, since this PR does something with respect to the handling of patterns and const-evaluation.

Update 2: @nikomatsakis I will actually build rust with this PR locally and check whether it indeed does fix the test case I listed above.

[nikomatsakis]

@pnkfelix that test case works on this branch. I did indeed revamp how constants are handled to just reuse more of the compiler's existing machinery.

[nikomatsakis]

Note: -Z always build Mir is only used currently when bootstrapping, not
during test runs.
On Oct 1, 2015 9:49 AM, "Felix S Klock II" notifications@github.com wrote:

(The reason that I point this out on this ticket is just to warn that we
do not seem to have been testing this pattern internally, if -Z
always-build-mir is always being passed ... but maybe its not being
passed during the test suite runs? In any case, I have not confirmed that
the above ICE persists after applying this PR; for all I know it might well
fix the above noted bug.)

—
Reply to this email directly or view it on GitHub
#28748 (comment).

[bors]

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

[pnkfelix]

@nikomatsakis okay I've finished reviewing. Looks fine, assuming you squash some of the later commits into the appropriate earlier commits (i.e. the removal of the reaches array and the change to NaN handling commits should both get squashed into earlier commits).

So r=me once that's done.

[nikomatsakis]

@bors r=pnkfelix

[bors]

📌 Commit 7e1e830 has been approved by pnkfelix

[bors]

⌛️ Testing commit 7e1e830 with merge c298efd...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt