-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
migrate compiler, bootstrap and compiletest to windows-rs #106610
Conversation
r? @davidtwco (rustbot has picked a reviewer for you, use r? to override) |
r? @jyn514 |
Shouldn't windows-sys be used instead? https://github.com/microsoft/windows-rs#windows-sys: |
Unless it makes compiling rustc significantly slower, I think the |
But there no windows perf runs, yet. |
Sure. I wouldn't expect the compile time of one crate to have a significant impact here though. And if it does we should see slower CI times. We can always switch to windows-sys if it does cause problems. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I just have a few comments, mostly nits.
unsafe { FileTimeToSystemTime(&user_filetime, &mut user_time) }.ok().ok()?; | ||
unsafe { FileTimeToSystemTime(&kernel_filetime, &mut kernel_time) }.ok().ok()?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than using unsafe
on almost every line, why not just keep the big unsafe
block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I prefer limiting the scope as much as possible, to just the FFI calls.
The idea seems fine, but I'm short on review time and not familiar with Windows. r? @ChrisDenton (thank you for your reviews so far ❤️) |
☔ The latest upstream changes (presumably #106851) made this pull request unmergeable. Please resolve the merge conflicts. |
Some changes occurred in src/tools/cargo cc @ehuss |
Sorry for the ping, accidentally included the cargo submodule in the previous rebase. |
I'm happy to review this; I'd mostly be keen to make sure the API calls end up the same. However, I'm not sure that I'm actually authorized to sign off on this change (I'm more std/libs). cc @Mark-Simulacrum maybe? Moving on from winapi (which is no longer updated) makes sense to do at some point. @klensy brings up the point that maybe we should be using |
@ChrisDenton consider this permission to sign off of the change :) I trust your judgement. @bors delegate=ChrisDenton |
✌️ @ChrisDenton can now approve this pull request |
Oh ok! In that case I'm fine with this as long as CI is also ok. @bors r+ rollup=never |
📌 Commit 2c691ae6036bab3dbd06ca0f0cd8c7e28f3b473f has been approved by It is now in the queue for this repository. |
@euclio Hey Andy, mind resolving the conflict here so we can give bors another whack at this? |
Ok, lets try again @bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (44f5180): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
Sweet - thanks all - that was some serious collaboration. 🎉 |
Yay! 🎉 It's in nightly now so we'll see how this goes... |
Hm, export table size of rustc_driver changed from 18104 to 25790 items (some nearby nightly), plus it looks like there imported few unused fn from windows libs. |
@dpaoliello could this be related to |
Just for future reference, the two relevant nightly versions are: rustc 1.70.0-nightly (44f5180 2023-03-20) Though in rustup you'll need to +1 to those dates. E.g.:
|
@kennykerr I don't think it's raw-dylib, look like a lot of the various windows-rs wrappers seem to be being exported. Using When dump that function via WinDbg:
That looks like a COM or WinRT call wrapper to me... I'm guessing that |
Thanks, yeah if it's a lib then that's not too surprising. |
It's not a lib, it's a dll that is exporting Rust functions (rather than C functions). If I understand Rust's model for this, then all Would it be possible to trim down the API exposed by |
Just using Cargo features - there's a discussion here about reducing the size of the largest namespaces where I mentioned the Reducing the size of that namespace would go a long way toward reducing the number of Alternatively, you could use the |
https://github.com/microsoft/windows-rs/releases/tag/0.47.0 has been published and includes an update to the metadata resulting in a much smaller |
Update windows-sys This updates the windows-sys dependency from 0.45 to 0.48. This shouldn't add or remove any duplicate dependencies (since there are other dependencies still using 0.45 and 0.42). The intent is to move it along the direction towards unifying in the future (though it seems like a moving target that will be difficult to ever hit). This also bumps the home crate version. I think it should be OK to make the migration from winapi to windows-sys a patch version, though there seems to be some issues with the way windows-sys works that could introduce some build-time problems in some situations (such as those encountered in rust-lang/rust#108665 and rust-lang/rust#106610). However, I don't expect too much of an issue.
This PR migrates the compiler, bootstrap, and compiletest to use windows-rs instead of winapi-rs. windows-rs is the bindings crate provided by Microsoft, and is actively maintained compared to winapi-rs. Not all ecosystem crates have migrated over yet, so there will be a period of time where both crates are used.
windows-rs also provides some nice ergonomics over winapi-rs to convert return values to
Result
s (which found a case where we forgot to check the return value ofCreateFileW
).