Incorrect compilation error of using sync Mutex across an await point

[RedKinda]

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

Bug Report

Version

❯ cargo tree | grep axum
├── axum v0.6.20
│ ├── axum-core v0.3.4
│ ├── axum-macros v0.3.8 (proc-macro)

Platform

Linux archlinux 6.5.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 10 Oct 2023 21:10:21 +0000 x86_64 GNU/Linux

Crates

Description

Acquiring a (sync, not tokio) mutex lock from shared state, and also using any await point within a route handler throws a compilation error. Minimal repro here https://pastebin.com/rgEnFPfm. Note that removing line 31 (which is a noop on an await point) makes it fail to compile, even though the MutexGuard locked is dropped on line 29. It is unclear to me whether this is a rust/axum bug, feel free to redirect this.

axum::debug_handler shows this

error: future cannot be sent between threads safely
  --> src/min_repro.rs:24:1
   |
24 | #[axum::debug_handler]
   | ^^^^^^^^^^^^^^^^^^^^^^ future returned by `my_route` is not `Send`
   |
   = help: within `impl std::future::Future<Output = (axum::http::StatusCode, std::string::String)>`, the trait `std::marker::Send` is not implemented for `std::sync::MutexGuard<'_, u64>`
note: future is not `Send` as this value is used across an await
  --> src/min_repro.rs:31:33
   |
26 |     let mut locked = state.locked.lock().unwrap();
   |         ---------- has type `std::sync::MutexGuard<'_, u64>` which is not `Send`
...
31 |     tokio::spawn(async move {}).await;
   |                                 ^^^^^ await occurs here, with `mut locked` maybe used later
note: required by a bound in `min_repro::__axum_macros_check_my_route_future::check`
  --> src/min_repro.rs:24:1
   |
24 | #[axum::debug_handler]
   | ^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `check`
   = note: this error originates in the attribute macro `axum::debug_handler` (in Nightly builds, run with -Z macro-backtrace for more info)

[davidpdrsn]

Not exactly sure why it doesn't work but its not an axum bug.

[jplatte]

This is a rustc bug: rust-lang/rust#57478

You can work around it by creating a smaller {} scope for the mutex guard.