| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Revert #51601
Closes: #55985
Specialization of `StepBy<Range(Inclusive)>` results in an incorrectly behaving code when `step_by` is combined with `skip` or `nth`.
If this will get merged we probably should reopen issues previously closed by #51601 (if there was any).
|
|
|
|
|
|
|
|
This commit changes the test code to compare against easier-to-read, static values instead of relying on the result of `wrapping_add()` which may or may not result in the value that we expect.
|
|
* Also update the bootstrap compiler
* Update cargo to 1.32.0
* Clean out stage0 annotations
|
|
It's already stable in 2018; this finishes the stabilization.
|
|
Fixes #55177
|
|
Fixes #47115
|
|
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
See #55177 for the tracking issue
|
|
|
|
|
|
|
|
Impl From<NonZero<T>> for T
Closes https://github.com/rust-lang/rust/issues/54171
r? @SimonSapin
|
|
Rename slice::exact_chunks() to slice::chunks_exact()
See https://github.com/rust-lang/rust/issues/47115#issuecomment-403090815
and https://github.com/rust-lang/rust/issues/47115#issuecomment-424053547
|
|
See https://github.com/rust-lang/rust/issues/47115#issuecomment-403090815
and https://github.com/rust-lang/rust/issues/47115#issuecomment-424053547
|
|
|
|
|
|
|
|
stabilize slice_align_to
This is very hard to implement correctly, and leads to [serious bugs](https://github.com/llogiq/bytecount/pull/42) when done incorrectly. Moreover, this is needed to be able to run code that opportunistically exploits alignment on miri. So code using `align_to`/`align_to_mut` gets the benefit of a well-tested implementation *and* of being able to run in miri to test for (some kinds of) UB.
This PR also clarifies the guarantee wrt. the middle part being as long as possible. Should the docs say under which circumstances the middle part could be shorter? Currently, that can only happen when running in miri.
|
|
|
|
|
|
Stablize Iterator::find_map
Stabilization PR for https://github.com/rust-lang/rust/issues/49602
|
|
debug_assert to ensure that from_raw_parts is only used properly aligned
This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by https://github.com/rust-lang/rust/issues/42789 *if* there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently [fail in the rg testsuite](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). So maybe it is worth it, after all.
I have seen the attribute `#[rustc_inherit_overflow_checks]` in some places, does that make it so that the *caller's* debug status is relevant? Is there a similar attribute for `debug_assert!`? That could even subsume `rustc_inherit_overflow_checks`: Something like `rustc_inherit_debug_flag` could affect *all* places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason *not* to handle the debug flag that way? I guess currently we apply debug flags like `cfg` so this is dropped early during the MIR pipeline?
EDIT: I learned from @eddyb that because of how `debug_assert!` works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^
|
|
|
|
unsized ManuallyDrop
I think this matches what @eddyb had in https://github.com/rust-lang/rust/pull/52711 originally.
~~However, I have never added a `CoerceUnsized` before so I am not sure if I did this right. I copied the `unstable` attribute on the `impl` from elsewhere, but AFAIK it is useless because `impl`'s are insta-stable... so shouldn't this rather say "stable since 1.30"?~~
This is insta-stable and hence requires FCP, at least.
Fixes https://github.com/rust-lang/rust/issues/47034
|
|
|
|
|
|
|
|
|
|
|
|
|
|
slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts
This fixes the problem that we are fabricating pointers out of thin air. I also managed to share more code between the mutable and shared iterators, while reducing the amount of macros.
I am not sure how useful it really is to add a `debug_assert!` in libcore. Everybody gets a release version of that anyway, right? Is there at least a CI job that runs the test suite with a debug version?
Fixes #42789
|
|
|
|
|
|
Treat gc=No characters as numeric
[`char::is_numeric`](https://doc.rust-lang.org/std/primitive.char.html#method.is_numeric) and [`char::is_alphanumeric`](https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric) are documented to be defined “in terms of the Unicode General Categories 'Nd', 'Nl', 'No'”, but unicode.py does not group 'No' with the other 'N' categories. These functions therefore currently return `false` for characters like ⟨¾⟩ and ⟨①⟩.
|
|
Remove unstable and deprecated APIs
|
|
|
|
|
|
Prefer to_string() to format!()
Simple benchmarks suggest in some cases it can be faster by even 37%:
```
test converting_f64_long ... bench: 339 ns/iter (+/- 199)
test converting_f64_short ... bench: 136 ns/iter (+/- 34)
test converting_i32_long ... bench: 87 ns/iter (+/- 16)
test converting_i32_short ... bench: 87 ns/iter (+/- 49)
test converting_str ... bench: 54 ns/iter (+/- 15)
test formatting_f64_long ... bench: 349 ns/iter (+/- 176)
test formatting_f64_short ... bench: 145 ns/iter (+/- 14)
test formatting_i32_long ... bench: 98 ns/iter (+/- 14)
test formatting_i32_short ... bench: 93 ns/iter (+/- 15)
test formatting_str ... bench: 86 ns/iter (+/- 23)
```
|
|
Misc cleanups
|
|
Change ManuallyDrop<T> to a lang item.
This PR implements the approach @RalfJung proposes in https://internals.rust-lang.org/t/pre-rfc-unions-drop-types-and-manuallydrop/8025 (lang item `struct` instead of `union`).
A followup PR can easily solve #47034 as well, by just adding a few `?Sized` to `libcore/mem.rs`.
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
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).
|
|
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
|
|
|
