-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggest solutions for fn foo(&foo: Foo)
#38605
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #38449) made this pull request unmergeable. Please resolve the merge conflicts. |
@estebank I definitely think we need suggestions here, but somehow I'm not sure this output will address the core problem, which tends to be that people don't know where to put the error[E0308]: inappropriate pattern for type
--> file.rs:3:8
|
3 | fn foo(&foo: Foo) {}
| ^^^^ `&` pattern cannot be used to match a value of type `Foo`
|
= help: use `foo: &Foo` to declare an argument `foo` of type `&Foo` I realize this is a deeper change, but my goals here are:
I am not crazy about the precise wording of my final suggestion there. (I wonder if @wycats has any suggestions here?) |
Perhaps the most important point of @nikomatsakis 's comment: in practice, someone who writes:
So I imagine a shallower change to your PR would be to make it emit:
|
Yeah, this is probably best |
Changed to @pnkfelix's version. Next time I have some time to look at this, I will look at adding a new error code for this specific case so that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add the wacky test cases too?
if let Ok(snippet) = self.sess().codemap() | ||
.span_to_snippet(pat.span) | ||
{ | ||
err.help(&format!("did you mean `{}: &{}`?", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One concern -- what happens in more extreme cases? I think we should check that the inner pattern (represented by inner
, here) is a binding pattern, so as not to trigger for something like fn foo(&&bar: &u32)
or fn foo(&[bar]: &u32)
. Suggesting &bar: &&u32
and [bar]: &&u32
respectively doesn't seem all that helpful (that is what we will do, right?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried adding these cases to the test and the results where:
fn ugh(&[bar]: &u32) {
}
error: slice pattern syntax is experimental (see issue #23121)
--> ../../src/test/ui/mismatched_types/issue-38371.rs:26:9
|
26 | fn ugh(&[bar]: &u32) {
| ^^^^^
fn agh(&&bar: &u32) {
}
error[E0308]: mismatched types
--> ../../src/test/ui/mismatched_types/issue-38371.rs:29:9
|
29 | fn agh(&&bar: &u32) {
| ^^^^ expected u32, found reference
|
= note: expected type `u32`
= note: found type `&_`
without changes to the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the first one is a case of needing a feature-gate, but I'm surprised by the second one. What does &&bar: &Foo
do? I can't tell why the help doesn't trigger here...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't tell why the help doesn't trigger here...?
Neither can I. I've never even thought about trying to use something like (&&bar: &u32)
.
the first one is a case of needing a feature-gate
I figured as much. Last time I looked at this I couldn't find the appropriate feature gate, but just googled again and found it. I added the test back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'll pull your branch and build it locally and try to figure out what is going on then. I mean the tests look pretty good but I'd rather not enable misleading output if we can help it. Might take a day or two though.
| ^^^^ expected struct `Foo`, found reference | ||
| | ||
= note: expected type `Foo` | ||
= note: found type `&_` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have to fix this here necessarily, but I feel like these note:
messages are kind of distracting from the help
, which is more likely to be of use. But I'm not sure how to fix without doing potentially more harm than good, so let's leave as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For a while I've been thinking wether it would make sense to make the expected
/found
notes a first class comment, so that these errors would look closer to
error[E0308]: mismatched types
--> ../../src/test/ui/mismatched_types/issue-38371.rs:14:8
|
14 | fn foo(&foo: Foo) {
| ^^^^ expected struct `Foo`, found reference
|
= expected type `Foo`
= found type `&_`
= help: did you mean `foo: &Foo`?
error[E0308]: mismatched types
--> ../../src/test/ui/mismatched_types/issue-38371.rs:26:9
|
26 | fn agh(&&bar: &u32) {
| ^^^^ expected u32, found reference
|
= expected type `u32`
= found type `&_`
If you feel there'd be value on that, I could create an issue and start a PR for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that looks better
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
c6abd17
to
a10f838
Compare
OK, I investigated. The reason that my examples were not producing bad suggestions was because the fn agh(&&&bar: u32) {
}
fn main() { } which emits:
I pushed a commit addressing this issue and adding a comment -- but without a test case yet. |
@bors r+ |
📌 Commit d723e02 has been approved by |
⌛ Testing commit d723e02 with merge 2a0b975... |
💔 Test failed - status-travis |
… On Wed, Jan 11, 2017 at 3:19 PM, bors ***@***.***> wrote:
💔 Test failed - status-travis
<https://travis-ci.org/rust-lang/rust/builds/191132785>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#38605 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD95G5JfDplqjUNAoe5n3r82h5fA-1gks5rRWOcgaJpZM4LVdSH>
.
|
Suggest solutions for `fn foo(&foo: Foo)` For a given file: ```rust struct Foo {} fn foo(&foo: Foo) {} ``` suggest: ``` error[E0308]: mismatched types --> file.rs:3:8 | 3 | fn foo(&foo: Foo) {} | ^^^^ expected struct `Foo`, found reference | = note: expected type `Foo` = note: found type `&_` = help: did you mean `foo: &Foo`? ``` Fix #38371.
☀️ Test successful - status-appveyor, status-travis |
For a given file:
suggest:
Fix #38371.