-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Don't suggest break through nested items #112024
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
If I'm not mistaken, this still suggests breaking out of the loop inside a closure - not sure what In the nested item case, currently, the compiler doesn't suggest breaking out of the loop, but instead returning (but only if the type and return types match): error[E0308]: mismatched types
--> src/lib.rs:5:17
|
4 | / if true {
5 | | Err(1)
| | ^^^^^^ expected `()`, found `Result<_, {integer}>`
6 | | }
| |_____________- expected this to be `()`
|
= note: expected unit type `()`
found enum `Result<_, {integer}>`
help: you might have meant to return this value
|
5 | return Err(1);
| ++++++ + |
lol, @SparkyPotato I should've read my own UI test stderr. I had made this work for closures, then refactored it for items and didn't check that I broke it for closures 😭 @rustbot author |
This does suggest breaking out of the loop currently: fn b() {
let _ = loop {
fn foo() -> Result<(), ()> {
if true {
Err(1)
//~^ ERROR mismatched types
}
Err(())
}
};
}
But that's fixed by this PR.
Can you give a more complete example? Not sure if you're asking for something additional that needs fixing, or just making an observation. |
9d8fe30
to
cd16d45
Compare
On stable: fn test() {
loop {
fn x() -> Result<(), i32> {
if true {
Err(1)
}
Ok(())
}
}
} suggests returning the value, while: fn test() {
loop {
fn x() -> Result<(), ()> {
if true {
Err(1)
}
Ok(())
}
}
} has no suggestions. Seemingly, the |
That's because the diagnostic checks that there's a |
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.
r=me with the async blocks handled (and probably also const blocks too?)
Err(1) | ||
//~^ ERROR mismatched types |
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.
Hm, I would expect this to suggest return
. (still better than the status quo ig)
cd16d45
to
0a51ab9
Compare
Async blocks were already handled, but good catch on const blocks. @bors r=WaffleLapkin |
Rollup of 7 pull requests Successful merges: - rust-lang#108459 (rustdoc: Fix LinkReplacer link matching) - rust-lang#111318 (Add a distinct `OperandValue::ZeroSized` variant for ZSTs) - rust-lang#111892 (rustdoc: add interaction delays for tooltip popovers) - rust-lang#111980 (Preserve substs in opaques recorded in typeck results) - rust-lang#112024 (Don't suggest break through nested items) - rust-lang#112128 (Don't compute inlining status of mono items in advance.) - rust-lang#112141 (remove reference to Into in ? operator core/std docs, fix rust-lang#111655) Failed merges: - rust-lang#112071 (Group rfcs tests) r? `@ghost` `@rustbot` modify labels: rollup
Fixes #112020