Closed
Description
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:
- It uses the terminology
variant
when discussing building up an instance of the structS
. - It uses a tuple struct form in the example rewrite it provides; but our
S
is a braced struct with named fields.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
only issue "variant of the expected type" suggestion for enums
only issue "variant of the expected type" suggestion for enums
zackmdavis commentedon Oct 21, 2018
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 commentedon Oct 21, 2018
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?!
Rollup merge of rust-lang#55253 - zackmdavis:some_suggestion, r=pnkfelix
Rollup merge of rust-lang#55253 - zackmdavis:some_suggestion, r=pnkfelix
Rollup merge of rust-lang#55253 - zackmdavis:some_suggestion, r=pnkfelix