Rollup of 14 pull requests #77437
Closed
Rollup of 14 pull requests #77437
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.
…criptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to send and receive file descriptors, by using `recvmsg` and `sendmsg` system call.
…OS list alphabetically
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 <[email protected]>
The primary purpose is to get the fixes from rust-lang/stdarch#920 and rust-lang/stdarch#922. The other changes included are rust-lang/stdarch#917 and rust-lang/stdarch#919.
unix: Extend UnixStream and UnixDatagram to send and receive file descriptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to `UnixDatagram` and `UnixStream`. With this functions `UnixDatagram` and `UnixStream` can send and receive file descriptors, by using `recvmsg` and `sendmsg` system call.
…chenkov Uplift drop-bounds lint from clippy Bounds on `T: Drop` do nothing, so they should warn.
…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.
Add accessors to Command. This adds some accessor methods to `Command` to provide a way to access the values set when building the `Command`. An example where this can be useful is to display the command to be executed. This is roughly based on the [`ProcessBuilder`](https://github.com/rust-lang/cargo/blob/13b73cdaf76b2d9182515c9cf26a8f68342d08ef/src/cargo/util/process_builder.rs#L105-L134) in Cargo. Possible concerns about the API: - Values with NULs on Unix will be returned as `"<string-with-nul>"`. I don't think it is practical to avoid this, since otherwise a whole separate copy of all the values would need to be kept in `Command`. - Does not handle `arg0` on Unix. This can be awkward to support in `get_args` and is rarely used. I figure if someone really wants it, it can be added to `CommandExt` as a separate method. - Does not offer a way to detect `env_clear`. I'm uncertain if it would be useful for anyone. - Does not offer a way to get an environment variable by name (`get_env`). I figure this can be added later if anyone really wants it. I think the motivation for this is weak, though. Also, the API could be a little awkward (return a `Option<Option<&OsStr>>`?). - `get_envs` could skip "cleared" entries and just return `&OsStr` values instead of `Option<&OsStr>`. I'm on the fence here. My use case is to display a shell command, and I only intend it to be roughly equivalent to the actual execution, and I probably won't display `None` entries. I erred on the side of providing extra information, but I suspect many situations will just filter out the `None`s. - Could implement more iterator stuff (like `DoubleEndedIterator`). I have not implemented new std items before, so I'm uncertain if the existing issue should be reused, or if a new tracking issue is needed. cc rust-lang#44434
…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.
Remove --cfg dox from rustdoc.rs This was added in rust-lang#53076 because several dependencies were using `cfg(dox)` instead of `cfg(rustdoc)` (now `cfg(doc)`). I ran `rg 'cfg\(dox\)'` on the source tree with no matches, so I think this is now safe to remove. r? @Mark-Simulacrum cc @QuietMisdreavus :)
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
|
uhm a rollup already exists.. :P |
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