cargo relies on unknown crate type warnings to detect if a target supports crate types, which can be suppressed by -Awarnings and thus break cargo's detection

[cybersoulK]

When compiling a Rust project for the wasm32-unknown-unknown target with the -Awarnings flag, the following error is encountered:

error: output of --print=file-names missing when learning about target-specific information from rustc
command was: `.../.rustup/toolchains/nightly-2023-07-12-aarch64-apple-darwin/bin/rustc - --crate-name ___ --print=file-names -Awarnings --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`

Steps To Reproduce:

Create blank project
Set RUSTFLAGS to "-Awarnings"
Run the command: cargo build --target wasm32-unknown-unknown

(Tested on Latest Stable as well)

[bjorn3]

What happens if you manually run the mentioned rustc command? Does it print anything? Does it crash?

[ehuss]

The problem is that cargo is looking for:

warning: dropping unsupported crate type `dylib` for target `wasm32-unknown-unknown`

to know which crate types are not supported. Suppressing that warning causes a mismatch of the list of crate names and what cargo is expecting.

One unbaked idea is to have a better interface between cargo and rustc of discovering target information (like maybe a JSON api). Right now, it uses a hacked delimiter system (using the ___ crate name), which is not great.

[cybersoulK]

Something else i have to say, even if this bug is fixed:

i have a reasonably long wasm rusflags in the config.toml. They need to be there for rust Anylazer to interpret the code correctly, and facilitate development.
And because the rustflags in the export are not additive but overwritable, and because putting awarnings in config.toml removes warnings from rust analyzer, i am in an tough spot.

My project is growing very big, and i have occasional warnings to mark unimplemented pieces.
Mutting every warning makes them less noticeable in RA than if having a TODO. i like warnings as another layer additional to TODO

But when i am running many builds for deployment, warnings clutter the output, and i miss what's happening, if there is a crate that fails, because i am not looking and waiting for the entire period.

Also, i use a combination of cargo, cross and zigbuild to cross compile from my mac. I cannot just use cargo rust c for these extensions.

That's why disabling warning must be separate than the other rustflags, as a cargo argument, --disable-warnings. And that can then be added to cross and zigbuilds afterwards too.

[terrybrash]

Is there a workaround? I'd like to keep warnings disabled when targeting wasm.

[terrybrash]

Seems like #![allow(warnings)] works well enough and doesn't break wasm compilation.

[weihanglo]

This should be fixed via rust-lang/cargo#15036.

@jieyouxu guess we can close this?