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

Rollup of 11 pull requests #77436

Merged
merged 28 commits into from
Oct 2, 2020
Merged

Rollup of 11 pull requests #77436

merged 28 commits into from
Oct 2, 2020

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

m-ou-se and others added 28 commits September 17, 2020 21:54
It was blocked by rust-lang#58732 (const fn NonZeroU32::new), which is fixed now.
The (unsafe) Mutex from sys_common had a rather complicated interface.
You were supposed to call init() manually, unless you could guarantee it
was neither moved nor used reentrantly.

Calling `destroy()` was also optional, although it was unclear if 1)
resources might be leaked or not, and 2) if destroy() should only be
called when `init()` was called.

This allowed for a number of interesting (confusing?) different ways to
use this Mutex, all captured in a single type.

In practice, this type was only ever used in two ways:

1. As a static variable. In this case, neither init() nor destroy() are
   called. The variable is never moved, and it is never used
   reentrantly. It is only ever locked using the LockGuard, never with
   raw_lock.

2. As a Boxed variable. In this case, both init() and destroy() are
   called, it will be moved and possibly used reentrantly.

No other combinations are used anywhere in `std`.

This change simplifies things by splitting this Mutex type into
two types matching the two use cases: StaticMutex and MovableMutex.

The interface of both new types is now both safer and simpler. The first
one does not call nor expose init/destroy, and the second one calls
those automatically in its new() and Drop functions. Also, the locking
functions of MovableMutex are no longer unsafe.
This test checks if the compiler complains about accesing a private
field before complaining (or crashing) about the private function on it
not marked as stable/unstable.

The interface of the internal type (sys_common's Mutex) used for this
was changed. With this change, it uses another function to test for the
same issue.
WASI does not match `cfg(unix)`, but its paths are Unix-like (`/some/path`) and don't have Windows-like prefixes.

Without this change, `is_absolute` for paths like `/some/path` was returning `false`on a WASI target, which is obviously not true and undesirable.
Found while working on rust-lang#77351;
these are just the ones that could be fixed automatically.
- Module name can now be any string, not just an ident.
  (Not all Windows api modules are valid Rust identifiers.)
- Adds c::FuncName::is_available() for checking if a function is really
  available without having to do a duplicate lookup.
- Add comment explaining the lack of locking.
- Use `$_:block` to simplify the macro_rules.
- Apply allow(unused_variables) only to the fallback instead of
  everything.
…ero, r=petrochenkov

Fix 'FIXME' about using NonZeroU32 instead of u32.

It was blocked by rust-lang#58732 (const fn NonZeroU32::new), which is fixed now.
…llback-check, r=dtolnay

Improve std::sys::windows::compat

Improves the compat_fn macro in sys::windows, which is used for conditionally loading APIs that might not be available.

- The module (dll) name can now be any string, not just an ident. (Not all Windows api modules are valid Rust identifiers. E.g. `WaitOnAddress` comes from `API-MS-Win-Core-Synch-l1-2-0.dll`.)
- Adds `FuncName::is_available()` for checking if a function is really available without having to do a duplicate lookup.
- Add comment explaining the lack of locking.
- Use `$_:block` to simplify the macro_rules.
- Apply `allow(unused_variables)` only to the fallback instead of everything.

---

The second point (`is_available()`) simplifies code that needs to pick an implementation depening on what is available, like `sys/windows/mutex.rs`. Before this change, it'd do its own lookup and keep its own `AtomicUsize` to track the result. Now it can just use `c::AcquireSRWLockExclusive::is_available()` directly.

This will also be useful when park/unpark/CondVar/etc. get improved implementations (e.g. from parking_lot or something else), as the best APIs for those are not available before Windows 8.
…slice-ptr-range, r=dtolnay

Stabilize slice_ptr_range.

This has been unstable for almost a year now. Time to stabilize?

Closes rust-lang#65807.

@rustbot modify labels: +T-libs +A-raw-pointers +A-slice +needs-fcp
…ex, r=dtolnay

Split sys_common::Mutex in StaticMutex and MovableMutex.

The (unsafe) `Mutex` from `sys_common` had a rather complicated interface. You were supposed to call `init()` manually, unless you could guarantee it was neither moved nor used reentrantly.

Calling `destroy()` was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if `destroy()` should only be called when `init()` was called.

This allowed for a number of interesting (confusing?) different ways to use this `Mutex`, all captured in a single type.

In practice, this type was only ever used in two ways:

1. As a static variable. In this case, neither `init()` nor `destroy()` are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using the `LockGuard`, never with `raw_lock`.

2. As a `Box`ed variable. In this case, both `init()` and `destroy()` are called, it will be moved and possibly used reentrantly.

No other combinations are used anywhere in `std`.

This change simplifies things by splitting this `Mutex` type into two types matching the two use cases: `StaticMutex` and `MovableMutex`.

The interface of both new types is now both safer and simpler. The first one does not call nor expose `init`/`destroy`, and the second one calls those automatically in its `new()` and `Drop` functions. Also, the locking functions of `MovableMutex` are no longer unsafe.

---

This will also make it easier to conditionally box mutexes later, by moving that decision into sys/sys_common. Some of the mutex implementations (at least those of Wasm and 'sys/unsupported') are safe to move, so wouldn't need a box. ~~(But that's blocked on  rust-lang#76932 for now.)~~ (See rust-lang#77380.)
…rk-Simulacrum

Remove outdated line from `publish_toolstate` hook

We no longer add `I-nominated` to toolstate failure issues since T-compiler changed its meeting preparation workflow.
Fix is_absolute on WASI

WASI does not match `cfg(unix)`, but its paths are Unix-like (`/some/path`) and don't have Windows-like prefixes.

Without this change, `is_absolute` for any paths, including `/some/path`, was returning `false`on a WASI target, which is obviously not true and undesirable.
rustc_metadata: Do not forget to encode inherent impls for foreign types

So I tried to move FFI interface for LLVM from `rustc_codegen_llvm` to `rustc_llvm` and immediately encountered this fascinating issue.

Fixes rust-lang#46665.
…-Simulacrum

Fix some clippy lints

Found while working on rust-lang#77351;
these are just the ones that could be fixed automatically.
…ulacrum

BTreeMap: use Unique::from to avoid a cast where type information exists

r? @Mark-Simulacrum
…r_new, r=jyn514

Link `new` method in `DefautHasher`s doc

FIXME referenced rust-lang#56922 which was resolved

r? @jyn514
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=5
@rustbot modify labels: rollup

@rustbot rustbot added the rollup A PR which is a rollup label Oct 1, 2020
@bors
Copy link
Contributor

bors commented Oct 1, 2020

📌 Commit 5a72180 has been approved by JohnTitor

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 1, 2020
@bors
Copy link
Contributor

bors commented Oct 2, 2020

⌛ Testing commit 5a72180 with merge f283d3f...

@bors
Copy link
Contributor

bors commented Oct 2, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: JohnTitor
Pushing f283d3f to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.