| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This prevents #113238 from hitting stable while we sort out options for avoiding it. The downgrade
is expected to not affect any users on stable, since it primarily affects tier 3 targets.
|
|
|
|
Use an unbounded lifetime in `String::leak`.
Using `'a` instead of `'static` is predicted to make the process of making `String` generic over an allocator easier/less of a breaking change.
See:
- https://github.com/rust-lang/rust/pull/109814#issuecomment-1550164195
- https://github.com/rust-lang/rust/pull/109814#issuecomment-1550250163
ACP: https://github.com/rust-lang/libs-team/issues/109
|
|
Fix docs for `alloc::realloc`
Fixes #108546.
Corrects the docs for `alloc::realloc` to bring the safety constraints into line with `Layout::from_size_align_unchecked`'s constraints.
|
|
Rework handling of recursive panics
This PR makes 2 changes to how recursive panics works (a panic while handling a panic).
1. The panic count is no longer used to determine whether to force an immediate abort. This allows code like the following to work without aborting the process immediately:
```rust
struct Double;
impl Drop for Double {
fn drop(&mut self) {
// 2 panics are active at once, but this is fine since it is caught.
std::panic::catch_unwind(|| panic!("twice"));
}
}
let _d = Double;
panic!("once");
```
Rustc already generates appropriate code so that any exceptions escaping out of a `Drop` called in the unwind path will immediately abort the process.
2. Any panics while the panic hook is executing will force an immediate abort. This is necessary to avoid potential deadlocks like #110771 where a panic happens while holding the backtrace lock. We don't even try to print the panic message in this case since the panic may have been caused by `Display` impls.
Fixes #110771
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #111936 (Include test suite metadata in the build metrics)
- #111952 (Remove DesugaringKind::Replace.)
- #111966 (Add #[inline] to array TryFrom impls)
- #111983 (Perform MIR type ops locally in new solver)
- #111997 (Fix re-export of doc hidden macro not showing up)
- #112014 (rustdoc: get unnormalized link destination for suggestions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add #[inline] to array TryFrom impls
I was looking into https://github.com/rust-lang/rust/issues/111959 and I realized we don't have these. They seem like an uncontroversial addition.
IMO this PR does not fix that issue. I think the bad codegen is being caused by some underlying deeper problem but this change might cause the MIR inliner to paper over it in this specific case.
r? `@thomcc`
|
|
Stabilize `BuildHasher::hash_one`
FCP completed in https://github.com/rust-lang/rust/issues/86161#issuecomment-1561125732
|
|
[RFC-2011] Expand more expressions
cc #44838
Expands `if`, `let`, `match` and also makes `generic_assert_internals` an allowed feature when using `assert!`. `#![feature(generic_assert)]` is still needed to activate everything.
```rust
#![feature(generic_assert)]
fn fun(a: Option<i32>, b: Option<i32>, c: Option<i32>) {
assert!(
if a.is_some() { 1 } else { 2 } == 3
&& if let Some(elem) = b { elem == 4 } else { false }
&& match c { Some(_) => true, None => false }
);
}
fn main() {
fun(Some(1), None, Some(2));
}
// Assertion failed: assert!(
// if a.is_some() { 1 } else { 2 } == 3
// && if let Some(elem) = b { elem == 4 } else { false }
// && match c { Some(_) => true, None => false }
// );
//
// With captures:
// a = Some(1)
// b = None
// c = Some(2)
```
|
|
r=albertlarsan68,oli-obk
new tool `rustdoc-gui-test`
Implements new tool `rustdoc-gui-test` that allows using compiletest headers for `rustdoc-gui` tests.
|
|
Update current implementation comments for `select_nth_unstable`
This more accurately reflects the actual implementation, as it hasn't been a simple quickselect since #106997. While it does say that the current implementation always runs in O(n), I don't think it should require an FCP as it doesn't guarantee linearity in general and only points out that the current implementation is in fact linear.
r? `@Amanieu`
|
|
Remove structural match from `TypeId`
As per https://github.com/rust-lang/rust/pull/99189#issuecomment-1203720442.
> Removing the structural equality might make sense, but is a breaking change that'd require a libs-api FCP.
https://github.com/rust-lang/rust/pull/99189#issuecomment-1197545482
> Landing this PR now (well, mainly the "remove structural equality" part) would unblock `const fn` `TypeId::of`, since we only postponed that because we were guaranteeing too much.
See also #99189, #101698
|
|
Clarify safety concern of `io::Read::read` is only relevant in unsafe code
We have this clarification note in other similar place like [Iterator::size_hint](https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.size_hint).
The lack of clarification might lead to confusion to Rust beginners. [Relevant URLO post](https://users.rust-lang.org/t/can-read-overflow-a-buffer/94347).
|
|
|
|
|
|
Add Median of Medians fallback to introselect
Fixes #102451.
This PR is a follow up to #106997. It adds a Fast Deterministic Selection implementation as a fallback to the introselect algorithm used by `select_nth_unstable`. This allows it to guarantee O(n) worst case running time, while maintaining good performance in all cases.
This would fix #102451, which was opened because the `select_nth_unstable` docs falsely claimed that it had O(n) worst case performance, even though it was actually quadratic in the worst case. #106997 improved the worst case complexity to O(n log n) by using heapsort as a fallback, and this PR further improves it to O(n) (this would also make #106933 unnecessary).
It also improves the actual runtime if the fallback gets called: Using a pathological input of size `1 << 19` (see the playground link in #102451), calculating the median is roughly 3x faster using fast deterministic selection as a fallback than it is using heapsort.
The downside to this is less code reuse between the sorting and selection algorithms, but I don't think it's that bad. The additional algorithms are ~250 LOC with no `unsafe` blocks (I tried using unsafe to avoid bounds checks but it didn't noticeably improve the performance).
I also let it fuzz for a while against the current `select_nth_unstable` implementation to ensure correctness, and it seems to still fulfill all the necessary postconditions.
cc `@scottmcm` who reviewed #106997
|
|
|
|
Support #[global_allocator] without the allocator shim
This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as `--emit obj` doesn't create an allocator shim.
Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once `#![feature(default_alloc_error_handler)]` becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either `--cfg no_global_oom_handling` for liballoc (like rust-for-linux) or `--gc-sections` no references to the oom error handler will exist.
To avoid this feature being insta-stable, you will have to define `__rust_no_alloc_shim_is_unstable` to avoid linker errors.
(Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the `__rust_no_alloc_shim_is_unstable` symbol requirement should prevent unintended dependence on this unstable feature.)
|
|
|
|
|
|
Add slice::{split_,}{first,last}_chunk{,_mut}
This adds to the existing tracking issue for `slice::array_chunks` (#74985) under a separate feature, `slice_get_chunk`.
Currently, we have the existing `first`/`last` API for slices:
```rust
impl [T] {
pub const fn first(&self) -> Option<&T>;
pub const fn first_mut(&mut self) -> Option<&mut T>;
pub const fn last(&self) -> Option<&T>;
pub const fn last_mut(&mut self) -> Option<&mut T>;
pub const fn split_first(&self) -> Option<(&T, &[T])>;
pub const fn split_first_mut(&mut self) -> Option<(&mut T, &mut [T])>;
pub const fn split_last(&self) -> Option<(&T, &[T])>;
pub const fn split_last_mut(&mut self) -> Option<(&mut T, &mut [T])>;
}
```
This augments it with a `first_chunk`/`last_chunk` API that allows retrieving multiple elements at once:
```rust
impl [T] {
pub const fn first_chunk<const N: usize>(&self) -> Option<&[T; N]>;
pub const fn first_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
pub const fn last_chunk<const N: usize>(&self) -> Option<&[T; N]>;
pub const fn last_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>;
pub const fn split_first_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>;
pub const fn split_first_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
pub const fn split_last_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>;
pub const fn split_last_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>;
}
```
The code is based off of a copy of the existing API, with the documentation and examples properly modified. Currently, the most common way to perform these kinds of lookups with the existing methods is via `slice.as_chunks::<N>().0[0]` or the worse `slice.as_chunks::<N>().0[slice.len() - N]`, which is substantially less readable than `slice.first_chunk::<N>()` or `slice.last_chunk::<N>()`.
ACP: https://github.com/rust-lang/libs-team/issues/69
|
|
|
|
libtest: Improve error when missing `-Zunstable-options`
"only accepted on the nightly compiler" is misleading when this *is* nightly.
|
|
|
|
"only accepted on the nightly compiler" is misleading when this *is* nightly.
|
|
|
|
This pulls in the weak-intrinsics feature (which currently
defaults off), and a minor version update to libm for the
compiler_builtins crate to 0.2.7.
|
|
[rustc_ty_utils] Treat `drop_in_place`'s *mut argument like &mut when adding LLVM attributes
This resurrects PR #103614, which has sat idle for a while.
This could probably use a new perf run, since we're on a new LLVM version now.
r? `@oli-obk`
cc `@RalfJung`
---
LLVM can make use of the `noalias` parameter attribute on the parameter to `drop_in_place` in areas like argument promotion. Because the Rust compiler fully controls the code for `drop_in_place`, it can soundly deduce parameter attributes on it.
In #103957, Miri was changed to retag `drop_in_place`'s argument as if it was `&mut`, matching this change.
|
|
Rename `{drop,forget}_{copy,ref}` lints to more consistent naming
This PR renames previous uplifted lints in https://github.com/rust-lang/rust/pull/109732 to more consistent naming.
I followed the renaming done [here](https://github.com/rust-lang/rust/issues/53224) and also advocated in this [clippy issue](https://github.com/rust-lang/rust-clippy/issues/2845):
- `drop_copy` to `dropping_copy_types`
- `forget_copy` to `forgetting_copy_types`
- `drop_ref` to `dropping_references`
- `forget_ref` to `forgetting_references`
|
|
Give better error when collecting into `&[T]`
The detection of slice reference of `{integral}` in `rustc_on_unimplemented` is hacky, but a proper solution requires changing `FmtPrinter` to add a parameter to print integers as `{integral}` and I didn't want to change it just for `rustc_on_unimplemented`. I can do that if requested, though.
I'm open to better wording; this is the best I could come up with.
|
|
Mark internal functions and traits unsafe to reflect preconditions
No semantics are changed in this PR; I only mark some functions and and a trait `unsafe` which already had implicit preconditions. Although it seems somewhat redundant for `numfmt::Part::Copy` to contain a `&[u8]` instead of a `&str`, given that all of its current consumers ultimately expect valid UTF-8. Is the type also intended to work for byte-slice formatting in the future?
|
|
Fix duplicate `arcinner_layout_for_value_layout` calls when using the uninit `Arc` constructors
What this fixes is the duplicate calls to `arcinner_layout_for_value_layout` seen here: https://godbolt.org/z/jr5Gxozhj
The issue was discovered alongside #111603 but is otherwise unrelated to the duplicate `alloca`s, which remain unsolved. Everything I tried to solve said main issue has failed.
As for the duplicate layout calculations, I also tried slapping `#[inline]` and `#[inline(always)]` on everything in sight but the only thing that worked in the end is to dedup the calls by hand.
|
|
Document `Pin` memory layout
The fact that `Pin` is `#[repr(transparent)]` technically isn't documented anywhere currently. I don't see any reason why `Pin`'s layout would ever change, so this PR codifies it.
`@rustbot` label +T-libs-api -T-libs +A-docs +A-layout +A-pin
|
|
Rollup of 2 pull requests
Successful merges:
- #111810 (Don't use inner macro in `marker_impls`)
- #111826 (Render test messages from bootstrap)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't use inner macro in `marker_impls`
Just recurse instead of having to define an inner macro to avoid the problem with expansion binders being misnumbered between the `$meta` and `$T` variables.
cc `@Veykril` this should fix rust-lang/rust-analyzer#14862 since we've gotten rid of the inner macro.
|
|
optimize next_chunk impls for Filter and FilterMap
```
OLD:
benchmarks:
iter::bench_next_chunk_filter_even 104.00ns/iter +/- 1.00ns
iter::bench_next_chunk_filter_map_even 101.00ns/iter +/- 1.00ns
iter::bench_next_chunk_filter_map_mostly_false 1.99µs/iter +/- 10.00ns
iter::bench_next_chunk_filter_map_predictably_true 56.00ns/iter +/- 0.00ns
iter::bench_next_chunk_filter_mostly_false 1.15µs/iter +/- 6.00ns
iter::bench_next_chunk_filter_predictably_true 65.00ns/iter +/- 1.00ns
NEW:
benchmarks:
iter::bench_next_chunk_filter_even 42.00ns/iter +/- 0.00ns
iter::bench_next_chunk_filter_map_even 49.00ns/iter +/- 1.00ns
iter::bench_next_chunk_filter_map_mostly_false 501.00ns/iter +/- 3.00ns
iter::bench_next_chunk_filter_map_predictably_true 31.00ns/iter +/- 0.00ns
iter::bench_next_chunk_filter_mostly_false 534.00ns/iter +/- 13.00ns
iter::bench_next_chunk_filter_predictably_true 28.00ns/iter +/- 1.00ns
```
|
|
|
|
|
|
|
|
r=compiler-errors
don't skip inference for type in `offset_of!`
Fixes https://github.com/rust-lang/rust/issues/111678 by no longer skipping inference on the type in `offset_of!`. Simply erasing the regions the during writeback isn't enough and can cause ICEs. A test case for this is included.
This reverts https://github.com/rust-lang/rust/pull/111661, because it becomes redundant, since inference already erases the regions.
|
|
|
|
|
|
|
|
r=cuviper
Use code with reliable branchless code-gen for slice::sort merge
The recent LLVM 16 update changes code-gen to be not branchless anymore, in the slice::sort implementation merge function. This improves performance by 30% for random patterns, restoring the performance to the state with LLVM 15.
Fixes #111559
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #111491 (Dont check `must_use` on nested `impl Future` from fn)
- #111606 (very minor cleanups)
- #111619 (Add timings for MIR passes to profiling report)
- #111652 (Better diagnostic for `use Self::..`)
- #111665 (Add more tests for the offset_of macro)
- #111708 (Give a more useful location for where a span_bug was delayed)
- #111715 (Fix doc comment for `ConstParamTy` derive)
- #111723 (style: do not overwrite obligations)
- #111743 (Improve cgu merging debug output)
- #111762 (fix: emit error when fragment is `MethodReceiverExpr` and items is empty)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix doc comment for `ConstParamTy` derive
See https://github.com/rust-lang/rust/pull/111670#discussion_r1196453888
Thanks ````@Nilstrieb```` for the pointer :)
|
