Closed Bug 1485409 Opened 1 year ago Closed 1 year ago

update trivially-updatable crates to use winapi 0.3.x


(Core :: General, enhancement)

Not set



Tracking Status
firefox63 --- fixed


(Reporter: froydnj, Assigned: froydnj)




(1 file, 1 obsolete file)

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,
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 #9003199 - Attachment is obsolete: true
Attachment #9004744 - Flags: review?(mh+mozilla)
Attachment #9004744 - Flags: review?(mh+mozilla) → review+
Pushed by
update crates to dispense with winapi 0.2.8 requirement; r=glandium
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.