These comments appear to have been written before `BorrowedBuf`'s
init tracking was simplified in
https://github.com/rust-lang/rust/pull/150129. The `BufWriter` comment
of the usage within `BufWriter` will be handled separately.
Start using pattern types in libcore
cc rust-lang/rust#135996
Replaces the innards of `NonNull` with `*const T is !null`.
This does affect LLVM's optimizations, as now reading the field preserves the metadata that the field is not null, and transmuting to another type (e.g. just a raw pointer), will also preserve that information for optimizations. This can cause LLVM opts to do more work, but it's not guaranteed to produce better machine code.
Once we also remove all uses of rustc_layout_scalar_range_start from rustc itself, we can remove the support for that attribute entirely and handle all such needs via pattern types
Fix thread::available_parallelism on WASI targets with threads
The refactoring in ba462864f1 ("std: Use more unix.rs code on WASI targets") moved WASI from its own thread module into the shared unix.rs module. However, it did not carry over the available_parallelism() implementation for WASI with threads, causing it to fall through to the unsupported catch-all. This silently regressed the support originally added in f0b7008648.
Fix this by adding WASI to the standard UNIX cfg_select branch.
Depends on rust-lang/rust#155057 (Update libc to v0.2.184).
Add #![unstable_removed(..)] attribute to track removed features
Adds the #![unstable_removed(..)] attribute to enable tracking removed library features.
Produce an error when a removed attribute is used.
Add a test that it works.
For https://github.com/rust-lang/rust/issues/141617
r? @jyn514
Update hashbrown to 0.17
The main benefit of this update is to include one potential UB fix and one bug; relevant changelog entries:
* Fixed potential UB in `RawTableInner::fallible_with_capacity` (rust-lang/hashbrown#692)
* Fixed incorrect length if a hasher panics during rehash (rust-lang/hashbrown#710)
cc @Amanieu
Also cc @RalfJung who had also noticed the UB issue with `-Zmiri-recursive-validation`.
The refactoring in ba462864f1 ("std: Use more unix.rs code on WASI
targets") moved WASI from its own thread module into the shared unix.rs
module. However, it did not carry over the available_parallelism()
implementation for WASI, causing it to fall through to the unsupported
catch-all. This silently regressed the support originally added in
f0b7008648.
Fix this by adding WASI to the sysconf-based cfg_select arm alongside
other platforms that use libc::sysconf(_SC_NPROCESSORS_ONLN). This
delegates to wasi-libc, which currently always returns 1 but opens up
the possibility for wasi-libc to report actual processor counts in the
future.
This requires libc to export _SC_NPROCESSORS_ONLN for WASI targets,
which has been added in libc 0.2.184.
unsafe keyword docs: bring back unsafe_op_in_unsafe_fn lint discussion
@traviscross in rust-lang/rust#141471 you asked me to also update the text to account for the edition change. Apparently I did that by entirely removing this part of the discussion (except for a dangling forward reference, a "see below"). Given that old editions still exist and given that `unsafe_op_in_unsafe_fn` is just a lint so the old behavior also still exists on new editions, I am no longer sure that was a good idea, so this brings back the old text with some editing to explain the current situation.
fix spurious test failure in `metadata_access_times`
Fixesrust-lang/rust#148408
The metadata_access_times test checks if the creation of a file occurs before another file, this check happens only on Linux. While on Win and Macos we check only that the created metadata is available. Given that the SystemTime is non monotonic as Instant this test could result in failures when the system clock changes.
Test(lib/sync): Fix `test_rwlock_max_readers` for x86 Win7
The test recently added in rust-lang/rust#153555 currently systematically deadlocks when running it under i686 Windows 7, but not x86_64 that passes it fine. This therefore fixes the test for the target.
Empirically, the correct value for `MAX_READERS` seems to be `2^28 - 1`: removing the `- 1` re-introduces the deadlock, at least under our testing environment. This fix thus uses this value. However, I have no real justification to support that, because I find myself a bit at a loss when comparing the implementation details, the comment added above the test and what the current value is; some help would therefore be nice in this aspect. Also, the value change is restricted to 32-bit Win7 as there is no evidence to support it should be done for other targets.
cc @roblabla
@rustbot label O-windows-msvc O-windows-7 O-x86_32 A-atomic T-libs
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`.
The recently-added test currently systematically deadlocks when running
it under i686 Windows 7, but not x86_64 that passes it fine. This
therefore fixes the test for the target.
Empirically, the correct value for `MAX_READERS` seems to be `2^28 - 1`:
removing the `- 1` re-introduces the deadlock, at least under our
testing environment. This fix thus uses this value. However, I have no
real justification to support that, because I find myself a bit at a
loss when comparing the implementation details, the comment added above
the test and what the current value is; some help would therefore be
nice in this aspect. Also, the value change is restricted to 32-bit Win7
as there is no evidence to support it should be done for other targets.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
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)