disallow non-static lifetimes in const generics

[yodaldevoid]

Disallow non-static lifetimes in const generics in order to to patch over an ICE caused when we encounter a non-static lifetime in a const generic during borrow checking. This restriction may be relaxed in the future, but we need more discussion before then, and in the meantime we should still deal with this ICE.

Fixes issue #60814

[rust-highfive]

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

[rust-highfive]

r? @eddyb

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

[bors]

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

[eddyb]

r? @matthewjasper cc @nikomatsakis

[nikomatsakis]

I'd cc @varkor and perhaps @lcnr, who seem to be spearheading const generics at this moment. I'm not sure what I think of this PR -- const generics is flagged as unstable, and it seems like papering over ICEs isn't something we necessarily have to do, as opposed to taking the time to fix them the right way. This change adds a new error code and modifies name resolution, which seems a bit "non-local" to me -- i.e., it's affecting code that really shouldn't have much to do with const generics at all. On the other hand, it's not a lot of code, and wouldn't be hard to remove per se. But I worry it might confuse people -- at minimum I'd want some FIXME comments.

[lcnr]

I fairly strongly believe this PR is useful.

Slightly elaborating on the sentiment in #74052 (comment), I think allowing lifetimes in the type of const parameters has (nearly) the same difficulty as allowing types (which we forbid in #74159). We have to think about how type inference should work without causing query cycles and what exactly non static lifetimes mean in a const expression.

@yodaldevoid can you add this as a test here (I would expect it to compile)

#![feature(const_generics)]

fn test<const N: usize>() {}

fn wow<'a>() -> &'a () {
    test::<{
        let _: &'a ();
        3
    }>();
    &()
}

I can't really judge the implementation itself here as I am not familiar with this code.

[nikomatsakis]

Ok, I'd be ok with it if the code is tagged with a FIXME comment that points to some representation issue saying "we should revisit this question at some point"

[yodaldevoid]

I'll update this in the next couple days to add the suggested test and some FIXME statements.

[lcnr]

Somewhat related, we also can't really handle lifetimes in anon consts inside of type defaults rn, so we should forbid something like

struct Foo<'a, T = [u8; {
    let _: &'a ();
    7
}]>(&'a (), T);

This currently ICEs on stable, I am adding the same restriction for other generic params in #74487

[yodaldevoid]

I've added a FIXME comment on the error-emitting function pointing to #74052 and the test asked for by @lcnr.

[nikomatsakis]

Hmm, I guess we don't have a RegionKind::Error to use here... unfortunate. I don't really remember what happens is we fail to store some kind of resolution for a lifetime in type check -- are we relying on not running type check here? Ah, ok, we insert 'static or an inference variable:

rust/src/librustc_typeck/astconv.rs

Lines 202 to 213 in 7138410

	None => {
	self.re_infer(def, lifetime.span).unwrap_or_else(|| {
	// This indicates an illegal lifetime
	// elision. `resolve_lifetime` should have
	// reported an error in this case -- but if
	// not, let's error out.
	tcx.sess.delay_span_bug(lifetime.span, "unelided lifetime in signature");
	// Supply some dummy value. We don't have an
	// `re_error`, annoyingly, so use `'static`.
	tcx.lifetimes.re_static
	})

I guess that's ok.

[nikomatsakis]

@bors r+

[bors]

📌 Commit c60a035 has been approved by nikomatsakis