False positive cyclic dependencies when building for different targets

Problem

If particular crate depends on crate A and crate B, such that if imported together, they would cause cyclic dependency, but crate B is only imported on specific target, for example wasm32, cargo will error out regardless of that target restriction.

Steps

1. Create brand new crate foo with the following:

❯ tree
.
└── foo
    ├── Cargo.lock
    ├── Cargo.toml
    └── src
        └── lib.rs

2. Include some dependencies that might cause cyclic problems if imported together, but keep one of them locked behind specific build target. For the sake of this example, I'm including the ones that caused problems to me personally. I would assume there would be more of them. Note that in "real world", my issue was caused by the problematic dependency being pulled indirectly through different crate.

Sample Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
edition = "2018"

[dependencies]
reqwest = "0.11.4"
sqlx = { version = "0.5.5", features = [ "runtime-tokio-rustls", "offline" ]}

[target.'cfg(target_arch = "wasm32")'.dependencies]
getrandom = { version = "0.2", features = ["js"] }

3. Try to build it explicitly for an x86 target: cargo build --target x86_64-unknown-linux-gnu. In my case I received the following cyclic dependency error:

cargo build --target x86_64-unknown-linux-gnu
    Updating crates.io index
error: cyclic package dependency: package `ahash v0.7.4` depends on itself. Cycle:
package `ahash v0.7.4`
    ... which is depended on by `hashbrown v0.11.2`
    ... which is depended on by `indexmap v1.7.0`
    ... which is depended on by `serde_json v1.0.64`
    ... which is depended on by `wasm-bindgen v0.2.74`
    ... which is depended on by `js-sys v0.3.51`
    ... which is depended on by `getrandom v0.2.3`
    ... which is depended on by `ahash v0.7.4`

4. If getrandom dependency is removed, everything builds without errors.

Notes

The issue was tested to present on the following versions:
❯ cargo version
cargo 1.53.0 (4369396ce 2021-04-27)

❯ cargo version
cargo 1.54.0-beta (5ae8d74b3 2021-06-22)

❯ cargo version
1.55.0-nightly (27277d966 2021-07-16)

Start with the sample Cargo.toml and reproduce the issue using cargo build --target x86_64-unknown-linux-gnu, comparing it with the configuration without getrandom. Trace how the target-specific dependency is included in dependency resolution. Done means the explicit x86 build no longer reports a cyclic dependency involving the wasm32-only dependency.