Explain that in paths generics can't be set on both the enum and the variant

[estebank]

error[E0109]: type arguments are not allowed on tuple variant `TSVariant`
  --> $DIR/enum-variant-generic-args.rs:54:29
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |                 ---------   ^^ type argument not allowed
   |                 |
   |                 not allowed on tuple variant `TSVariant`
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
help: remove the generics arguments from one of the path segments
   |
LL -     Enum::<()>::TSVariant::<()>(());
LL +     Enum::TSVariant::<()>(());
   |
LL -     Enum::<()>::TSVariant::<()>(());
LL +     Enum::<()>::TSVariant(());
   |

Fix #93993.

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

HIR ty lowering was modified

cc @fmease

[lcnr]

it's not that they aren't allowed on enum variants at all, they are only forbidden if they are already specified on the enum type:

type OptionU32 = Option<u32>;
fn main() {
    Some::<u32>; // ok
    Option::Some::<u32>; // ok
    Option::<u32>::Some::<u32>; // ERROR
    OptionU32::Some; // ok
    OptionU32::Some::<u32>; // ERROR
}

[BoxyUwU]

@rustbot author

[lcnr]

vibe: I feel like making this a suggestion is not worth it and that the 6 additional lines in the error message add more noise. I would personally prefer to only make this a help message

r=me with or without that change

[estebank]

I had a few different alternatives on how to communicate this, because previously we didn't point at the previous type args:

error[E0109]: type arguments are not allowed on tuple variant `TSVariant`
  --> $DIR/enum-variant-generic-args.rs:54:29
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |                 ---------   ^^ type argument not allowed
   |                 |
   |                 not allowed on tuple variant `TSVariant`
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
help: remove the generics arguments from one of the path segments
   |
LL -     Enum::<()>::TSVariant::<()>(());
LL +     Enum::TSVariant::<()>(());
   |
LL -     Enum::<()>::TSVariant::<()>(());
LL +     Enum::<()>::TSVariant(());
   |

error[E0109]: type arguments are not allowed on tuple variant `TSVariant`
  --> $DIR/enum-variant-generic-args.rs:54:29
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |                 ---------   ^^ type argument not allowed
   |                 |
   |                 not allowed on tuple variant `TSVariant`
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |           ^^^^              ^^

error[E0109]: type arguments are not allowed on tuple variant `TSVariant`
  --> $DIR/enum-variant-generic-args.rs:54:29
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |           ----  ---------   ^^
   |           |     |           |
   |           |     |           type argument not allowed
   |           |     |           type argument on the variant
   |           |     not allowed on tuple variant `TSVariant`
   |           type argument on the enum
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other

I wasn't happy with any of them, tbh. They are all verbose, at lesat the suggestion one has the chance of being understood by the widest amount of people. One other option is to emit a specific error:

error[E0109]: type arguments are not allowed on enum `Enum` and tuple variant `TSVariant` at the same time
  --> $DIR/enum-variant-generic-args.rs:54:29
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |            ^^   ---------   ^^ type argument on the variant
   |            |     
   |            type argument on the enum
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other

Any preference?

[lcnr]

maybe also pointing to the generic args on the enum inline

error[E0109]: type arguments are not allowed on variant `SVariant`
  --> $DIR/enum-variant-generic-args.rs:72:28
   |
LL |     Enum::<()>::SVariant::<()> { v: () };
   |                 --------   ^^ type argument not allowed
   |                 |
   |                 not allowed on variant `SVariant`
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segment simultaneously
   = help: consider removing the redundant generic arguments from the variant's path

I feel like we should be opinionated here and suggest keeping the args on the enum.

[estebank]

What about the current output?

[lcnr]

I personally prefer my suggestion from the last comment over the status quo. It's also still broken in the AliasFixed error message, isn't it?

I think stating both "not allowed on enum Enum" and "not allowed on tuple variant TSVariant" is confusing. I would chnage the first to "already specified on enum Enum" maybe?

[BoxyUwU]

In the AliasFixed examples it's not valid to turbofish the alias or the variant, I don't expect this PR to affect anything there (though it may be a good follow up PR to consolidate the errors for each segment into a single one).

[BoxyUwU]

I think I agree with lcnr about how having extra spans and things in the error message for the enum arguments too is confusing. Can you just remove this so we keep the current set of segments, then I think this is good to merge

[estebank]

done

[BoxyUwU]

@rustbot author

[estebank]

@BoxyUwU changed

@rustbot review

[BoxyUwU]

@bors r+ rollup

[bors]

📌 Commit 23daa8c has been approved by BoxyUwU

It is now in the queue for this repository.