2018-style module paths not working in a vendored crate


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?


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.


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


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.


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

"RUSTFLAGS=-C opt-level=0 -C debuginfo=2  ",


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?


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.