panic does not compile intoResponse in Rust 1.85 and edition2024

[Havunen]

• I have looked for existing issues (including closed) about this

Bug Report

Version

cargo tree | grep axum

├── axum v0.8.1
│   ├── axum-core v0.5.0

Platform

Linux linuxdesktop 6.12.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 02 Jan 2025 22:52:26 +0000 x86_64 GNU/Linux

Steps to reproduce code:

Cargo.toml

edition = "2024"
rust-version = "1.85.0"

main.rs

use axum::Router;
use axum::routing::get;

#[tokio::main]
async fn main() {
    let app = Router::new()
        .route("/fail2", get(|| async { panic!("panic") }));

    let listener = tokio::net::TcpListener::bind("0.0.0.0").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

compiler errors:

error[E0277]: the trait bound `!: IntoResponse` is not satisfied
   --> crates/ae_api/src/main.rs:7:30
    |
7   |         .route("/fail2", get(|| async { panic!("panic") }));
    |                          --- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `IntoResponse` is not implemented for `!`
    |                          |
    |                          required by a bound introduced by this call
    |
    = help: the following other types implement trait `IntoResponse`:
              &'static [u8; N]
              &'static [u8]
              &'static str
              ()
              (R,)
              (Response<()>, R)
              (Response<()>, T1, R)
              (Response<()>, T1, T2, R)
            and 120 others
    = note: this error might have been caused by changes to Rust's type-inference algorithm (see issue #48950 <https://github.com/rust-lang/rust/issues/48950> for more information)
    = help: did you intend to use the type `()` here instead?
    = note: required for `{closure@crates/ae_api/src/main.rs:7:30: 7:32}` to implement `Handler<((),), ()>`
note: required by a bound in `axum::routing::get`
   --> /.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/axum-0.8.1/src/routing/method_routing.rs:440:1
    |
440 | top_level_handler_fn!(get, GET);
    | ^^^^^^^^^^^^^^^^^^^^^^---^^^^^^
    | |                     |
    | |                     required by a bound in this function
    | required by this bound in `get`
    = note: this error originates in the macro `top_level_handler_fn` (in Nightly builds, run with -Z macro-backtrace for more info)

edition2021 compiles without errors.

Maybe its related to this: rust-lang/rust#123748

[Turbo87]

Since we can't impl IntoResponse for ! due to rust-lang/rust#35121, I don't think there is much we can do about this 🤔

[jplatte]

Yeah we can impl this once ! is stable.

[Havunen]

I quickly skimmed through that issue.
Can Infallible be used to impl IntoResponse?

https://doc.rust-lang.org/std/convert/enum.Infallible.html

[jplatte]

That's already implemented: https://docs.rs/axum-core/0.5.0/axum_core/response/trait.IntoResponse.html#impl-IntoResponse-for-Infallible

[Havunen]

Rust 1.85 and edition2024 is now stable, is there any workaround available?

[mladedav]

If you need just a workaround, then cast it explicitly, e.g. .route("/panic", get(|| async { panic!() as () })

But otherwise we need to implement the trait but make sure we do it in a way that doesn't break people who still use the older edition.

[mladedav]

Actually, I'm not so sure we can do that simply. We can gate the implementation block based on compiler version used but I don't think we can support two editions unless we release two different versions axum which I don't think is warranted just for this.

For context, our current MSRV is 1.75 and supporting this would mean we would have to bump it all the way to the current stable which is 1.85. When we went from edition 2018 to 2021, it was 8 months after its initial release, upgrading to 1.56 while 1.61 was already out.

I think we should give users some time to upgrade if we're to upgrade this in a patch release.

[Turbo87]

out of curiosity, what is the use case for supporting unconditional panic!() in the first place? it seems to me that for prototyping code todo!() might be a better fit, and in production code panic!() should probably be avoided too.

[mladedav]

todo!() would run into the same issue though. Even loop {} would and I gotta say writing (loop {}) as () is kind of weird 😄

[Turbo87]

are you sure about that? my understating is that that todo macro uses a generic return type and behaves differently from panic in that regard.

I agree that writing the loop that way is weird but I don't see the use case for wiring that in a route handler fn in the first place 😄

[jplatte]

I am certain that all the cases David listed are the same. And ! is not stabilized even in 1.85, so bumping MSRV would not help at all.

[Turbo87]

looks like you're right. I wasn't aware that the behavior of todo!() also changed in the 2024 edition. seems like a questionable change IMHO, but I guess that ship has sailed.

but as you said, since the ! is still not stabilized there is unfortunately not much we can do about it. I thought we might get away with impl<T: Into<Infallible>> IntoResponse for T but the compiler then complains about "conflicting implementations".

[jplatte]

No macro behavior was changed. It's type inference that changed.

[alice-i-cecile]

FYI, Bevy ran into this over at rust-lang/rust#139610, and we're considering implementing the never_say_never hacky workaround if you'd like to learn from our approach.

[jplatte]

I know about that hack, but we already implement IntoResponse for Infallible, so if we were to use that hack, the stabilization of never would definitely break all versions of axum with it since Infallible will become an alias for never.

[Turbo87]

could we restrict the hack impl by Rust version or something like that?

[jplatte]

I suppose we could do a compile probe thing. For using the version, we'd have to know which version is going to stabilize never, and then it could still break for nightly users.

Also, so far this issue has not received any reactions or comments from users other than the one who reported it. I don't think we urgently need to do anything.