Change:
LL |     this_function_expects_a_double_option(DoubleOption::AlternativeSome(n)); |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to previous error </del> <ins> error[E0308]: mismatched types --> $DIR/issue-42764.rs:37:33 | LL |     let _c = Context { wrapper: Payload{} }; |                                 ^^^^^^^^^ expected struct `Wrapper`, found struct `Payload` | = note: expected type `Wrapper` found type `Payload` error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0308`.

Discussion:
Consider the following code (): It currently yields the following diagnostic messages: This line is what I object to: It has two problems: It uses the terminology when discussing building up an instance of the struct . It uses a tuple struct form in the example rewrite it provides; but our is a braced struct with named fields.
Is GitHub suffering from some kind of cache-consistency problem!? (I guess so: they're investigating service unavailability.) I apparently-successfully opened PR to fix this, but then it wasn't showing up in the and the pull/ 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 in particular?!
Is GitHub suffering from some kind of cache-consistency problem!? (I guess so: they're investigating service unavailability.)

I apparently-successfully opened PR to fix this, but then it wasn't showing up in the and the pull/ 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 in particular?!