core::sync: rename `Exclusive` to `SyncView` and make improvements
This PR implements the renaming of `core::sync::Exclusive` to `SyncView` as decided in rust-lang/rust#98407. To preserve the ability to search for the old name, it adds `Exclusive` as a `doc_alias`.
It also makes the following additional changes:
- Converting the `get_mut` method to being an instance of `AsMut::as_mut`. In the process, it makes both the new `impl AsMut` and the existing `impl AsRef` `const`, and it also renames `get_pin_mut` to `as_pin_mut` for consistency. This direction follows a suggestion from rust-lang/rust#98407.
- Adding an `as_pin` method that can only be used when the wrapped type implements `Sync`, to complete the square of access methods.
- Making as many of the existing `impl`s `const` as possible; this involved making the existing `impl Default` no longer derived.
- Adding `impl`s for `AsyncFnOnce`, `AsyncFnMut`, and `AsyncFn`, akin to the existing `impls` for `FnOnce`, `FnMut`, and `Fn`.
It does not yet do the following, which may be desirable:
- Fixing/improving the documentation to address the concern pointed out in rust-lang/rust#146245.
It previously did the following, but this was removed after discussion:
- Adding an `impl` for (`const`) `Iterator`, which felt in line with the existing `impl`s for `Future` and `Coroutine`.
library: std: motor: use OS' process::exit in abort_internal
abort_internal() is used in panics; if it calls core::intrinsics::abort(), the process triggers an invalid op code (on x86_64), which is a much harder "abort" than a user-controlled exit via a panic.
Most other OSes don't use core::intrinsics::abort() here, but either libc::abort(), or a native OS abort/exit API.
Add more info about where autodiff can be applied
It's taken quite a few years, but we finally have a PR open to distribute Enzyme: https://github.com/rust-lang/rust/pull/154754
I therefore went over the docs once more and noticed we don't explain a lot of the most basic features, which we added over the years and have since taken for granted.
@Sa4dUs, do you think there are more interesting cases that we are missing?
Generally, there's still a lot of complexity in it, especially for people who haven't used Enzyme before.
To some extent, that's just a result of my general design goal to expose all performance-relevant features of Enzyme, and let users explore nice abstractions on top if it, via crates. Since we don't have those nightly users yet, users haven't had time to build nicer abstractions on top of it.
I also feel like a more guided book would be a better first introduction to Enzyme, but for now I just focused on the list of features.
r? @oli-obk
abort_internal() is used in panics; if it calls
core::intrinsics::abort(), the process triggers an
invalid op code (on x86_64), which is a much harder "abort"
than a user-controlled exit via a panic.
Most other OSes don't use core::intrinsics::abort() here,
but either libc::abort(), or a native OS abort/exit API.
`BorrowedCursor`: make `init` a boolean
This PR changes uninitialized bytes tracking in `BorrowedBuf` from being byte-wise to being buffer-wise.
I've put all the API around `init` a new unstable feature `borrowed_buf_init`, to split the part that needs it and the part that doesn't. It will avoids accidental stabilization of this part.
I'm not really convinced of the rename of `advance_unchecked` to `advance`, but I did it anyway. The old `advance` was kept as `advance_checked`.
Alternative of rust-lang/rust#148937
Cc rust-lang/rust#78485rust-lang/rust#117693
Cc @joshtriplett
r? @Amanieu
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#147552 ([Debugger Visualizers] Optimize lookup behavior)
- rust-lang/rust#154052 (float: Fix panic at max exponential precision)
- rust-lang/rust#154706 (fix compilation of time/hermit.rs)
- rust-lang/rust#154707 (Make `substr_range` and `subslice_range` return the new `Range` type)
- rust-lang/rust#154767 (triagebot: roll library reviewers for `{coretests,alloctests}`)
- rust-lang/rust#154797 (bootstrap: Include shorthand aliases in x completions)
Panic/return false on overflow in no_threads read/try_read impl
As per discussion with Mark in rust-lang/rust#153555, it's possible for `no_threads` impl of `RwLock` to trigger a silent overflow on `RwLock::read`/`RwLock::try_read` if we try to acquire more than `isize::MAX` read locks. This PR adds an explicit panic/return false when our read lock counter is at `isize::MAX` for `RwLock::read`/`RwLock::try_read`; the message is similar to that of sys/sync/rwlock/futex.rs [here](https://github.com/rust-lang/rust/blob/fb27476aaf1012f1f6ace6306f9b990e0d989c31/library/std/src/sys/sync/rwlock/futex.rs#L143).
Edit the docs new_in() and with_capacity_in()
I have updated the documentation for new_in().
While reviewing the code, I noticed that the documentation for with_capacity_in() was also inaccurate, so I have corrected it.
Closerust-lang/rust#154452
Fix SGX delayed host lookup via ToSocketAddr
rust-lang/rust#146541 introduced a regression in the `x86_64-fortanix-unknown-sgx` target, where arguments to TcpStream::connect and TcpListener::bind are no longer being passed down correctly to the underlying platform, resulting in connection/bind failures
* Add a test for the desired behavior (this test passes on Rust 1.33 through 1.91)
* Refactor lookup_host logic again
Fixesrust-lang/rust#152848
cc @joboet
Clarified docs in std::sync::RwLock + added test to ensure that max reader count is respected
This addresses the issue with the [`std::sync::RwLock` docs](https://doc.rust-lang.org/std/sync/struct.RwLock.html) in rust-lang/rust#115338. It centers around the following lines:
> An `RwLock` will allow any number of readers to acquire the lock as long as a writer is not holding the lock.
It's true that the `RwLock` in theory should allow any number of readers to acquire the lock when a writer is not holding it, but this may not be true in the implementation and could be os dependent. I decided to replace "any number of readers" to "multiple", so that it implies that more than 1 reader can acquire the lock, but you can't necessarily take away that this value is unbounded.
@rustbot label +A-docs
std::net: clamp linger timeout value to prevent silent truncation.
Duration::as_secs() returns u64 but l_linger field type is narrower, c_int on most unix platforms, c_ushort on cygwin and windows. clamping before the cast, consistent with how set_timeout handles this.
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#154249 (Mention on which items the `missing_doc_code_examples` is not emitted)
- rust-lang/rust#154266 (UdpSocket: document `recv/recv_from` differences)
UdpSocket: document `recv/recv_from` differences
Per libs-api consensus, fixesrust-lang/rust#149392 by documenting possible platform-specific behavior in `UdpSocket`.
r? libs
Update libc to v0.2.183
Follow-up of https://github.com/rust-lang/rust/pull/150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
stabilizes `core::range::Range`
stabilizes `core::range::RangeIter`
stabilizes `std::range` which was missed in prior PRs
Updates docs to reflect stabilization (removed "experimental")
`RangeIter::remainder` is excluded from stabilization
update zulip link in `std` documentation
#docs doesn't seem to exist anymore, so point people to `t-libs`. Also include direct link to topic since Zulip is world-viewable now.
Add `IoSplit` diagnostic item for `std::io::Split`
Similar to the existing `IoLines` item. It will be used in Clippy to detect uses of `Split` leading to infinite loops similar to the existing lint for `Lines`.
feat: reimplement `hash_map!` macro
originally implemented in rust-lang/rust#144070, this had to be reverted in rust-lang/rust#148049 due to name ambiguity, as the macro was automatically put into the prelude. now, that rust-lang/rust#139493 has landed, it is possible to have a top-level macro, that is not exported by default, which should make it possible to reland this again.
implements rust-lang/rust#144032
implementation from rust-lang/rust#144070, original author has been added as co-author
effectively reverts rust-lang/rust#148049
Prevent no_threads RwLock's write() impl from setting mode to -1 when it is locked for reading
In my time updating the docs to `std::sync::RwLock` and adding a test verifying that max reader count is reachable in rust-lang/rust#153555, I noticed that the no_threads RwLock's `write()` implementation always sets the `mode` to `-1` (denoting writer locked) even though it could be reader locked. I feel like that's logically incorrect and that it should only be setting the `mode` to `-1` when we know that the mode is unlocked (`0`); `write()` should mirror the code that `read()` and `try_read()` has with `try_write()`.
For reference on read/try_read and write/try_write current implementations:
```rust
#[inline]
pub fn read(&self) {
let m = self.mode.get();
if m >= 0 {
self.mode.set(m + 1);
} else {
rtabort!("rwlock locked for writing");
}
}
#[inline]
pub fn try_read(&self) -> bool {
let m = self.mode.get();
if m >= 0 {
self.mode.set(m + 1);
true
} else {
false
}
}
#[inline]
pub fn write(&self) {
if self.mode.replace(-1) != 0 { // <-- This behavior logically does something different than what `try_write` does
rtabort!("rwlock locked for reading")
}
}
#[inline]
pub fn try_write(&self) -> bool {
if self.mode.get() == 0 {
self.mode.set(-1);
true
} else {
false
}
}
```
r? @jhpratt
Use common Timestamp impl in Hermit (attempt 2)
The goal is to have less code to maintain, so to be able to make changes easier.
Previous attempt https://github.com/rust-lang/rust/pull/148847 was asked to postpone because there was restructure of code, which is complete now.
r? joboet
Similar to the existing `IoLines` item. It will be used in Clippy to
detect uses of `Split` leading to infinite loops similar to the existing
lint for `Lines`.
Also, delete impls on non-Deref types.
Pin doesn't do anything useful for non-Deref types, so PinCoerceUnsized
on such types makes no sense.
This is a breaking change, since stable code can observe the deleted
`PinCoerceUnsized` impls by uselessly coercing between such types
inside a `Pin`.
There is still some strange behavior, such as `Pin<&mut i32>` being
able to coerce to `Pin<&dyn Send>`, but not being able to coerce to
`Pin<&i32>`. However, I don't think it's possible to fix this.
Fixes https://github.com/rust-lang/rust/issues/145081
Jacob Pratt