| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Implement `Option::replace` in the core library
Here is the implementation of the `Option::replace` method. The first step of [the tracking issue #51998](https://github.com/rust-lang/rust/issues/51998).
|
|
Change RangeInclusive to a three-field struct.
Fix #45222.
This PR also reverts #48012 (i.e. removed the `try_fold`/`try_rfold` specialization for `RangeInclusive`) because LLVM no longer has trouble recognizing a RangeInclusive loop.
|
|
|
|
When the index is not PartialOrd, always treat the range as empty.
|
|
|
|
Fix #45222.
|
|
|
|
Add ExactChunks::remainder and ExactChunks::into_remainder
These allow to get the leftover items of the slice that are not being
iterated as part of the iterator due to not filling a complete chunk.
The mutable version consumes the slice because otherwise we would either
a) have to borrow the iterator instead of taking the lifetime of
the underlying slice, which is not what *any* of the other iterator
functions is doing, or
b) would allow returning multiple mutable references to the same data
The current behaviour of consuming the iterator is consistent with
IterMut::into_slice for the normal iterator.
----
This is related to https://github.com/rust-lang/rust/issues/47115#issuecomment-392685177 and the following comments.
While there the discussion was first about a way to get the "tail" of the iterator (everything from the slice that is still not iterated yet), this gives kind of unintuitive behaviour and is inconsistent with how the other slice iterators work.
Unintuitive because the `next_back` would have no effect on the tail (or otherwise the tail could not include the remainder items), inconsistent because a) generally the idea of the slice iterators seems to be to only ever return items that were not iterated yet (and don't provide a way to access the same item twice) and b) we would return a "flat" `&[T]` slice but the iterator's shape is `&[[T]]` instead, c) the mutable variant would have to borrow from the iterator instead of the underlying slice (all other iterator functions borrow from the underlying slice!)
As such, I've only implemented functions to get the remainder. This also allows the implementation to be completely safe still (and around slices instead of raw pointers), while getting the tail would either be inefficient or would have to be implemented around raw pointers.
CC @kerollmops
|
|
|
|
use proper footnote syntax for references
The previous syntax was causing rustdoc to interpret them as links.
|
|
step_by: leave time of item skip unspecified
This gives us some leeway when optimizing. `StepBy<RangeFrom<_>>` is one case where this is needed.
|
|
The previous syntax was causing rustdoc to interpret them as links.
|
|
Avoid unwrapping in PanicInfo doc example.
Fixes https://github.com/rust-lang/rust/issues/51768.
|
|
Fix typo in error message E0277
Fix a typo we stumbled upon by accident :)
r? @estebank
|
|
Better docs for copy_from_slice & clone_from_slice
I copy-pasted the text from clone_from_slice to copy_from_slice :smile:
@steveklabnik feel free to suggest changes.
edit: closes #49769
|
|
Fixes https://github.com/rust-lang/rust/issues/51768.
|
|
|
|
Trait impl settings
Fixes #51797.
r? @QuietMisdreavus
PS: I was annoyed by some intra link failures so I fixed them as well.
|
|
Add #[repr(transparent)] to Atomic* types
This allows them to be used in `#[repr(C)]` structs without warnings. Since rust-lang/rfcs#1649 and rust-lang/rust#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.
This was briefly part of #51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).
|
|
Clarifying how the alignment of the struct works
The docs were not specifying how to compute the alignment of the struct, so I had to spend some time trying to figure out how that works. Found the answer [on this page](http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html):
> The total size of this struct is 5, but the most-aligned field is b with alignment 2, so we round up to 6 and give the struct an alignment of 2 bytes.
|
|
|
|
It wasn't abundantly clear to me what `.take` returned. Perhaps this is a slightly frivolous change, but I think it's an improvement. =)
Apologies if I'm not following proper procedures.
|
|
this gives us some leeway when optimizing
|
|
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
|
|
|
|
|
|
|
|
|
|
This allows them to be used in #[repr(C)] structs without warnings. Since rust-lang/rfcs#1649 and rust-lang/rust#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.
|
|
Remove unnecessary feature gate.
To fix a warning.
|
|
|
|
enable Atomic*.{load,store} for ARMv6-M / MSP430
closes #45085
as proposed in https://github.com/rust-lang/rust/issues/45085#issuecomment-384825434
this commit adds an `atomic_cas` target option and extends the `#[cfg(target_has_atomic)]`
attribute to enable a subset of the `Atomic*` API on architectures that don't support atomic CAS
natively, like MSP430 and ARMv6-M.
r? @alexcrichton
|
|
To fix a warning.
|
|
Any docs preposition change
This changes the docs referring to where a user should be wary of depending on "Any" trait impls from warning about relying on them "outside" of their code to warning about relying on them "inside" of their code.
|
|
|
|
closes #45085
this commit adds an `atomic_cas` target option and an unstable `#[cfg(target_has_atomic_cas)]`
attribute to enable a subset of the `Atomic*` API on architectures that don't support atomic CAS
natively, like MSP430 and ARMv6-M.
|
|
The docs were not specifying how to compute the alignment of the struct, so I had to spend some time trying to figure out how that works. Found the answer [on this page](http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html):
> The total size of this struct is 5, but the most-aligned field is b with alignment 2, so we round up to 6 and give the struct an alignment of 2 bytes.
|
|
|
|
Add #[repr(transparent)] to some libcore types
* `UnsafeCell`
* `Cell`
* `NonZero*`
* `NonNull`
* `Unique`
CC https://github.com/rust-lang/rust/issues/43036
|
|
Unpin references
I also considered adding an impl for raw pointers as well, but that makes it easy to accidentally have unsound owning-collections that might otherwise be able to project pinned-ness (e.g. `Box`).
cc @RalfJung
r? @withoutboats
|
|
This changes the docs referring to where a user should be wary of depending on "Any" trait impls from warning about relying on them "outside" of their code to warning about relying on them "inside" of their code.
|
|
Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms
This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a "Remove TryFrom impls that might become conditionally-infallible with a portability lint".
This fixes #49415 by adding (restoring) missing `TryFrom` impls for integer conversions to or from `usize` or `isize`, by making them always fallible at the type system level (that is, with `Error=TryFromIntError`) even though they happen to be infallible on some platforms (for some values of `size_of::<usize>()`).
They had been removed to allow the possibility to conditionally having some of them be infallible `From` impls instead, depending on the platforms, and have the [portability lint](https://github.com/rust-lang/rfcs/pull/1868) warn when they are used in code that is not already opting into non-portability. For example `#[allow(some_lint)] usize::from(x: u64)` would be valid on code that only targets 64-bit platforms.
This PR gives up on this possiblity for two reasons:
* Based on discussion with @aturon, it seems that the portability lint is not happening any time soon. It’s better to have the conversions be available *at all* than keep blocking them for so long. Portability-lint-gated platform-specific APIs can always be added separately later.
* For code that is fine with fallibility, the alternative would force it to opt into "non-portability" even though there would be no real portability issue.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
