Braced variant ctor gets rejected if enum has lifetime params & you pass gen args to enum explicitly

[ijackson]

I tried this code:

#![allow(dead_code)]
#![allow(unused_variables)]
enum Enum<'l, F> {
    Tuple(&'l F),
    Struct { f: &'l F },
}
fn main(){
    let v = 42u32;
    let t = Enum::<u32>::Struct { f: &v };
}

I expected to see this happen: it compiles.

Instead, this happened (on the playground, with stable and with nightly):

error[E0109]: lifetime arguments are not allowed on variant `Struct`
 --> src/main.rs:9:26
  |
9 |     let t = Enum::<u32>::Struct { f: &v };
  |                          ^^^^^^
  |                          |
  |                          lifetime argument not allowed
  |                          not allowed on variant `Struct`
  |
  = note: enum variants can't have type parameters

error[E0107]: this enum takes 1 lifetime argument but 0 lifetime arguments were supplied
 --> src/main.rs:9:13
  |
9 |     let t = Enum::<u32>::Struct { f: &v };
  |             ^^^^ expected 1 lifetime argument
  |
note: enum defined here, with 1 lifetime parameter: `'l`
 --> src/main.rs:3:6
  |
3 | enum Enum<'l, F> {
  |      ^^^^ --
help: add missing lifetime argument
  |
9 |     let t = Enum::<'l, u32>::Struct { f: &v };
  |                    +++

It's not 100% clear to me that this syntax, with the generics applied to the enum type rather than the variant, is intended to be accepted. I think it probably ought to be, though. On this point I found #69363/#69356. The Reference doesn't seem to discuss it.

Also, the error messages are nonsensical, and the suggestion doesn't compile.

Variations:

    let t = Enum::<'l, u32>::Tuple { 0: &v }; // use of undeclared lifetime name `'l`  [obviously]
    let t = Enum::<u32>::Tuple { 0: &v }; //  lifetime arguments are not allowed on variant `Tuple`
    let t = Enum::<'_, u32>::Tuple { 0: &v }; // //  lifetime arguments are not allowed on variant `Tuple`
    let t = Enum::<u32>::Tuple(&v);; // compiles, but of course you can't use this for a named-fields variant
    let t = Enum::Struct::<u32> { f: &v }; // compiles
    let t = Enum::Tuple::<u32> { 0: &v }; // compiles

[ijackson]

Oh, and, if we take the lifetime out of the enum type and just use owned values, it comples just fine:

#![allow(dead_code)]
#![allow(unused_variables)]
enum Enum<F> {
    Tuple(F),
    Struct { f: F },
}
fn main(){
    let v = 42u32;
    let t = Enum::<u32>::Struct { f: v };
}

[clubby789]

@rustbot label +A-diagnostics

I wonder if we should always suggest '_ when the lifetime is not in scope. The suggestion looks right at a glance which seems pretty confusing

[fmease]

I wouldn't classify this as a diagnostic bug, I'd consider this to be a proper bug.

[fmease]

This "regressed" in 1.14 (2016), more precisely between nightly-2016-10-28 and nightly-2016-11-02 (no nightlies in between are available, likely due to broken components). Most likely "due to" PR #37035 which added tcx.prohibit_type_params(base_segments.split_last().unwrap().1); in branch Def::Variant(did) in fn base_def_to_ty in mod astconv (today: HIR ty lowering).

I say "regressed" in quotes because prior to that, Enum::<'a>::Var::<'b> { … } was legal thereby completely ignoring 'a.

I say "due to" because that PR only made apparent a deeper fault. Before that, the i32 in your Enum::<u32>::Struct would've been ignored completely.

[fmease]

Context: I stumbled upon this issue myself when trying to answer a recent review comment: #129543 (comment).

Explanation of what's happening here: I might be misremembering the details but essentially in HIR ty lowering we're interpreting Enum::Var::<'a, T, N> as Enum::<'a, T, N>::Var because it's the enum Enum that actually has the generic params, not the variant. Of course, we're therefore rejecting code that tries to specify args for both the enum & the variant like Enum::<'a, T, N>::Var::<'a, T, N>.

However, lifetime elision doesn't seem to honor this at all (in today's rustc lifetime resolution (which understands elision, too, ofc) happens a lot earlier but that's probably not super relevant). Consequently, the code dealing with lifetime elision just chucks the elided lifetimes onto the variant, at least in the case of braced variant constructions. So Enum::<'a>::Var {} gets lowered/elaborated to Enum::<'a>::Var::<'_> {} which HIR ty lowering later sees and rejects obviously.

I don't know why this is only an issue for braced constructions (where the path resolution is Variant) and doesn't affect unit & tuple ctors (path resolution is Ctor(Variant, Const | Fn)). Would need to investigate further.

[fmease]

MCVEs:

enum E<'a> { V, H(&'a ()) }

fn main() { E::<'_>::V {}; } //~ ERROR lifetime arguments are not allowed on variant `V`

enum E<'a> { V(&'a ()) }

fn main() { E::<'_>::V { 0: &() }; } //~ ERROR lifetime arguments are not allowed on variant `V`

enum E<'a> { V { f: &'a () } }

fn main() { E::<'_>::V { f: &() }; } //~ ERROR lifetime arguments are not allowed on variant `V`