| Age | Commit message (Collapse) | Author | Lines |
|
Refactor IntErrorKind to avoid "underflow" terminology
This PR is a continuation of #76455
# Changes
- `Overflow` renamed to `PosOverflow` and `Underflow` renamed to `NegOverflow` after discussion in #76455
- Changed some of the parsing code to return `InvalidDigit` rather than `Empty` for strings "+" and "-". https://users.rust-lang.org/t/misleading-error-in-str-parse-for-int-types/49178
- Carry the problem `char` with the `InvalidDigit` variant.
- Necessary changes were made to the compiler as it depends on `int_error_matching`.
- Redid tests to match on specific errors.
r? ```@KodrAus```
|
|
Constantify `UnsafeCell::into_inner` and related
Tracking issue: #78729
This PR constantifies:
- `UnsafeCell::into_inner`
- `Cell::into_inner`
- `RefCell::into_inner`
- `Atomic*::into_inner`
r? `````@dtolnay`````
|
|
Stabilize `Poll::is_ready` and `is_pending` as const
Insta-stabilize the methods `is_ready` and `is_pending` of `std::task::Poll` as const, in the same way as [PR#76198](https://github.com/rust-lang/rust/pull/76198).
Possible because of the recent stabilization of const control flow.
Part of #76225.
|
|
Adds structural match tests for all range types.
Note: also adds the otherwise unrelated test `test_range_to_inclusive` for completeness
|
|
Move range in ui test to ops test in library/core
Helps with #76268
r? ````@matklad````
|
|
|
|
|
|
|
|
|
|
Also includes:
- Cell::into_inner
- RefCell::into_inner
- Atomic*::into_inner
|
|
|
|
|
|
Duration::ZERO composes better with match and various other things,
at the cost of an occasional parens, and results in less work for the
optimizer, so let's use that instead.
|
|
This expands time's test suite to use more and in more places the
range of methods and constants added to Duration in recent
proposals for the sake of testing more API surface area and
improving legibility.
|
|
|
|
|
|
Replace absolute paths with relative ones
Modern compilers allow reaching external crates
like std or core via relative paths in modules
outside of lib.rs and main.rs.
|
|
Modern compilers allow reaching external crates
like std or core via relative paths in modules
outside of lib.rs and main.rs.
|
|
This stabilizes the functionality in slice_partition_at_index,
but under the names `select_nth_unstable*`. The functions
`partition_at_index*` are left as deprecated, to be removed in
a later release.
Closes #55300
|
|
|
|
|
|
|
|
|
|
Implement advance_by, advance_back_by for iter::Chain
Part of #77404.
This PR does two things:
- implement `Chain::advance[_back]_by` in terms of `advance[_back]_by` on `self.a` and `advance[_back]_by` on `self.b`
- change `Chain::nth[_back]` to use `advance[_back]_by` on `self.a` and `nth[_back]` on `self.b`
This ensures that `Chain::nth` can take advantage of an efficient `nth` implementation on the second iterator, in case it doesn't implement `advance_by`.
cc `@scottmcm` in case you want to review this
|
|
|
|
|
|
Move Wrapping<T> ui tests into library
Part of #76268
r? @matklad
|
|
|
|
Add Iterator::advance_by and DoubleEndedIterator::advance_back_by
This PR adds the iterator method
```rust
fn advance_by(&mut self, n: usize) -> Result<(), usize>
```
that advances the iterator by `n` elements, returning `Ok(())` if this succeeds or `Err(len)` if the length of the iterator was less than `n`.
Currently `Iterator::nth` is the method to override for efficiently advancing an iterator by multiple elements at once. `advance_by` is superior for this purpose because
- it's simpler to implement: instead of advancing the iterator and producing the next element you only need to advance the iterator
- it composes better: iterators like `Chain` and `FlatMap` can implement `advance_by` in terms of `advance_by` on their inner iterators, but they cannot implement `nth` in terms of `nth` on their inner iterators (see #60395)
- the default implementation of `nth` can trivially be implemented in terms of `advance_by` and `next`, which this PR also does
This PR also adds `DoubleEndedIterator::advance_back_by` for all the same reasons.
I'll make a tracking issue if it's decided this is worth merging. Also let me know if anything can be improved, this went through several iterations so there might very well still be room for improvement (especially in the doc comments). I've written overrides of these methods for most iterators that already override `nth`/`nth_back`, but those still need tests so I'll add them in a later PR.
cc @cuviper @scottmcm @Amanieu
|
|
UI to unit test for those using Cell/RefCell/UnsafeCell
Helps with #76268.
I'm working on all files using `Cell` and moving them to unit tests when possible.
r? @matklad
|
|
fusion-engineering-forks:fix-fixme-min-max-sign-test, r=nagisa
Fix FIXME in core::num test: Check sign of zero in min/max tests.
r? nagisa
@rustbot modify labels: +C-cleanup
|
|
|
|
Unstably allow assume intrinsic in const contexts
Not sure much about this usage because there are concerns
about [blocking optimization][1] and [slowing down LLVM][2] when using `assme` intrinsic
in inline functions.
But since Oli suggested in https://github.com/rust-lang/rust/issues/76960#issuecomment-695772221,
here we are.
[1]: https://github.com/rust-lang/rust/pull/54995#issuecomment-429302709
[2]: https://github.com/rust-lang/rust/issues/49572#issuecomment-589615423
|
|
|
|
|
|
|
|
Make some methods of `Pin` unstable const
Make the following methods unstable const under the `const_pin` feature:
- `new`
- `new_unchecked`
- `into_inner`
- `into_inner_unchecked`
- `get_ref`
- `into_ref`
- `get_mut`
- `get_unchecked_mut`
Of these, `into_inner` and `into_inner_unchecked` require the unstable `const_precise_live_drops`.
Also adds tests for these methods in a const context.
Tracking issue: #76654
r? @ecstatic-morse
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Part of #76268
|
|
|
|
Stabilize some Result methods as const
Stabilize the following methods of Result as const:
- `is_ok`
- `is_err`
- `as_ref`
A test is also included, analogous to the test for `const_option`.
These methods are currently const under the unstable feature `const_result` (tracking issue: #67520).
I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations, see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463) and [PR#76135](https://github.com/rust-lang/rust/pull/76135).
Note: these methods are the only methods currently under the `const_result` feature, thus this PR results in the removal of the feature.
Related: #76225
|
|
|