-
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
"not all control paths return a value" should indicate which control paths don't return a value #18390
Comments
Triage: no change. As an attempt to reproduce this, here's a big function: fn main() {
let _ = foo();
}
fn foo() -> i32 {
let x = 5;
match x {
1 => {
1
},
2 => {
2
},
3 => {
3
},
4 => {
4
},
5 => {
5
},
_ => {
0
},
};
match x {
1 => {
1
},
2 => {
2
},
3 => {
3
},
4 => {
4
},
5 => {
5
},
_ => {
0
},
}; // <- here is the culprit!
} Here's the error:
Doesn't point out the second |
Hi ! Maybe worth bumping and linking to the recent big push for better error messages ? (Not sure/haven't found yet which issue to link specifically) |
Triage: now fixed? Playground says:
|
It's now:
|
#39968 is a clear case where this goes wrong. I'm tempted to close this (not sure how helpful it is)... |
"Not all control paths" error is no longer being displayed, but rather we're catching type errors and extraneous semicolons and providing help for them:
|
I think we can close this... I think the interesting case is now covered by #39968. That is, I modified the original example to something like this: fn main() {
let _ = foo();
}
fn foo() -> i32 {
let x = 5;
match x {
1 => {
1
},
2 => {
2
},
3 => {
3
},
4 => {
4
},
5 => {
5
},
_ => {
0
},
};
match x {
1 => {
return 1
},
2 => {
return 2
},
3 => {
return 3
},
4 => {
return 4
},
5 => {
return 5
},
_ => { }
}
} But now you get:
which is not the original example here. |
Going to close. |
fix: Prevent public re-export of private item
When a glob import overriding the visibility of a previous glob import was not properly resolved when the items are only available in the next fixpoint iteration. The bug was hidden until rust-lang#18390.
It's very mysterious when this error occurs in a big function and it's not one of the obvious extra-semicolon errors.
The text was updated successfully, but these errors were encountered: