1482257 - [meta] do something about 0.2.x winapi-rs crate requirements

Status: RESOLVED WORKSFORME

(Core :: General, enhancement, P3)

Description

[Nathan Froyd [:froydnj]]

We have a lot of crates that depend on winapi (winapi-rs):

https://searchfox.org/mozilla-central/search?q=(winapi+%3D%7C%5C.winapi)&case=false&regexp=true&path=Cargo.toml

Unfortunately, many of those crates depend on a 0.2.x version of winapi, whereas mainline development has moved on to 0.3.x.  Adding support for aarch64 windows to 0.3.x is something I've started doing:

https://github.com/retep998/winapi-rs/issues/659

but we'd still need to do something about 0.2.x, either moving those crates forward to the 0.3.x line or developing a private fork of 0.2.x that we can make those crates depend on.

The crates that directly depend on 0.2.x and do not have a semver-compatible version that we can just `cargo update` to are:

u2f-hid-rs (https://github.com/jcjones/u2f-hid-rs/issues/65 for updating)
atty-0.1.2 (atty 0.2 uses winapi 0.3.x, so we have to fix dependent crates here)
dwrote (newer versions use winapi 0.3.x, need to have webrender crates update)
gdi32-sys
iovec (https://github.com/carllerche/iovec/issues/16 for updating)
kernel32-sys
memmap (memmap 0.6 uses winapi 0.3.x, need to fix dependent crates)
mio (https://github.com/carllerche/mio/issues/658 for updating)
miow (newer versions use winapi 0.3.x, need to fix mio)
term (newer versions use winapi 0.3.x, need to fix dependent crates)
term_size (newer versions use winapi 0.3.x, need to fix dependent crates)
ws2_32-sys

I *think* that moving things that depend on {gdi32,kernel32,ws2_32}-sys to a newer version of winapi eliminates the *-sys dependencies, so that should be easy-ish.

If we were to try and move to a version of these crates that support 0.3.x--and note that not all of them do, see iovec and mio for examples--that would be a potentially large undertaking.

ni? to ajones to try and figure out something here.

Comment 1

[Nathan Froyd [:froydnj]]

It looks like the major hurdle here is dwrote, and we can work around that by disabling webrender.  mio/tokio, which are on older versions of winapi and apparently likely to stay that way for a while, are only used for cubeb remoting.  cubeb remoting isn't used on Windows currently and if/when it is, we can just disable it (ideally).

I am writing a patch for some of the smaller hurdles to jump over.

Comment 2

[Nathan Froyd [:froydnj]]

The only crates dependent on winapi 0.2.x are geckodriver, which we've disabled until such time as testing is needed, and some audio crates that we don't use on Windows (yet?).  I think we can call this fixed for now.