| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Co-Authored-By: Matthias247 <matthias.einwag@live.com>
|
|
This change updates the future and task API as discussed in the stabilization RFC at https://github.com/rust-lang/rfcs/pull/2592.
Changes:
- Replacing UnsafeWake with RawWaker and RawWakerVtable
- Removal of LocalWaker
- Removal of Arc-based Wake trait
|
|
|
|
|
|
|
|
Specialize Iterator::try_fold and DoubleEndedIterator::try_rfold to
improve code generation in all internal iteration scenarios.
This changes brings the performance of internal iteration with
RangeInclusive on par with the performance of iteration with Range:
- Single conditional jump in hot loop,
- Unrolling and vectorization,
- And even Closed Form substitution.
Unfortunately, it only applies to internal iteration. Despite various
attempts at stream-lining the implementation of next and next_back,
LLVM has stubbornly refused to optimize external iteration
appropriately, leaving me with a choice between:
- The current implementation, for which Closed Form substitution is
performed, but which uses 2 conditional jumps in the hot loop when
optimization fail.
- An implementation using a "is_done" boolean, which uses 1
conditional jump in the hot loop when optimization fail, allowing
unrolling and vectorization, but for which Closed Form substitution
fails.
In the absence of any conclusive evidence as to which usecase matters
most, and with no assurance that the lack of Closed Form substitution
is not indicative of other optimizations being foiled, there is no way
to pick one implementation over the other, and thus I defer to the
statu quo as far as next and next_back are concerned.
|
|
Update visibility of intermediate use items.
Fixes #57410 and fixes #53925 and fixes #47816.
Currently, the target of a use statement will be updated with
the visibility of the use statement itself (if the use statement was
visible).
This PR ensures that if the path to the target item is via another
use statement then that intermediate use statement will also have the
visibility updated like the target. This silences incorrect
`unreachable_pub` lints with inactionable suggestions.
|
|
Rename iter::unfold to iter::from_fn and remove explicit state
This API is unstable.
CC https://github.com/rust-lang/rust/issues/55977#issuecomment-459657195
|
|
Currently, the target of a use statement will be updated with
the visibility of the use statement itself (if the use statement was
visible).
This commit ensures that if the path to the target item is via another
use statement then that intermediate use statement will also have the
visibility updated like the target. This silences incorrect
`unreachable_pub` lints with inactionable suggestions.
|
|
|
|
This API is unstable.
CC https://github.com/rust-lang/rust/issues/55977#issuecomment-459657195
|
|
Tracking issue FCP to merge: https://github.com/rust-lang/rust/issues/48656#issuecomment-442372750
|
|
|
|
Remember that the signed and unsigned versions are slightly different here, so there's four functions made const instead of just two.
|
|
Add suggestions to deprecation lints
Clippy used to do this suggestion, but the clippy lints happen after the deprecation lints so we ended up never seeing the structured suggestions.
|
|
Use LLVM intrinsics for saturating add/sub
Use the `[su](add|sub).sat` LLVM intrinsics, if we're compiling against LLVM 8, as they should optimize and codegen better than IR based on `[su](add|sub).with.overlow`.
For the fallback for LLVM < 8 I'm using the same expansion that target lowering in LLVM uses, which is not the same as Rust currently uses (in particular due to the use of selects rather than branches).
Fixes #55286.
Fixes #52203.
Fixes #44500.
r? @nagisa
|
|
update docs for fix_start/end_matches
fixes #57686:
|
|
Mark str::trim.* functions as #[must_use].
The functions return a reference to a new object and do not modify in-place
as the following code shows:
````
let s = String::from(" hello ");
s.trim();
assert_eq!(s, " hello ");
````
The new reference should be bound to a variable as now indicated by #[must_use].
|
|
|
|
|
|
|
|
Update stdsimd
This is the companion PR to https://github.com/rust-lang-nursery/stdsimd/pull/640
r? @alexcrichton
|
|
|
|
Kill remaining uses of mem::uninitialized in libcore, liballoc
Kill remaining uses of mem::uninitialized in libcore and liballoc, and enable a lint that will warn when uses are added again in the future.
To avoid casting raw pointers around (which is always very dangerous because it is not typechecked at all -- it doesn't even get the "same size" sanity check that `transmute` gets), I also added two new functions to `MaybeUninit`:
```rust
/// Get a pointer to the first contained values.
pub fn first_ptr(this: &[MaybeUninit<T>]) -> *const T {
this as *const [MaybeUninit<T>] as *const T
}
/// Get a mutable pointer to the first contained values.
pub fn first_mut_ptr(this: &mut [MaybeUninit<T>]) -> *mut T {
this as *mut [MaybeUninit<T>] as *mut T
}
```
I changed some of the existing code to use array-of-`MaybeUninit` instead of `MaybeUninit`-of-array, successfully removing raw pointer casts there as well.
|
|
Use pinning for generators to make trait safe
I'm unsure whether there needs to be any changes to the actual generator transform. Tests are passing so the fact that `Pin<&mut T>` is fundamentally the same as `&mut T` seems to allow it to still work, but maybe there's something subtle here that could go wrong.
This is specified in [RFC 2349 § Immovable generators](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md#immovable-generators) (although, since that RFC it has become safe to create an immovable generator, and instead it's unsafe to resume any generator; with these changes both are now safe and instead the unsafety is moved to creating a `Pin<&mut [static generator]>` which there are safe APIs for).
CC #43122
|
|
|
|
|
|
This is needed to properly respect "deny_warnings = false" in config.toml
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Refactor core::iter module
A while back, I refactored `core::ops` in #42523 because the module had become a giant mess and was difficult to modify. Now, I'm doing the same with the `core::iter` module.
Like the `core::ops` refactor, things have been split up into multiple commits to make rebasing easier, and so that you can follow changes. Although the diffs are hard to decipher, the only actual code changes I've made in the first few commits are to modify exports and imports. I save all of the actual code refactoring, e.g. modifying what methods are called, for the end.
|
|
Bump bootstrap compiler to 1.33 beta
r? @alexcrichton or @pietroalbini
cc @rust-lang/release
|
|
Fixed Deref coercion explanation for DerefMut using shared references
|
|
|
|
The example no longer produces an error in the 2018 edition
|
|
This is not really significant, accept or reject as you wish. I
just want to make sure I understand how the PR process works and
I'm doing it right before doing a bigger one for #33417.
|
|
un-deprecate mem::zeroed
as per the discussion around <https://github.com/rust-lang/rust/issues/53491#issuecomment-451454793>
|
|
|
|
This commit stabilizes the `Atomic{I,U}{8,16,32,64}` APIs in the
`std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753
and tracked in #32976 this feature has been unstable for quite some time
and is hopefully ready to go over the finish line now!
The API is being stabilized as-is. The API of `AtomicU8` and friends
mirrors that of `AtomicUsize`. A list of changes made here are:
* A portability documentation section has been added to describe the
current state of affairs.
* Emulation of smaller-size atomics with larger-size atomics has been
documented.
* As an added bonus, `ATOMIC_*_INIT` is now scheduled for deprecation
across the board in 1.34.0 now that `const` functions can be invoked
in statics.
Note that the 128-bit atomic types are omitted from this stabilization
explicitly. They have far less platform support than the other atomic
types, and will likely require further discussion about their best
location.
Closes #32976
Closes #56753
|
|
Add grammar in docs for {f32,f64}::from_str, mention known bug.
- Original bug about documenting grammar
- https://github.com/rust-lang/rust/issues/32243
- Known bug with parsing
- https://github.com/rust-lang/rust/issues/31407
|
|
core::mem::transmute, create documentation pages for them.
This renders them discoverable via search. I removed the mention of the exports in the transmute documentation, but can re-add it if desired.
|
|
Stabilize no_panic_pow
This would close #48320.
I'm not sure if I've done this right, I've just changed attribute name to stable and set `since` to two minor versions above current stable since that seemed like what others were doing.
|
|
|
|
Stabilize Any::get_type_id and rename to type_id
FCP: https://github.com/rust-lang/rust/issues/27745#issuecomment-373906749
Closes https://github.com/rust-lang/rust/issues/27745.
|
