`cargo test` rustc error on Windows: The filename or extension is too long

[jszwedko]

Problem

Hi all!

I originally opened over on rust-lang but realized it probably fits better over here.

We have a project where we noticed that any PRs that introduce a new dependency were causing our cargo test invocations in Windows CI builds to fail with:

Caused by:
  The filename or extension is too long. (os error 206)

I think we are running into the same issue described by rust-lang/rust#39644 but with rustc.exe rather than link.exe for cargo test's invocation of rustc.

In the example failure below, it does seem like the rustc command is 33,184 characters, which would be over the 32,767 character limit mentioned in https://docs.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/command-line-string-limitation.

Example failure:

https://github.com/vectordotdev/vector/runs/5157867395?check_suite_focus=true

Does that sound right to people? Do we need the same fix from rust-lang/rust#44094 but for the rustc invocation from cargo?

Steps

On Windows:

1. git clone https://github.com/vectordotdev/vector
2. make test

Possible Solution(s)

I think we are running into the same issue described by rust-lang/rust#39644 but with rustc.exe rather than link.exe for cargo test's invocation of rustc?

Notes

No response

Version

cargo 1.58.0 (f01b232bc 2022-01-19)
release: 1.58.0
commit-hash: f01b232bc7f4d94f0c4603930a5a96277715eb8c
commit-date: 2022-01-19
host: x86_64-pc-windows-msvc
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:Schannel)
os: Windows 10.0.17763 (Windows Server 2019 Datacenter) [64-bit]

[weihanglo]

FWIW, there is a tracking issue in to Windows file paths #9770

[ehuss]

You have an impressive number of features! 😆

I think using @ files if the path is too long is reasonable, and something we inevitably will need as more flags get added. It's also possible that cargo could just be more efficient with the way it passes flags (like using relative paths), but that is less clear on exactly how, and still runs the risk of inevitably hitting the limit with more complex projects.

As a workaround, I might recommend running in a directory closer to the root to shorten the paths. I know that GitHub Actions usually runs in a short path (like D:\a) to avoid these problems. Perhaps you have a longer path because you are using a self-hosted runner?

[jszwedko]

Thanks @ehuss ! That's a good idea to try running from a shorter path in CI for now. I'll give that a go.