ICE: "encountered errors lowering pattern: [ConstEval(ConstEvalErr { ... kind: NonConstPath })]"

[est31]

Following (wrong) code gives an error on beta 1.19 and stable 1.18, but ICEs on current nightly:

fn main() {
	let mut y;
	macro_rules! m {
		($a:expr) => {
			let $a = 0;
		}
	}
	m!(y);
}

The error (expected behaviour):

error: expected pattern, found `y`

The ICE message (new behaviour):

internal compiler error: /checkout/src/librustc_const_eval/pattern.rs:282: encountered errors lowering pattern: [ConstEval(ConstEvalErr { span: src/main.rs:8:5: 8:6, kind: NonConstPath })]

Nightly (soon beta) regression. Bisected using rust-bisect to #42964 (7acce37).

[est31]

One possible cause is #42886 . cc @durka @petrochenkov

[alexcrichton]

cc @rust-lang/compiler

[Mark-Simulacrum]

Also cc @eddyb specifically, looks CTFE related.

[eddyb]

What's surprising is that there's no name resolution error. Patterns shouldn't be able to refer to variables, even when there's macro treachery afoot.

[arielb1]

Why would there be a name-resolution error?

You can reach this in stable with range patterns, but you get an error from const-checking which prevents the ICE. Maybe we should const-check literals too?

fn main() {
	let y: usize = 1;
	let 0...y = 1; //~ ERROR constant evaluation error
}

[eddyb]

We solved this in name resolution in other situations, didn't we? Like, if you have an array length that's a variable in scope.

[alexcrichton]

ping @eddyb and @arielb1, did y'all get any further in taking a look at this?

[eddyb]

@alexcrichton We don't agree on the solution. IMO name resolution should not see variables in scope from that position, only constant items.

[alexcrichton]

Hm ok, I guess in that sense this is a reminder that 1.20 is released in less than 3 weeks now, so the clock is ticking for getting some solution into the compiler.