Closed Bug 1531577 Opened 9 months ago Closed 9 months ago

vendor winapi crate with BITS fixes

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set

Tracking

(firefox67 fixed)

RESOLVED FIXED
mozilla67
Tracking Status
firefox67 --- fixed

People

(Reporter: agashlin, Assigned: froydnj)

References

Details

Attachments

(1 file)

I've had two PRs accepted upstream that are needed for bug 1523417:

https://github.com/retep998/winapi-rs/pull/704
https://github.com/retep998/winapi-rs/pull/737

As in bug 1502964 it isn't clear when the next winapi release is planned, so we may want to update our vendored copy.

Flags: needinfo?(nfroyd)

If we're cherry-picking instead of picking up the whole latest winapi 0.3, it would also be helpful to pick this one for the upcoming update agent work:

https://github.com/retep998/winapi-rs/pull/703

I am planning on just pulling in the entire 0.3 branch, rather than trying to manage cherry-picking.

Assignee: nobody → nfroyd
Flags: needinfo?(nfroyd)

We've implemented several fixes to upstream winapi-rs that are
necessary for other work. We might as well make our upstream branch
track upstream winapi-rs instead of keeping track of the cherry-picked
fixes that we need.

Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2237ab9382ec
update winapi-rs to a new upstream version; r=agashlin
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

It looks like clobber is needed with this, but I'm not clear why as I thought cargo should deal with the dependencies?

Flags: needinfo?(nfroyd)

I think it's an issue with winapi's internal dependency tracking. Here are the errors I get:

 0:57.27 error[E0432]: unresolved import `shared::devpropdef`
 0:57.27  --> C:\mozilla-source\mozilla-central3\third_party\rust\winapi\src\um\cfgmgr32.rs:9:13
 0:57.27   |
 0:57.27 9 | use shared::devpropdef::{DEVPROPKEY, DEVPROPTYPE};
 0:57.27   |             ^^^^^^^^^^ could not find `devpropdef` in `shared`
 0:57.27 error[E0432]: unresolved import `um::wincontypes`
 0:57.27  --> C:\mozilla-source\mozilla-central3\third_party\rust\winapi\src\um\consoleapi.rs:9:9
 0:57.27   |
 0:57.27 9 | use um::wincontypes::{COORD, HPCON, PINPUT_RECORD};
 0:57.27   |         ^^^^^^^^^^^ could not find `wincontypes` in `um`
 0:57.27 error[E0432]: unresolved import `um::wincontypes`
 0:57.27   --> C:\mozilla-source\mozilla-central3\third_party\rust\winapi\src\um\wincon.rs:18:13
 0:57.27    |
 0:57.28 18 | pub use um::wincontypes::{
 0:57.28    |             ^^^^^^^^^^^ could not find `wincontypes` in `um`
 0:57.55 error[E0432]: unresolved import `um::wingdi`
 0:57.55   --> C:\mozilla-source\mozilla-central3\third_party\rust\winapi\src\shared\wtypes.rs:14:9
 0:57.55    |
 0:57.55 14 | use um::wingdi::LOGPALETTE;
 0:57.55    |         ^^^^^^ could not find `wingdi` in `um`
 0:57.55 error[E0432]: unresolved import `shared::devpropdef`
 0:57.55  --> C:\mozilla-source\mozilla-central3\third_party\rust\winapi\src\um\cfgmgr32.rs:9:13
 0:57.55   |
 0:57.55 9 | use shared::devpropdef::{DEVPROPKEY, DEVPROPTYPE};
 0:57.55   |             ^^^^^^^^^^ could not find `devpropdef` in `shared`
 0:58.72 error[E0432]: unresolved import `um::wincontypes`
 0:58.72  --> C:\mozilla-source\mozilla-central3\third_party\rust\winapi\src\um\consoleapi.rs:9:9
 0:58.72   |
 0:58.72 9 | use um::wincontypes::{COORD, HPCON, PINPUT_RECORD};
 0:58.72   |         ^^^^^^^^^^^ could not find `wincontypes` in `um`
 0:58.72 error[E0432]: unresolved import `um::wincontypes`
 0:58.72   --> C:\mozilla-source\mozilla-central3\third_party\rust\winapi\src\um\wincon.rs:18:13
 0:58.72    |
 0:58.72 18 | pub use um::wincontypes::{
 0:58.72    |             ^^^^^^^^^^^ could not find `wincontypes` in `um`
 0:59.60 error: aborting due to 3 previous errors

third_party/rust/winapi/build.rs has these changes among others:

  • cfgmgr32 adds a dependency on devpropdef
  • consoleapi ... wincontypes
  • wincon ... wincontypes
  • wtypes ... wingdi

If I re-run ./mach build I don't get these errors again, so maybe a full clobber isn't necessary if we can figure out what ordering issue is messing up here.

(In reply to Adam Gashlin [:agashlin] from comment #6)

It looks like clobber is needed with this, but I'm not clear why as I thought cargo should deal with the dependencies?

comment 7 makes it sound like winapi's build.rs is getting the dependencies wrong?

Flags: needinfo?(nfroyd)

It seems like something is using the old generated dependencies before winapi's build script gets a chance to update them.

You need to log in before you can comment on or make changes to this bug.