Remove Windows function preloading

[ChrisDenton]

After @Mark-Simulacrum asked me to provide guidance for when optionally imported functions should be preloaded, I realised my justifications were now quite weak. I think the strongest argument that can be made is that it avoids some degree of nondeterminism when calling these functions (in as far as system API calls can be said to be deterministic). However, I don't think that's particularly convincing unless there's a real world use case where it matters. Further discussion with @thomcc has strengthened my feeling that preloading isn't really needed.

Note that WaitOnAddress needed some adjustment to work without preloading. I opted not to use a macro for this special case as it seemed silly to do so for just one thing (and I don't like macros tbh).

[rust-highfive]

@ChrisDenton: no appropriate reviewer found, use r? to override

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[ChrisDenton]

r? libs

[thomcc]

I'd still like to review this one, then.

r? @thomcc

[thomcc]

Thanks for doing this. I was pretty uncomfortable with relying on static init for this (and we deliberately don't do so on unix), but wasn't sure there was a good reason for that beyond users calling into std from an initializer.

Two issues:

• Orderings are wrong for lazy loading of these, and technically could result in a race between the call and the loader.
• This is a pretty leaky abstraction, and adds very tight coupling between compat and the windows thread parker. For now adding more comments is hopefully sufficient, but we probably should revisit it.

[thomcc]

Looks good with the updates.

[thomcc]

Seems good to me!

@bors r+

[bors]

📌 Commit a0e4c16 has been approved by thomcc

It is now in the queue for this repository.