float: Replace some approximate assertions with exact
As was mentioned at [1], we currently use `assert_approx_eq` for testing
some math functions that guarantee exact results. Replace approximate
assertions with exact ones for the following:
* `ceil`
* `floor`
* `fract`
* `from_bits`
* `mul_add`
* `round_ties_even`
* `round`
* `trunc`
This likely wasn't done in the past to avoid writing out exact decimals
that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004),
but ensuring our results are accurate seems more important here.
[1]: https://github.com/rust-lang/rust/pull/138087#issuecomment-2842069281
The first commit is a small bit of macro cleanup.
try-job: aarch64-gnu
try-job: x86_64-gnu-aux
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
`assert_eq!` ignores the sign of zero, but for any tests involving zeros
we do care about this sign. Replace `assert_eq!` with `assert_biteq!`
everywhere possible for float tests to ensure we don't miss this.
`assert_biteq!` is also updated to check equality on non-NaNs, to catch
the unlikely case that bitwise equality works but our `==`
implementation is broken.
There is one notable output change: we were asserting that
`(-0.0).fract()` and `(-1.0).fract()` both return -0.0, but both
actually return +0.0.
As was mentioned at [1], we currently use `assert_approx_eq` for testing
some math functions that guarantee exact results. Replace approximate
assertions with exact ones for the following:
* `ceil`
* `floor`
* `fract`
* `from_bits`
* `mul_add`
* `round_ties_even`
* `round`
* `trunc`
This likely wasn't done in the past to avoid writing out exact decimals
that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004),
but ensuring our results are accurate seems more important here.
[1]: https://github.com/rust-lang/rust/pull/138087#issuecomment-2842069281
Add `loongarch64` with `d` feature to `f32::midpoint` fast path
This patch enables the optimized implementation of `f32::midpoint` for `loongarch64` targets that support the `d`feature. Targets with reliable 64-bit float support can safely use the faster and more accurate computation via `f64`, avoiding the fallback branchy version.
float: Disable `total_cmp` sNaN tests for `f16`
There is an LLVM bug with lowering of basic `f16` operations that mean a round trip via `__extendhfsf2` and `__truncsfhf2` may happen for simple `abs` calls or bitcasts [1]. This is problematic because the round trip quiets signaling NaNs. For most operations this is acceptable, but it is causing `total_cmp` tests to fail unless optimizations are enabled.
Disable `total_cmp` tests involving signaling NaNs until this issue is resolved.
Fixes: https://github.com/rust-lang/rustc_codegen_cranelift/issues/1578
Fixes: https://github.com/rust-lang/rust/issues/141503
[1]: https://github.com/llvm/llvm-project/issues/104915
The float modules in `std` are currently top-level but for `core`, they
are nested within the `num` directory and referenced by `#[path = ...]`.
For consistency, adjust `std` to use the same structure as `core`.
Also change the `f16` and `f128` gates from outer attributes to inner
attributes like `core` has.
Do not get proc_macro from the sysroot in rustc
With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work.
To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
Add `rustc_diagnostic_item` to `sys::Mutex` methods
For an ongoing project for adding a concurrency model checker to Miri we need to be able to intercept locking/unlocking operations on standard library mutexes.
This PR adds diagnostic items to the relevant calls `lock`, `try_lock` and `unlock` for the `sys::Mutex` implementation on the targets we care about.
This PR also makes the internals of `pthread::Mutex` less public, to reduce the chance of anyone locking/unlocking a mutex without going through the intercepted methods.
r? ``@RalfJung``
clean up old rintf leftovers
As usual stdarch needed special treatment due to https://github.com/rust-lang/stdarch/issues/1655, and apparently I forgot to clean up these leftovers here. They can be removed now.
Path::with_extension: show that it adds an extension where one did no…
…t exist
I think the times I encountered this, I had to check first if files without extensions were added, since all examples only had files with existing extensions.
Also, this replaced example already has a similar example below.
Test(fs): Fix `test_eq_windows_file_type` for Windows 7
Would otherwise fail on:
```
thread 'fs::tests::test_eq_windows_file_type' panicked at library/std/src/test_helpers.rs:53:20:
called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }
```
This came from the read-only attribute set on the test file. In order to fix this, instead of simply disabling the test, the attribute is reset before the test's end so it may still run successfully.
`@rustbot` label T-libs A-filesystem A-testsuite O-windows-7 O-windows-msvc
This patch enables the optimized implementation of `f32::midpoint` for
`loongarch64` targets that support the `d`feature. Targets with reliable
64-bit float support can safely use the faster and more accurate computation
via `f64`, avoiding the fallback branchy version.
Split `autodiff` into `autodiff_forward` and `autodiff_reverse`
This PR splits `#[autodiff]` macro so `#[autodiff(df, Reverse, args)]` would become `#[autodiff_reverse(df, args)]` and `#[autodiff(df, Forward, args)]` would become `#[autodiff_forwad(df, args)]`.
Add data_ptr method to Mutex and RwLock
Implementation of https://github.com/rust-lang/rust/issues/140368 / https://github.com/rust-lang/libs-team/issues/531.
I tried to write a useful safety section about when it is safe to read or write through the returned pointers, but couldn't come up with something nice. Hoping this PR is still useful without that. I'm happy to add any doc strings other people come up with if needed before merge, of course.
Unresolved questions:
- Return a `LockResult` or not?
- Return `*mut T` like existing APIs (`Cell::as_ptr` / `MaybeUninit::as[_mut]_ptr` / `Vec::as_ptr` / ...) or be more precise and return `NonNull<T>`?
Would otherwise fail on:
```
thread 'fs::tests::test_eq_windows_file_type' panicked at library/std/src/test_helpers.rs:53:20:
called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }
```
This came from the read-only attribute set on the test file. In order to
fix this, instead of simply disabling the test, the attribute is reset
before the test's end so it may still run successfully.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
Add some track_caller info to precondition panics
Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.
I thought of this while looking at https://github.com/rust-lang/rust/pull/129642#issuecomment-2311703898.
The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces.
The perf implications of this are:
* Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out.
* The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU.
* The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
With the stage0 refactor the proc_macro version found in the sysroot
will no longer always match the proc_macro version that proc-macros get
compiled with by the rustc executable that uses this proc_macro. This
will cause problems as soon as the ABI of the bridge gets changed to
implement new features or change the way existing features work.
To fix this, this commit changes rustc crates to depend directly on the
local version of proc_macro which will also be used in the sysroot that
rustc will build.
speed up charsearcher for ascii chars
attempt at fixing rust-lang/rust#82471
this implementation should be valid because ascii characters are always one byte and there are no continuation bytes that overlap with ascii characters
im not completely sure that this is _always_ an improvement but it seems to be an improvement for this case and i dont think it can significantly regress any cases
Attempt to improve the `std::fs::create_dir_all` docs related to atomicity
The original paragraph was added in rust-lang/rust#124520. It doesn't match the actual code logic. It says "function returns an error" if "the parent components" _(which also implies directories)_ "have been created already". The code is as follows:
e88e854634/library/std/src/fs.rs (L3146)e88e854634/library/std/src/fs.rs (L3160)
These lines suppress all errors if any path component is a directory. I've updated the paragraph to mirror this.
Clarify WTF-8 safety docs
This PR is a follow-up to PR #140159, which clarifies ~~two things~~:
- the WTF-8 safety comment [was confusing](https://github.com/rust-lang/rust/pull/140159#discussion_r2082766965), either surrogate condition is actually sufficient for safety, both are not required
- ~~the private `os_str::Slice` type name is easily confused with `std::slice`~~
~~Happy to bikeshed the `OsSlice` name, other alternatives are `OsStrSlice` and `StrSlice`. Now it's got a distinct name from `std::slice`, it's easy to search and replace.~~
cc ``@thaliaarchi`` ``@workingjubilee``
Implement `normalize_lexically`
Implements #134694
This is, I think, the most straightforward implementation I could do, which will hopefully more easily allow experimentation if we decide to change the design here.
Implement `advance_by` via `try_fold` for `Sized` iterators
When `try_fold` is overriden, it is usually easier for compilers to optimize.
Example difference: https://iter.godbolt.org/z/z8cEfnKro
