Zig build system incorrectly parses some depfiles generated by Rust on Windows

[bcrist]

Zig Version

0.13.0-dev.274+c0da92f71

Steps to Reproduce and Observed Behavior

I recently worked on creating a build.zig for a C project that utilizes a rust crate as a static library. I used build.crab to integrate the cargo build for the rust library, and it uses std.Build.Step.Run.addDepFileOutputArg to ensure that cargo gets invoked when source files change. Rust automatically generates a .d file for each crate that it builds, but on Windows systems where the rust project's path has a space in it, rust generates a depfile that zig's DepTokenizer parses incorrectly. Zig expects paths with spaces to be quoted, but rust uses backslashes to escape spaces in the path.

Zig ends up assuming that the backslashes indicate a subdirectory, and when it goes to read the "dependency" it just prints out FileNotFound

Expected Behavior

• std.Build.Cache.populateFileHash should report the missing path when error.FileNotFound is encountered.
• Spaces escaped by \ in unquoted depfile prereq paths should be supported, at least in the common cases.

The only cases where this would change the current interpretation of paths in DepTokenizer is when an unquoted path segment begins with a space. But this is unlikely to affect many real world uses, as it's difficult to create such paths in Windows. Explorer will silently trim leading spaces when you rename, though it is possible through the command line.

On the other hand, the common case of multiple words separated by spaces is especially important because if a rust project is built as part of a dependency, it will often end up being inside C:\Users\Firstname Lastname\AppData\Local\zig\p\1220...

Additionally, this style of escaping spaces is already supported by DepTokenizer for target tokens, so it makes sense to support it for prereq tokens as well.