When given an enum E and expecting a struct S, rustc suggests using "a variant" of S.

[pnkfelix]

Consider the following code (play):

enum E { Var1, Var2, }

struct S { base: E, }

struct Context { s: S, }

fn main() { let _c = Context { s: E::Var1 }; }

It currently yields the following diagnostic messages:

error[E0308]: mismatched types
 --> src/main.rs:7:35
  |
7 | fn main() { let _c = Context { s: E::Var1 }; }
  |                                   ^^^^^^^
  |                                   |
  |                                   expected struct `S`, found enum `E`
  |                                   help: try using a variant of the expected type: `S(E::Var1)`
  |
  = note: expected type `S`
             found type `E`

This line is what I object to:

  |                                   help: try using a variant of the expected type: `S(E::Var1)`

It has two problems:

1. It uses the terminology variant when discussing building up an instance of the struct S.
2. It uses a tuple struct form in the example rewrite it provides; but our S is a braced struct with named fields.

[zackmdavis]

Is GitHub suffering from some kind of cache-consistency problem!? (I guess so: status.github.com now says they're investigating service unavailability.) I apparently-successfully opened PR #55253 to fix this, but then it wasn't showing up in the PR list and the pull/55253 URL was 404ing, so then I thought that it might not have actually gone through, so then I tried to resubmit, and then that failed with an "A pull request already exists" flash message, and then I wanted to try submitting under a different branch name, and/or rebased so as to have a different SHA (on the theory that maybe the problem had something to do with the fact that I was reusing the branch name from the my PR of last year in which the "variant of the expected type" message was introduced, even though it would be really surprising if a site as old and usually-stable as GitHub didn't already handle that case), but then the "Compare branches" pages aren't showing the open-pull-request form that they usually do.

Typically I wouldn't even bother commenting about this kind of glitch (trusting that our friends at GitHub will sort it out any mere availability issue soon enough), but the fact that other PR pages are loading fine for me makes me wonder if there's some kind of bad state associated with #55253 in particular?!

[zackmdavis]

Is GitHub suffering from some kind of cache-consistency problem!? (I guess so: status.github.com now says they're investigating service unavailability.) I apparently-successfully opened PR #55253 to fix this, but then it wasn't showing up in the PR list and the pull/55253 URL was 404ing, so then I thought that it might not have actually gone through, so then I tried to resubmit, and then that failed with an "A pull request already exists" flash message, and then I wanted to try submitting under a different branch name, and/or rebased so as to have a different SHA (on the theory that maybe the problem had something to do with the fact that I was reusing the branch name from the my PR of last year in which the "variant of the expected type" message was introduced, even though it would be really surprising if a site as old and usually-stable as GitHub didn't already handle that case), but then the "Compare branches" pages aren't showing the open-pull-request form that they usually do.

Typically I wouldn't even bother commenting about this kind of glitch (trusting that our friends at GitHub will sort it out any mere availability issue soon enough), but the fact that other PR pages are loading fine for me makes me wonder if there's some kind of bad state associated with #55253 in particular?!