| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#138285 (Stabilize `repr128`)
- rust-lang/rust#139994 (add `CStr::display`)
- rust-lang/rust#141571 (coretests: extend and simplify float tests)
- rust-lang/rust#141656 (CI: Add cargo tests to aarch64-apple-darwin)
Failed merges:
- rust-lang/rust#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`)
- rust-lang/rust#141636 (avoid some usages of `&mut P<T>` in AST visitors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add `CStr::display`
The implementation delegates to `<ByteStr as Display>::fmt`.
Link: https://github.com/rust-lang/libs-team/issues/550
Link: https://github.com/rust-lang/rust/issues/139984.
r? ```@BurntSushi```
cc ```@Darksonn``` ```@tgross35``` ```@ojeda``` ```@joshtriplett```
|
|
core: unstably expose atomic_compare_exchange so stdarch can use it
Due to https://github.com/rust-lang/stdarch/issues/1655, cleaning up the atomic intrinsics will be a bunch of extra work: stdarch directly calls them [here](https://github.com/rust-lang/stdarch/blob/8764244589373b8b48864c0ad11fd9233c672249/crates/core_arch/src/x86_64/cmpxchg16b.rs#L58-L74).
Instead of duplicating that match, stdarch should use what we have in libcore, so let's expose that.
r? `@bjorn3`
|
|
Call out possibility of invariant result in variance markers
ref https://github.com/rust-lang/rust/issues/135806#issuecomment-2766191535
|
|
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.
|
|
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)]`.
|
|
|
|
|
|
This reverts commit 245bf503e2a948ac98170516d11df632e85a948b.
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#140367 (add `asm_cfg`: `#[cfg(...)]` within `asm!`)
- rust-lang/rust#140894 (Make check-cfg diagnostics work in `#[doc(cfg(..))]`)
- rust-lang/rust#141252 (gvn: bail out unavoidable non-ssa locals in repeat)
- rust-lang/rust#141517 (rustdoc: use descriptive tooltip if doctest is conditionally ignored)
- rust-lang/rust#141551 (Make two transmute-related MIR lints into HIR lint)
- rust-lang/rust#141591 (ci: fix llvm test coverage)
- rust-lang/rust#141647 (Bump master `stage0` compiler)
- rust-lang/rust#141659 (Add `Result::map_or_default` and `Option::map_or_default`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add `Result::map_or_default` and `Option::map_or_default`
Closes: https://github.com/rust-lang/rust/pull/138068
_This PR has been recreated because of the inactivity of the author (Cf. https://github.com/rust-lang/rust/pull/138068#issuecomment-2912412288)_
|
|
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.
|
|
|
|
intrinsics, ScalarInt: minor cleanup
Taken out of https://github.com/rust-lang/rust/pull/141507 while we resolve technical disagreements in that PR.
r? ``@bjorn3``
|
|
|
|
this also cleans up two inconsistancies:
1. both doctests on the ::add methods were
actually calling the const version.
2. on of the ::offset methods was missing
a line of clarification.
part of https://github.com/rust-lang/rust/issues/139190
|
|
|
|
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
|
|
|
|
Specify that split_ascii_whitespace uses the same definition as is_ascii_whitespace
|
|
|
|
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
|
|
|
|
use `cfg_select!` to select the right `VaListImpl` definition
tracking issue: https://github.com/rust-lang/rust/issues/44930
Just a bit of cleanup really.
We could use `PhantomInvariantLifetime<'f>` (https://github.com/rust-lang/rust/issues/135806) to make it more precise what that `PhantomData<&'f mut &'f c_void>` marker is doing. I'm not sure how ready that feature is though, `@jhpratt` are these types good to use internally?
---
Some research into the lifetimes of `VaList` and `VaListImpl`:
It's easy to see why the lifetime of these types should not be extended, a `VaList` or `VaListImpl` escaping its function is a bad idea. I don't currently see why coercing the lifetime to a shorter lifetime is problematic though, but probably I just don't understand variance well enough to see it. The history does not provide much explanation:
- https://github.com/immunant/rust/commit/08140878fefaa4b16939b904bf825b7107069b42 original implementation
- https://github.com/immunant/rust/commit/b9ea653aee231114acbe6d4b3c7b1d692772d060 adds `VaListImpl<'f>`, but it is only covariant in `'f`
- https://github.com/rust-lang/rust/pull/62639 makes `VaListImpl<'f>` invariant over `'f` (because `VaList<'a, 'f>` is already invariant over `'f`, but I think that is just an implementation detail?)
Beyond that I don't see how the lifetime situation can be simplified significantly, e.g. this function really needs `'copy` to be unconstrained.
```rust
/// Copies the `va_list` at the current location.
pub unsafe fn with_copy<F, R>(&self, f: F) -> R
where
F: for<'copy> FnOnce(VaList<'copy, 'f>) -> R,
{
let mut ap = self.clone();
let ret = f(ap.as_va_list());
// SAFETY: the caller must uphold the safety contract for `va_end`.
unsafe {
va_end(&mut ap);
}
ret
}
```
`@rustbot` label +F-c_variadic
r? `@workingjubilee`
|
|
Use C-string literals to reduce boilerplate
Reduce boilerplate in doctests by replacing fallible function calls with
literals.
|
|
Stabilize `<[T; N]>::as_mut_slice` as `const`
This is trivial and has no design questions.
Tracked in https://github.com/rust-lang/rust/issues/133333.
r? libs-api
|
|
Guarantee behavior of transmuting `Option::<T>::None` subject to NPO
In https://github.com/rust-lang/rust/pull/115333, we added a guarantee that transmuting from `[0u8; N]` to `Option<P>` is sound where `P` is a pointer type subject to the null pointer optimization (NPO). It would be useful to be able to guarantee the inverse - that a `None::<P>` value can be transmutes to an array and that will yield `[0u8; N]`.
Closes #117591
|
|
implementations live
|
|
Reduce boilerplate in doctests by replacing fallible function calls with
literals.
|
|
The implementation delegates to `<ByteStr as Display>::fmt`.
Link: https://github.com/rust-lang/libs-team/issues/550
Link: https://github.com/rust-lang/rust/issues/139984.
|
|
Remove #![feature(let_chains)] from libcore
PR https://github.com/rust-lang/rust/pull/132833 has stabilized the let_chains feature. This PR removes the last occurrence from the library.
Split out of #140966 as it caused breakage. Now we have a patch to the linux tree that fixes the build, so we update the linux tree to it.
cc https://github.com/Rust-for-Linux/linux/issues/1163
cc https://github.com/rust-lang/rust/issues/140722
|
|
Updated std doctests for wasm
This updates some doctests that fail to run on wasm. We will soon be supporting cross-compiled doctests, and the test-various job fails to run these tests. These tests fail because wasm32-wasip1 does not support threads.
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #135562 (Add ignore value suggestion in closure body)
- #139635 (Finalize repeat expr inference behaviour with inferred repeat counts)
- #139668 (Handle regions equivalent to 'static in non_local_bounds)
- #140218 (HIR ty lowering: Clean up & refactor the lowering of type-relative paths)
- #140435 (use uX::from instead of _ as uX in non - const contexts)
- #141130 (rustc_on_unimplemented cleanups)
- #141286 (Querify `coroutine_hidden_types`)
Failed merges:
- #140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustc_on_unimplemented cleanups
Addresses some of the fixmes from https://github.com/rust-lang/rust/pull/139091 and https://github.com/rust-lang/rust/pull/140307.
- switch from `_Self` to `Self` in library
- properly validate that arguments in the `on` filter and the format strings are actually valid
See https://github.com/rust-lang/rustc-dev-guide/pull/2357 for the relevant documentation.
|
|
|
|
Rename `cfg_match!` to `cfg_select!`
[`@Nemo157` pointed out](https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605) that `cfg_match!` syntax does not actually align well with match syntax, which is a possible source of confusion. The comment points out that usage is instead more similar to ecosystem `select!` macros. Rename `cfg_match!` to `cfg_select!` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/115585
[1]: https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605
|
|
limit impls of `VaArgSafe` to just types that are actually safe
tracking issue: https://github.com/rust-lang/rust/issues/44930
Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See https://github.com/rust-lang/rust/issues/61275#issuecomment-2193942535 for more detail.
This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB.
r? `@workingjubilee`
|
|
docs: Specify that common sort functions sort in an ascending direction
From [forum discussion](https://users.rust-lang.org/t/is-there-a-way-to-sort-a-slice-in-specifically-ascending-or-descending-order/128998?u=natr1x) it seems like the sorting direction can be expected to always be ascending (in terms of `cmp::Ordering`).
If this is the case then it would be nice to have this stated in the documentation.
|
|
8 and 16-bit integers are subject to upcasting in C, and hence are not reliably safe. users should perform their own casting and deal with the consequences
|
|
|
|
|
|
Implement `ptr::try_cast_aligned` and `NonNull::try_cast_aligned`.
Implement three common methods on raw pointers and `NonNull`s: `try_cast_aligned`.
## Related links
- Tracking Issue: https://github.com/rust-lang/rust/issues/141221
## About `#[inline]`
Since the result of a call to `align_of` is a power of two known at compile time, the compiler is able to reduce a call to `try_cast_aligned` to only test and sete (or test and jne if followed by `unwrap`), at least on every tier 1 target's arch. This seemed like a good reason to `#[inline]` the function.
- https://godbolt.org/z/ocehvPWMx (raw inlining)
- https://godbolt.org/z/3qa4j4Yrn (comparison with no inlining)
|
|
At [1] it was pointed out that `cfg_match!` syntax does not actually
align well with match syntax, which is a possible source of confusion.
The comment points out that usage is instead more similar to ecosystem
`select!` macros. Rename `cfg_match!` to `cfg_select!` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/115585
[1]: https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605
|
|
|
|
use `Self` alias in self types rather than manually substituting it
Of the rougly 145 uses of `self: Ty` in the standard library, 5 of them don't use `Self` but instead choose to manually "substitute" the `impl`'s self type into the type.
This leads to weird behavior sometimes (https://github.com/rust-lang/rust/issues/140611#issuecomment-2883761300) -- **to be clear**, none of these usages actually trigger any bugs, but it's possible that they may break in the future (or at least lead to lints), so let's just "fix" them proactively.
|
