macOS 27: can't find crate for `rquickjs_macro`

[clason]

After updating to macOS 27 beta (including Xcode Command Line Tools 27 beta)¹, rquickjs fails to build in release mode with the macro feature:

Steps to reproduce:

git clone https://github.com/DelSkayn/rquickjs.git
cd rquickjs
git submodule update --init
cargo b --release --features=macro

Output:

   Compiling rquickjs-macro v0.12.1 (/Users/clason/build/rquickjs/macro)
   Compiling rquickjs v0.12.1 (/Users/clason/build/rquickjs)
error[E0463]: can't find crate for `rquickjs_macro`
   --> src/lib.rs:129:9
    |
129 | pub use rquickjs_macro::{
    |         ^^^^^^^^^^^^^^ can't find crate

For more information about this error, try `rustc --explain E0463`.
error: could not compile `rquickjs` (lib) due to 1 previous error

Curiously, cargo b --features=macro works fine, as does cargo b --release. This is with rustc 1.97.1 but already happened with 1.96.x, too, so I don't think it's a Rust regression. Since it may be relevant: This is with homebrew installed rustup. Obviously I tried wiping .cargo, reinstalling everything, etc.

---

¹I know that this is an unsupported platform and this is my own fault, but I'm opening this because

1. I am completely baffled and hoping someone here will have some idea what's going on;
2. other people may run into the same problem (especially if they use rquickjs as a dependency in their project, like we do in tree-sitter);
3. the issue has persisted over multiple betas so is very likely to make it into the final release.

[richarddd]

Not a 100% sure I don't think this is an rquickjs issue. The can't find crate error is misleading since the macro crate compiles fine right before it fails. What's actually happening is rustc loads the compiled proc macro dylib at that use and can't find the registrar symbol inside it (__rustc_proc_macro_decls_*).

Your three cases point right at it. Debug works because nothing gets stripped, plain --release works because the macro dylib never gets loaded, and only --release --features=macro both optimizes the dylib and loads it. So I'm pretty sure the new linker in the macOS 27 beta is dead stripping that symbol out of the release build and rustc can't dlsym it.

Can you check? After the failing build run nm target/release/deps/librquickjs_macro-*.dylib | grep proc_macro_decls. On macOS 26 it's there for me. If it's gone on your setup that
confirms it.

Workaround is telling the linker not to strip: RUSTFLAGS="-C link-arg=-Wl,-no_dead_strip" cargo b --release --features=macro, or switch to lld (brew install lld then -C link-arg=-fuse-ld=lld). This isn't specific to us either, any proc macro crate should hit it on the beta toolchain so probably worth an upstream rust issue too.

[clason]

Thank you! I will test as soon as I am back at a desk, but I fully agree that this is not an rquickjs issue and, from what else I see and hear, a linker issue (Apple bug or rather YOLO undocumented breaking behavior change) related to stripping sounds right on the money.

[clason]

Hmm, it seems to be there:

/b/rquickjs ⟩ nm target/release/deps/librquickjs_macro-*.dylib | grep proc_macro_decls 
00000000004d16b8 S ___rustc_proc_macro_decls_34e05c9326d960d3__

(And just for the record: RUSTFLAGS="-C link-arg=-Wl,-no_dead_strip" cargo b --release --features=macro is not a workaround since the fruitclang linker does not support that flag... I also have had bad experiences with vanilla llvm on macOS since you quickly run into problems when mixing upstream and Apple clang support files.)

[clason]

Possibly related: rust-lang/rust#157750

(TL;DR: alignment issue after stripping, although the original issue should have been resolved in beta 3/rustc 1.97.)