Update windows-bindgen to 0.100.0 - #162270
Conversation
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
rustbot
added
O-windows
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Note that I've split this into three commits. The middle commit is purely generated code. |
|
|
||
| /// Like an `as u32` cast except that it asserts the type is i32 before the cast. | ||
| /// This will ensure we can remove casts once they're no longer necessary. | ||
| macro_rules! as_u32 { |
There was a problem hiding this comment.
This macro converts types from i32 to u32. This keeps all the as casts in one place instead of needing them to be spread throughout the code. I also added an assert to ensure we remove them once they're no longer needed (which is my hope).
|
@bors try jobs=msvc,mingw |
This comment has been minimized.
This comment has been minimized.
Update `windows-bindgen` to 0.100.0 try-job: *msvc* try-job: *mingw*
This comment has been minimized.
This comment has been minimized.
1f3b8b5 to
6a839b6
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Just FYI - many of the other functions and structs that are manually declared in c.rs are now included in |
|
I'll look to see if I can clean that up a bit now but there are generally two reasons we manually declare types:
There's also one function that's not in |
| } | ||
|
|
||
| #[cfg(not(target_vendor = "win7"))] | ||
| // Use raw-dylib to import synchronization functions to workaround issues with the older mingw import library. |
There was a problem hiding this comment.
This was introduced to workaround #123999 where the ancient mingw on github's windows server 2019 had an incorrect import library. Github no longer has a 2019 runner and in general this shouldn't be a problem since rust-lang/compiler-team#993. That didn't technically set a requirement for the import libraries but it would be highly unusual for people to be using a newer mingw toolchain with very very old import libraries.
6d72f2b to
3c6b763
Compare
| use core::ffi::{CStr, c_int, c_uint, c_ulong, c_ushort, c_void}; | ||
| use core::ptr; | ||
|
|
||
| #[allow(unused)] |
There was a problem hiding this comment.
Does this imply we're pulling in more bindings than we actually need? Why does windows-bindgen itself not insert the allow if it's always necessary? (Or is it expedience, e.g., we have some targets that need a binding and others don't?)
There was a problem hiding this comment.
It's a mix of things. Indeed some targets use things that others don't and those targets in turn may use things that are unused by other targets. Historically the bindings have also tended to pull in more than we needed but I think that's less of an issue nowadays. One big reason though is that I've also found it annoying for contributors if there's a lot of churn in the bindings so I tend to only remove things occasionally when I'm sure they're not going to be needed again. After all it's basically used as if it's an external crate (similar to libc).
There was a problem hiding this comment.
It would make sense to summarise mostly what you said in a comment.
|
Hm, this probably should get a real review. r? clarfonthey |
3c6b763 to
85be443
Compare
This comment has been minimized.
This comment has been minimized.
85be443 to
a3c6e9d
Compare
This comment has been minimized.
This comment has been minimized.
c24e47d to
a300bc1
Compare
|
I think everything's been addressed, so, r=me minus the note about documenting the allow(unused) bit. |
Mingw used to have an incorrect import library for the synchronization functions `WaitOnAddress`, `WakeByAddressSingle` and `WakeByAddressAll`. This was fixed a long time ago and our windows-gnu targets require a much newer mingw in any case.
a300bc1 to
d45c710
Compare
|
Added a comment. @bors r=clarfonthey |
rust-bors
Bot
added
S-waiting-on-bors
Update `windows-bindgen` to 0.100.0 This release represents a major change in the way bindings are generated. See microsoft/windows-rs#4867 for details. In short, it now more directly follows the C headers. For the standard library's purposes this is mostly reflected in relatively minor type changes or with some `const` pointers becoming `mut`. There is however one big change that affects a lot of types. In the headers there are a lot of `#define`s like this: ```c #define GENERIC_READ (0x80000000L) #define GENERIC_WRITE (0x40000000L) ``` These are constants for the access mode. In this case they're explicitly declared as `L` (aka signed long) integer types (in other cases there's no type at all). However, this conflicts with how access mode constants are actually used. E.g., see `CreateFileW`: ```c WINBASEAPI HANDLE WINAPI CreateFileW( _In_ LPCWSTR lpFileName, _In_ DWORD dwDesiredAccess, _In_ DWORD dwShareMode, _In_opt_ LPSECURITY_ATTRIBUTES lpSecurityAttributes, _In_ DWORD dwCreationDisposition, _In_ DWORD dwFlagsAndAttributes, _In_opt_ HANDLE hTemplateFile ); ``` Here `dwDesiredAccess` is a `DWORD`, which in rust equates to `u32`. The constant being signed but the usage being unsigned is not a problem for C/C++. They will happily convert between types at the drop of a hat. Rust however is stricter, as you know. The old metadata used by `windows-bindgen` tried to try to fixup this mismatch but the new one goes strictly by what can be inferred from the headers. The hope in the future is that the headers themselves will be updated so better bindings can be directly derived from them.
Rollup of 5 pull requests Successful merges: - #162270 (Update `windows-bindgen` to 0.100.0) - #162492 (Revert "Rollup merge of #157518 - CAD97:xdg_basedir, r=aapoalas") - #162607 (Basic cleanup in `rustc_transmute`) - #162514 (Simplify diagnostic levels) - #162613 (iter::repeat_with, iter::successors, iter::from_fn added as diagnostic items)
Update `windows-bindgen` to 0.100.0 This release represents a major change in the way bindings are generated. See microsoft/windows-rs#4867 for details. In short, it now more directly follows the C headers. For the standard library's purposes this is mostly reflected in relatively minor type changes or with some `const` pointers becoming `mut`. There is however one big change that affects a lot of types. In the headers there are a lot of `#define`s like this: ```c #define GENERIC_READ (0x80000000L) #define GENERIC_WRITE (0x40000000L) ``` These are constants for the access mode. In this case they're explicitly declared as `L` (aka signed long) integer types (in other cases there's no type at all). However, this conflicts with how access mode constants are actually used. E.g., see `CreateFileW`: ```c WINBASEAPI HANDLE WINAPI CreateFileW( _In_ LPCWSTR lpFileName, _In_ DWORD dwDesiredAccess, _In_ DWORD dwShareMode, _In_opt_ LPSECURITY_ATTRIBUTES lpSecurityAttributes, _In_ DWORD dwCreationDisposition, _In_ DWORD dwFlagsAndAttributes, _In_opt_ HANDLE hTemplateFile ); ``` Here `dwDesiredAccess` is a `DWORD`, which in rust equates to `u32`. The constant being signed but the usage being unsigned is not a problem for C/C++. They will happily convert between types at the drop of a hat. Rust however is stricter, as you know. The old metadata used by `windows-bindgen` tried to try to fixup this mismatch but the new one goes strictly by what can be inferred from the headers. The hope in the future is that the headers themselves will be updated so better bindings can be directly derived from them.
Rollup of 10 pull requests Successful merges: - #162270 (Update `windows-bindgen` to 0.100.0) - #162492 (Revert "Rollup merge of #157518 - CAD97:xdg_basedir, r=aapoalas") - #162607 (Basic cleanup in `rustc_transmute`) - #162619 (Add test for the missing Clone requirement for Cow slices) - #162172 (mention the opaque when its hidden type cannot be inferred) - #162514 (Simplify diagnostic levels) - #162546 (Use lld by default on `loongarch64-unknown-linux-gnu` nightly) - #162564 (yeet StabilityLevel) - #162613 (iter::repeat_with, iter::successors, iter::from_fn added as diagnostic items) - #162616 (regression test for async main diagnostic)
6 participants
View all comments
This release represents a major change in the way bindings are generated. See microsoft/windows-rs#4867 for details.
In short, it now more directly follows the C headers. For the standard library's purposes this is mostly reflected in relatively minor type changes or with some
constpointers becomingmut.There is however one big change that affects a lot of types. In the headers there are a lot of
#defines like this:These are constants for the access mode. In this case they're explicitly declared as
L(aka signed long) integer types (in other cases there's no type at all). However, this conflicts with how access mode constants are actually used. E.g., seeCreateFileW:Here
dwDesiredAccessis aDWORD, which in rust equates tou32. The constant being signed but the usage being unsigned is not a problem for C/C++. They will happily convert between types at the drop of a hat. Rust however is stricter, as you know.The old metadata used by
windows-bindgentried to try to fixup this mismatch but the new one goes strictly by what can be inferred from the headers. The hope in the future is that the headers themselves will be updated so better bindings can be directly derived from them.