in which we plug the crack where ?-desugaring leaked into errors
#51938
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Most of the time, it's not a problem that the types of the arm bodies in
a desugared-from-`?` match are different (that is, specifically: in `x?`
where x is a `Result<A, B>`, the `Ok` arm body is an `A`, whereas the
`Err` arm diverges to return a `Result<A, B>`), because they're being
assigned to different places. But in tail position, the types do need to
match, and our error message was explicitly referring to "match arms",
which is confusing when there's no `match` in the sweetly sugared
source.
It is not without some misgivings that we pollute the clarity-of-purpose
of `note_error_origin` with the suggestion to wrap with `Ok` (the other
branches are pointing out the odd-arm-out in the HIR that is the origin
of the error; the new branch that issues the `Ok` suggestion is serving
a different purpose), but it's the natural place to do it given that
we're already matching on `ObligationCauseCode::MatchExpressionArm {
arm_span, source }` there.
Resolves rust-lang#51632.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? @estebank |
|
@bors r+ |
|
📌 Commit 6cc78bf has been approved by |
bors
added
S-waiting-on-bors
Mark-Simulacrum
added a commit
to Mark-Simulacrum/rust
that referenced
this pull request
Jul 2, 2018
…ing_desugar, r=estebank
in which we plug the crack where `?`-desugaring leaked into errors
Most of the time, it's not a problem that the types of the arm bodies in
a desugared-from-`?` match are different (that is, specifically: in `x?`
where x is a `Result<A, B>`, the `Ok` arm body is an `A`, whereas the
`Err` arm diverges to return a `Result<A, B>`), because they're being
assigned to different places. But in tail position, the types do need to
match, and our error message was explicitly referring to "match arms",
which is confusing when there's no `match` in the sweetly sugared
source.
It is not without some misgivings that we pollute the clarity-of-purpose
of `note_error_origin` with the suggestion to wrap with `Ok` (the other
branches are pointing out the odd-arm-out in the HIR that is the origin
of the error; the new branch that issues the `Ok` suggestion is serving
a different purpose), but it's the natural place to do it given that
we're already matching on `ObligationCauseCode::MatchExpressionArm {
arm_span, source }` there.
Resolves rust-lang#51632.
|
⌛ Testing commit 6cc78bf with merge 7f5f5ea7415ebf38502bc23bd46af34f0f2c1d93... |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
1 similar comment
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
CI failure looks dubious |
|
@bors retry |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 6cc78bf with merge cb12d627cc626cc6d67556e1ec215b9d76a428fe... |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
1 similar comment
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jul 5, 2018
…, r=estebank
in which we plug the crack where `?`-desugaring leaked into errors
Most of the time, it's not a problem that the types of the arm bodies in
a desugared-from-`?` match are different (that is, specifically: in `x?`
where x is a `Result<A, B>`, the `Ok` arm body is an `A`, whereas the
`Err` arm diverges to return a `Result<A, B>`), because they're being
assigned to different places. But in tail position, the types do need to
match, and our error message was explicitly referring to "match arms",
which is confusing when there's no `match` in the sweetly sugared
source.
It is not without some misgivings that we pollute the clarity-of-purpose
of `note_error_origin` with the suggestion to wrap with `Ok` (the other
branches are pointing out the odd-arm-out in the HIR that is the origin
of the error; the new branch that issues the `Ok` suggestion is serving
a different purpose), but it's the natural place to do it given that
we're already matching on `ObligationCauseCode::MatchExpressionArm {
arm_span, source }` there.
Resolves #51632.
|
☀️ Test successful - status-appveyor, status-travis |
zackmdavis
added a commit
to zackmdavis/rust
that referenced
this pull request
Oct 27, 2018
This suggestion was introduced in rust-lang#51938 / 6cc78bf (while introducing different language for type errors coming from `?` rather than a `match`), but it has a lot of false-positives (as repeatedly reported in Issues rust-lang#52537, rust-lang#52598, rust-lang#54578, rust-lang#55336), and incorrect suggestions carry more badness than marginal good suggestions do goodness. Just get rid of it (unless and until someone figures out how to do it correctly). Resolves rust-lang#52537, resolves rust-lang#54578.
pietroalbini
added a commit
to pietroalbini/rust
that referenced
this pull request
Oct 29, 2018
…ng_suggestion, r=estebank back out bogus `Ok`-wrapping suggestion on `?` arm type mismatch This suggestion was introduced in rust-lang#51938 / 6cc78bf (while introducing different language for type errors coming from `?` rather than a `match`), but it has a lot of false-positives, and incorrect suggestions carry more badness than marginal good suggestions do goodness. I regret not doing this earlier. 😞 Resolves rust-lang#52537, resolves rust-lang#54578. r? @estebank
pietroalbini
pushed a commit
to alexcrichton/rust
that referenced
this pull request
Oct 29, 2018
This suggestion was introduced in rust-lang#51938 / 6cc78bf (while introducing different language for type errors coming from `?` rather than a `match`), but it has a lot of false-positives (as repeatedly reported in Issues rust-lang#52537, rust-lang#52598, rust-lang#54578, rust-lang#55336), and incorrect suggestions carry more badness than marginal good suggestions do goodness. Just get rid of it (unless and until someone figures out how to do it correctly). Resolves rust-lang#52537, resolves rust-lang#54578.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most of the time, it's not a problem that the types of the arm bodies in
a desugared-from-
?match are different (that is, specifically: inx?where x is a
Result<A, B>, theOkarm body is anA, whereas theErrarm diverges to return aResult<A, B>), because they're beingassigned to different places. But in tail position, the types do need to
match, and our error message was explicitly referring to "match arms",
which is confusing when there's no
matchin the sweetly sugaredsource.
It is not without some misgivings that we pollute the clarity-of-purpose
of
note_error_originwith the suggestion to wrap withOk(the otherbranches are pointing out the odd-arm-out in the HIR that is the origin
of the error; the new branch that issues the
Oksuggestion is servinga different purpose), but it's the natural place to do it given that
we're already matching on
ObligationCauseCode::MatchExpressionArm { arm_span, source }there.Resolves #51632.