False positive in a loop that uses let/else

[shinypb]

Summary

Using let/else rather than an alternative block of code doing the same thing causes clippy to think that a loop never actually loops.

Lint Name

clippy::never_loop

Reproducer

This repository demonstrates the problem:
https://github.com/shinypb/rust-clippy-loop-false-positive

I tried this code:

    while let Ok(event) = receiver.recv() {
        let ServiceEvent::ServiceResolved(info) = event else {
            // We don't care about other events here
            continue;
        };
        let Some(addr) = info.get_addresses().iter().next() else {
            // No one should ever have zero addresses, but just in case...
            continue;
        };
        let port = info.get_port();
        return Ok((
            info.get_fullname().to_string(),
            format!("http://{addr}:{port}"),
        ));
    }

I saw this happen:

error: this loop never actually loops
  --> src/main.rs:8:5
   |
8  | /     while let Ok(event) = receiver.recv() {
9  | |         let ServiceEvent::ServiceResolved(info) = event else {
10 | |             // We don't care about other events here
11 | |             continue;
...  |
21 | |         ));
22 | |     }
   | |_____^
   |
   = note: `#[deny(clippy::never_loop)]` on by default
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#never_loop

error: could not compile `rust-clippy-loop-false-positive` due to previous error

Changing my code to avoid the let/else makes the problem go away (yes, this is a very gross way of doing that; I am just trying to have a minimal patch for the purposes of this example 😅 ):

-        let Some(addr) = info.get_addresses().iter().next() else {
+        let mut addr = String::from("");
+        if let Some(addr_inner) = info.get_addresses().iter().next() {
+            // ...
+            addr.push_str(&addr_inner.to_string());
+        } else {

Version

rustc 1.65.0 (897e37553 2022-11-02)
binary: rustc
commit-hash: 897e37553bba8b42751c67658967889d11ecd120
commit-date: 2022-11-02
host: aarch64-apple-darwin
release: 1.65.0
LLVM version: 15.0.0

Additional Labels

No response

[ericwu17]

Thanks for including such a detailed report! I just cloned the repo and ran cargo clippy, and I did not see any warnings emitted. My active toolchain is:

active toolchain
----------------

stable-aarch64-apple-darwin (default)
rustc 1.66.0 (69f9c33d7 2022-12-12)

I believe updating should fix this issue. Looks like it was fixed in pull request #9496

[shinypb]

Thanks, Eric—looks like you're right. 🎉 I appreciate the response. ✨