Skip to content
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

Merged
merged 1 commit into from
Mar 20, 2023

Conversation

euclio
Copy link
Contributor

@euclio euclio commented Jan 9, 2023

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 Results (which found a case where we forgot to check the return value of CreateFileW).

@rustbot
Copy link
Collaborator

rustbot commented Jan 9, 2023

r? @davidtwco

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 9, 2023
@davidtwco
Copy link
Member

r? @jyn514

@rustbot rustbot assigned jyn514 and unassigned davidtwco Jan 9, 2023
@klensy
Copy link
Contributor

klensy commented Jan 9, 2023

Shouldn't windows-sys be used instead?

https://github.com/microsoft/windows-rs#windows-sys: The windows-sys crate is a zero-overhead fallback for the most demanding situations

@ChrisDenton
Copy link
Member

Unless it makes compiling rustc significantly slower, I think the windows crate is better for this. The "overhead", such as returning Results, is helpful and is something we'd want to do anyway.

@klensy
Copy link
Contributor

klensy commented Jan 9, 2023

Unless it makes compiling rustc significantly slower

But there no windows perf runs, yet.

@ChrisDenton
Copy link
Member

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.

Copy link
Member

@ChrisDenton ChrisDenton left a 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.

compiler/rustc_data_structures/src/profiling.rs Outdated Show resolved Hide resolved
compiler/rustc_data_structures/src/profiling.rs Outdated Show resolved Hide resolved
compiler/rustc_errors/src/lock.rs Outdated Show resolved Hide resolved
compiler/rustc_session/src/filesearch.rs Outdated Show resolved Hide resolved
Comment on lines +278 to +314
unsafe { FileTimeToSystemTime(&user_filetime, &mut user_time) }.ok().ok()?;
unsafe { FileTimeToSystemTime(&kernel_filetime, &mut kernel_time) }.ok().ok()?;
Copy link
Member

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?

Copy link
Contributor Author

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.

src/bootstrap/util.rs Outdated Show resolved Hide resolved
src/bootstrap/util.rs Outdated Show resolved Hide resolved
@jyn514
Copy link
Member

jyn514 commented Jan 10, 2023

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 ❤️)

@bors
Copy link
Contributor

bors commented Jan 14, 2023

☔ The latest upstream changes (presumably #106851) made this pull request unmergeable. Please resolve the merge conflicts.

@rustbot
Copy link
Collaborator

rustbot commented Jan 15, 2023

Some changes occurred in src/tools/cargo

cc @ehuss

@euclio
Copy link
Contributor Author

euclio commented Jan 15, 2023

Sorry for the ping, accidentally included the cargo submodule in the previous rebase.

@ChrisDenton
Copy link
Member

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 windows-sys instead of windows due to compile times (see comment). But I would be keen to at least try windows for correctness reasons (e.g. its use of Result helps avoid at least one source of potential mistakes).

@jyn514
Copy link
Member

jyn514 commented Jan 16, 2023

@ChrisDenton consider this permission to sign off of the change :) I trust your judgement.

@bors delegate=ChrisDenton

@bors
Copy link
Contributor

bors commented Jan 16, 2023

✌️ @ChrisDenton can now approve this pull request

@ChrisDenton
Copy link
Member

Oh ok! In that case I'm fine with this as long as CI is also ok.

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented Jan 16, 2023

📌 Commit 2c691ae6036bab3dbd06ca0f0cd8c7e28f3b473f has been approved by ChrisDenton

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 16, 2023
@riverar
Copy link
Contributor

riverar commented Mar 20, 2023

@euclio Hey Andy, mind resolving the conflict here so we can give bors another whack at this?

@ChrisDenton
Copy link
Member

Ok, lets try again @bors r+

@bors
Copy link
Contributor

bors commented Mar 20, 2023

📌 Commit bb7c373 has been approved by ChrisDenton

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 20, 2023
@bors
Copy link
Contributor

bors commented Mar 20, 2023

⌛ Testing commit bb7c373 with merge 44f5180...

@bors
Copy link
Contributor

bors commented Mar 20, 2023

☀️ Test successful - checks-actions
Approved by: ChrisDenton
Pushing 44f5180 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 20, 2023
@bors bors merged commit 44f5180 into rust-lang:master Mar 20, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 20, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (44f5180): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This 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.

mean range count
Regressions ❌
(primary)
2.2% [1.0%, 3.4%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.1% [-3.4%, -0.8%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [-3.4%, 3.4%] 4

Cycles

Results

This 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.

mean range count
Regressions ❌
(primary)
0.5% [0.5%, 0.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.7% [-0.7%, -0.7%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.1% [-0.7%, 0.5%] 2

@kennykerr
Copy link
Contributor

Sweet - thanks all - that was some serious collaboration. 🎉

@ChrisDenton
Copy link
Member

Yay! 🎉

It's in nightly now so we'll see how this goes...

@klensy
Copy link
Contributor

klensy commented Mar 21, 2023

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.

@kennykerr
Copy link
Contributor

@dpaoliello could this be related to raw-dylib? This PR uses the windows crate with the windows_raw_dylib cfg flag which means the windows crate won't include a dependency on the windows-targets crate containing the libs.

@ChrisDenton
Copy link
Member

Just for future reference, the two relevant nightly versions are:

rustc 1.70.0-nightly (44f5180 2023-03-20)
rustc 1.70.0-nightly (da7c50c 2023-03-19)

Though in rustup you'll need to +1 to those dates. E.g.:

> rustup toolchain install nightly-2023-03-20-x86_64-pc-windows-msvc
> rustup toolchain install nightly-2023-03-21-x86_64-pc-windows-msvc

@dpaoliello
Copy link
Contributor

@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 dumpbin /exports I'm seeing things like:
1860 743 04E57BD0 _RNvMNtNtNtNtNtCse7B3NxVOzTG_7windows7Windows5Win326System11Diagnostics5DebugNtB2_32AsyncIDebugApplicationNodeEvents14Begin_onDetach = _RNvMNtNtNtNtNtCse7B3NxVOzTG_7windows7Windows5Win326System11Diagnostics5DebugNtB2_32AsyncIDebugApplicationNodeEvents14Begin_onDetach

When dump that function via WinDbg:

0:000> uf 0000000184E57BD0
rustc_driver_fcf43a7b54edf3a8!RNvMsj_NtNtNtNtNtCse7B3NxVOzTG_7windows7Windows5Win326System11Diagnostics5DebugNtB5_13IActiveScript5Close:
00000001`84e57bd0 56              push    rsi
00000001`84e57bd1 4883ec20        sub     rsp,20h
00000001`84e57bd5 4889ce          mov     rsi,rcx
00000001`84e57bd8 488b0a          mov     rcx,qword ptr [rdx]
00000001`84e57bdb 488b01          mov     rax,qword ptr [rcx]
00000001`84e57bde ff5038          call    qword ptr [rax+38h]
00000001`84e57be1 85c0            test    eax,eax
00000001`84e57be3 780e            js      rustc_driver_fcf43a7b54edf3a8!RNvMsj_NtNtNtNtNtCse7B3NxVOzTG_7windows7Windows5Win326System11Diagnostics5DebugNtB5_13IActiveScript5Close+0x23 (00000001`84e57bf3)  Branch

rustc_driver_fcf43a7b54edf3a8!RNvMsj_NtNtNtNtNtCse7B3NxVOzTG_7windows7Windows5Win326System11Diagnostics5DebugNtB5_13IActiveScript5Close+0x15:
00000001`84e57be5 31c0            xor     eax,eax

rustc_driver_fcf43a7b54edf3a8!RNvMsj_NtNtNtNtNtCse7B3NxVOzTG_7windows7Windows5Win326System11Diagnostics5DebugNtB5_13IActiveScript5Close+0x17:
00000001`84e57be7 488906          mov     qword ptr [rsi],rax
00000001`84e57bea 4889f0          mov     rax,rsi
00000001`84e57bed 4883c420        add     rsp,20h
00000001`84e57bf1 5e              pop     rsi
00000001`84e57bf2 c3              ret

rustc_driver_fcf43a7b54edf3a8!RNvMsj_NtNtNtNtNtCse7B3NxVOzTG_7windows7Windows5Win326System11Diagnostics5DebugNtB5_13IActiveScript5Close+0x23:
00000001`84e57bf3 89c1            mov     ecx,eax
00000001`84e57bf5 e89685ffff      call    rustc_driver_fcf43a7b54edf3a8!RNvXs4_NtNtCse7B3NxVOzTG_7windows4core5errorNtB5_5ErrorINtNtCs3tdp6Z6tc58_4core7convert4FromNtNtB7_7hresult7HRESULTE4from (00000001`84e50190)
00000001`84e57bfa 48894608        mov     qword ptr [rsi+8],rax
00000001`84e57bfe 895610          mov     dword ptr [rsi+10h],edx
00000001`84e57c01 b801000000      mov     eax,1
00000001`84e57c06 ebdf            jmp     rustc_driver_fcf43a7b54edf3a8!RNvMsj_NtNtNtNtNtCse7B3NxVOzTG_7windows7Windows5Win326System11Diagnostics5DebugNtB5_13IActiveScript5Close+0x17 (00000001`84e57be7)  Branch

That looks like a COM or WinRT call wrapper to me...

I'm guessing that rustc_driver is a Rust dylib and so all pub Rust functions are exported?

@kennykerr
Copy link
Contributor

Thanks, yeah if it's a lib then that's not too surprising.

@dpaoliello
Copy link
Contributor

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 pub Rust functions must be exported from that dll in case a dependent of rustc_driver attempts to use a function in one rustc_driver's dependencies.

Would it be possible to trim down the API exposed by windows-rs to reduce the number of pub functions?

@kennykerr
Copy link
Contributor

kennykerr commented Mar 22, 2023

Would it be possible to trim down the API exposed by windows-rs to reduce the number of pub functions?

Just using Cargo features - there's a discussion here about reducing the size of the largest namespaces where I mentioned the Windows.Win32.System.Diagnostics.Debug namespace listed in your dump.

Reducing the size of that namespace would go a long way toward reducing the number of pub functions in the scenario.

Alternatively, you could use the windows-sys crate, which has a much smaller surface area and omits all of those COM interface functions.

@kennykerr
Copy link
Contributor

Would it be possible to trim down the API exposed by windows-rs to reduce the number of pub functions?

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 Win32_System_Diagnostics_Debug feature. This should go a long way toward reducing the number of pub functions.

@euclio euclio deleted the windows-rs branch March 29, 2023 13:54
bors added a commit to rust-lang/cargo that referenced this pull request Apr 24, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.