Skip to content

Conversation

@dianqk
Copy link

@dianqk dianqk commented Jun 27, 2025

@seanmonstar
Copy link
Member

Thanks for the PR! I agree with this statement in the upstream issue:

The underlying issue causes miscompilation of so many things besides hyper that I would recommend not using such workarounds. I. recommend using either use an earlier toolchain (1.85?) or a later one (upcoming 1.89?) with the fix.

That the miscompilation causes the output of bad HTTP message in hyper is almost a good thing: it's very noticeable. So many other miscompilations likely exist that are much more invisible. It'd be better for anyone experiencing this to downgrade rustc for a while.

@dianqk
Copy link
Author

dianqk commented Jun 27, 2025

That's fine with me. BTW, upstream LLVM, which is upstream of rustc, can only add a workaround for this too. 🫠

@dianqk dianqk closed this Jun 27, 2025
@dianqk dianqk deleted the match-version branch June 27, 2025 22:45
@roblabla
Copy link

roblabla commented Jul 3, 2025

That's fine with me. BTW, upstream LLVM, which is upstream of rustc, can only add a workaround for this too. 🫠

I don't understand this. The problem also occurs with LLD. In this case, the whole toolchain is open source and controlled by either rustc or llvm: Rustc generates the LLVM IR, llvm turns that into machine code, and llvm's LLD turns it into a mach-o. So how is it that only a "workaround" can be added?

@dianqk
Copy link
Author

dianqk commented Jul 3, 2025

That's fine with me. BTW, upstream LLVM, which is upstream of rustc, can only add a workaround for this too. 🫠

I don't understand this. The problem also occurs with LLD. In this case, the whole toolchain is open source and controlled by either rustc or llvm: Rustc generates the LLVM IR, llvm turns that into machine code, and llvm's LLD turns it into a mach-o. So how is it that only a "workaround" can be added?

First, ld64 is a commonly used linker for Mach-O, which is the main issue to be addressed. We cannot ask users to switch to LLD.
Second, Yes, LLD is open source, but we can't ask someone to fix it immediately.

bgw added a commit to vercel/next.js that referenced this pull request Jul 22, 2025
…#81950)

Uses hyperium/hyper#3908 cherry-picked on top of
hyper v1.6.0 to work around
hyperium/hyper#3902 and
rust-lang/rust#140686

- Git Branch:
https://github.com/bgw/hyper-rs/commits/v1.6.0-with-macos-intel-miscompilation-workaround/
- Cherry-picked commit:
bgw/hyper-rs@ab35449

Fixes #81697

The proper fix is to update the rustc toolchain, but since we use
nightly toolchains, this is too risky for a minor patch release. So this
applies the workaround instead.

## Test Plan

Force using x86-64 under Rosetta by downloading a "standalone" version
of nodejs and adding it to the front of the `PATH` with:

```
export PATH=/Users/bgw/Downloads/node-v22.17.1-darwin-x64/bin/:"$PATH"
```

Use `create-next-app` to create a new app. This fetching Geist by
default.

Run `pnpm dev`, see the 404 errors.

Modify the `package.json` to use this preview version:

```
    "next": "https://vercel-packages.vercel.app/next/commits/16196a3d2d7df65222727619e8db993336cf7aff/next"
```

Run `pnpm i && pnpm dev`, see that the 404s are solved!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants