regression - nightly 2023-03-30 -> 2023-03-31 causes linker error when importing wasm_bindgen::JsValue in a proc_macro

[finnbear]

Notes for other investigators

(2023-07-19)

1. stylist-rs has been updated with a workaround, so the reproduction described below will need adapting (e.g. check out that repo from around futursolo/stylist-rs@fbd788f or earlier, since that will not include the workaround added in Mitigate linker error from Rust compiler futursolo/stylist-rs#123 )

2. This problem exhibits itself only with certain numbers of codegen-units. The default setting for codegen-units is host dependent (the default is chosen, in part, as a function of the number of cores the host has available, in order to parallelize the code-generation performed by LLVM). In my own experiments, the problem is masked (does not arise) for codegen-units={1,2,4,8}, and the problem does arise for codegen-units={16,32,64,128,256}. You are best off passing -Ccodegen-units explicit when investigating this, just to ward against that being an invisible factor in the experiments.

(bug report follows below)

Code

I tried this code:

[package]
name = "nightly_stylist"
version = "0.1.0"
edition = "2021"

[dependencies]
stylist-macros = "0.12"

fn main() {}

stylist-macros

I expected to see this happen: cargo check succeeds in debug mode.

Instead, this happened: cargo check fails in debug mode.

  = note: /usr/bin/ld: __wbindgen_realloc: undefined version: 
          /usr/bin/ld: __wbindgen_malloc: undefined version: 
          /usr/bin/ld: __wbindgen_free: undefined version: 
          /usr/bin/ld: __wbindgen_exn_store: undefined version: 
          /usr/bin/ld: failed to set dynamic section sizes: bad value
          collect2: error: ld returned 1 exit status

Version it worked on

rustc 1.70.0-nightly (ec2f40c6b 2023-03-30)
binary: rustc
commit-hash: ec2f40c6b04f0e9850dd1f454e8639d319f4ed9b
commit-date: 2023-03-30
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.0

Version with regression

rustc 1.70.0-nightly (5e1d3299a 2023-03-31)
binary: rustc
commit-hash: 5e1d3299a290026b85787bc9c7e72bcc53ac283f
commit-date: 2023-03-31
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.0

Cargo bisect-rustc

searched toolchains ec2f40c6b04f0e9850dd1f454e8639d319f4ed9b through 5e1d3299a290026b85787bc9c7e72bcc53ac283f


********************************************************************************
Regression in 22a7a19f9333bc1fcba97ce444a3515cb5fb33e6
********************************************************************************

*isn't immediately obvious why this change would cause the problem

searched nightlies: from nightly-2023-03-27 to nightly-2023-04-02
regressed nightly: nightly-2023-04-01
searched commit range: ec2f40c...5e1d329
regressed commit: 22a7a19

bisected with cargo-bisect-rustc v0.6.6

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start 2023-03-27 --end 2023-04-02 

[finnbear]

I forked stylist and minimized the reproducible example down to simply having a type (but not a value) with wasm_bindgen::JsValue in a proc_macro crate (and then adding that proc macro crate as a dependency of another crate).

You can find it here: https://github.com/finnbear/stylist-rs/tree/rustc (just run cargo check in packages/stylist)

Here is a workaround for the crate: futursolo/stylist-rs#121

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high +T-compiler

[lqd]

TBH it's not clear to me how alignment checks would end up causing linker errors, but since this seems bisected to #98112, let's at the very least notify the PR's author @saethlin.

[saethlin]

I already looked over this and was also mystified. I suppose I could take another look? I know almost completely nothing about wasm so I'm not hopeful.

[saethlin]

Builds fine:

RUSTFLAGS=-Zmir-enable-passes=-CheckAlignment cargo +nightly build

Same linker error:

RUSTFLAGS=-Zmir-enable-passes=-CheckAlignment cargo +nightly build -Zbuild-std --target=x86_64-unknown-linux-gnu

As a mitigation for the linker error, users may put this in their Cargo.toml (for the workspace!)

[profile.dev.package.wasm-bindgen]
debug-assertions = false

That only helps with the alignment checks, -Zbuild-std is still not going to work.

[saethlin]

I can build the reproducer, unmodified, if I use LLD.

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-Clink-arg=-fuse-ld=lld"]

Or

RUSTFLAGS="-Clinker=clang -Clink-arg=-fuse-ld=lld" cargo +nightly build

https://borngeek.com/2009/3/13/gcc-dynamic-section-sizes-error/ suggests this might be a link order issue. That would explain why LLD is fine with the link, but GNU's linker isn't.

Actually, that doesn't make much sense because our standard library is already at the end of the link. I'm out of ideas 🤷 I think this is somehow dependent on linker details that I don't know and I'm struggling to educate myself on.