Commit Graph

2093 Commits

Author SHA1 Message Date
sharnoff
12d199be77
Add missing "allocated object" doc link 2021-08-01 19:48:26 -07:00
bors
effea9a2a0 Auto merge of #87689 - JohnTitor:rollup-ns38b56, r=JohnTitor
Rollup of 13 pull requests

Successful merges:

 - #86183 (Change environment variable getters to error recoverably)
 - #86439 (Remove `Ipv4Addr::is_ietf_protocol_assignment`)
 - #86509 (Move `os_str_bytes` to `sys::unix`)
 - #86593 (Partially stabilize `const_slice_first_last`)
 - #86936 (Add documentation for `Ipv6MulticastScope`)
 - #87282 (Ensure `./x.py dist` adheres to `build.tools`)
 - #87468 (Update rustfmt)
 - #87504 (Update mdbook.)
 - #87608 (Remove unused field `Session.system_library_path`)
 - #87629 (Consistent spelling of "adapter" in the standard library)
 - #87633 (Update compiler_builtins to fix i128 shift/mul on thumbv6m)
 - #87644 (Recommend `swap_remove` in `Vec::remove` docs)
 - #87653 (mark a UB doctest as no_run)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-08-02 02:33:16 +00:00
Yuki Okushi
0851841970
Rollup merge of #87653 - RalfJung:dont-run-ub, r=kennytm
mark a UB doctest as no_run

See https://github.com/rust-lang/rust/pull/87547#discussion_r680334117
Cc `@GuillaumeGomez` `@kennytm`
2021-08-02 11:03:31 +09:00
Yuki Okushi
87c143661c
Rollup merge of #87629 - steffahn:consistent_adapter_spelling, r=m-ou-se
Consistent spelling of "adapter" in the standard library

Change all occurrences of "(A|a)daptor" to "(A|a)dapter".

The spelling “adapter” seems to be significantly more common both in general in the English language and also in the `rust` repository and standard library. I don’t like the inconsistency that’s currently found on pages like https://doc.rust-lang.org/std/iter/trait.Iterator.html. Note however that the Rust book consistently uses the spelling “iterator adaptor”.

Related discussion [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/adapter.20.2F.20adaptor) ([in the archive](https://zulip-archive.rust-lang.org/219381tlibs/60284adapteradaptor.html)).

`@rustbot` label T-libs
2021-08-02 11:03:28 +09:00
Yuki Okushi
77d568344f
Rollup merge of #86593 - jhpratt:stabilize-const_slice_first_last, r=m-ou-se
Partially stabilize `const_slice_first_last`

This stabilizes the non-`mut` methods of `const_slice_first_last` as `const`. These methods are trivial to implement and have no blockers that I am aware of.

`@rustbot` label +A-const-fn +S-waiting-on-review +T-libs-api
2021-08-02 11:03:21 +09:00
bors
24bbf7ac2f Auto merge of #85272 - ChayimFriedman2:matches-leading-pipe, r=m-ou-se
Allow leading pipe in `matches!()` patterns.

This is allowed in `match` statement, and stated in https://internals.rust-lang.org/t/leading-pipe-in-core-matches/14699/2 that it should be allowed in these macros too.
2021-08-02 00:13:40 +00:00
Mara Bos
9854d30543 Update const_slice_first_last_not_mut stable version. 2021-08-01 17:25:19 +02:00
Pietro Albini
24f9de5a44 bump bootstrap compiler to 1.55 2021-08-01 11:19:24 -04:00
Anton Golov
40eaab17de Add documentation for the order of Option and Result 2021-08-01 13:59:19 +02:00
bors
f381e77d35 Auto merge of #84662 - dtolnay:unwindsafe, r=Amanieu
Move UnwindSafe, RefUnwindSafe, AssertUnwindSafe to core

They were previously only available in std::panic, not core::panic.

- https://doc.rust-lang.org/1.51.0/std/panic/trait.UnwindSafe.html
- https://doc.rust-lang.org/1.51.0/std/panic/trait.RefUnwindSafe.html
- https://doc.rust-lang.org/1.51.0/std/panic/struct.AssertUnwindSafe.html

Where this is relevant: trait objects! Inside a `#![no_std]` library it's otherwise impossible to have a struct holding a trait object, and at the same time can be used from downstream std crates in a way that doesn't interfere with catch_unwind.

```rust
// common library

#![no_std]

pub struct Thing {
    pub(crate) x: &'static (dyn SomeTrait + Send + Sync),
}

pub(crate) trait SomeTrait {...}
```

```rust
// downstream application

fn main() {
    let thing: library::Thing = ...;
    let _ = std::panic::catch_unwind(|| { let _ = thing; });  // does not work :(
}
```

See a4131708e2/src/gradient.rs (L7-L15) for a real life example of needing to work around this problem. In particular that workaround would not even be viable if implementors of the trait were provided externally by a caller, as the `feature = "std"` would become non-additive in that case.

What happens without the UnwindSafe constraints:

```rust
fn main() {
    let gradient = colorous::VIRIDIS;
    let _ = std::panic::catch_unwind(|| { let _ = gradient; });
}
```

```console
error[E0277]: the type `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
   --> src/main.rs:3:13
    |
3   |     let _ = std::panic::catch_unwind(|| { let _ = gradient; });
    |             ^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
    |
   ::: .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:430:40
    |
430 | pub fn catch_unwind<F: FnOnce() -> R + UnwindSafe, R>(f: F) -> Result<R> {
    |                                        ---------- required by this bound in `catch_unwind`
    |
    = help: within `Gradient`, the trait `RefUnwindSafe` is not implemented for `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
    = note: required because it appears within the type `&'static (dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
    = note: required because it appears within the type `Gradient`
    = note: required because of the requirements on the impl of `UnwindSafe` for `&Gradient`
    = note: required because it appears within the type `[closure@src/main.rs:3:38: 3:62]`
```
2021-08-01 02:53:13 +00:00
David Tolnay
d1586fc6bb
Fix unused sync::atomic import on targets without atomics 2021-07-31 17:27:29 -07:00
Ralf Jung
6aaa8327f9 mark a UB doctest as no_run 2021-07-31 11:37:48 +02:00
bors
6b0b07d41f Auto merge of #87387 - the8472:slice-iter-advance_by, r=scottmcm
Implement advance_by, advance_back_by for slice::{Iter, IterMut}

Part of #77404.

Picking up where #77633 was closed.

I have addressed https://github.com/rust-lang/rust/pull/77633#issuecomment-771842599 by restoring `nth` and `nth_back`. So according to that comment this should already be r=m-ou-se, but it has been sitting for a while.
2021-07-31 05:22:13 +00:00
Yuki Okushi
f4dfb76ea1
Rollup merge of #87609 - LukasKalbertodt:improve-array-map-docs, r=m-ou-se
Add docs about performance and `Iterator::map` to `[T; N]::map`

This suboptimal code gen for some usages of array::map got a bit of
attention by multiple people throughout the community. Some cases:

- https://github.com/rust-lang/rust/issues/75243#issuecomment-866051086
- https://github.com/rust-lang/rust/issues/75243#issuecomment-874732134
- https://www.reddit.com/r/rust/comments/oeqqf7/unexpected_high_stack_usage/

My *guess* is that this gets the attention it gets because in JavaScript
(and potentially other languages), a `map` function on arrays is very
commonly used since in those languages, arrays basically take the role
of Rust's iterator. I considered explicitly naming JavaScript in the
first paragraph I added, but I couldn't find precedence of mentioning
other languages in standard library doc, so I didn't add it.

When array::map was stabilized, we still wanted to add docs, but that
somehow did not happen in time. So here we are. Not sure if this sounds
crazy but maybe it is worth considering beta backporting this? Only if
it's not a lot of work, of course! But yeah, stabilized array::map is
already in beta and if this problem is really as big as it sometimes seems,
might be worth having the docs in place when 1.55 is released.

CC ``@CryZe``

r? ``@m-ou-se`` (since you were involved in that discussion and the stabilization)
2021-07-31 04:09:33 +09:00
Yuki Okushi
f7a2a22815
Rollup merge of #87547 - GuillaumeGomez:nonnull-examples, r=kennytm
Add missing examples for NonNull
2021-07-31 04:09:26 +09:00
David Tolnay
60fa568c31
Fix some broken rustdoc links in core::panic documentation 2021-07-30 10:42:20 -07:00
David Tolnay
6d988dc1e3
Fix undocumented unsafe in AssertUnwindSafe impls 2021-07-30 10:42:18 -07:00
David Tolnay
4e17994b2c
Move UnwindSafe, RefUnwindSafe, AssertUnwindSafe to core 2021-07-30 10:42:15 -07:00
David Tolnay
76e73b74a6
Fix separation of public vs internal parts of Location 2021-07-30 10:40:02 -07:00
David Tolnay
d7c82ba4a1
Split core::panic module to subdirectory 2021-07-30 10:39:56 -07:00
Frank Steffahn
8d2bb9389a Consistent spelling of "adapter" in the standard library
Change all occurrences of "(A|a)daptor" to "(A|a)dapter".
2021-07-30 17:23:07 +02:00
Guillaume Gomez
1bbe6188d2 Add missing examples for NonNull 2021-07-30 11:30:34 +02:00
Yuki Okushi
6e61383b66
Rollup merge of #87585 - GuillaumeGomez:char-types-doc, r=joshtriplett
Add missing links for core::char types
2021-07-30 16:26:59 +09:00
Yuki Okushi
fd79e7740b
Rollup merge of #87522 - frogtd:patch-1, r=yaahc
Fix assert in diy_float

The shifting should have gone the other way, the current incarnation is always true.
2021-07-30 16:26:53 +09:00
Yuki Okushi
c25b979db6
Rollup merge of #87052 - phlopsi:patch-1, r=jyn514
Optimize fmt::PadAdapter::wrap

After adding the first `write!` usage to my project and printing the result to the console, I noticed, that my binary contains the strings "called `Option::unwrap()` on a `None` value`" and more importantly "C:\Users\Patrick Fischer\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\fmt\builders.rs", with my release build being configured as follows:
```
[profile.release]
panic = "abort"
codegen-units = 1
strip = "symbols" # the important bit
lto = true
```
I am in a no_std environment and my custom panic handler is a simple `loop {}`. I did not expect the above information to be preserved. I heavily suspect the edited function to be the culprit. It contains the only direct use of `Option::unwrap` in the entire file and I tracked the symbols in the assembly to be used from the section `_ZN68_$LT$core..fmt..builders..PadAdapter$u20$as$u20$core..fmt..Write$GT$9write_str17ha1d5e5efe167202aE`.

Aside from me suspecting this function to be the culprit, the replaced code performs the same operation as `Option::insert`, but without the `unreachable_unchecked` optimization `Option::insert` provides. Therefore, it makes sense to me to use the more optimized version, instead.

As I don't change any semantics, I hope a simple pull request suffices.
2021-07-30 16:26:52 +09:00
bors
fe1c942eee Auto merge of #87445 - amalik18:issue-83584-fix, r=kennytm
Fix may not to appropriate might not or must not

I went through and changed occurrences of `may not` to be more explicit with `might not` and `must not`.
2021-07-30 04:34:13 +00:00
Lukas Kalbertodt
5cc7702bde
Add docs about performance and Iterator::map to [T; N]::map 2021-07-30 00:08:48 +02:00
Jade
3cf820e17d rfc3052: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
2021-07-29 14:56:05 -07:00
Guillaume Gomez
cf0f5021f4 Add missing links for core::char types 2021-07-29 14:13:41 +02:00
bors
5fb3394cbd Auto merge of #86664 - m-ou-se:uninit-track-caller, r=JohnTitor
Add #[track_caller] for some function in core::mem.

These functions can panic for some types. This makes the panic point to the code that calls e.g. mem::uninitialized(), instead of inside the definition of mem::uninitialized.
2021-07-29 09:35:23 +00:00
bors
6e0a8bf790 Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str, r=oli-obk
Make const panic!("..") work in Rust 2021.

During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead.

panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.

r? `@RalfJung`
2021-07-29 07:12:07 +00:00
Ali Malik
ffcf8a0d76 Fix may not to appropriate might not or must not 2021-07-29 01:16:53 -04:00
Ali Malik
e43254aad1 Fix may not to appropriate might not or must not 2021-07-29 01:15:20 -04:00
bors
85237886df Auto merge of #85874 - steffahn:fix_unsound_zip_optimization, r=yaahc
Remove unsound TrustedRandomAccess implementations

Removes the implementations that depend on the user-definable trait `Copy`.

Fixes #85873 in the most straightforward way.

<hr>

_Edit:_ This PR now contains additional trait infrastructure to avoid performance regressions around in-place collect, see the discussion in this thread starting from the codegen test failure at https://github.com/rust-lang/rust/pull/85874#issuecomment-872327577.

With this PR, `TrustedRandomAccess` gains additional documentation that specifically allows for and specifies the safety conditions around subtype coercions – those coercions can happen in safe Rust code with the `Zip` API’s usage of `TrustedRandomAccess`. This PR introduces a new supertrait of `TrustedRandomAccess`(currently named `TrustedRandomAccessNoCoerce`) that _doesn’t allow_ such coercions, which means it can be still be useful for optimizing cases such as in-place collect where no iterator is handed out to a user (who could do coercions) after a `get_unchecked` call; the benefit of the supertrait is that it doesn’t come with the additional safety conditions around supertraits either, so it can be implemented for more types than `TrustedRandomAccess`.

The `TrustedRandomAccess` implementations for `vec::IntoIter`, `vec_deque::IntoIter`, and `array::IntoIter` are removed as they don’t conform with the newly documented safety conditions, this way unsoundness is removed. But this PR in turn (re-)adds a `TrustedRandomAccessNoCoerce` implementation for `vec::IntoIter` to avoid performance regressions from stable in a case of in-place collecting of `Vec`s [the above-mentioned codegen test failure]. Re-introducing the (currently nightly+beta-only) impls for `VecDeque`’s and `[T; N]`’s iterators is technically possible, but goes beyond the scope of this PR (i.e. it can happen in a future PR).
2021-07-29 00:31:07 +00:00
Yuki Okushi
6c4888a74e
Rollup merge of #87565 - ibraheemdev:patch-7, r=scottmcm
Use backticks when referring to `core::future::Ready` in panic message
2021-07-29 06:11:50 +09:00
Yuki Okushi
7c1283a068
Rollup merge of #81363 - jonhoo:no-unpin-in-pin-future-impl, r=m-ou-se
Remove P: Unpin bound on impl Future for Pin

We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly.

The `Unpin` bound was originally added in #56939 following the recommendation of ``@withoutboats`` in https://github.com/rust-lang/rust/issues/55766#issue-378417538

That comment does not give explicit justification for why the bound should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
2021-07-29 06:11:42 +09:00
Yuki Okushi
fef1725c0f
Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready, r=m-ou-se
Stabilize core::task::ready!

_Tracking issue: https://github.com/rust-lang/rust/issues/70922_

This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886, this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed.

The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library.

r? ``@tmandry``

cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs``

## Example
```rust
use core::task::{Context, Poll};
use core::future::Future;
use core::pin::Pin;

async fn get_num() -> usize {
    42
}

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut f = get_num();
    let f = unsafe { Pin::new_unchecked(&mut f) };

    let num = ready!(f.poll(cx));
    // ... use num

    Poll::Ready(())
}
```
2021-07-29 06:11:41 +09:00
Ibraheem Ahmed
2d8b6e3476
Use backticks when referring to core::future::Ready in panic message 2021-07-28 16:22:34 -04:00
Mara Bos
18cc06c848 Update stable version of ready!() macro. 2021-07-28 16:56:12 +02:00
Mara Bos
312bf8e0b8 Extend documentation of const_format_args!(). 2021-07-28 16:18:38 +02:00
Mara Bos
0b8033ad8d Improve comments about const panic handling
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-07-28 16:18:38 +02:00
Mara Bos
38bf5b0412 Make const_fmt_args!() work during bootstrap. 2021-07-28 16:12:31 +02:00
Mara Bos
b48274fd98 Use unreachable_unchecked in const_panic_fmt. 2021-07-28 16:12:30 +02:00
Mara Bos
b64c4f9560 Add new const_format_args!() macro and use it in panics. 2021-07-28 16:12:25 +02:00
Mara Bos
f827d3e285 Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and
std::panicking::being_panic_fmt with a call to a new const fn:
core::panicking::const_panic_fmt. That function uses
fmt::Arguments::as_str() to get the str and calls panic_str with that
instead.

panic!() invocations with formatting arguments are still not accepted,
as the creation of such a fmt::Arguments cannot be done in constant
functions right now.
2021-07-28 16:10:41 +02:00
Mara Bos
3f6dc9a8ab Add #[track_caller] for some function in core::mem.
These functions can panic for some types. This makes the panic point to
the code that calls e.g. mem::uninitialized(), instead of inside the
definition of mem::uninitialized.
2021-07-28 14:34:36 +02:00
Frank Steffahn
6d9c0a16d9 Documentation improvements 2021-07-28 14:33:37 +02:00
Frank Steffahn
89583e98e8 Make SpecInPlaceCollect use TrustedRandomAccessNoCoerce 2021-07-28 14:33:36 +02:00
Frank Steffahn
bbc6b2691e Change __iterator_get_unchecked to work with TrustedRandomAccessNoCoerce 2021-07-28 14:33:35 +02:00
Frank Steffahn
69dd992f95 Add TrustedRandomAccessNoCoerce supertrait without requirements or guarantees about subtype coercions
Update all the TrustedRandomAccess impls to also implement the new supertrait
2021-07-28 14:33:35 +02:00
Frank Steffahn
1c7f27f792 Improve documentation of TrustedRandomAccess
Include new details regarding coercions to a subtype.
These conditions also explain why the previously removed implementations
for {array, vec, vec_deque}::IntoIter<T> were unsound, because they introduced
an extra `T: Clone` for the TrustedRandomAccess impl, even though their parameter T
is covariant.
2021-07-28 14:33:35 +02:00
Yuki Okushi
4ae529688a
Rollup merge of #87523 - frogtd:patch-2, r=dtolnay
Stop creating a reference then immediately dereferencing it.

Stop creating a reference then immediately dereferencing it.
2021-07-28 18:28:22 +09:00
Yuki Okushi
35dddd3dea
Rollup merge of #87500 - Smittyvb:min-max-docs, r=kennytm
Document math behind MIN/MAX consts on integers

Currently the documentation for `[integer]::{MIN, MAX}` doesn't explain where the constants come from. This documents how the values of those constants are related to powers of 2.
2021-07-28 18:28:18 +09:00
bors
aea2e446f0 Auto merge of #86735 - jhpratt:rfc-3107, r=petrochenkov
Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute

This PR implements RFC 3107, which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.
2021-07-28 05:59:30 +00:00
Smitty
0e017496eb remove unneeded stringify 2021-07-27 16:37:18 -04:00
frogtd
47414aa1bd
Update range.rs
Stop creating a reference then immediately dereferencing it.
2021-07-27 16:14:48 -04:00
Jacob Pratt
7bf791d162
Stabilize const_fn_union 2021-07-27 16:03:33 -04:00
Jacob Pratt
36f02f3523
Stabilize const_fn_transmute 2021-07-27 16:03:09 -04:00
frogtd
b8eb1f167c
Fix assert in diy_float
The shifting should have gone the other way, the current incarnation is always true.
2021-07-27 16:02:35 -04:00
Jacob Pratt
c70147fd66
Permit deriving default on enums with #[default] 2021-07-27 15:47:47 -04:00
bors
3bc9dd0dd2 Auto merge of #87509 - JohnTitor:rollup-8iqn6cl, r=JohnTitor
Rollup of 10 pull requests

Successful merges:

 - #86450 (Add flag to configure `large_assignments` lint)
 - #86764 (Avoid ICE on type error recovery)
 - #87354 (Update VxWork's UNIX support)
 - #87427 (get rid of NoMirFor error variant)
 - #87446 (macos current_exe using directly libc instead.)
 - #87494 (fix typo: whenver -> whenever)
 - #87497 (Add long explanation for E0544.)
 - #87499 (Remove ASCII fast path from `rustc_lexer::{is_id_continue, is_id_start}`)
 - #87502 (Update cargo)
 - #87503 (Update books)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-07-27 13:31:40 +00:00
Yuki Okushi
7282d71dc2
Rollup merge of #87494 - midgleyc:comment-typos, r=joshtriplett
fix typo: whenver -> whenever

Fix a typo in a comment in RefCell: "whenver" -> "whenever".
2021-07-27 19:52:48 +09:00
bors
99d6692f6c Auto merge of #87431 - the8472:array-iter-fold, r=kennytm
implement fold() on array::IntoIter to improve flatten().collect() perf

With #87168 flattening `array::IntoIter`s is now `TrustedLen`, the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features.

This should address the main issue in #87411

```
# old
test vec::bench_flat_map_collect                         ... bench:   2,244,024 ns/iter (+/- 18,903)

# new
test vec::bench_flat_map_collect                         ... bench:     172,863 ns/iter (+/- 2,141)
```
2021-07-27 10:38:41 +00:00
bors
c51607e031 Auto merge of #87062 - poliorcetics:fix-85462, r=dtolnay
Make StrSearcher behave correctly on empty needle

Fix #85462.

This will not affect ABI since the other variant of the enum is bigger.
It may break some code, but that would be very strange: usually people
don't continue after the first `Done` (or `None` for a normal iterator).

`@rustbot` label T-libs A-str A-patterns
2021-07-27 00:31:20 +00:00
Smitty
7abbc6e3c5 Document math behind MIN/MAX consts on integers 2021-07-26 20:22:44 -04:00
The8472
2276c5e3d7 from review: add a comment why try_fold was chosen instead of fold 2021-07-27 00:14:19 +02:00
Chris Midgley
cccd4e2a27 fix typo: whenver -> whenever 2021-07-26 22:12:35 +01:00
ibraheemdev
3171bd5bf5 ignore comments in tidy-filelength 2021-07-25 17:10:51 -04:00
The8472
e015e9da71 implement fold() on array::IntoIter to improve flatten().collect() perf
```
# old
test vec::bench_flat_map_collect                         ... bench:   2,244,024 ns/iter (+/- 18,903)

# new
test vec::bench_flat_map_collect                         ... bench:     172,863 ns/iter (+/- 2,141)
```
2021-07-24 19:24:11 +02:00
Manish Goregaokar
acfa3ac405
Rollup merge of #87422 - mgeier:doc-strip-feature-attribute, r=LeSeulArtichaut
DOC: remove unnecessary feature crate attribute from example code

I'm not sure whether I fully understand the stabilization process (I most likely don't), but I think this attribute isn't necessary here, right?

This was recently stabilized in #86344.
2021-07-24 09:52:04 -07:00
Manish Goregaokar
e932113c7e
Rollup merge of #87410 - jonas-schievink:doc-hidden-format_args_nl, r=nagisa
Mark `format_args_nl` as `#[doc(hidden)]`

It's described as being internal-only and has no tracking issue, so hide it from public docs.
2021-07-24 09:52:02 -07:00
Matthias Geier
7879a59ac7 DOC: remove unnecessary feature crate attribute from example code 2021-07-24 11:27:42 +02:00
Yuki Okushi
1a2b90bc91
Rollup merge of #87255 - RalfJung:miri-test-libcore, r=Mark-Simulacrum
better support for running libcore tests with Miri

See https://github.com/rust-lang/miri-test-libstd/issues/4 for a description of the problem that this fixes.
Thanks to `@hyd-dev` for suggesting this patch!
2021-07-24 04:31:07 +09:00
Jonas Schievink
04634e88a3 Mark format_args_nl as #[doc(hidden)] 2021-07-23 19:04:07 +02:00
Yoshua Wuyts
8c91805fd1 Stabilize core::task::ready! 2021-07-23 15:42:34 +02:00
Yuki Okushi
ba6957c9fb
Rollup merge of #87034 - mgeier:doc-step_by, r=JohnTitor
DOC: fix hypothetical Rust code in `step_by()` docstring

I don't know how important that is, but if I'm not mistaken, the hypothetical code in the docstring of `step_by()` (see https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.step_by) isn't correct.

I guess writing `next()` instead of `self.next()` isn't a biggie, but this would also imply that `advance_n_and_return_first()` is a method, which AFAICT it isn't.

I've also done some re-formatting in a separate commit and a parameter renaming in yet another commit.

Feel free to take or leave any combination of those commits.
2021-07-23 19:27:43 +09:00
Tim Vermeulen
5485f8a8ba Fix whitespace
Co-authored-by: Ivan Tham <pickfire@riseup.net>
2021-07-22 22:05:41 +02:00
Tim Vermeulen
5e90909f38 Add tests 2021-07-22 22:05:41 +02:00
Tim Vermeulen
2b89914962 Implement slice::{Iter, IterMut}::{advance_by, advance_back_by}
Co-authored-by: The8472 <git@infinite-source.de>
2021-07-22 22:05:37 +02:00
Guillaume Gomez
aece3df81e
Rollup merge of #87343 - steffahn:fix_unsound_zip_optimization_only_regression_fix, r=cuviper
Regression fix to avoid further beta backports: Remove unsound TrustedRandomAccess implementations

Removes the implementations that depend on the user-definable trait `Copy`.

Only fix regressions to ensure merge in 1.55: Does not modify `vec::IntoIter`.

<hr>

This PR applies the beta-`1.53` backport #86222 (merged as part of #86225), a reduced version of #85874 that only fixes regressions, to `master` in order to avoid the need for further backports from `1.55` onwards. Beta-`1.54` backport already happened with #87136. In case that #85874 gets merged quickly (within a week), this PR would be unnecessary.

r? `@cuviper`
2021-07-22 13:39:24 +02:00
Eric Huss
a3e1259c4d
Rollup merge of #81864 - ijackson:globalalloc-example, r=Amanieu
docs: GlobalAlloc: completely replace example with one that works

Since this is an example, this could really do with some review from someone familiar with unsafe stuff!

I made the example no longer `no_run` since it works for me.

Fixes #81847
2021-07-21 10:12:26 -07:00
Frank Steffahn
1b66a799c7 Remove unsound TrustedRandomAccess implementations
Removes the implementations that depend on the user-definable trait `Copy`.

Only fix regressions to ensure merge in 1.55: Does not modify `vec::IntoIter`.
2021-07-21 14:37:23 +02:00
Ian Jackson
03d7001564 docs: GlobalAlloc: Make example only require 4096-aligned static
Alignments > 4k are not supported,
  https://github.com/rust-lang/rust/issues/70022
  https://github.com/rust-lang/rust/issues/70144

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-21 12:37:59 +01:00
bors
fabf502a7a Auto merge of #87168 - the8472:flatten-len, r=scottmcm
implement TrustedLen for Flatten/FlatMap if the U: IntoIterator == [T; N]

This only works if arrays are passed directly instead of array iterators
because we need to be sure that they have not been advanced before
Flatten does its size calculation.

resolves #87094
2021-07-20 23:47:48 +00:00
Ian Jackson
07e11e8495 docs: GlobalAlloc: completely replace example with one that works
Since this is an example, this could really do with some review from
someone familiar with unsafe stuff !

I made the example no longer `no_run` since it works for me.

Fixes #81847

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2021-07-20 14:49:35 +01:00
The8472
c3ac8d8b86 replace Option combinators with try block 2021-07-19 20:22:26 +02:00
Guillaume Gomez
65b7aa98c7
Rollup merge of #87227 - bstrie:asm2arch, r=Amanieu
Move asm! and global_asm! to core::arch

Follow-up to https://github.com/rust-lang/stdarch/pull/1183 .

Implements the libs-api team decision from rust-lang/rust#84019 (comment) .

In order to not break nightly users, this PR also adds the newly-moved items to the prelude. However, a decision will need to be made before stabilization as to whether these items should remain in the prelude. I will file an issue for this separately.

Fixes #84019 .

r? `@Amanieu`
2021-07-19 11:37:44 +02:00
bors
83f08223a9 Auto merge of #87196 - oxalica:option-insert-must-use, r=joshtriplett
Mark `Option::insert` as must_use

Some people seems misled by the function name and use it in case where a simple assignment just works.
If the return value is not used, `option = Some(value);` should be preferred instead of `option.insert(value);`
2021-07-19 07:03:36 +00:00
bstrie
f26fbe2453 Move asm! and global_asm! to core::arch 2021-07-18 18:30:58 -04:00
Ralf Jung
6cba79851a better support for running libcore and liballoc tests with Miri 2021-07-18 19:11:45 +02:00
Yuki Okushi
c1ee9a3a03
Rollup merge of #87183 - RalfJung:option-doctest, r=jyn514
fix typo in compile_fail doctest

Fixes a typo introduced by https://github.com/rust-lang/rust/pull/86211. For some reason this typo makes Miri go all crazy when running libcore doctests (https://github.com/rust-lang/miri/issues/1852). Kudos to ``@hyd-dev`` for noticing the typo.

Cc ``@tlyu`` ``@joshtriplett``
2021-07-18 14:21:58 +09:00
Yuki Okushi
07faa2e32c
Rollup merge of #87170 - xFrednet:clippy-5393-add-diagnostic-items, r=Manishearth,oli-obk
Add diagnostic items for Clippy

This adds a bunch of diagnostic items to `std`/`core`/`alloc` functions, structs and traits used in Clippy. The actual refactorings in Clippy to use these items will be done in a different PR in Clippy after the next sync.

This PR doesn't include all paths Clippy uses, I've only gone through the first 85 lines of Clippy's [`paths.rs`](ecf85f4bdc/clippy_utils/src/paths.rs) (after rust-lang/rust-clippy#7466) to get some feedback early on. I've also decided against adding diagnostic items to methods, as it would be nicer and more scalable to access them in a nicer fashion, like adding a `is_diagnostic_assoc_item(did, sym::Iterator, sym::map)` function or something similar (Suggested by `@camsteffen` [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/Diagnostic.20Item.20Naming.20Convention.3F/near/225024603))

There seems to be some different naming conventions when it comes to diagnostic items, some use UpperCamelCase (`BinaryHeap`) and some snake_case (`hashmap_type`). This PR uses UpperCamelCase for structs and traits and snake_case with the module name as a prefix for functions. Any feedback on is this welcome.

cc: rust-lang/rust-clippy#5393

r? `@Manishearth`
2021-07-18 14:21:57 +09:00
bors
f502bd3abd Auto merge of #86761 - Alexhuszagh:master, r=estebank
Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.

# Summary

Rust, although it implements a correct float parser, has major performance issues in float parsing. Even for common floats, the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust).

Recently, major advances in float-parsing algorithms have been developed by Daniel Lemire, along with others, and implement a fast, performant, and correct float parser, with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](0e2b5d163d/data/canada.txt) dataset, 10x faster than Rust's 130 MiB/s.

In addition, [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](868c702d0c/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct, but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf), which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm, respectively.

Finally, this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed, due to use of the `Big32x40`, which simply does not have enough digits to round a float correctly. Using a custom decimal class, with much simpler logic, we can parse all valid decimal strings of any digit count.

```rust
// Issue in Rust's dec2fly.
"2.47032822920623272088284396434110686182e-324".parse::<f64>();   // Err(ParseFloatError { kind: Invalid })
```

# Solution

This pull request implements the Eisel-Lemire algorithm, modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT), along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core.

**Documentation**

Extensive documentation has been added to ensure the code base may be maintained by others, which explains the algorithms as well as various associated constants and routines. For example, two seemingly magical constants include documentation to describe how they were derived as follows:

```rust
    // Round-to-even only happens for negative values of q
    // when q ≥ −4 in the 64-bit case and when q ≥ −17 in
    // the 32-bitcase.
    //
    // When q ≥ 0,we have that 5^q ≤ 2m+1. In the 64-bit case,we
    // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case,we have
    // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10.
    //
    // When q < 0, we have w ≥ (2m+1)×5^−q. We must have that w < 2^64
    // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case)
    // or 2m+1 > 2^24 (32-bit case). Hence,we must have 2^53×5^−q < 2^64
    // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11
    // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase).
    //
    // Thus we have that we only need to round ties to even when
    // we have that q ∈ [−4,23](in the 64-bit case) or q∈[−17,10]
    // (in the 32-bit case). In both cases,the power of five(5^|q|)
    // fits in a 64-bit word.
    const MIN_EXPONENT_ROUND_TO_EVEN: i32;
    const MAX_EXPONENT_ROUND_TO_EVEN: i32;
```

This ensures maintainability of the code base.

**Improvements for Disguised Fast-Path Cases**

The fast path in float parsing algorithms attempts to use native, machine floats to represent both the significant digits and the exponent, which is only possible if both can be exactly represented without rounding. In practice, this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22, 22]` (for an f64). This is similar to the existing dec2flt implementation.

However, disguised fast-path cases exist, where there are few significant digits and an exponent above the valid range, such as `1.23e25`. In this case, powers-of-10 may be shifted from the exponent to the significant digits, discussed at length in https://github.com/rust-lang/rust/issues/85198.

**Digit Parsing Improvements**

Typically, integers are parsed from string 1-at-a-time, requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements, and is implemented for both big and little-endian systems.

**Unsafe Changes**

Relative to fast-float-rust, this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this, which is deceptively marked as safe for unsafe functionality.

```rust
impl AsciiStr {
    #[inline]
    pub fn step_by(&mut self, n: usize) -> &mut Self {
        unsafe { self.ptr = self.ptr.add(n) };
        self
    }
}

...

#[inline]
fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 {
    // the first character is 'e'/'E' and scientific mode is enabled
    let start = *s;
    s.step();
    ...
}
```

The new code clearly documents safety concerns, and does not mark unsafe functionality as safe, leading to better safety guarantees.

```rust
impl AsciiStr {
    /// Advance the view by n, advancing it in-place to (n..).
    pub unsafe fn step_by(&mut self, n: usize) -> &mut Self {
        // SAFETY: same as step_by, safe as long n is less than the buffer length
        self.ptr = unsafe { self.ptr.add(n) };
        self
    }
}

...

/// Parse the scientific notation component of a float.
fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 {
    let start = *s;
    // SAFETY: the first character is 'e'/'E' and scientific mode is enabled
    unsafe {
        s.step();
    }
    ...
}
```

This allows us to trivially demonstrate the new implementation of dec2flt is safe.

**Inline Annotations Have Been Removed**

In the previous implementation of dec2flt, inline annotations exist practically nowhere in the entire module. Therefore, these annotations have been removed, which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157).

**Fixed Correctness Tests**

Numerous compile errors in `src/etc/test-float-parse` were present, due to deprecation of `time.clock()`, as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse), and any errors in `runtests.py` have been patched.

**Undefined Behavior**

An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored, to ensure that the behavior is well-defined. The original code is as follows:

```rust
    #[inline]
    pub fn check_len(&self, n: usize) -> bool {
        unsafe { self.ptr.add(n) <= self.end }
    }
```

And the new implementation is as follows:

```rust
    /// Check if the slice at least `n` length.
    fn check_len(&self, n: usize) -> bool {
        n <= self.as_ref().len()
    }
```

Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29).

**Inferring Binary Exponents**

Rather than explicitly store binary exponents, this new implementation infers them from the decimal exponent, reducing the amount of static storage required. This removes the requirement to store [611 i16s](868c702d0c/library/core/src/num/dec2flt/table.rs (L8)).

# Code Size

The code size, for all optimizations, does not considerably change relative to before for stripped builds, however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu.

**new**

Using rustc version 1.55.0-dev.

opt-level|size|size(stripped)
|:-:|:-:|:-:|
0|400k|300K
1|396k|292K
2|392k|292K
3|392k|296K
s|396k|292K
z|396k|292K

**old**

Using rustc version 1.53.0-nightly.

opt-level|size|size(stripped)
|:-:|:-:|:-:|
0|3.2M|304K
1|3.2M|292K
2|3.1M|284K
3|3.1M|284K
s|3.1M|284K
z|3.1M|284K

# Correctness

The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests, along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham  [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore, it is unlikely that this algorithm will incorrectly round parsed floats.

# Issues Addressed

This will fix and close the following issues:

- resolves #85198
- resolves #85214
- resolves #85234
- fixes #31407
- fixes #31109
- fixes #53015
- resolves #68396
- closes https://github.com/aldanor/fast-float-rust/issues/15
2021-07-17 12:56:22 +00:00
Alex Huszagh
8752b40369 Changed dec2flt to use the Eisel-Lemire algorithm.
Implementation is based off fast-float-rust, with a few notable changes.

- Some unsafe methods have been removed.
- Safe methods with inherently unsafe functionality have been removed.
- All unsafe functionality is documented and provably safe.
- Extensive documentation has been added for simpler maintenance.
- Inline annotations on internal routines has been removed.
- Fixed Python errors in src/etc/test-float-parse/runtests.py.
- Updated test-float-parse to be a library, to avoid missing rand dependency.
- Added regression tests for #31109 and #31407 in core tests.
- Added regression tests for #31109 and #31407 in ui tests.
- Use the existing slice primitive to simplify shared dec2flt methods
- Remove Miri ignores from dec2flt, due to faster parsing times.

- resolves #85198
- resolves #85214
- resolves #85234
- fixes #31407
- fixes #31109
- fixes #53015
- resolves #68396
- closes https://github.com/aldanor/fast-float-rust/issues/15
2021-07-17 00:30:34 -05:00
bors
0cd12d649e Auto merge of #87195 - yaahc:move-assert_matches-again, r=oli-obk
rename assert_matches module

Fixes nightly breakage introduced in https://github.com/rust-lang/rust/pull/86947
2021-07-17 00:35:36 +00:00
Jane Lusby
d0e8de68c4 i sweat to god 2021-07-16 13:25:11 -07:00
Jane Lusby
085d52c588 pls this time 2021-07-16 12:16:39 -07:00
The8472
8dd903cc77 implement ConstSizeIntoIterator for &[T;N] in addition to [T;N]
Due to #20400 the corresponding TrustedLen impls need a helper trait
instead of directly adding `Item = &[T;N]` bounds.
Since TrustedLen is a public trait this in turn means
the helper trait needs to be public. Since it's just a workaround
for a compiler deficit it's marked hidden, unstable and unsafe.
2021-07-16 20:38:42 +02:00
Guillaume Gomez
7c5cabe30f
Rollup merge of #87174 - inquisitivecrystal:array-map, r=kennytm
Stabilize `[T; N]::map()`

This stabilizes the `[T; N]::map()` function, gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138)

Closes #75243.
2021-07-16 19:54:04 +02:00
The8472
18a034f97e rename specializing trait to ConstSizeIntoIterator 2021-07-16 19:17:30 +02:00