2018-style module paths not working in a vendored crate

help
1

packed_simd 0.3.3 is an edition 2018 crate. When I build it as part of a normal crates.io-backed dependency graph, it builds fine using nightly Rust. It also builds fine if I make a local git clone and cargo build that. If I use cargo vendor to vendor it into a locally-vendored dependency graph but cd into its directory and cargo build it from there, it builds fine.

However, when I build the whole vendored dependency graph, the vendored packed_simd crate fails to build. The errors are related to module references. If I remove edition = "2018" from packed_simd's Cargo.toml when building it individually, I get the same errors plus errors about locating cfg_if.

This suggests that when packed_simd is built as part of a vendored dependency graph, somehow the module path resolution goes into the 2015 mode.

Yet, when watching the process list, I see that packed_simd is built with the expected nightly rustc binary and --edition=2018 is passed as part of the invocation.

The dependency tree uses a workspace where the vendored crates are "excluded".

There are a couple of existing edition 2018 crates that use 2018-style module paths (cranelift-* crates).

Is this kind of unwanted 2015-mode module path processing in a vendored 2018 crate a known failure mode? How should I go about debugging this?

2

Disabling sccache doesn't help. Vendoring packed_simd into a minimal workspace where the vendoring directory is in the excludes does not reproduce the problem.

3

Try running cargo build —verbose to check if the correct edition flag is passed to the compiler.

4

strace says that --edition=2018 is passed. I'll try to figure out how to pass --verbose through the Firefox build system. Maybe it shows something else that's interesting.

5

strace doesn't show anything interesting in the environment. The variables that start with RUST are:

"RUSTC=/home/hsivonen/.cargo/bin/rustc",
"RUSTDOC=/home/hsivonen/.cargo/bin/rustdoc",
"RUSTFLAGS=-C opt-level=0 -C debuginfo=2  ",
"RUSTFMT=/home/hsivonen/.cargo/bin/rustfmt",
"RUSTUP_HOME=/home/hsivonen/.rustup",
"RUSTUP_TOOLCHAIN=nightly-x86_64-unknown-linux-gnu",
"RUST_BACKTRACE=full",
"RUST_RECURSION_COUNT=2",
6

Is there anything other than the --edition=2018 command-line argument that affects rustc's decision on whether to apply 2015 or 2018 module path rules?

7

This turned out to be a matter of a 2018 crate importing a macro from another crate while specifying the version of the other crate too loosely, so an edition 2018-incompatible macro got imported cross-crate when cargo update was done precisely.