Should enum discriminants have generics in scope?

[eddyb]

What are our options?

1. we teach name resolution (rustc_resolve) to hide enum generic parameters from the discriminant expression
   • this effectively enshrines that we don't want the parameterization to happen
   • I'm not sure this can be backwards-compatible with 2.
2. we keep the current name resolution support but error if we can't evaluate to concrete values
   • the concrete values are necessary to check, at the definition site, that discriminants don't overlap
     • there are special-cases (only the first variant having an explicit discriminant, while the rest keep counting up) where we could check w/o knowing the values
     • long-term we could let more examples compile via explicit != bounds
   • note that expressions that use generics can still evaluate to concrete values
   • we could make this work w/o #![feature(const_generics)] (see examples below) by using the same approach as in typeck: always expose repeat count AnonConsts' parent in generics_of. #70452, as enums are in a similar situation that shouldn't cause query cycles
   • EDIT: opened typeck: always expose explicit enum discriminant AnonConsts' parent in generics_of. #70825 for this

---

Examples of current behavior:

Note: #![feature(const_generics)] is used below so that this special-case kicks in:

rust/src/librustc_typeck/collect.rs

Lines 1183 to 1185 in 62c6006

	// FIXME(#43408) enable this always when we get lazy normalization.
	Node::AnonConst(_) => {
	// HACK(eddyb) this provides the correct generics when

Also, note that the reason for the uniform current treatment (which doesn't consider enum parameters as not in scope of discriminants), is because rustc_resolve treats surrounding generics as being in scope of AnonConsts, always - all the bugs later in compilation are due to the lack of lazy normalization (see #43408).

---

This ICEs currently (playground):

#![feature(const_generics)]

#[repr(usize)]
enum Foo<T> {
    Zero = 0,
    SizeOf = std::mem::size_of::<T>(),
}

with

error: internal compiler error: src/librustc/ty/mod.rs:2538: enum discriminant depends on generic arguments
 --> src/lib.rs:6:14
  |
6 |     SizeOf = std::mem::size_of::<T>(),
  |              ^^^^^^^^^^^^^^^^^^^^^^^^

Same thing happens if a const parameter is used instead of size_of::<T>().

If we choose option 2, this ICE will turn into a regular error.

---

EDIT: and this currently compiles on nightly (playground):

#![feature(const_generics, arbitrary_enum_discriminant)]

#[repr(usize)]
enum MyWeirdOption<T> {
    None = 0,
    Some(T) = std::mem::size_of::<*mut T>(),
}

And using *mut *mut T instead of *mut T would make it work even when T: Sized isn't known.
(If not for the substitution failure, you could remove #![feature(const_generics)])

---

cc @rust-lang/compiler @rust-lang/lang

[petrochenkov]

This seems equivalent to something like

type A<T> = [u8; std::mem::size_of::<T>()]; // ERROR the size for values of type `T` cannot be known at compilation time

where T is "obviously" in scope, it's just not concrete enough for a use in a constant (the current error is weird though).

I don't like the idea of hiding the name T, but if this is going to be done in resolve, we could setup a "barrier" making it an error to use it, like in this case

fn f<T>() {
    fn f() {
        std::mem::size_of::<T>(); // ERROR can't use generic parameters from outer function
    }
}

, but I'd still prefer the option 2.

[eddyb]

where T is "obviously" in scope, it's just not concrete enough for a use in a constant (the current error is weird though).

No, that's #43408, which is why I added #![feature(const_generics)] to enable the fix above.
This is how it should work and maybe we should just apply an approach like #70452 to as many cases that won't cause query cycle errors, as we can, even before lazy normalization is ready with the full fix.

but if this is going to be done in resolve, we could setup a "barrier" making it an error to use it

Right, this matches my intuition for 1., another example of that error being:

fn f<T>() {
    const _: usize = std::mem::size_of::<T>(); // ERROR can't use generic parameters from outer function
}

but I'd still prefer the option 2.

Me too, if for no other reason that we shouldn't paint ourselves into a corner if we can avoid it.

[spastorino]

We've discussed this briefly during pre triage, I think this was I-nominated in order to be discussed during some T-lang and/or T-compiler meeting. Prioritizing it as P-medium mainly given that it requires nightly.

[eddyb]

@spastorino "requires nightly" is misleading, I'm only using #![feature(const_generics)] to bypass #43408 (enum discriminant expressions are in the same boat as array lengths today).
I'll adjust the labels to match reality and reduce confusion.

More to the point: if we apply the #70452 treatment to enum discriminants (as a partial #43408 fix), then #![feature(const_generics)] won't be necessary.

---

Also, here's an example that compiles on nightly, I'll add it to the issue description:

#![feature(const_generics, arbitrary_enum_discriminant)]

#[repr(usize)]
enum MyWeirdOption<T> {
    None = 0,
    Some(T) = std::mem::size_of::<*mut T>(),
}

And using *mut *mut T instead of *mut T would make it work even when T: Sized isn't known.
(If not for the substitution failure, you could remove #![feature(const_generics)])