Rust 1.88.0 causes broken HTTP requests with hyper on x86_64-darwin on optimization levels greater than 1

[grahamc]

I upgraded to Rust 1.88.0, and suddenly my builds for Intel macOS can't make HTTP requests.

Code

With this Cargo.toml:

[package]
name = "what"
version = "0.0.1"
edition = "2024"

[dependencies]
http = "1.3"
http-body-util = "0.1.3"
hyper-util = { version = "0.1", features = ["client", "client-legacy", "http1"] }
tokio = "1"

[profile.dev]
opt-level = 2

And this main.rs:

use http::Method;
use hyper_util::client::legacy::Client;

fn main() {
    tokio::runtime::Builder::new_current_thread()
        .enable_all()
        .build()
        .unwrap()
        .block_on(async {
            let response = Client::builder(hyper_util::rt::TokioExecutor::new())
                .build_http()
                .request(http::request::Builder::new()
                    .uri("http://127.0.0.1:6789")
                    .method(Method::GET)
                    .body(http_body_util::Empty::<&[u8]>::new())
                    .unwrap())
                .await
                .unwrap();

            let status = response.status();

            panic!("{status}");
        });
}

Then, in one terminal:

nc -l 6789

...and in another terminal, run the program in the dev profile:

cargo run

Observe an invalid request is received by nc:

GET /
host: 127.0.0.1:6789

Then, edit the Cargo.toml to set opt-level = 1 on the dev profile. Restart the nc listener and recompile / re-run the Rust program.

Observe a correctly formatted HTTP 1.1 request:

GET / HTTP/1.1
host: 127.0.0.1:6789

Version it worked on

Before I upgraded, I was successfully using:

rustc 1.85.0 (4d91de4e4 2025-02-17)
binary: rustc
commit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688
commit-date: 2025-02-17
host: x86_64-apple-darwin
release: 1.85.0
LLVM version: 19.1.7

Version with regression

Then I upgraded to the below version and found it broken:

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-apple-darwin
release: 1.88.0
LLVM version: 20.1.5

--

Please note I typically use Nix to get Rust / Cargo / etc. I put together this minimal repository that replicates the behavior for me: https://github.com/grahamc/rustc-1-88-0-broke-my-http-client-on-intel-macs

[saethlin]

I'm unable to reproduce this on x86_86 Linux, even if I try matching the x86_86 Mac target features. It's possible that the relevant code is behind a cfg somewhere.

[kpreid]

I'm unable to reproduce this on x86_64-apple-darwin rustc installed via rustup (identical rustc -vV output to the report) and running on an x86 MacBook Pro, not emulation. So, either Nix is influencing the situation or there are other required conditions not discovered.

[DaniPopes]

Could be a duplicate of #140686, can you reproduce on nightly?

[cole-h]

Looks very similar indeed. I cannot reproduce on nightly with:

$ rustc --version --verbose
rustc 1.90.0-nightly (e46629662 2025-07-17)
binary: rustc
commit-hash: e4662966273ed58b51f9ff8d682accc202aa1210
commit-date: 2025-07-17
host: x86_64-apple-darwin
release: 1.90.0-nightly
LLVM version: 20.1.8

[Mozart409]

I installed rust via rustup and I can NOT reproduce it.

rustc 1.88.0 (6b00bc3 2025-06-23)
binary: rustc
commit-hash: 6b00bc3
commit-date: 2025-06-23
host: x86_64-apple-darwin
release: 1.88.0
LLVM version: 20.1.5

[Noratrieb]

@grahamc am I understanding correctly that your flake gets Rust from fenix, which downloads the official static.rust-lang.org builds?

Are you able to reproduce this behavior with rustup as well, or just with your Nix setup? If no, what about using the rustup nix package? It seems like this is not a universal issue as others are unable to reproduce it, so we need some more details on the setup and where everything comes from to figure out what could cause it.