| Age | Commit message (Collapse) | Author | Lines |
|---|
|
`rint` had a couple recent failures from the random tests:
---- mp_random_rint stdout ----
Random Mpfr rint arg 1/1: 10000 iterations (10000 total) using `LIBM_SEED=Fl1f69DaJnwkHN2FeuCXaBFRvJYsPvEY`
thread 'mp_random_rint' panicked at crates/libm-test/tests/multiprecision.rs:41:49:
called `Result::unwrap()` on an `Err` value:
input: (-849751480.5001163,) (0xc1c95316dc4003d0,)
expected: -849751481.0 0xc1c95316dc800000
actual: -849751480.0 0xc1c95316dc000000
Caused by:
ulp 8388608 > 100000
And:
---- mp_random_rint stdout ----
Random Mpfr rint arg 1/1: 10000 iterations (10000 total) using `LIBM_SEED=XN7VCGhX3Wu6Mzn8COvJPITyZlGP7gN7`
thread 'mp_random_rint' panicked at crates/libm-test/tests/multiprecision.rs:41:49:
called `Result::unwrap()` on an `Err` value:
input: (-12493089.499809155,) (0xc167d4242ffe6fc5,)
expected: -12493089.0 0xc167d42420000000
actual: -12493090.0 0xc167d42440000000
Caused by:
ulp 536870912 > 100000
It seems we just implement an incorrect rounding mode. Replace the
existing `rint` override with an xfail if the difference is 0.0 <= ε <=
1.0.
|
|
`compiler_builtins` exposes an `extern "C"` version of `libm` routines,
so add the same here. There really isn't much to test here (unless we
later add tests against C `libm` suites), but one nice benefit is this
gives us a library with unmangled names that is easy to `objdump`. In
accordance with that, also update `cb` to be a `staticlib`.
Unfortunately this also means we have to remove it from the workspace,
since Cargo doesn't allow setting `panic = "abort"` for a single crate.
|
|
Make (unstable API) `UniqueRc` invariant for soundness
Add test case from https://github.com/rust-lang/rust/pull/133572#issuecomment-2543007164 (comment in review of `UniqueArc`), and fix the issue for `UniqueRc`.
|
|
|
|
It would be preferable to switch to a different generator, or at least
set the seed within the benchmark, but this is the most straightforward
way to make things simple.
|
|
These are two convenience methods. Additionally, add tests for the trait
methods, and an `assert_biteq!` macro to check and print the output.
|
|
A failing debug assertion or overflow without correctly wrapping or
saturating is a bug, but the `debug` profile that has these enabled does
not run enough test cases to hit edge cases that may trigger these. Add
a new `release-checked` profile that enables debug assertions and
overflow checks. This seems to only extend per-function test time by a
few seconds (or around a minute on longer extensive tests), so enable
this as the default on CI.
In order to ensure `no_panic` still gets checked, add a build-only step
to CI.
|
|
`ExpInt` is likely to only have performance benefits on 16-bit
platforms, but makes working with the exponent more difficult. It seems
like a worthwhile tradeoff to instead just use `i32`, so do that here.
|
|
I do not believe Cargo separately caches crates with different sets of
features enabled. So, ensuring that tests run with `unstable-intrinsics`
are always grouped should slightly reduce runtime.
As an added benefit, all the debug mode tests run first so initial
feedback is available faster.
|
|
There is a difference in intent between wishing to cast and truncate the
value, and expecting the input to be within range. To make this clear,
add separate `cast_lossy` and `cast_from_lossy` to indicate what that
truncation is intended, leaving `cast` and `cast_from` to only be casts
that expected not to truncate.
Actually enforcing this at runtime is likely to have a cost, so just
`debug_assert!` that `cast` doesn't truncate.
|
|
|
|
These wasm functions are available in `core::arch::wasm32` since [1], so
we can use them while avoiding the possibly-recursive `intrinsics::*`
calls (in practice none of those should always lower to libcalls on
wasm, but that is up to LLVM).
Since these require an unstable feature, they are still gated under
`unstable-intrinsics`.
[1]: https://github.com/rust-lang/stdarch/pull/1677
|
|
update and clarify StructuralPartialEq docs
This apparently hasn't been updated when we finalized the current const pattern matching behavior.
Fixes https://github.com/rust-lang/rust/issues/92454 by providing rationale and context in the docs linked from that error message.
|
|
|
|
|
|
|
|
|
|
|
|
One of `CStr` constructors, `CStr::from_bytes_with_nul(bytes: &[u8])` handles 3 cases:
1. `bytes` has one NULL as the last value - creates CStr
2. `bytes` has no NULL - error
3. `bytes` has a NULL in some other position - error
The 3rd case is error that may require lossy conversion, but the 2nd case can easily be handled by the user code. Unfortunately, this function returns an opaque `FromBytesWithNulError` error in both 2nd and 3rd case, so the user cannot detect just the 2nd case - having to re-implement the entire function and bring in the `memchr` dependency.
In [this code](https://github.com/gquintard/varnish-rs/blob/f86d7a87683b08d2e634d63e77d9dc1d24ed4a13/varnish-sys/src/vcl/ws.rs#L158), my FFI code needs to copy user's `&[u8]` into a C-allocated memory blob in a NUL-terminated `CStr` format. My code must first validate if `&[u8]` has a trailing NUL (case 1), no NUL (adds one on the fly - case 2), or NUL in the middle (3rd case - error). I had to re-implement `from_bytes_with_nul` and add `memchr`dependency just to handle the 2nd case.
This PR renames the former `kind` enum from `FromBytesWithNulErrorKind` to `FromBytesWithNulError`, and removes the original struct.
|
|
Use `NonNull::without_provenance` within the standard library
This API removes the need for several `unsafe` blocks, and leads to clearer code. It uses feature `nonnull_provenance` (#135243).
Close #135343
|
|
Initial fs module for uefi
- Just a copy of unsupported fs right now to reduce the noise from future PRs to allow for easier review.
- For the full working version of fs on uefi, see [0]
- This is an effort to break the original PR (#129700) into much smaller chunks for faster upstreaming.
[0]: https://github.com/Ayush1325/rust/tree/uefi-file-full
|
|
Update a bunch of library types for MCP807
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
r? ghost
|
|
For now, apply `no_global_oom_handling` to all of
library/alloc/src/bstr.rs . We can make it more fine-grained later.
|
|
https://github.com/rust-lang/rust/issues/135100
|
|
Approved ACP: https://github.com/rust-lang/libs-team/issues/502
Tracking issue: https://github.com/rust-lang/rust/issues/134915
These types represent human-readable strings that are conventionally,
but not always, UTF-8. The `Debug` impl prints non-UTF-8 bytes using
escape sequences, and the `Display` impl uses the Unicode replacement
character.
This is a minimal implementation of these types and associated trait
impls. It does not add any helper methods to other types such as `[u8]`
or `Vec<u8>`.
I've omitted a few implementations of `AsRef`, `AsMut`, `Borrow`,
`From`, and `PartialOrd`, when those would be the second implementation
for a type (counting the `T` impl) or otherwise may cause inference
failures. These impls are important, but we can attempt to add them
later in standalone commits, and run them through crater.
In addition to the `bstr` feature, I've added a `bstr_internals` feature
for APIs provided by `core` for use by `alloc` but not currently
intended for stabilization.
This API and its implementation are based *heavily* on the `bstr` crate
by Andrew Gallant (@BurntSushi).
|
|
|
|
This API removes the need for several `unsafe` blocks, and leads to
clearer code.
|
|
Rug does not yet expose this function, but it is possible to use the
MPFR bindings directly.
|
|
Fixes #135338
|
|
r=tgross35
proc_macro: Use `ToTokens` trait in `quote` macro
Tracking issues: #130977, #54722
This PR changed `proc_macro::quote!` to use `ToTokens` trait instead of `TokenStream::from`, and migrated test cases from `quote` crate.
r? `@dtolnay`
CC `@tgross35`
|
|
Used pthread name functions returning result for FreeBSD and DragonFly
`pthread_getname_np` and `pthread_setname_np` received a wider adoption in past years and was added to:
* FreeBSD by June 11 2020 via [`2ef84b7da9a6c3e23b4a135e6e863581f16d46e1`](https://github.com/freebsd/freebsd-src/commit/2ef84b7da9a6c3e23b4a135e6e863581f16d46e1),
* DargonFly by March 8 2021 via [`ab5dc9aceb34419d1c4b6006739e61acee8ee999`](https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/ab5dc9aceb34419d1c4b6006739e61acee8ee999).
There's not so much advantage except that the result can be checked in debug builds. Ideally it should be unified with Linux' implementation, but it trims the input.
|
|
This greatly reduces the number of places that actually use the `rustc_layout_scalar_valid_range_*` attributes down to just 3:
```
library/core\src\ptr\non_null.rs
68:#[rustc_layout_scalar_valid_range_start(1)]
library/core\src\num\niche_types.rs
19: #[rustc_layout_scalar_valid_range_start($low)]
20: #[rustc_layout_scalar_valid_range_end($high)]
```
Everything else -- PAL Nanoseconds, alloc's `Cap`, niched FDs, etc -- all just wrap those `niche_types` types.
|
|
- Just a copy of unsupported fs right now to reduce the noise from
future PRs to allow for easier review.
- For the full working version of fs on uefi, see [0]
[0]: https://github.com/Ayush1325/rust/tree/uefi-file-full
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
Fix `ptr::from_ref` documentation example comment
The comment says that the expression involves no function call, but that was only true for the example above, the example here _does_ contain a function call.
``@rustbot`` label A-docs
|
|
Improve prose around `as_slice` example of IterMut
I've removed the cryptic message about not being able to call `&mut self` methods while retaining a shared borrow of the iterator, such as `as_slice` produces. This is just normal borrowing rules and does not seem especially relevant here. I can whip up a replacement if someone thinks it has value.
|
|
|
|
|
|
|
|
Master bootstrap update
Part of the release process.
r? `@Mark-Simulacrum`
|
|
Remove some unnecessary `.into()` calls
|
|
add missing provenance APIs on NonNull
This adds some provenance APIs that exist on raw pointers but have been forgotten on `NonNull`:
```rust
impl<T> NonNull<T> {
pub const fn without_provenance(addr: NonZero<usize>) -> Self;
pub fn from_exposed_provenance(addr: NonZero<usize>) -> Self;
}
impl<T: ?Sized> NonNull<T> {
pub fn expose_provenance(self) -> NonZero<usize>;
}
```
https://github.com/rust-lang/libs-team/issues/518 is the ACP for the two exposed provenance ones; I forgot to include `without_provenance` there but I hope that, too, is uncontroversial (and anyway this PR only adds things unstably). Cc `@rust-lang/libs-api`
Tracking issue: https://github.com/rust-lang/rust/issues/135243
|
|
|
|
|
|
|
|
|
|
|
|
More compelling env_clear() examples
`ls` isn't a command that people usually set env vars for, and `PATH` in particular isn't even used by `ls`.
|
|
Condvar: implement wait_timeout for targets without threads
This always falls back to sleeping since there is no way to notify a condvar on a target without threads.
Even on a target that has no threads the following code is a legitimate use case:
```rust
use std::sync::{Condvar, Mutex};
use std::time::Duration;
fn main() {
let cv = Condvar::new();
let mutex = Mutex::new(());
let mut guard = mutex.lock().unwrap();
cv.notify_one();
let res;
(guard, res) = cv.wait_timeout(guard, Duration::from_secs(3)).unwrap();
assert!(res.timed_out());
}
```
|
|
Impl String::into_chars
Tracking issue - https://github.com/rust-lang/rust/issues/133125
r? `@programmerjake` `@kennytm` `@Amanieu`
This refers to https://github.com/rust-lang/libs-team/issues/268
Before adding tests and creating a tracking issue, I'd like to reach a consensus on the implementation direction and two questions:
1. Whether we'd add a `String::into_char_indices` method also?
2. See inline comment.
|
|
See https://github.com/rust-lang/rust/pull/115491 for prior related
modifications.
https://godbolt.org/z/MTsz87jGj shows a reduction of the code size
for TLS accesses.
|
