Failure targeting `wasm32-unknown-unknown`

[joshlf]

TLDR: Running with --target wasm32-unknown-unknown fails regardless of crate contents.

Steps to reproduce:

• Create empty crate via cargo init --vcs none --lib
• Run cargo semver-checks check-release --target wasm32-unknown-unknown

Observed output:

     Parsing tmp067 v0.1.0 (current)
error: running cargo-doc on crate tmp067 failed with output:
-----
error: output of --print=file-names missing when learning about target-specific information from rustc
command was: `.../.rustup/toolchains/stable-aarch64-apple-darwin/bin/rustc - --crate-name ___ --print=file-names --cap-lints=allow --target wasm32-unknown-unknown --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg`

--- stdout
___.wasm
lib___.rlib
___.wasm
lib___.a
.../.rustup/toolchains/stable-aarch64-apple-darwin
off
___
debug_assertions
fmt_debug="full"
overflow_checks
panic="abort"
proc_macro
relocation_model="static"
target_abi=""
target_arch="wasm32"
target_endian="little"
target_env=""
target_family="wasm"
target_feature="multivalue"
target_feature="mutable-globals"
target_feature="reference-types"
target_feature="sign-ext"
target_has_atomic
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_equal_alignment="16"
target_has_atomic_equal_alignment="32"
target_has_atomic_equal_alignment="64"
target_has_atomic_equal_alignment="8"
target_has_atomic_equal_alignment="ptr"
target_has_atomic_load_store
target_has_atomic_load_store="16"
target_has_atomic_load_store="32"
target_has_atomic_load_store="64"
target_has_atomic_load_store="8"
target_has_atomic_load_store="ptr"
target_os="unknown"
target_pointer_width="32"
target_thread_local
target_vendor="unknown"
ub_checks


-----

error: failed to build rustdoc for crate tmp067 v0.1.0
note: this is usually due to a compilation error in the crate,
      and is unlikely to be a bug in cargo-semver-checks
note: the following command can be used to reproduce the compilation error:
      cargo new --lib example &&
          cd example &&
          echo '[workspace]' >> Cargo.toml &&
          cargo add --path .../tmp/tmp067 --no-default-features &&
          cargo check

error: aborting due to failure to build rustdoc for crate tmp067 v0.1.0

[obi1kenobi]

Also tracked by obi1kenobi/cargo-semver-checks#1068, and is caused by a cargo <--> rustc communication issue: rust-lang/cargo#8010

A fix was merged and is slated for Rust 1.86: rust-lang/cargo#15036

Could you by any chance check if the issue persists in Rust 1.86 beta? If so, we'll need to follow up with the cargo team.

[memark]

I'm able to reproduce this issue on both 1.85.1 and 1.86.0-beta.6: (not using the Action though)

rustc +beta --version
rustc 1.86.0-beta.6 (8c7969a3a 2025-03-16)

cargo +beta semver-checks check-release --target wasm32-unknown-unknown
    Building hej v0.1.0 (current)
error: running cargo-doc on crate 'hej' failed with output:
-----
error: output of --print=file-names missing when learning about target-specific information from rustc
command was: `/Users/memark/.rustup/toolchains/beta-aarch64-apple-darwin/bin/rustc - --crate-name ___ --print=file-names --cap-lints=allow --target wasm32-unknown-unknown --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg -Wwarnings`

--- stdout
___.wasm
lib___.rlib
___.wasm
lib___.a
/Users/memark/.rustup/toolchains/beta-aarch64-apple-darwin
off
___
debug_assertions
fmt_debug="full"
overflow_checks
panic="abort"
proc_macro
relocation_model="static"
target_abi=""
target_arch="wasm32"
target_endian="little"
target_env=""
target_family="wasm"
target_feature="multivalue"
target_feature="mutable-globals"
target_feature="reference-types"
target_feature="sign-ext"
target_has_atomic
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_equal_alignment="16"
target_has_atomic_equal_alignment="32"
target_has_atomic_equal_alignment="64"
target_has_atomic_equal_alignment="8"
target_has_atomic_equal_alignment="ptr"
target_has_atomic_load_store
target_has_atomic_load_store="16"
target_has_atomic_load_store="32"
target_has_atomic_load_store="64"
target_has_atomic_load_store="8"
target_has_atomic_load_store="ptr"
target_os="unknown"
target_pointer_width="32"
target_thread_local
target_vendor="unknown"
ub_checks


-----

error: failed to build rustdoc for crate hej v0.1.0
note: this is usually due to a compilation error in the crate,
      and is unlikely to be a bug in cargo-semver-checks
note: the following command can be used to reproduce the compilation error:
      cargo new --lib example &&
          cd example &&
          echo '[workspace]' >> Cargo.toml &&
          cargo add --path /private/var/folders/pz/23v9mn0s78scfwbxw1sb5zqc0000gn/T/tmp.OGZ1MJWhOh &&
          cargo check

error: aborting due to failure to build rustdoc for crate hej v0.1.0

[obi1kenobi]

cc @weihanglo do you happen to know if rust-lang/cargo#15036 is already in Rust 1.86.0-beta.6?

If so, it seems that either rust-lang/cargo#8010 wasn't completely fixed, or there's an additional problem that's causing this issue and obi1kenobi/cargo-semver-checks#1068

If not, then we'll re-check this with the next beta release :)

[weihanglo]

Yeah, just checked that. This works

$ cargo +beta -V
cargo 1.86.0-beta.6 (adf9b6ad1 2025-02-28)
$ RUSTFLAGS="--allow warnings" cargo +beta build --target wasm32-unknown-unknown
   Compiling foo v0.1.0 (/projects/foo)
error[E0463]: can't find crate for `std`
  |
  = note: the `wasm32-unknown-unknown` target may not be installed
  = help: consider downloading the target with `rustup target add wasm32-unknown-unknown`

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

This doesn't.

$ cargo +stable -V
cargo 1.85.1 (d73d2caf9 2024-12-31)
$ RUSTFLAGS="--allow warnings" cargo +stable build --target wasm32-unknown-unknown
error: output of --print=file-names missing when learning about target-specific information from rustc
command was: `/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc - --crate-name ___ --print=file-names --allow warnings --target wasm32-unknown-unknown --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg`
...
...

[weihanglo]

For obi1kenobi/cargo-semver-checks#1068 it is the --cap-lints that we need to deal with. I looks forward to rust-lang/rust#138640. Cargo could switch to that for probing crate types, instead of guessing from error messages.

[obi1kenobi]

Ah, thank you! Looks like the issue already has a PR in progress, excited to see it 🚀

[obi1kenobi]

rust-lang/rust#138641 was merged last night, fixing the underlying issue.

It should make it to nightly in the next couple of days, at which point I'd appreciate it if folks here could test if the issue is resolved with that Rust release. If not, we'll want to follow back up with the cargo team and possibly open a new upstream issue.

Thanks, everyone!

[weihanglo]

Just realized that doesn't really help fix it. See

• Tracking Issue for --print=supported-crate-types rust-lang/rust#138640 (comment)
• #t-compiler > Proposal: `--print=supported-crate-types` @ 💬

[jonathanpallant]

This still isn't working for me.

In a checkout of https://github.com/knurling-rs/defmt, in the firmware folder, I get:

$ cargo +nightly semver-checks --target=thumbv7em-none-eabihf
    Building defmt-itm v0.4.0 (current)
error: running cargo-doc on crate 'defmt-itm' failed with output:
-----
error: output of --print=file-names missing when learning about target-specific information from rustc
command was: `/Users/jonathan/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/rustc - --crate-name ___ --print=file-names --cap-lints=allow --target thumbv7em-none-eabihf --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg -Wwarnings`

--- stdout
___
lib___.rlib
lib___.a
/Users/jonathan/.rustup/toolchains/nightly-aarch64-apple-darwin
off
___
debug_assertions
fmt_debug="full"
overflow_checks
panic="abort"
proc_macro
relocation_model="static"
target_abi="eabihf"
target_arch="arm"
target_endian="little"
target_env=""
target_feature="dsp"
target_feature="fpregs"
target_feature="mclass"
target_feature="thumb-mode"
target_feature="thumb2"
target_feature="v5te"
target_feature="v6"
target_feature="v6k"
target_feature="v6t2"
target_feature="v7"
target_has_atomic
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_equal_alignment="16"
target_has_atomic_equal_alignment="32"
target_has_atomic_equal_alignment="8"
target_has_atomic_equal_alignment="ptr"
target_has_atomic_load_store
target_has_atomic_load_store="16"
target_has_atomic_load_store="32"
target_has_atomic_load_store="8"
target_has_atomic_load_store="ptr"
target_has_reliable_f128
target_has_reliable_f16
target_has_reliable_f16_math
target_os="none"
target_pointer_width="32"
target_vendor="unknown"
ub_checks


-----

error: failed to build rustdoc for crate defmt-itm v0.4.0
note: this is usually due to a compilation error in the crate,
      and is unlikely to be a bug in cargo-semver-checks
note: the following command can be used to reproduce the compilation error:
      cargo new --lib example &&
          cd example &&
          echo '[workspace]' >> Cargo.toml &&
          cargo add --path /Users/jonathan/Documents/knurling-rs/defmt/firmware/defmt-itm &&
          cargo check

Plus more of the same for every other crate in the workspace. Weirdly, running the command it said failed actually works without error? I don't know what's going on here. I see the same on stable and nightly.

[obi1kenobi]

Weirdly, running the command it said failed actually works without error?

Is it possible that you might have some cargo configuration that gets applied in some paths but not others? I recently realized that this can cause some of our "run this command to reproduce" messages to not work, and I put together this demo to show one possible avenue of how that might happen.

I'm hoping to tackle at least this portion soon, since it's within cargo-semver-checks control.

The bigger picture issue is still blocked on the challenges outlined in @weihanglo's earlier message, unfortunately.