Closed Bug 1485409 Opened 1 year ago Closed 1 year ago
update trivially-updatable crates to use winapi 0
We should just go ahead and bump things that `cargo update` can bump for us.
winapi 0.2.8 is used by a number of crates in our dependency graph. The newest version of winapi is 0.3.4, which is a significant restructuring and also more amenable to further development, e.g. adding AArch64 support. This patch does the easy work of updating as many things as possible to winapi 0.3.4 via a simple `cargo update`: cargo update -p atty -p fs2 -p msdos_time -p parking_lot_core -p aho-corasick and then vendoring the results of those changes. The only non-trivial part of this patch is the change to vendor_rust.py, which stems from the fuchsia-zircon* packages. We previously had fuchsia-zircon* vendored through: fuchsia-zircon v0.2.1 └── rand v0.3.18 ├── phf_generator v0.7.21 │ └── phf_codegen v0.7.21 │ └── cssparser-macros v0.3.3 │ └── cssparser v0.24.0 │ ├── geckoservo v0.0.1 (file:///home/froydnj/src/m-c.hg/servo/ports/geckolib) and as several packages depended on rand 0.3.18, this was not problematic. We now have packages that depend on a newer version: fuchsia-zircon v0.3.3 └── rand v0.4.3 ├── parking_lot_core v0.2.14 │ └── parking_lot v0.6.3 │ ├── geckoservo v0.0.1 (file:///home/froydnj/src/m-c.hg/servo/ports/geckolib) and we thus need to vendor multiple versions of fuchsia-zircon*, leading to the need to whitelist multiple versions. These packages are only compiled on x86_64-unknown-fuchsia, and therefore do not need special license review. (Note that trying to upgrade `phf_generator` to a newer version wouldn't solve this problem, as it depends on a *newer* version of `rand`, and other packages depend on `rand` 0.3.18 anyway.)
Attachment #9003199 - Flags: review?(core-build-config-reviews)
I wonder if we could figure out a way to avoid vendoring crates like that that we'll never actually need? I understand that cargo just sticks everything it could possibly need in every build configuration into Cargo.lock, and cargo-vendor vendors the whole lot, but we're not going to build Firefox for fuchsia anytime soon so these crates are just wasting space.
I assume we'd need either a post-pass tool that knew all the targets we were going to compile for, and stripped out things we would never need, or we'd need to see about modifying `cargo vendor` to take a similar list of targets for the same purpose. All this assumes that cargo doesn't require packages that it's not compiling for the current target to be present at compile time.
Attachment #9003199 - Flags: review?(core-build-config-reviews) → review?(mh+mozilla)
Comment on attachment 9003199 [details] [diff] [review] update crates to dispense with winapi 0.2.8 requirement Review of attachment 9003199 [details] [diff] [review]: ----------------------------------------------------------------- This patch doesn't apply anymore. There are conflicts in Cargo.toml, fuchsia-zircon-sys, fuchsia-zircon and rand.
Attachment #9003199 - Flags: review?(mh+mozilla)
Now with no `mach vendor rust` changes. \o/
Attachment #9004744 - Flags: review?(mh+mozilla) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/3bfb261380d4 update crates to dispense with winapi 0.2.8 requirement; r=glandium
You need to log in before you can comment on or make changes to this bug.