"unreachable_code" warns even on "unreachable!" itself

[safinaskar]

Code

pub async fn get(client: &reqwest::Client, params: &[(&str, &str)]) -> String {
    loop {
        let response = client.get("https://example.com")
            .query(params).send().await.unwrap();
        if response.status().is_success() {
            return response.text().await.unwrap();
        }
        assert!(response.status() == reqwest::StatusCode::TOO_MANY_REQUESTS);
    }
    unreachable!();
}

Current output

Compiling playground v0.0.1 (/playground)
warning: unreachable statement
  --> src/lib.rs:10:5
   |
2  | /     loop {
3  | |         let response = client.get("https://example.com")
4  | |             .query(params).send().await.unwrap();
5  | |         if response.status().is_success() {
...  |
8  | |         assert!(response.status() == reqwest::StatusCode::TOO_MANY_REQUESTS);
9  | |     }
   | |_____- any code following this expression is unreachable
10 |       unreachable!();
   |       ^^^^^^^^^^^^^^ unreachable statement
   |
   = note: `#[warn(unreachable_code)]` on by default
   = note: this warning originates in the macro `unreachable` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: `playground` (lib) generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 1.11s

Desired output

There should be no warning

Rationale and extra context

Code above is based on my actual production code. The intention is this: continue issuing requests as long as we get TOO_MANY_REQUESTS. When we get SUCCESS, return from the function. I put unreachable! to the end intentionally: to make sure that that line is actually unreachable. I. e. I want to get panic if I'm wrong.

In this particular example rustc can prove that that piece is unreachable and thus give me a warning. But I don't like it. I don't want to remove unreachable!. It is present for a reason.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=684eaca4cc578206f971cc6345e3d0c6

Here is even more reduced version: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e90f7dbeb04fd15ed2ae6354cb158fce (so that you can see that async and reqwest are not related here)

Other cases

No response

Anything else?

No response

[eggyal]

I put unreachable! to the end intentionally: to make sure that that line is actually unreachable. I. e. I want to get panic if I'm wrong.

Surely then this is a perfect use-case for applying #[allow(unreachable_code)] to the function, or if you want to be more specific then to a block containing the unreachable!() invocation:

#[allow(unreachable_code)]
{
    unreachable!();
}

[safinaskar]

@eggyal , you mean I should place #[allow(unreachable_code)] in my code? Well, any allow constructs look dangerous for me. They all scream: "Hey! Dragons here! Here we are doing something dangerous and we disable some compiler checks, so that the compiler doesn't tell us about this. So we (not rustc) are now have responsibility to check everything is okay"

[safinaskar]

@rustbot label +A-control-flow +A-lint

[eggyal]

I think it's more useful to have the compiler warn that an unreachable! invocation is in fact guaranteed to be unreachable and therefore can be removed than it is to have such warnings suppressed by default, especially since it's trivial to manually suppress the warning in rare cases such as these where it's desired. But that's just my humble opinion, perhaps the team will see it differently.

[ChrisDenton]

Hm, in this particular case you can have a compile time guarantee that code after the loop can never be reached because the function signature requires returning a value other than (). You just need to add a semicolon after the loop.

But in the general case it does seem like it would be useful to have something similar to compile_error but that's removed for provably unreachable code.

[safinaskar]

@eggyal

and therefore can be removed

I don't want to remove it. What if I change something and this place becomes reachable?

Also, if the team thinks that this code should give a warning, then I want some other macro (say, static_unreachable!), which will check statically that code is unreachable. (If someone can give implementation, this will be nice.)

@ChrisDenton

Hm, in this particular case you can have a compile time guarantee that code after the loop can never be reached because the function signature requires returning a value other than ()

Yes. But what if in the future I change function return value?

[ChrisDenton]

Yes. But what if in the future I change function return value?

I was agreeing with that, hence the paragraph that followed.

[eggyal]

If this is to be remedied, rather than special case the unreachable_code lint it may be better to include an #[allow(unreachable_code)] attribute in the unreachable! macro's expansion.

[timotree3]

Using the unstable #[expect()] feature, you can get a compile error if the code is reachable, regardless of the return type of the function

#![feature(lint_reasons)]

pub fn reachable() {
    loop { break; }
    #[deny(unfulfilled_lint_expectations)]
    #[expect(unreachable_code)]
    { unreachable!() }
}


pub fn not_reachable() {
    loop {}
    #[deny(unfulfilled_lint_expectations)]
    #[expect(unreachable_code)]
    { unreachable!() }
}

playground

[safinaskar]

@timotree3 , thanks a lot! I just tried to create static_unreachable! macro using your method, but I failed:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=9bda0ef1763224a77e2f973edbabb2f6

[timotree3]

If you invoke it as static_unreachable!() instead of static_unreachable!(); (remove the ;) it works

I think the ; is making the macro expand into this

{
    #[deny(unfulfilled_lint_expectations)]
    #[expect(unreachable_code)]
    {
        unreachable!()
    }
}; // < unreachable statement!

The outer block is an unreachable statement without any allow or expect attached to it