| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 37a5b515e9c36ee3f57d9e0d7db7efce2fb02195.
|
|
Removes the implementations that depend on the user-definable trait `Copy`.
Beta backport: Does not modify `vec::IntoIter`.
|
|
This is to address issue 84297.
|
|
This is preparation for reverting 81238 for short-term resolution of issue 84297.
|
|
using allow_internal_unstable (as recommended)
Fixes: #84836
```shell
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs
error[E0554]: `#![feature]` may not be used on the dev release channel
--> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1
|
2 | #![feature(no_coverage)]
| ^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0554`.
```
|
|
The unsoundness is not in Peekable per se, it rather is due to the
interaction between Peekable being able to hold an extra item
and vec::IntoIter's clone implementation shortening the allocation.
An alternative solution would be to change IntoIter's clone implementation
to keep enough spare capacity available.
|
|
This reverts commit 0a8e401188062f0c60c989978352663b1e25e70e.
|
|
This reverts commit eb18746bc6c6c5c710ad674873438cbad5894f06.
|
|
Searching for "reduce" currently puts the `reduce` alias for `fold`
above the actual `reduce` function. The `reduce` function already has a
cross-reference for `fold`, and vice versa.
|
|
|
|
The Eq trait has a special hidden function. MIR `InstrumentCoverage`
would add this function to the coverage map, but it is never called, so
the `Eq` trait would always appear uncovered.
Fixes: #83601
The fix required creating a new function attribute `no_coverage` to mark
functions that should be ignored by `InstrumentCoverage` and the
coverage `mapgen` (during codegen).
While testing, I also noticed two other issues:
* spanview debug file output ICEd on a function with no body. The
workaround for this is included in this PR.
* `assert_*!()` macro coverage can appear covered if followed by another
`assert_*!()` macro. Normally they appear uncovered. I submitted a new
Issue #84561, and added a coverage test to demonstrate this issue.
|
|
They were described backwards. #84608
|
|
Add the `try_trait_v2` library basics
No compiler changes as part of this -- just new unstable traits and impls thereof.
The goal here is to add the things that aren't going to break anything, to keep the feature implementation simpler in the next PR.
(Draft since the FCP won't end until Saturday, but I was feeling optimistic today -- and had forgotten that FCP was 10 days, not 7 days.)
|
|
Stabilize ordering_helpers.
Tracking issue: https://github.com/rust-lang/rust/issues/79885
Closes https://github.com/rust-lang/rust/issues/79885
|
|
Stabilize Duration::MAX
Following the suggested direction from https://github.com/rust-lang/rust/issues/76416#issuecomment-817278338, this PR proposes that `Duration::MAX` should have been part of the `duration_saturating_ops` feature flag all along, having been
0. heavily referenced by that feature flag
1. an odd duck next to most of `duration_constants`, as I expressed in https://github.com/rust-lang/rust/issues/57391#issuecomment-717681193
2. introduced in #76114 which added `duration_saturating_ops`
and accordingly should be folded into `duration_saturating_ops` and therefore stabilized.
r? `@m-ou-se`
|
|
Document Hasher spec decision from #42951
Since that ticket was closed without the decision actually being documented.
Fixes #42951.
|
|
Fix 'const-stable since' of reverse_bits
This fixes the const_stable `since` of `reverse_bits` for the signed and unsigned integer types. The previous value was incorrect, as it pointed to an older version where `reverse_bits` hadn't been stabilized yet.
`reverse_bits` was const-stable from the start, as can be seen from:
https://doc.rust-lang.org/1.37.0/std/primitive.u32.html#method.reverse_bits
https://doc.rust-lang.org/1.37.0/std/primitive.i32.html#method.reverse_bits
|
|
|
|
|
|
|
|
move core::hint::black_box under its own feature gate
The `black_box` function had its own RFC and is tracked separately from the `test` feature at https://github.com/rust-lang/rust/issues/64102. Let's reflect this in the feature gate.
To avoid breaking all the benchmarks, libtest's `test::black_box` is a wrapping definition, not a reexport -- this means it is still under the `test` feature gate.
|
|
|
|
|
|
Cautiously add IntoIterator for arrays by value
Add the attribute described in #84133, `#[rustc_skip_array_during_method_dispatch]`, which effectively hides a trait from method dispatch when the receiver type is an array.
Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally, but `array.into_iter()` has edition-dependent behavior, returning `slice::Iter` for 2015 and 2018 editions, or `array::IntoIter` for 2021 and later.
r? `@nikomatsakis`
cc `@LukasKalbertodt` `@rust-lang/libs`
|
|
Duration is used in std to represent a difference between two Instants.
As such, it has to at least contain that span of time in it. However,
Instant can vary by platform. Thus, we should explain the impl of
Duration::MAX is sensitive to these vagaries of the platform.
|
|
further split up const_fn feature flag
This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)
I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.
`@oli-obk` are you currently able to do reviews?
|
|
stabilize `core::array::{from_ref,from_mut}` in `1.53.0`
I didn't get any response in https://github.com/rust-lang/rust/issues/77101#issuecomment-761831104, so I figured out I can try opening stabilization pr.
---
This PR stabilizes following functions:
```rust
// core::array
pub fn from_ref<T>(s: &T) -> &[T; 1];
pub fn from_mut<T>(s: &mut T) -> &mut [T; 1];
```
Functions are similar to already stabilized `core::slice::{`[`from_ref`](https://doc.rust-lang.org/std/slice/fn.from_ref.html),[`from_mut`](https://doc.rust-lang.org/std/slice/fn.from_mut.html)`}` and were unstable without any problems/questions for a while now.
---
resolves #77101
``@rustbot`` modify labels: +T-libs
|
|
|
|
Mention FusedIterator case in Iterator::fuse doc
Using `fuse` on an iterator that incorrectly implements
`FusedIterator` does not fuse the iterator. This commit adds a
note about this in the documentation of this method to increase
awareness about this potential issue (esp. when relying on fuse
in unsafe code).
Closes #83969
|
|
implement `TrustedRandomAccess` for `Take` iterator adapter
`TrustedRandomAccess` requires the iterator length to fit within `usize`. `take(n)` only constrains the upper bound of an iterator. So if the inner is `TrustedRandomAccess` (which already implies a finite length) then so can be `Take`.
```````@rustbot``````` label T-libs-impl
|
|
r=yaahc
doc: Get rid of "[+] show undocumented items" toggle on numeric From impls
On most From implementations, the docstring is attached to the function. This is also how people have been [recommended] to do it.
Screenshots:
* [before](https://user-images.githubusercontent.com/1593513/115767662-323c5480-a35e-11eb-9918-98aba83e9183.png)
* [after](https://user-images.githubusercontent.com/1593513/115767675-35374500-a35e-11eb-964f-c28eeb6c807a.png)
[recommended]: https://github.com/rust-lang/rust/issues/51430#issuecomment-398322434
|
|
Improve `Iterator::by_ref` example
I split the example into two: one that fails to compile, and one that
works. I also made them identical except for the addition of `by_ref`
so we don't confuse readers with random differences.
cc `@steveklabnik,` who is the one that added the previous version of this example
|
|
Using `fuse` on an iterator that incorrectly implements
`FusedIterator` does not fuse the iterator. This commit adds a
note about this in the documentation of this method to increase
awareness about this potential issue (esp. when relying on fuse
in unsafe code).
|
|
Added CharIndices::offset function
The CharIndices iterator has a field internally called front_offset, that I think would be very useful to have access to.
You can already do something like ``char_indices.next().map(|(offset, _)| offset)``, but that is wordy, in addition to not handling the case where the iterator has ended, where you'd want the offset to be equal to the length.
I'm very new to the open source world and the rust repository, so I'm sorry if I missed a step or did something weird.
|
|
On most From implementations, the docstring is attached to the
function. This is also how people have been [recommended] to do it.
Screenshots:
* [before](https://user-images.githubusercontent.com/1593513/115767662-323c5480-a35e-11eb-9918-98aba83e9183.png)
* [after](https://user-images.githubusercontent.com/1593513/115767675-35374500-a35e-11eb-964f-c28eeb6c807a.png)
[recommended]: https://github.com/rust-lang/rust/issues/51430#issuecomment-398322434
|
|
Implement indexing slices with pairs of core::ops::Bound<usize>
Closes #49976.
I am not sure about code duplication between `check_range` and `into_maybe_range`. Should be former implemented in terms of the latter? Also this PR doesn't address code duplication between `impl SliceIndex for Range*`.
|
|
Remove `delete` alias from `mem::drop`.
See https://github.com/rust-lang/rust/pull/81988#issuecomment-824168459 and https://github.com/rust-lang/rust/pull/81988#issuecomment-824213843
|
|
m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose, r=kennytm
Format `Struct { .. }` on one line even with `{:#?}`.
The result of `debug_struct("A").finish_non_exhaustive()` before this change:
```
A {
..
}
```
And after this change:
```
A { .. }
```
If there's any fields, the result stays unchanged:
```
A {
field: value,
..
}
|
|
Document that `index` and `index_mut` can panic
I thought this was noteworthy and I think a bit more explicitness does no harm.
|
|
fix 'const-stable since' for NonZeroU*::new_unchecked
For the unsigned `NonZero` types, `new_unchecked` was const-stable from the start with https://github.com/rust-lang/rust/pull/50808. Fix the docs to accurately reflect that.
I think this `since` is also incorrect:
```rust
#[stable(feature = "from_nonzero", since = "1.31.0")]
impl From<$Ty> for $Int {
```
The signed nonzero types were only stabilized in 1.34, so that `From` impl certainly didn't exist before. But I had enough of digging through git histories after I figured out when `new_unchecked` became const-stable...^^
|
|
Replace all `fmt.pad` with `debug_struct`
This replaces any occurrence of:
- `f.pad("X")` with `f.debug_struct("X").finish()`
- `f.pad("X { .. }")` with `f.debug_struct("X").finish_non_exhaustive()`
This is in line with existing formatting code such as
https://github.com/rust-lang/rust/blob/125505306744a0a5bb01d62337260a95d9ff8d57/library/std/src/sync/mpsc/mod.rs#L1470-L1475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
