migrate to winapi 0.3 #4877
migrate to winapi 0.3 #4877
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matklad (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Cargo.toml
Outdated
| psapi-sys = "0.1" | ||
| winapi = "0.2" | ||
| winapi = { version = "0.3", features = ["handleapi", "jobapi", "jobapi2", "minwindef", "ntdef", | ||
| "processenv", "processthreadsapi", "psapi", "synchapi", "winerror", "winbase", "wincon", "winnt"] } |
There was a problem hiding this comment.
Out of curiosity, are all of these really required? I would have no idea how to generate this list...
There was a problem hiding this comment.
They should be required, yes.
Usually I just refactor the function calls to the new import path and then add the features when the import cannot be resolved.
There was a problem hiding this comment.
In order to reduce compile times I had to gate each header with a feature. Unfortunately this does mean you sometimes end up with really long feature lists like this, but there's really not any better way to deal with such a massive crate that will only continue to grow.
The list isn't difficult to generate, just a bit tedious. If you use anything from the winapi::um::foo or winapi::shared::bar modules then you would add foo or bar to the feature list.
There was a problem hiding this comment.
Is there no better recourse for this? This seems pretty unergonomic to list dozens of modules in each project importing winapi and for example from an API like AssignProcessToJobObject how would I conclude it's in the jobapi2 feature and module without reading both sets of documentation? Or is reading both sets of documentation required?
There was a problem hiding this comment.
Unfortunately items have to be defined in separate modules because sometimes two headers will define a symbol with the same name but different values, which also means I can't even glob import all the items into the crate root. The recommended way to figure out which module/feature an item comes from is using the search bar in the documentation. I certainly welcome proposals for how to make things easier to use.
src/cargo/util/job.rs
Outdated
|
|
||
| use std::ffi::OsString; | ||
| use std::io; | ||
| use std::mem; | ||
| use std::os::windows::prelude::*; | ||
| use self::winapi::shared::{basetsd, ntdef, minwindef}; | ||
| use self::winapi::um::{handleapi, jobapi, jobapi2, processthreadsapi, psapi, synchapi, winbase, winnt}; |
There was a problem hiding this comment.
Could this perhaps just use * below? There's no hope of me ever knowing how this list is generated :(
There was a problem hiding this comment.
Yeah sure, there shouldn't be any future conflicts since it's limited by the enabled features (I hope it stays that way).
That basically was just the explicit safe route, depending on what modules are used.
|
@bors: r+ |
|
📌 Commit 64828ba has been approved by |
|
⌛ Testing commit 64828ba with merge ff22bd590902cba8146e2454f286ac34709e7005... |
migrate to winapi 0.3 - [x] Some of those changes should also be applied to cargo, to keep those common files consistent. filed rust-lang/cargo#4877
|
💔 Test failed - status-appveyor |
|
@bors: retry |
|
☀️ Test successful - status-appveyor, status-travis |
migrate to winapi 0.3 - [x] Some of those changes should also be applied to cargo, to keep those common files consistent. filed rust-lang/cargo#4877
migrate to winapi 0.3 - [x] Some of those changes should also be applied to cargo, to keep those common files consistent. filed rust-lang/cargo#4877
migrate to winapi 0.3 - [x] Some of those changes should also be applied to cargo, to keep those common files consistent. filed rust-lang/cargo#4877
No description provided.