Commit Graph

5463 Commits

Author SHA1 Message Date
Matthias Krüger
346f833c3d
Rollup merge of #89678 - marcelo-gonzalez:master, r=joshtriplett
Fix minor std::thread documentation typo

callers of spawn_unchecked() need to make sure that the thread
not outlive references in the passed closure, not the other way around.
2021-10-09 11:56:01 +02:00
Matthias Krüger
36db658796
Rollup merge of #88707 - sylvestre:split_example, r=yaahc
String.split_terminator: Add an example when using a slice of chars
2021-10-09 11:55:58 +02:00
bors
910692de74 Auto merge of #89582 - jkugelman:optimize-file-read-to-end, r=joshtriplett
Optimize File::read_to_end and read_to_string

Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer "warms up" and grows to its final size. This is perhaps a necessary evil with generic readers, but files can be read in smarter by checking the file size and reserving that much capacity.

`std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file, reads its metadata, and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls.

However, if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization.

```rust
let mut buf = Vec::new();
file.read_to_end(&mut buf)?;
```

I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests, which isn't a big deal, but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here:

https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999

Most telling, the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem.

To that end, this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in.

A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example, this code from `compiler/rustc_serialize/src/json.rs`:

```rust
pub fn from_reader(rdr: &mut dyn Read) -> Result<Json, BuilderError> {
    let mut contents = Vec::new();
    match rdr.read_to_end(&mut contents) {
```

Related changes:

- I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized  implementations if the inner reader is a file.

- The private `std::io::append_to_string` function is now marked `unsafe`.

- `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502.

r? `@joshtriplett`
2021-10-09 05:24:47 +00:00
Marcelo Diop-Gonzalez
82c974dab5 Fix minor std::thread documentation typo
callers of spawn_unchecked() need to make sure that the thread
not outlive references in the passed closure, not the other way around.
2021-10-08 15:29:04 -04:00
Loïc BRANSTETT
0a03ec4724 Cfg hide more conditions for alloc 2021-10-08 17:11:57 +02:00
Loïc BRANSTETT
31b2eb16e3 Cfg hide more conditions for core 2021-10-08 16:13:49 +02:00
Jubilee
30e068f58b
Rollup merge of #89622 - m-ou-se:debug-assert-2021, r=estebank
Use correct edition for panic in [debug_]assert!().

See https://github.com/rust-lang/rust/issues/88638#issuecomment-915472783
2021-10-07 20:26:15 -07:00
Jubilee
37f17bca7c
Rollup merge of #89082 - smoelius:master, r=kennytm
Implement #85440 (Random test ordering)

This PR adds `--shuffle` and `--shuffle-seed` options to `libtest`. The options are similar to the [`-shuffle` option](c894b442d1/src/testing/testing.go (L1482-L1499)) that was recently added to Go.

Here are the relevant parts of the help message:
```
        --shuffle       Run tests in random order
        --shuffle-seed SEED
                        Run tests in random order; seed the random number
                        generator with SEED
...
By default, the tests are run in alphabetical order. Use --shuffle or set
RUST_TEST_SHUFFLE to run the tests in random order. Pass the generated
"shuffle seed" to --shuffle-seed (or set RUST_TEST_SHUFFLE_SEED) to run the
tests in the same order again. Note that --shuffle and --shuffle-seed do not
affect whether the tests are run in parallel.
```
Is an RFC needed for this?
2021-10-07 20:26:12 -07:00
Jubilee
2b6d7f75f7
Rollup merge of #88772 - orlp:result-map-or-else-docfix, r=yaahc
Fixed confusing wording on Result::map_or_else.

Fixes https://github.com/rust-lang/rust/issues/88195.
2021-10-07 20:26:11 -07:00
bors
2ee06e7372 Auto merge of #89638 - rust-lang:revert-88548-intersperse, r=Mark-Simulacrum
Revert "Stabilize `Iterator::intersperse()`"

Reverts rust-lang/rust#88548

First step in resolving https://github.com/rust-lang/rust/issues/88967
2021-10-07 23:50:54 +00:00
John Kugelman
a990c76d84 Optimize File::read_to_end and read_to_string
Reading a file into an empty vector or string buffer can incur
unnecessary `read` syscalls and memory re-allocations as the buffer
"warms up" and grows to its final size. This is perhaps a necessary evil
with generic readers, but files can be read in smarter by checking the
file size and reserving that much capacity.

`std::fs::read` and `read_to_string` already perform this optimization:
they open the file, reads its metadata, and call `with_capacity` with
the file size. This ensures that the buffer does not need to be resized
and an initial string of small `read` syscalls.

However, if a user opens the `File` themselves and calls
`file.read_to_end` or `file.read_to_string` they do not get this
optimization.

```rust
let mut buf = Vec::new();
file.read_to_end(&mut buf)?;
```

I searched through this project's codebase and even here are a *lot* of
examples of this. They're found all over in unit tests, which isn't a
big deal, but there are also several real instances in the compiler and
in Cargo. I've documented the ones I found in a comment here:

https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999

Most telling, the `Read` trait and the `read_to_end` method both show
this exact pattern as examples of how to use readers. What this says to
me is that this shouldn't be solved by simply fixing the instances of it
in this codebase. If it's here it's certain to be prevalent in the wider
Rust ecosystem.

To that end, this commit adds specializations of `read_to_end` and
`read_to_string` directly on `File`. This way it's no longer a minor
footgun to start with an empty buffer when reading a file in.

A nice side effect of this change is that code that accesses a `File` as
a bare `Read` constraint or via a `dyn Read` trait object will benefit.
For example, this code from `compiler/rustc_serialize/src/json.rs`:

```rust
pub fn from_reader(rdr: &mut dyn Read) -> Result<Json, BuilderError> {
    let mut contents = Vec::new();
    match rdr.read_to_end(&mut contents) {
```

Related changes:

- I also added specializations to `BufReader` to delegate to
  `self.inner`'s methods. That way it can call `File`'s optimized
  implementations if the inner reader is a file.

- The private `std::io::append_to_string` function is now marked
  `unsafe`.

- `File::read_to_string` being more efficient means that the performance
  note for `io::read_to_string` can be softened. I've added @camelid's
  suggested wording from:

  https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502
2021-10-07 18:42:02 -04:00
Jane Lusby
8965b5884a
Revert "Stabilize Iterator::intersperse()" 2021-10-07 10:39:36 -07:00
Guillaume Gomez
e32328bdc5
Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg, r=jyn514
Make cfg imply doc(cfg)

This is a reopening of #79341, rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well):

 * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand, so we need this information in later parts of rustdoc.
 * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation.
 * I updated the version for the feature.

There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624)

> I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different.

How/why should they differ?

EDIT: this part has been solved, the current code was fine, just needed a little simplification.

cc `@Nemo157`
r? `@jyn514`

Original PR description:

This is only active when the `doc_cfg` feature is active.

The implicit cfg can be overridden via `#[doc(cfg(...))]`, so e.g. to hide a `#[cfg]` you can use something like:

```rust
#[cfg(unix)]
#[doc(cfg(all()))]
pub struct Unix;
```

By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.
2021-10-07 16:24:53 +02:00
Mara Bos
afe5335b97 Use correct edition for panic in [debug_]assert!() etc. 2021-10-07 14:27:08 +02:00
Manish Goregaokar
79a1fc8419
Rollup merge of #89531 - devnexen:stack_overflow_bsd_libc_upd, r=dtolnay
library std, libc dependency update

to solve #87528 build.
2021-10-06 12:33:22 -07:00
Manish Goregaokar
b4615b5bf9
Rollup merge of #89324 - yoshuawuyts:hardware-parallelism, r=m-ou-se
Rename `std:🧵:available_conccurrency` to `std:🧵:available_parallelism`

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

This PR renames  `std:🧵:available_conccurrency` to `std:🧵:available_parallelism`.

## Rationale

The API was initially named `std:🧵:hardware_concurrency`, mirroring the [C++ API of the same name](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency). We eventually decided to omit any reference to the word "hardware" after [this comment](https://github.com/rust-lang/rust/pull/74480#issuecomment-662045841). And so we ended up with `available_concurrency` instead.

---

For a talk I was preparing this week I was reading through ["Understanding and expressing scalable concurrency" (A. Turon, 2013)](http://aturon.github.io/academic/turon-thesis.pdf), and the following passage stood out to me (emphasis mine):

> __Concurrency is a system-structuring mechanism.__ An interactive system that deals with disparate asynchronous events is naturally structured by division into concurrent threads with disparate responsibilities. Doing so creates a better fit between problem and solution, and can also decrease the average latency of the system by preventing long-running computations from obstructing quicker ones.

> __Parallelism is a resource.__ A given machine provides a certain capacity for parallelism, i.e., a bound on the number of computations it can perform simultaneously. The goal is to maximize throughput by intelligently using this resource. For interactive systems, parallelism can decrease latency as well.

_Chapter 2.1: Concurrency is not Parallelism. Page 30._

---

_"Concurrency is a system-structuring mechanism. Parallelism is a resource."_ — It feels like this accurately captures the way we should be thinking about these APIs. What this API returns is not "the amount of concurrency available to the program" which is a property of the program, and thus even with just a single thread is effectively unbounded. But instead it returns "the amount of _parallelism_ available to the program", which is a resource hard-constrained by the machine's capacity (and can be further restricted by e.g. operating systems).

That's why I'd like to propose we rename this API from `available_concurrency` to `available_parallelism`. This still meets the criteria we previously established of not attempting to define what exactly we mean by "hardware", "threads", and other such words. Instead we only talk about "concurrency" as an abstract resource available to our program.

r? `@joshtriplett`
2021-10-06 12:33:17 -07:00
Manish Goregaokar
14da7fc9ae
Rollup merge of #89245 - DeveloperC286:iter_mut_fields_to_private, r=joshtriplett
refactor: make VecDeque's IterMut fields module-private, not just crate-private

Made the fields of VecDeque's IterMut private by creating a IterMut::new(...) function to create a new instance of IterMut and migrating usage to use IterMut::new(...).
2021-10-06 12:33:16 -07:00
Manish Goregaokar
91e3b5172c
Rollup merge of #89050 - DeveloperC286:drain_fields_to_private, r=joshtriplett
refactor: VecDeques Drain fields to private

Made the fields of VecDeque's Drain private by creating a Drain::new(...) function to create a new instance of Drain and migrating usage to use Drain::new(...).
2021-10-06 12:33:15 -07:00
Manish Goregaokar
1e3b5d6725
Rollup merge of #88523 - kpreid:category, r=yaahc
Expand documentation for `FpCategory`.

I intend these changes to be helpful to readers who are not yet familiar with the quirks of floating-point numbers. Additionally, I felt it was misleading to describe `Nan` as being the result of division by zero, since most divisions by zero (except for 0/0) produce `Infinite` floats, so I moved that remark to the `Infinite` variant with adjustment.

The first sentence of the `Nan` documentation is copied from `f32`; I followed the example of the `f64` documentation by referring to `f32` for general concepts, rather than duplicating the text.

----

I considered making similar changes to the documentation of the `is_*` methods of floats, but decided that that was a much larger and trickier problem; here, each of the variants' descriptions can be expected to be read in context of being mutually exclusive with the others.
2021-10-06 12:33:14 -07:00
Manish Goregaokar
3209582a87
Rollup merge of #87601 - a1phyr:feature_uint_add_signed, r=kennytm
Add functions to add unsigned and signed integers

This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`.

The added API is:

```rust
// `uX` is `u8`, `u16`, `u32`, `u64`,`u128`, `usize`
impl uX {
    pub const fn checked_add_signed(self, iX) -> Option<Self>;
    pub const fn overflowing_add_signed(self, iX) -> (Self, bool);
    pub const fn saturating_add_signed(self, iX) -> Self;
    pub const fn wrapping_add_signed(self, iX) -> Self;
}

impl iX {
    pub const fn checked_add_unsigned(self, uX) -> Option<Self>;
    pub const fn overflowing_add_unsigned(self, uX) -> (Self, bool);
    pub const fn saturating_add_unsigned(self, uX) -> Self;
    pub const fn wrapping_add_unsigned(self, uX) -> Self;

    pub const fn checked_sub_unsigned(self, uX) -> Option<Self>;
    pub const fn overflowing_sub_unsigned(self, uX) -> (Self, bool);
    pub const fn saturating_sub_unsigned(self, uX) -> Self;
    pub const fn wrapping_sub_unsigned(self, uX) -> Self;
}
```

Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?
2021-10-06 12:33:13 -07:00
Guillaume Gomez
8fac41a530 Clean up code a bit:
* Remove "bool_to_options" feature
 * Update version for compiler feature
 * rustfmt
2021-10-06 20:23:57 +02:00
Orson Peters
c3dfda0e3d Rebase Result::map_or_else doc wording on top of #89400. 2021-10-06 09:03:18 +02:00
Manish Goregaokar
4e8c853c9e
Rollup merge of #89502 - FabianWolff:issue-89493, r=joshtriplett
Fix Lower/UpperExp formatting for integers and precision zero

Fixes the integer part of #89493 (I daren't touch the floating-point formatting code). The issue is that the "subtracted" precision essentially behaves like extra trailing zeros, but this is not currently reflected in the code properly.
2021-10-05 12:52:46 -07:00
Manish Goregaokar
e745e098c4
Rollup merge of #89351 - tspiteri:wrapping_rem, r=dtolnay
for signed wrapping remainder, do not compare lhs with MIN

Since the wrapped remainder is going to be 0 for all cases when the rhs is -1, there is no need to compare the lhs with MIN.
2021-10-05 12:52:45 -07:00
Manish Goregaokar
eb860987cf
Rollup merge of #88828 - FabianWolff:issue-88585, r=dtolnay
Use `libc::sigaction()` instead of `sys::signal()` to prevent a deadlock

Fixes #88585. POSIX [specifies](https://man7.org/linux/man-pages/man3/fork.3p.html) that after forking,
> to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called.

Rust's standard library does not currently adhere to this, as evidenced by #88585. The child process calls [`sys::signal()`](7bf0736e13/library/std/src/sys/unix/android.rs (L76)), which on Android calls [`libc::dlsym()`](7bf0736e13/library/std/src/sys/unix/weak.rs (L101)), which is [**not**](https://man7.org/linux/man-pages/man7/signal-safety.7.html) async-signal-safe, and in fact causes a deadlock in the example in #88585.

I think the easiest solution here would be to just call `libc::sigaction()` instead, which [is](https://man7.org/linux/man-pages/man7/signal-safety.7.html) async-signal-safe, provides the functionality we need, and is apparently available on all Android versions because it is also used e.g. [here](7bf0736e13/library/std/src/sys/unix/stack_overflow.rs (L112-L114)).
2021-10-05 12:52:42 -07:00
DeveloperC
5af61cb114 refactor: VecDeques IterMut fields to private
Made the fields of VecDeque's IterMut private by creating a IterMut::new(...) function to create a new instance of IterMut and migrating usage to use IterMut::new(...).
2021-10-05 19:09:49 +01:00
DeveloperC286
b2e4e59fbe refactor: VecDeques Drain fields to private 2021-10-05 19:02:36 +01:00
Wim Looman
0031ce3a91 Suppress some cfg from being shown in the stdlib docs 2021-10-05 18:15:29 +02:00
Trevor Spiteri
4ec0377d6a for signed overflowing remainder, delay comparing lhs with MIN
Since the wrapped remainder is going to be 0 for all cases when the rhs is -1,
there is no need to divide in this case. Comparing the lhs with MIN is only done
for the overflow bool. In particular, this results in better code generation for
wrapping remainder, which discards the overflow bool completely.
2021-10-05 15:15:24 +02:00
Manish Goregaokar
a23d7f01d3
Rollup merge of #89462 - devnexen:haiku_thread_aff_build_fix, r=nagisa
haiku thread affinity build fix
2021-10-04 23:56:22 -07:00
Manish Goregaokar
eeadc9d63f
Rollup merge of #89244 - DeveloperC286:pair_slices_fields_to_private, r=joshtriplett
refactor: VecDeques PairSlices fields to private

Reducing VecDeque's PairSlices fields to private, a `from(...)` method is already used to create PairSlices.
2021-10-04 23:56:18 -07:00
Manish Goregaokar
dd223d5c6d
Rollup merge of #88651 - AGSaidi:monotonize-inner-64b-aarch64, r=dtolnay
Use the 64b inner:monotonize() implementation not the 128b one for aarch64

aarch64 prior to v8.4 (FEAT_LSE2) doesn't have an instruction that guarantees
untorn 128b reads except for completing a 128b load/store exclusive pair
(ldxp/stxp) or compare-and-swap (casp) successfully. The requirement to
complete a 128b read+write atomic is actually more expensive and more unfair
than the previous implementation of monotonize() which used a Mutex on aarch64,
especially at large core counts.  For aarch64 switch to the 64b atomic
implementation which is about 13x faster for a benchmark that involves many
calls to Instant::now().
2021-10-04 23:56:17 -07:00
Manish Goregaokar
0fb01224dd
Rollup merge of #87631 - :solarish_upd_fs, r=joshtriplett
os current_exe using same approach as linux to get always the full ab…

…solute path
2021-10-04 23:56:15 -07:00
David Carlier
c79447e708 library std, libc dependency update
to solve #87528 build.
2021-10-05 05:58:09 +01:00
Jubilee
05b4cd6789
Rollup merge of #89413 - matthewjasper:spec-marker-fix, r=nikomatsakis
Correctly handle supertraits for min_specialization

Supertraits of specialization markers could circumvent checks for
min_specialization. Elaborating predicates prevents this.

r? ````@nikomatsakis````
2021-10-04 21:12:35 -07:00
Jubilee
7aa9ce55b9
Rollup merge of #89270 - seanyoung:join_fold, r=m-ou-se
path.push() should work as expected on windows verbatim paths

On Windows, std::fs::canonicalize() returns an so-called UNC path.  UNC paths differ with regular paths because:

- This type of path can much longer than a non-UNC path (32k vs 260 characters).
- The prefix for a UNC path is ``Component::Prefix(Prefix::DiskVerbatim(..)))``
- No `/` is allowed
- No `.` is allowed
- No `..` is allowed

Rust has poor handling of such paths. If you join a UNC path with a path with any of the above, then this will not work.

I've implemented a new method `fn join_fold()` which joins paths and also removes any `.` and `..` from it, and replaces `/` with `\` on Windows. Using this function it is possible to use UNC paths without issue. In addition, this function is useful on Linux too; paths can be appended without having to call `canonicalize()` to remove the `.` and `..`.

This PR needs test cases, which can I add. I hope this will a start of a discussion.
2021-10-04 21:12:35 -07:00
Jubilee
234fa90878
Rollup merge of #88780 - orlp:int-abs-diff, r=m-ou-se
Added abs_diff for integer types.

Closes https://github.com/rust-lang/rust/issues/62111.
2021-10-04 21:12:34 -07:00
Jubilee
99e6e3ff07
Rollup merge of #87993 - kornelski:try_reserve_stable, r=joshtriplett
Stabilize try_reserve

Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).
2021-10-04 21:12:33 -07:00
Jubilee
9866b090f4
Rollup merge of #89508 - jhpratt:stabilize-const_panic, r=joshtriplett
Stabilize `const_panic`

Closes #51999

FCP completed in #89006

```@rustbot``` label +A-const-eval +A-const-fn +T-lang

cc ```@oli-obk``` for review (not `r?`'ing as not on lang team)
2021-10-04 13:58:17 -07:00
Jubilee
5352e17df3
Rollup merge of #89483 - hkmatsumoto:patch-diagnostics-2, r=estebank
Practice diagnostic message convention

Detected by #89455.

r? ```@estebank```
2021-10-04 13:58:15 -07:00
Jubilee
e1478d650d
Rollup merge of #89443 - cuviper:btree-hash-len, r=dtolnay
Include the length in BTree hashes

This change makes it consistent with `Hash` for all other collections.
2021-10-04 13:58:11 -07:00
Jubilee
9e387cf27e
Rollup merge of #89400 - Nitepone:nitepone/map-or-else-docfix, r=dtolnay
Improve wording of `map_or_else` docs

Changes doc text to refer to the "default" parameter as the "default"
function.

Previously, the doc text referred to the "f" parameter as the "default" function; and the "default" parameter as the "fallback" function.
2021-10-04 13:58:09 -07:00
Jubilee
19d9a147be
Rollup merge of #88452 - xu-cheng:vecdeque-from-array, r=m-ou-se
VecDeque: improve performance for From<[T; N]>

Create `VecDeque` directly from the array instead of inserting items one-by-one.

Benchmark
```
./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000
```

* Before
```
test vec_deque::bench_from_array_1000                    ... bench:       3,991 ns/iter (+/- 717)
```

* After
```
test vec_deque::bench_from_array_1000                    ... bench:         268 ns/iter (+/- 37)
```
2021-10-04 13:58:08 -07:00
Jubilee
ca8a10845f
Rollup merge of #87091 - the8472:more-advance-by-impls, r=joshtriplett
implement advance_(back_)_by on more iterators

Add more efficient, non-default implementations for `feature(iter_advance_by)` (#77404) on more iterators and adapters.

This PR only contains implementations where skipping over items doesn't elide any observable side-effects such as user-provided closures or `clone()` functions. I'll put those in a separate PR.
2021-10-04 13:58:07 -07:00
Benoît du Garreau
47edde1086 Optimize saturating_add_signed 2021-10-04 18:52:17 +02:00
bors
175b8db73b Auto merge of #88834 - the8472:char-count, r=joshtriplett
optimize str::from_utf8() validation when slice contains multibyte chars and str.chars().count() in all cases

The change shows small but consistent improvements across several x86 target feature levels. I also tried to optimize counting with `slice.as_chunks` but that yielded more inconsistent results, bigger improvements for some optimization levels, lesser ones in others.

```
old, -O2, x86-64
test str::str_char_count_emoji                                  ... bench:       1,924 ns/iter (+/- 26)
test str::str_char_count_lorem                                  ... bench:         879 ns/iter (+/- 12)
test str::str_char_count_lorem_short                            ... bench:           5 ns/iter (+/- 0)

new, -O2, x86-64
test str::str_char_count_emoji                                  ... bench:       1,878 ns/iter (+/- 21)
test str::str_char_count_lorem                                  ... bench:         851 ns/iter (+/- 11)
test str::str_char_count_lorem_short                            ... bench:           4 ns/iter (+/- 0)

old, -O2, x86-64-v2
test str::str_char_count_emoji                                  ... bench:       1,477 ns/iter (+/- 46)
test str::str_char_count_lorem                                  ... bench:         675 ns/iter (+/- 15)
test str::str_char_count_lorem_short                            ... bench:           5 ns/iter (+/- 0)

new, -O2, x86-64-v2
test str::str_char_count_emoji                                  ... bench:       1,323 ns/iter (+/- 39)
test str::str_char_count_lorem                                  ... bench:         593 ns/iter (+/- 18)
test str::str_char_count_lorem_short                            ... bench:           4 ns/iter (+/- 0)

old, -O2, x86-64-v3
test str::str_char_count_emoji                                  ... bench:         748 ns/iter (+/- 7)
test str::str_char_count_lorem                                  ... bench:         348 ns/iter (+/- 2)
test str::str_char_count_lorem_short                            ... bench:           5 ns/iter (+/- 0)

new, -O2, x86-64-v3
test str::str_char_count_emoji                                  ... bench:         650 ns/iter (+/- 4)
test str::str_char_count_lorem                                  ... bench:         301 ns/iter (+/- 1)
test str::str_char_count_lorem_short                            ... bench:           5 ns/iter (+/- 0)
```

and for the multibyte-char string validation:

```
old, -O2, x86-64
test str::str_validate_emoji                                    ... bench:       4,606 ns/iter (+/- 64)

new, -O2, x86-64
test str::str_validate_emoji                                    ... bench:       3,837 ns/iter (+/- 60)
```
2021-10-04 12:49:57 +00:00
Kornel
00152d8977 Stabilize try_reserve 2021-10-04 10:29:46 +01:00
Yoshua Wuyts
03fbc160cd Add doc aliases to std:🧵:available_parallelism 2021-10-04 11:13:39 +02:00
bors
44593aeb13 Auto merge of #89512 - Manishearth:rollup-meh9x7r, r=Manishearth
Rollup of 14 pull requests

Successful merges:

 - #86434 (Add `Ipv6Addr::is_benchmarking`)
 - #86828 (const fn for option copied, take & replace)
 - #87679 (BTree: refine some comments)
 - #87910 (Mark unsafe methods NonZero*::unchecked_(add|mul) as const.)
 - #88286 (Remove unnecessary unsafe block in `process_unix`)
 - #88305 (Manual Debug for Unix ExitCode ExitStatus ExitStatusError)
 - #88353 (Partially stabilize `array_methods`)
 - #88370 (Add missing `# Panics` section to `Vec` method)
 - #88481 (Remove some feature gates)
 - #89138 (Fix link in Ipv6Addr::to_ipv4 docs)
 - #89401 (Add truncate note to Vec::resize)
 - #89467 (Fix typos in rustdoc/lints)
 - #89472 (Only register `WSACleanup` if `WSAStartup` is actually ever called)
 - #89505 (Add regression test for spurious const error with NLL)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-10-04 07:25:50 +00:00
Jacob Pratt
bce8621983
Stabilize const_panic 2021-10-04 02:33:33 -04:00