| Age | Commit message (Collapse) | Author | Lines |
|---|
|
There is no idx in the function signature.
|
|
Better explain the reasoning for the `next_up`/`next_down` integer
implementation, as requested by Ralf.
|
|
This will make it easier to keep `f16` and `f128` consistent as their
implementations get added.
|
|
|
|
|
|
Co-authored-by: Wedson Almeida Filho <walmeida@microsoft.com>
|
|
Rollup of 3 pull requests
Successful merges:
- #126140 (Rename `std::fs::try_exists` to `std::fs::exists` and stabilize fs_try_exists)
- #126318 (Add a `x perf` command for integrating bootstrap with `rustc-perf`)
- #126552 (Remove use of const traits (and `feature(effects)`) from stdlib)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove use of const traits (and `feature(effects)`) from stdlib
The current uses are already unsound because they are using non-const impls in const contexts. We can reintroduce them by reverting the commit in this PR, after #120639 lands.
Also, make `effects` an incomplete feature.
cc `@rust-lang/project-const-traits`
r? `@compiler-errors`
|
|
Generalize `{Rc,Arc}::make_mut()` to unsized types.
* `{Rc,Arc}::make_mut()` now accept any type implementing the new unstable trait `core::clone::CloneToUninit`.
* `CloneToUninit` is implemented for `T: Clone` and for `[T] where T: Clone`.
* `CloneToUninit` is a generalization of the existing internal trait `alloc::alloc::WriteCloneIntoRaw`.
* New feature gate: `clone_to_uninit`
This allows performing `make_mut()` on `Rc<[T]>` and `Arc<[T]>`, which was not previously possible.
---
Previous PR description, now obsolete:
> Add `{Rc, Arc}::make_mut_slice()`
>
> These functions behave identically to `make_mut()`, but operate on `Arc<[T]>` instead of `Arc<T>`.
>
> This allows performing the operation on slices, which was not previously possible because `make_mut()` requires `T: Clone` (and slices, being `!Sized`, do not and currently cannot implement `Clone`).
>
> Feature gate: `make_mut_slice`
try-job: test-various
|
|
This trait allows cloning DSTs, but is unsafe to implement and use
because it writes to possibly-uninitialized memory which must be of the
correct size, and must initialize that memory.
It is only implemented for `T: Clone` and `[T] where T: Clone`, but
additional implementations could be provided for specific `dyn Trait`
or custom-DST types.
|
|
Stop using `unlikely` in `strict_*` methods
The `strict_*` methods don't need (un)likely, because the `overflow_panic` calls are all `#[cold]`, [meaning](https://llvm.org/docs/LangRef.html#function-attributes) that LLVM knows any branch to them is unlikely without us needing to say so.
r? libs
|
|
|
|
|
|
It's unnecessary when that arm leads to a `#[cold]` panic anyway, since controlling branch likihood is what `#[cold]` is all about.
(And, well, it's unclear whether `unlikely!` even works these days anyway.)
|
|
|
|
Account for things that optimize out in inlining costs
This updates the MIR inlining `CostChecker` to have both bonuses and penalties, rather than just penalties.
That lets us add bonuses for some things where we want to encourage inlining without risking wrapping into a gigantic cost. For example, `switchInt(const …)` we give an inlining bonus because codegen will actually eliminate the branch (and associated dead blocks) once it's monomorphized, so measuring both sides of the branch gives an unrealistically-high cost to it. Similarly, an `unreachable` terminator gets a small bonus, because whatever branch leads there doesn't actually exist post-codegen.
|
|
Replace sort implementations
This PR replaces the sort implementations with tailor-made ones that strike a balance of run-time, compile-time and binary-size, yielding run-time and compile-time improvements. Regressing binary-size for `slice::sort` while improving it for `slice::sort_unstable`. All while upholding the existing soft and hard safety guarantees, and even extending the soft guarantees, detecting strict weak ordering violations with a high chance and reporting it to users via a panic.
* `slice::sort` -> driftsort [design document](https://github.com/Voultapher/sort-research-rs/blob/main/writeup/driftsort_introduction/text.md), includes detailed benchmarks and analysis.
* `slice::sort_unstable` -> ipnsort [design document](https://github.com/Voultapher/sort-research-rs/blob/main/writeup/ipnsort_introduction/text.md), includes detailed benchmarks and analysis.
#### Why should we change the sort implementations?
In the [2023 Rust survey](https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results.html#challenges), one of the questions was: "In your opinion, how should work on the following aspects of Rust be prioritized?". The second place was "Runtime performance" and the third one "Compile Times". This PR aims to improve both.
#### Why is this one big PR and not multiple?
* The current documentation gives performance recommendations for `slice::sort` and `slice::sort_unstable`. If for example only one of them were to be changed, this advice would be misleading for some Rust versions. By replacing them atomically, the advice remains largely unchanged, and users don't have to change their code.
* driftsort and ipnsort share a substantial part of their implementations.
* The implementation of `select_nth_unstable` uses internals of `slice::sort_unstable`, which makes it impractical to split changes.
---
This PR is a collaboration with `@orlp.`
|
|
Remove `feature(const_closures)` from libcore
This is an incomplete feature and apparently it has no uses in `core`. Incomplete features should generally not be used in our standard library.
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #126380 (Add std Xtensa targets support)
- #126636 (Resolve Clippy `f16` and `f128` `unimplemented!`/`FIXME`s )
- #126659 (More status-quo tests for the `#[coverage(..)]` attribute)
- #126711 (Make Option::as_[mut_]slice const)
- #126717 (Clean up some comments near `use` declarations)
- #126719 (Fix assertion failure for some `Expect` diagnostics.)
- #126730 (Add opaque type corner case test)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Clean up some comments near `use` declarations
#125443 will reformat all `use` declarations in the repository. There are a few edge cases involving comments on `use` declarations that require care. This PR cleans up some clumsy comment cases, taking us a step closer to #125443 being able to merge.
r? ``@lqd``
|
|
Make Option::as_[mut_]slice const
These two functions can both be made `const`. I have added them to the `const_option_ext` feature, #91930. I don't believe there is anything blocking stabilization of `as_slice`, but `as_mut_slice` contains mutable references so depends on `const_mut_refs`.
|
|
Stabilise `c_unwind`
Fix #74990
Fix #115285 (that's also where FCP is happening)
Marking as draft PR for now due to `compiler_builtins` issues
r? `@Amanieu`
|
|
|
|
reword the hint::blackbox non-guarantees
People were tripped up by the "precludes", interpreting it that this function must not ever be used in cryptographic contexts rather than the std lib merely making zero promises about it being fit-for-purpose.
What remains unchanged is that if someone does try to use it *despite the warnings* then it is on them to pin their compiler versions and verify the assembly of every single binary build they do.
|
|
|
|
Make both `hint_assert_unchecked` and `const_hint_assert_unchecked`
stable as `hint_assert_unchecked`.
|
|
Rearrange the sections and add an example to
`core::hint::assert_unchecked`.
|
|
Most modules have such a blank line, but some don't. Inserting the blank
line makes it clearer that the `//!` comments are describing the entire
module, rather than the `use` declaration(s) that immediately follows.
|
|
|
|
People were tripped up by the "precludes", interpreting it that this function
must not ever be used in cryptographic contexts rather than the std lib merely
making zero promises about it being fit-for-purpose.
What remains unchanged is that if someone does try to use it *despite the warnings*
then it is on them to pin their compiler versions and verify the assembly of every
single binary build they do.
|
|
|
|
|
|
|
|
|
|
|
|
Edit from #126631 to revert changes on ui tests
|
|
Return opaque type from PanicInfo::message()
This changes the return type of the (unstable) PanicInfo::message() method to an opaque type (that implements Display). This allows for a bit more flexibility in the future.
See https://github.com/rust-lang/rust/issues/66745
|
|
Due to refactoring the const_trait usage, the CopyMarker impl was
accidentally deleted, which had the consequence that the Copy
specialization for the small-sort was never picked.
|
|
|
|
|
|
Freeze + Copy types should be allowed to choose between all three
small-sort variants. With the recent changes to small-sort selection,
a regression was added that only let such types choose between network
and fallback. It can now also choose general where appropriate.
|
|
Rollup of 8 pull requests
Successful merges:
- #125258 (Resolve elided lifetimes in assoc const to static if no other lifetimes are in scope)
- #126250 (docs(change): Don't mention a Cargo 2024 edition change for 1.79)
- #126288 (doc: Added commas where needed)
- #126346 (export std::os::fd module on HermitOS)
- #126468 (div_euclid, rem_euclid: clarify/extend documentation)
- #126531 (Add codegen test for `Request::provide_*`)
- #126535 (coverage: Arrange span extraction/refinement as a series of passes)
- #126538 (coverage: Several small improvements to graph code)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add codegen test for `Request::provide_*`
Codegen before & after https://github.com/rust-lang/rust/pull/126242: https://gist.github.com/slanterns/3789ee36f59ed834e1a6bd4677b68ed4.
Also adjust an outdated comment since `tag_id` is no longer attached to `TaggedOption` via `Erased`, but stored next to it in `Tagged` under the new implementation.
My first time writing FileCheck xD. Correct me if there is anything that should be amended.
r? libs
|
|
div_euclid, rem_euclid: clarify/extend documentation
|
|
doc: Added commas where needed
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
|
|
make `ptr::rotate` smaller when using `optimize_for_size`
code to reproduce https://github.com/folkertdev/optimize_for_size-slice-rotate
In the example the size of `.text` goes down from 1624 to 276 bytes.
```
> cargo size --release --features "left-std" -- -A
slice-rotate :
section size addr
.vector_table 1024 0x0
.text 1624 0x400
.rodata 0 0xa58
.data 0 0x20000000
.gnu.sgstubs 0 0xa60
.bss 0 0x20000000
.uninit 0 0x20000000
.debug_loc 591 0x0
.debug_abbrev 1452 0x0
.debug_info 10634 0x0
.debug_aranges 480 0x0
.debug_ranges 1504 0x0
.debug_str 11716 0x0
.comment 72 0x0
.ARM.attributes 56 0x0
.debug_frame 1036 0x0
.debug_line 5837 0x0
Total 36026
> cargo size --release --features "left-size" -- -A
slice-rotate :
section size addr
.vector_table 1024 0x0
.text 276 0x400
.rodata 0 0x514
.data 0 0x20000000
.gnu.sgstubs 0 0x520
.bss 0 0x20000000
.uninit 0 0x20000000
.debug_loc 347 0x0
.debug_abbrev 965 0x0
.debug_info 4216 0x0
.debug_aranges 168 0x0
.debug_ranges 216 0x0
.debug_str 3615 0x0
.comment 72 0x0
.ARM.attributes 56 0x0
.debug_frame 232 0x0
.debug_line 723 0x0
Total 11910
```
tracking issue: https://github.com/rust-lang/rust/issues/125612
|
|
|
|
|
