Commit Graph

1756 Commits

Author SHA1 Message Date
Iago-lito
7e0b9a8bd0 NonZero saturating_mul. 2021-06-09 17:28:33 +02:00
Iago-lito
ac3eb90d59 NonZero checked_mul. 2021-06-09 17:28:33 +02:00
Iago-lito
7e7b316163 NonZero unsigned_abs. 2021-06-09 17:28:33 +02:00
Iago-lito
b6589bbfa9 NonZero wrapping_abs. 2021-06-09 17:28:32 +02:00
Iago-lito
65e7321457 NonZero saturating_abs. 2021-06-09 17:28:32 +02:00
Iago-lito
6083b0ad2a NonZero overflowing_abs. 2021-06-09 17:28:32 +02:00
Iago-lito
62f97d950f NonZero checked_abs. 2021-06-09 17:28:31 +02:00
Iago-lito
a433b06347 NonZero abs. 2021-06-09 17:28:31 +02:00
Iago-lito
f7a1a9d075 NonZero checked_next_power_of_two. 2021-06-09 17:28:31 +02:00
Iago-lito
a3e1c358b6 NonZero unchecked_add. 2021-06-09 17:28:31 +02:00
Iago-lito
a67d605496 NonZero saturating_add. 2021-06-09 17:28:30 +02:00
Iago-lito
832c7f5061 NonZero checked_add. 2021-06-09 17:28:30 +02:00
bors
38bc9b9933 Auto merge of #85975 - the8472:revert-take-tra, r=scottmcm
Revert "implement TrustedRandomAccess for Take iterator adapter"

This reverts commit 37a5b515e9 (#83990).

The original change unintentionally caused side-effects from certain iterator chains combining `take`, `zip` and `next_back()` to be omitted which is observable by user code and thus likely a breaking change

Technically one could declare it not a breaking change since `Zip`'s API contract is silent about about its backwards iteration behavior but on the other hand there is nothing in the stable Iterator API that could justify the currently observable behavior. And either way, this impact wasn't noticed or discussed in the original PR.

Fixes #85969
2021-06-09 11:24:54 +00:00
Yuki Okushi
a416e05d27
Rollup merge of #86101 - glittershark:bound-as-mut-doc-fix, r=m-ou-se
Correct type signature in doc for Bound::as_mut

Thanks to ``@drmason13`` for pointing this out!
2021-06-08 13:26:37 +09:00
Yuki Okushi
2a23af6341
Rollup merge of #85985 - Lionelf329:master, r=joshtriplett
Clarify documentation of slice sorting methods

After reading about [this](https://polkadot.network/a-polkadot-postmortem-24-05-2021/), I realized that although the documentation of these methods is not ambiguous in its current state, it is very easy to read it and erroneously assume that their exact behaviour can be relied upon to be deterministic. Although the docs make no guarantees about which index is returned when there are multiple matches, being more explicit about when and how their determinism can be relied upon should help prevent people from making this mistake in the future.

r? ``@steveklabnik``
2021-06-08 13:26:29 +09:00
Lionel Foxcroft
fddf012177 Clarify documentation of slice sorting methods 2021-06-07 16:50:08 -04:00
Griffin Smith
5aa188ac5d Correct type signature in doc for Bound::as_mut 2021-06-07 11:00:59 -04:00
Yuki Okushi
f923f73b9a
Rollup merge of #85930 - mominul:array_into_iter, r=m-ou-se
Update standard library for IntoIterator implementation of arrays

This PR partially resolves issue #84513 of updating the standard library part.

I haven't found any remaining doctest examples which are using iterators over e.g. &i32 instead of just i32 in the standard library. Can anyone point me to them if there's remaining any?

Thanks!

r? ```@m-ou-se```
2021-06-06 19:11:19 +09:00
Guillaume Gomez
1594076748
Rollup merge of #83646 - glittershark:bound-map, r=m-ou-se
Add a map method to Bound

Add a map method to std::ops::range::Bound, patterned off of the method
of the same name on Option.

Have left off creating a tracking issue initially, but as soon as I get the go-ahead from a reviewer I'll make that right away 😄
2021-06-05 19:41:34 +02:00
Griffin Smith
223c0d2a85 Add a map method to Bound
Add a map method to std::ops::range::Bound, patterned off of the method
of the same name on Option
2021-06-05 17:22:30 +02:00
bors
2c106885d5 Auto merge of #85457 - jyn514:remove-doc-include, r=GuillaumeGomez
Remove `doc(include)`

This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539, but technically it was for deprecating, not removing the feature altogether.

This should not be merged before #83366.

cc `@petrochenkov`
2021-06-05 03:36:26 +00:00
Joshua Nelson
7411a9e7cc rustdoc: link to stable/beta docs consistently in documentation
## User-facing changes

- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.

Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.

 ## Implementation changes

- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel

  This avoids linking to nightly docs on stable.

- Update rustdoc to use channel-dependent links for primitives from an
  unknown crate

- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
2021-06-04 14:18:21 -04:00
Joshua Nelson
15fec1fb80 Remove doc(include) 2021-06-04 08:05:54 -04:00
Yuki Okushi
0a12431962
Rollup merge of #85963 - m-ou-se:constructor-type-name, r=yaahc
Show `::{{constructor}}` in std::any::type_name().

Fix #84666

Before:
```
[src/main.rs:6] type_name::<T>() = "playground::Velocity"
[src/main.rs:6] type_name::<T>() = "playground::Velocity"
```

After:
```
[src/main.rs:6] type_name::<T>() = "scratchpad::Velocity::{{constructor}}"
[src/main.rs:6] type_name::<T>() = "scratchpad::Velocity"
```

cc ``@scottmcm``
2021-06-04 13:43:02 +09:00
Yuki Okushi
f6aaf05363
Rollup merge of #85888 - steffahn:fix_internal_trustedrandomaccess_docs, r=Mark-Simulacrum
Fix typo in internal documentation for `TrustedRandomAccess`

`next_back` is a method of DoubleEndedIterator, not Iterator.
2021-06-04 13:42:55 +09:00
The8472
dbc43ece10 Revert "implement TrustedRandomAccess for Take iterator adapter"
This reverts commit 37a5b515e9.
2021-06-03 21:47:59 +02:00
Mara Bos
e3b19e5c25 Add test for issue 84666. 2021-06-03 16:13:45 +02:00
Yuki Okushi
bd18686b5f
Rollup merge of #85877 - est31:intra_doc_links, r=jyn514
Intra doc link-ify a reference to a function
2021-06-03 14:35:34 +09:00
Muhammad Mominul Huque
507d97b26e Update expressions where we can use array's IntoIterator implementation 2021-06-02 16:09:04 +06:00
Muhammad Mominul Huque
01d4d46f66 Replace IntoIter::new with IntoIterator::into_iter in std 2021-06-02 16:09:04 +06:00
bors
c4f186f0ea Auto merge of #85687 - m-ou-se:new-prelude, r=yaahc
New prelude

RFC: rust-lang/rfcs#3114
Tracking issue: https://github.com/rust-lang/rust/issues/85684
2021-06-02 02:36:44 +00:00
Frank Steffahn
c5233b7d4b Fix typo in internal documentation for TrustedRandomAccess
`next_back` is a method of DoubleEndedIterator, not Iterator.
2021-06-01 13:18:20 +02:00
Guillaume Gomez
f4d3f32f45
Rollup merge of #85826 - jsha:npo, r=joshtriplett
Mention "null pointer optimization" in option docs.

I had seen people discuss "null pointer optimization," but when I tried to find official documentation (using Google), the `std::option` page didn't show up, because it doesn't use that term. Hopefully adding the term will help others find it in the future.
2021-06-01 11:29:44 +02:00
est31
a0228d9b87 Intra doc link-ify a reference to a function 2021-06-01 05:04:48 +02:00
bors
bff138dbd9 Auto merge of #85754 - the8472:revert-83770, r=Mark-Simulacrum
Revert "Auto merge of #83770 - the8472:tra-extend, r=Mark-Simulacrum"

Due to a performance regression that didn't show up in the original perf run
this reverts commit 9111b8ae97 (#83770), reversing
changes made to 9a700d2947.

Since since is expected to have the inverse impact it should probably be rollup=never.

r? `@Mark-Simulacrum`
2021-05-30 04:12:44 +00:00
bors
9a72afa7dd Auto merge of #83772 - jhpratt:revamp-step-trait, r=Mark-Simulacrum
Make `Step` trait safe to implement

This PR makes a few modifications to the `Step` trait that I believe better position it for stabilization in the short term. In particular,

1. `unsafe trait TrustedStep` is introduced, indicating that the implementation of `Step` for a given type upholds all stated invariants (which have remained unchanged). This is gated behind a new `trusted_step` feature, as stabilization is realistically blocked on min_specialization.
2. The `Step` trait is internally specialized on the `TrustedStep` trait, which avoids a serious performance regression.
3. `TrustedLen` is implemented for `T: TrustedStep` as the latter's invariants subsume the former's.
4. The `Step` trait is no longer `unsafe`, as the invariants must not be relied upon by unsafe code (unless the type implements `TrustedStep`).
5. `TrustedStep` is implemented for all types that implement `Step` in the standard library and compiler.
6. The `step_trait_ext` feature is merged into the `step_trait` feature. I was unable to find any reasoning for the features being split; the `_unchecked` methods need not necessarily be stabilized at the same time, but I think it is useful to have them under the same feature flag.

All existing implementations of `Step` will be broken, as it is not possible to `unsafe impl` a safe trait. Given this trait only exists on nightly, I feel this breakage is acceptable. The blanket `impl<T: Step> TrustedLen for T` will likely cause some minor breakage, but this should be covered by the equivalent impl for `TrustedStep`.

Hopefully these changes are sufficient to place `Step` in decent position for stabilization, which would allow user-defined types to be used with `a..b` syntax.
2021-05-30 01:21:39 +00:00
Jacob Hoffman-Andrews
79575a1a8e Mention "null pointer optimization" in option docs. 2021-05-29 09:57:12 -07:00
ltdk
2a40f2423a Add inherent unchecked_shl, unchecked_shr to integers 2021-05-28 22:54:39 -04:00
Guillaume Gomez
e30192ac5c
Rollup merge of #85730 - Smittyvb:iter-min-max-floats, r=m-ou-se
Mention workaround for floats in Iterator::{min, max}

`Iterator::{min, max}` can't be used with iterators of floats due to NaN issues. This suggests a workaround in the documentation of those functions.
2021-05-27 20:08:21 +02:00
The8472
f72c60a39a Revert "Auto merge of #83770 - the8472:tra-extend, r=Mark-Simulacrum"
Due to a performance regression that didn't show up in the original perf run
this reverts commit 9111b8ae97, reversing
changes made to 9a700d2947.
2021-05-27 18:17:09 +02:00
Dylan DPC
de1d7dbd0f
Rollup merge of #85689 - m-ou-se:array-intoiter-3, r=estebank
Remove Iterator #[rustc_on_unimplemented]s that no longer apply.

Now that `IntoIterator` is implemented for arrays, all the `rustc_on_unimplemented` for arrays of ranges (e.g. `for _ in [1..3] {}`) no longer apply, since they are now valid Rust.

Separated these from #85670, because we should discuss a potential new (clippy?) lint for these.

Until Rust 1.52, `for _ in [1..3] {}` produced:

```
error[E0277]: `[std::ops::Range<{integer}>; 1]` is not an iterator
 --> src/main.rs:2:14
  |
2 |     for _ in [1..3] {}
  |              ^^^^^^ if you meant to iterate between two values, remove the square brackets
  |
  = help: the trait `std::iter::Iterator` is not implemented for `[std::ops::Range<{integer}>; 1]`
  = note: `[start..end]` is an array of one `Range`; you might have meant to have a `Range` without the brackets: `start..end`
  = note: required by `std::iter::IntoIterator::into_iter`
```

But in Rust 1.53 and later, it compiles fine. It iterates over the array by value, for one iteration with the element `1..3`.

This is probably a mistake, which is no longer caught. Should we have a lint for it? Should Clippy have a lint for it?

cc ```@estebank``` ```@flip1995```

cc https://github.com/rust-lang/rust/issues/84513
2021-05-27 03:02:10 +02:00
Smittyvb
b00f6fc8a1
don't use unneeded closure
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
2021-05-26 20:38:50 -04:00
Smittyvb
7146a05a43
don't use unneeded closure
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
2021-05-26 20:38:43 -04:00
Jacob Pratt
35ce36812a
Unify feature flags as step_trait
While stdlib implementations of the unchecked methods require unchecked
math, there is no reason to gate it behind this for external users. The
reasoning for a separate `step_trait_ext` feature is unclear, and as
such has been merged as well.
2021-05-26 18:07:10 -04:00
Jacob Pratt
bc2f0fb5a9
Specialize implementations
Implementations in stdlib are now optimized as they were before.
2021-05-26 18:07:09 -04:00
Smitty
e7a3ada210 Mention float workaround in Iterator::{min,max} 2021-05-26 17:15:54 -04:00
bors
9111b8ae97 Auto merge of #83770 - the8472:tra-extend, r=Mark-Simulacrum
Add `TrustedRandomAccess` specialization for `Vec::extend()`

This should do roughly the same as the `TrustedLen` specialization but result in less IR by using `__iterator_get_unchecked`
instead of `Iterator::for_each`

Conflicting specializations are manually prioritized by grouping them under yet another helper trait.
2021-05-26 19:22:31 +00:00
Dylan DPC
9ee87c7e00
Rollup merge of #85712 - BlackHoleFox:fix-iter-typo, r=jyn514
Fix typo in core::array::IntoIter comment

Saw a small typo reading some internal comments and decided to just throw this up to fix it for future readers.
2021-05-26 13:32:12 +02:00
Dylan DPC
f3b10dd709
Rollup merge of #85679 - hch12907:master, r=Mark-Simulacrum
Remove num_as_ne_bytes feature

From the discussion in #76976, it is determined that eventual results of the safe transmute work as a more general mechanism will let these conversions happen in safe code without needing specialized methods.

Merging this PR closes #76976 and resolves #64464. Several T-libs members have raised their opinion that it doesn't pull its weight as a standalone method, and so we should not track it as a specific thing to add.
2021-05-26 13:32:11 +02:00
Dylan DPC
3c2a709620
Rollup merge of #85678 - lukas-code:matches2021, r=dtolnay
fix `matches!` and `assert_matches!` on edition 2021

Previously this code failed to compile on edition 2021. [(Playground)](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=53960f2f051f641777b9e458da747707)
```rust
fn main() {
    matches!((), ());
}
```
```
   Compiling playground v0.0.1 (/playground)
error: `$pattern:pat` may be followed by `|`, which is not allowed for `pat` fragments
    |
    = note: allowed there are: `=>`, `,`, `=`, `if` or `in`

error: aborting due to previous error

error: could not compile `playground`

To learn more, run the command again with --verbose.
```
2021-05-26 13:32:10 +02:00