wasm-pack example doesn't compile

[tstachl]

Code

mod utils;

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern "C" {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet() {
    alert("Hello, wasm-game-of-life!");
}

Meta

rustc --version --verbose:

rustc 1.76.0 (07dca489a 2024-02-04) (built from a source tarball)
binary: rustc
commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce
commit-date: 2024-02-04
host: aarch64-apple-darwin
release: 1.76.0
LLVM version: 17.0.6

Error output

$ wasm-pack build

[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
   Compiling proc-macro2 v1.0.78
   Compiling unicode-ident v1.0.12
   Compiling wasm-bindgen-shared v0.2.92
   Compiling log v0.4.21
   Compiling once_cell v1.19.0
   Compiling bumpalo v3.15.4
   Compiling wasm-bindgen v0.2.92
   Compiling cfg-if v1.0.0
   Compiling quote v1.0.35
   Compiling syn v2.0.52
   Compiling wasm-bindgen-backend v0.2.92
   Compiling wasm-bindgen-macro-support v0.2.92
   Compiling wasm-bindgen-macro v0.2.92
   Compiling console_error_panic_hook v0.1.7
   Compiling wasm-game-of-life v0.1.0 (/Users/thomas/workspace/wasm-game-of-life)
warning: function `set_panic_hook` is never used
 --> src/utils.rs:1:8
  |
1 | pub fn set_panic_hook() {
  |        ^^^^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

thread 'rustc' panicked at compiler/rustc_codegen_ssa/src/back/linker.rs:1269:9:
frameworks not supported
stack backtrace:
   0:        0x100edafd4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h61949099c17bb561
   1:        0x100f262a0 - core::fmt::write::he0c0819610fe7c82
   2:        0x100eb52dc - std::io::Write::write_fmt::h14dadda6958822c3
   3:        0x100edae28 - std::sys_common::backtrace::print::h10166cbeffac9d38
   4:        0x100edc22c - std::panicking::default_hook::{{closure}}::hfec7fca779e11f3b
   5:        0x100edbfac - std::panicking::default_hook::h26402d2c6670ffd0
   6:        0x104ce3cdc - std[d0251ff5e400585e]::panicking::update_hook::<alloc[6ce8990e7c5dc05d]::boxed::Box<rustc_driver_impl[8e5d690fd0be477f]::install_ice_hook::{closure#0}>>::{closure#0}
   7:        0x100edc94c - std::panicking::rust_panic_with_hook::hb00dd38969b5a277
   8:        0x100edc62c - std::panicking::begin_panic_handler::{{closure}}::hc86edf66ba485638
   9:        0x100edb208 - std::sys_common::backtrace::__rust_end_short_backtrace::h24f57ebe971b5eac
  10:        0x100edc3e0 - _rust_begin_unwind
  11:        0x100f373a8 - core::panicking::panic_fmt::h21b3a72f47844886
  12:        0x1063c8f90 - <rustc_codegen_ssa[a999618830fe78cb]::back::linker::WasmLd as rustc_codegen_ssa[a999618830fe78cb]::back::linker::Linker>::framework_path
  13:        0x1063940b0 - rustc_codegen_ssa[a999618830fe78cb]::back::link::linker_with_args
  14:        0x10638d5d0 - rustc_codegen_ssa[a999618830fe78cb]::back::link::link_natively
  15:        0x10638a058 - rustc_codegen_ssa[a999618830fe78cb]::back::link::link_binary
  16:        0x104f23d14 - <rustc_codegen_llvm[2b9269ad3452bf90]::LlvmCodegenBackend as rustc_codegen_ssa[a999618830fe78cb]::traits::backend::CodegenBackend>::link
  17:        0x104e3abc8 - <rustc_interface[dd532f6f2f02f054]::queries::Linker>::link
  18:        0x104cb252c - rustc_span[8e20f49d120d5a21]::set_source_map::<core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>, rustc_interface[dd532f6f2f02f054]::interface::run_compiler<core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>, rustc_driver_impl[8e5d690fd0be477f]::run_compiler::{closure#0}>::{closure#0}::{closure#0}>
  19:        0x104cd8a44 - <scoped_tls[800220c1626a2492]::ScopedKey<rustc_span[8e20f49d120d5a21]::SessionGlobals>>::set::<rustc_interface[dd532f6f2f02f054]::interface::run_compiler<core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>, rustc_driver_impl[8e5d690fd0be477f]::run_compiler::{closure#0}>::{closure#0}, core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>>
  20:        0x104cb44f8 - rustc_span[8e20f49d120d5a21]::create_session_globals_then::<core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>, rustc_interface[dd532f6f2f02f054]::interface::run_compiler<core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>, rustc_driver_impl[8e5d690fd0be477f]::run_compiler::{closure#0}>::{closure#0}>
  21:        0x104d14ca8 - std[d0251ff5e400585e]::sys_common::backtrace::__rust_begin_short_backtrace::<rustc_interface[dd532f6f2f02f054]::util::run_in_thread_with_globals<rustc_interface[dd532f6f2f02f054]::interface::run_compiler<core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>, rustc_driver_impl[8e5d690fd0be477f]::run_compiler::{closure#0}>::{closure#0}, core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>>
  22:        0x104ce4160 - <<std[d0251ff5e400585e]::thread::Builder>::spawn_unchecked_<rustc_interface[dd532f6f2f02f054]::util::run_in_thread_with_globals<rustc_interface[dd532f6f2f02f054]::interface::run_compiler<core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>, rustc_driver_impl[8e5d690fd0be477f]::run_compiler::{closure#0}>::{closure#0}, core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[8a3d40ff46b1d1ff]::result::Result<(), rustc_span[8e20f49d120d5a21]::ErrorGuaranteed>>::{closure#1} as core[8a3d40ff46b1d1ff]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  23:        0x100ed5370 - std::sys::unix::thread::Thread::new::thread_start::hbfaa262dcce3c585
  24:        0x1984e6fa0 - __pthread_joiner_wake

error: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.76.0 (07dca489a 2024-02-04) (built from a source tarball) running on aarch64-apple-darwin

note: compiler flags: --crate-type cdylib --crate-type rlib -C opt-level=s -C embed-bitcode=no

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
warning: `wasm-game-of-life` (lib) generated 1 warning
error: could not compile `wasm-game-of-life` (lib); 1 warning emitted
Error: Compiling your crate to WebAssembly failed
Caused by: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit status: 101
  full command: cd "/Users/thomas/workspace/wasm-game-of-life" && "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

Backtrace

$ RUST_BACKTRACE=1 wasm-pack build

[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
   Compiling wasm-game-of-life v0.1.0 (/Users/thomas/workspace/wasm-game-of-life)
warning: function `set_panic_hook` is never used
 --> src/utils.rs:1:8
  |
1 | pub fn set_panic_hook() {
  |        ^^^^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

thread 'rustc' panicked at compiler/rustc_codegen_ssa/src/back/linker.rs:1269:9:
frameworks not supported
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: <rustc_codegen_ssa::back::linker::WasmLd as rustc_codegen_ssa::back::linker::Linker>::framework_path
   3: rustc_codegen_ssa::back::link::linker_with_args
   4: rustc_codegen_ssa::back::link::link_natively
   5: rustc_codegen_ssa::back::link::link_binary
   6: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::link
   7: <rustc_interface::queries::Linker>::link
   8: rustc_span::set_source_map::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}>::{closure#0}::{closure#0}>
   9: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}>::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>
  10: rustc_span::create_session_globals_then::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}>::{closure#0}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.76.0 (07dca489a 2024-02-04) (built from a source tarball) running on aarch64-apple-darwin

note: compiler flags: --crate-type cdylib --crate-type rlib -C opt-level=s -C embed-bitcode=no

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
warning: `wasm-game-of-life` (lib) generated 1 warning
error: could not compile `wasm-game-of-life` (lib); 1 warning emitted
Error: Compiling your crate to WebAssembly failed
Caused by: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit status: 101
  full command: cd "/Users/thomas/workspace/wasm-game-of-life" && "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

[bjorn3]

Does it stil crash if you remove mod utils; and if not what are the contents of utils.rs? Also what is the content of Cargo.toml?

[tstachl]

Hey @bjorn3, yes, it still crashes. Here is the repo I'm working with: https://github.com/tstachl/wasm-game-of-life

Also, I'm using nix to setup the development environment for this project.

[domenkozar]

Similar backtrace at https://github.com/cachix/devenv-nixpkgs/actions/runs/8722974881/job/23930171199#step:6:74

Using https://github.com/cachix/devenv/blob/main/examples/rust-wasm-cross/devenv.nix

[saethlin]

A reproducer that doesn't involve Nix would really help in debugging this.

[workingjubilee]

The reproducer is actually quite brutally simple.

With the following Rust code:

fn main() {}

So note it must be a binary, not a library...

Run this: rustc -Lframework="blah" wasm-cant-framework.rs --target=wasm32-unknown-unknown

[workingjubilee]

Yay, a cdylib also works!

[bjorn3]

I think this ICEs on all targets that don't use gcc or clang as linker. And on non-apple targets that use gcc or clang as linker I think it will result in the linker giving an error about an unsupported flag.

[workingjubilee]

My understanding of frameworks and deployment targets is that macOS hosts should be making the frameworks they pass dependent on their actual build/deployment target (which may differ from the host's Apple SDK!), so it would make sense to also avoid passing in frameworks when building for wasm.

I think thus that the rejection is not a bug but the ICE is, as we need to issue actual diagnostics instead.

[saethlin]

we need to issue actual diagnostics instead.

This is common in that part of the compiler. There are 6 bug! in compiler/rustc_codegen_ssa/src/back/linker.rs which should all be diagnostics, not ICEs.

And there are 2 in compiler/rustc_codegen_ssa/src/back/link.rs, at least one of those should be a diagnostic.

[workingjubilee]

I suppose one could argue "that should be handled earlier" so things like my "try to get --emit=metadata to ICE, but it doesn't" don't happen, but the implementation of the linker and rustc's Session are right there, so...

[workingjubilee]

I suppose one could argue "that should be handled earlier" so things like my "try to get --emit=metadata to ICE, but it doesn't" don't happen, but the implementation of the linker and rustc's Session are right there, so...

I slept on this twice. I initially persuaded myself that "yeah, we should check for frameworks and stop this before it even gets that far". But then I thought about the "real issue" here: the real issue is that you may ask for us to use a linker that can't support the target's demands. In this case, the target also asks for a specific linker by default, but I think if someone makes a really interesting set of demands, they will manage to find a way to slip through our "defenses", thus it's fine to let the linker-driver impl sort this out.