-
Notifications
You must be signed in to change notification settings - Fork 2.9k
cargo 0.73 build broken on windows #12562
Copy link
Copy link
Labels
A-cargo-apiArea: cargo-the-library API and internal code issuesArea: cargo-the-library API and internal code issuesO-windowsOS: WindowsOS: WindowsP-highPriority: HighPriority: HighS-acceptedStatus: Issue or feature is accepted, and has a team member available to help mentor or reviewStatus: Issue or feature is accepted, and has a team member available to help mentor or review
Metadata
Metadata
Assignees
Labels
A-cargo-apiArea: cargo-the-library API and internal code issuesArea: cargo-the-library API and internal code issuesO-windowsOS: WindowsOS: WindowsP-highPriority: HighPriority: HighS-acceptedStatus: Issue or feature is accepted, and has a team member available to help mentor or reviewStatus: Issue or feature is accepted, and has a team member available to help mentor or review
Type
Fields
Give feedbackNo fields configured for issues without a type.
I updated cargo to 0.73 from crates.io in cargo-udeps (commit) and got the following build failure on ci:
If you look at the rustdoc for LockFileEx, it writes:
Compare this with the Cargo.toml of 0.73:
cargo/Cargo.toml
Lines 180 to 188 in 103a7ff
The former two are found while
Win32_System_IOisn't present. I suppose this is the cause for the failure: in thecargorepo this works fine because of dependency unification and another crate in the DAG enabling theWin32_System_IOfeatures. But if you usecargofrom crates.io, then it is not enabled, which is what I ran into.The fix is simple, just add
Win32_System_IOto the list. Ideally this would also be published in a new release.I have worked around the issue by making cargo-udeps depend on windows-sys and enabling the feature (commit).