allow const function calls in consts that are used in patterns

[oli-obk]

r? @arielb1

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[oli-obk]

the reason this PR fixes two bugs, is that #29927 was also breaking the test for #30117

[arielb1]

@oli-obk

Why are you using PatLit? Will this work for more complicated const fn return results (that feels like a separate issue to me)?

[oli-obk]

it's already done for everything that is not a pattern directly. Like if you have an integral operation in a constant, it'll just defer it to PatLit and run the const evaluator later.

[oli-obk]

example: this won't work, since the enum is not directly in a const:

enum Cake {
    BlackForest,
    Marmor,
}
use Cake::*;

const BOO: (Cake, Cake) = (Marmor, BlackForest);
const FOO: Cake = BOO.1;

fn main() {
    match BlackForest {
        FOO => println!("hi"),
        _ => println!("bye"),
    }
}

[oli-obk]

The only expressions that are handled without the const evaluator are ExprTup, ExprCall, ExprStruct, ExprVec and ExprPath. Everything else is turned into a PatLit (see https://github.com/rust-lang/rust/pull/30141/files#diff-58f4817150d93d34d850a20426c38371L366) and then const evaluated here: https://github.com/rust-lang/rust/blob/master/src/librustc/middle/check_match.rs#L781

[arielb1]

@oli-obk

At least add a test that these kinds of abuse result in an error rather than an ICE.

[oli-obk]

added a test and noticed that the error is reported twice for the const fn. So now I'm bailing out in case the error was repeated previously.

do you mean "abuse" in the "you shouldn't do this" way or in the "complex situation" way?

[arielb1]

@oli-obk

According to @nikomatsakis we are going to change constant patterns to eliminate that possibility - but still we should not ICE.

[oli-obk]

I removed the commit that bailed early, check-stage1 passes locally, but travis didn't notice the removed commit.

[bors]

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

[oli-obk]

rebased

[oli-obk]

I'm not sure what possibility is going to be eliminated, but the following already works, because it hits something (a tuple index op) that will be const evaluated:

#![feature(const_fn)]
const BOO: (i32, i64) = (5, bla());
const fn bla() -> i64 { 6 }
const FOO: i64 = BOO.1;

fn main() {
    match 6 {
        FOO => println!("hi"),
        _ => println!("bye"),
    }
}

all this PR does is to make sure the following also works

#![feature(const_fn)]
const fn bla() -> i64 { 6 }
const FOO: i64 = bla();

fn main() {
    match 6 {
        FOO => println!("hi"),
        _ => println!("bye"),
    }
}

[arielb1]

@bors r+

[bors]

📌 Commit c71dcca has been approved by arielb1

[bors]

⌛ Testing commit c71dcca with merge 9ace0a4...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, 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-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