error: output of --print=file-names missing when learning about target-specific information from rustc when --target is specified

[zjp-CN]

Steps to reproduce the bug with the above code

Thanks for this great tool!

I see a bunch of these repos whos semver-checks results on non-host (x86_64-unknown-linux-gnu) targets report as the title shows.
One of the repos is https://github.com/arceos-org/arm_gicv2 . (I can list more if needed.)

Reproducible commands:

# latest hash: https://github.com/arceos-org/arm_gicv2/commit/cf756f7623b6b6af2f6fe423d1da19ebe96e7e1d
git clone https://github.com/arceos-org/arm_gicv2.git 
cd arm_gicv2
rustup target add aarch64-unknown-none-softfloat
cargo semver-checks --target aarch64-unknown-none-softfloat

Actual Behaviour

I got compilation error from rustc.

error: output of --print=file-names missing when learning about target-specific information from rustc
command was: `/root/.cargo/bin/sccache /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc - --crate-name ___ --print=file-names --cap-lints=allow --target aarch64-unknown-none-softfloat --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
___
lib___.rlib
lib___.a
/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu
off
___
debug_assertions
fmt_debug="full"
overflow_checks
panic="abort"
proc_macro
relocation_model="static"
target_abi="softfloat"
target_arch="aarch64"
target_endian="little"
target_env=""
target_has_atomic
target_has_atomic="128"
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="128"
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="128"
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="none"
target_pointer_width="64"
target_vendor="unknown"
ub_checks


-----

error: failed to build rustdoc for crate arm_gicv2 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 /rust/tmp/os-checker/repos/arm_gicv2 &&
          cargo check

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

I also run the suggested commands to reproduce the compilation error, and it compiles just fine.

Expected Behaviour

There should be no compilation errors.

Generated System Information

Software version

cargo-semver-checks 0.38.0 (507393d-modified)

Operating system

• OS: Linux (Ubuntu 24.04)
• Kernel: 6.8.0-51-generic

Command-line

/root/.cargo/bin/cargo-semver-checks semver-checks --bugreport

cargo version

> cargo -V
cargo 1.85.0-nightly (c86f4b3a1 2024-12-24)

Compile time information

• Profile: release
• Target triple: x86_64-unknown-linux-gnu
• Family: unix
• OS: linux
• Architecture: x86_64
• Pointer width: 64
• Endian: little
• CPU features: fxsr,sse,sse2,x87
• Host: x86_64-unknown-linux-gnu

Cargo build configuration:

[build]
rustc-wrapper = "/root/.cargo/bin/sccache"

Build Configuration

None.

Additional Context

I think it might be a bug with RUSTFLAGS. When I look into the generated cargo doc command from semver-checks, it's like the following

export RUSTC_BOOTSTRAP=1
export RUSTDOCFLAGS="-Z unstable-options --document-private-items --document-hidden-items --output-format=json --cap-lints=allow"
export RUSTFLAGS=--cap-lints=allow
cargo doc --manifest-path target/semver-checks/local-arm_gicv2-0_1_0-01666ec060466c14/Cargo.toml --target-dir arm_gicv2/target/semver-checks/local-arm_gicv2-0_1_0-01666ec060466c14/target --package arm_gicv2@0.1.0 --lib --target aarch64-unknown-none-softfloat --no-deps --color=always

This just results in the exact same error report as above. (I'm not sure if the hash string in path is the same for your local testing.)

And when RUSTFLAGS=--cap-lints=allow is not included, it compiles and successfully generates the doc.

So I try removing RUSTFLAGS from run_cargo_doc fn, install it locally, and run cargo semver-checks --target aarch64-unknown-none-softfloat agian, semver-checks just works.

    Building arm_gicv2 v0.1.0 (current)
       Built [   0.733s] (current)
     Parsing arm_gicv2 v0.1.0 (current)
      Parsed [   0.002s] (current)
    Building arm_gicv2 v0.1.0 (baseline)
        Built [   0.558s] (baseline)
      Parsing arm_gicv2 v0.1.0 (baseline)
       Parsed [   0.002s] (baseline)
     Checking arm_gicv2 v0.1.0 -> v0.1.0 (no change)
      Checked [   0.020s] 120 checks: 120 pass, 0 skip
      Summary no semver update required
     Finished [   3.697s] arm_gicv2

[obi1kenobi]

Sorry for the delay, I was travelling and only just got home.

As far as I can tell, this is a bug upstream, likely in rustc or rustdoc 😮 --cap-lints=allow means "please don't error out on lints". It has no effect on the compiled code or anything related to the target, so specifying that flag should never cause code to not compile. What you've found is quite shocking to me!

Would you mind making a bug report issue in https://github.com/rust-lang/rust and linking it to this one?

If you'd prefer not to, I can also open the issue upstream. But since you already did all the work to narrow down the source of the bug, I didn't want to appear to take credit for your work by opening the upstream issue :)

[zjp-CN]

😄 I'd like to open one on rust-lang repo. I'll try to make reproducible code that can be run without cargo-semver-checks.

[zjp-CN]

I've submitted it: rust-lang/rust#135233

[weihanglo]

I believe rust-lang/cargo#15036 should fix this. It will get into the main rust-lang/rust repo on Friday, so expect to see it on nightly in the weekend!

[zjp-CN]

Well, I think rust-lang/cargo#15036 doesn't solve the issue here.

I've tested with nightly-2025-01-12 where that cargo PR landed, the same error: output of --print=file-names missing when learning about target-specific information from rustc occurs. You can see them from the CI result which runs on nightly-2025-01-01 and nightly-2025-01-12¹.

I believe --cap-lint=allow fix introduced in handling -Dwarnings (ref #589 ) is not proper. --cap-lint=allow eliminates warnings even if cargo sets -Awarnings in the cargo PR. cargo-semver-checks should remove -Dwarnings from RUSTFLAGS and do not set --cap-lint.

---

Quote from #589 :

2. Attempt to parse RUSTFLAGS and remove -Dwarnings in its many forms.
   a. Can we really be sure that we're doing this safely and in a way that won't ever go wrong?
   b. If we fail to remove -Dwarnings because it was specified in some way we didn't catch, this can be even more confusing. I generally don't love "magic" like this because it has a tendency to go wrong and cause more issues.

If removing -Dwarnings is not so simple to accept, I think semver-checks just do nothing here. Leave the compiler error to the user, and the user would set up proper RUSTFLAGS.

For (b), I admit -Dwarnings may come from a cargo config file, then it's sad to see compilation error. But cargo-semver-checks hasn't really thought about cargo config for now IIUC.

Footnotes

1. Interestingly, nightly-2025-01-12 actually makes RUSTFLAGS="-Dwarnings -Awarnings" cargo check pass while that check cmd fails on nightly-2025-01-01. So a fix for semver-checks is to append -Awarnings in RUSTFLAGS, but it's too subtle to be worth considering. ↩

[weihanglo]

Oh I see now. For --cap-lints, the behavior for this flag is the first occurrence wins rust-lang/rust#54282. I am unsure if we really want to and can depend on it.

[obi1kenobi]

My preference, if at all possible, would be to stick to --cap-lints=allow since we're using the flag for exactly its intended purpose: declaring that we don't care about lints, at all, under any circumstance. By comparison, editing the user's provided RUSTFLAGS feels icky and wrong.

That said, I understand that the cargo -> rustc interface is limited and there are workarounds in place. I trust the judgment of cargo team members like @weihanglo on whether it's feasible to make --cap-lints=allow work for us in the near term, or if we should go with editing user-provided RUSTFLAGS instead.