Rollup of 11 pull requests #77436
Merged
Rollup of 11 pull requests #77436
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Co-authored-by: David Tolnay <dtolnay@gmail.com>
…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.
Improve the example for ptr::copy Fixes rust-lang#77220
…-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
|
📌 Commit 5a72180 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions, checks-azure |
This was referenced Oct 2, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
publish_toolstatehook #77312 (Remove outdated line frompublish_toolstatehook)newmethod inDefaultHashers doc #77429 (Linknewmethod inDefautHashers doc)Failed merges:
r? @ghost