Commit Graph

2062 Commits

Author SHA1 Message Date
Chase Wilson
eea3520a8f
Added some basic tests for Option::unzip() and Option::zip() (I noticed that zip had no tests) 2021-08-09 10:24:00 -05:00
Chase Wilson
bc4ce79764
Added the Option::unzip() method 2021-08-09 10:23:46 -05:00
bors
4e886d6876 Auto merge of #87827 - eddyb:wrapperless-mem-replace, r=m-ou-se
Avoid using the `copy_nonoverlapping` wrapper through `mem::replace`.

This is a much simpler way to achieve the pre-#86003 behavior of `mem::replace` not needing dynamically-sized `memcpy`s (at least before inlining), than re-doing #81238 (which needs #86699 or something similar).

I didn't notice it until recently, but `ptr::write` already explicitly avoided using the wrapper, while `ptr::read` just called the wrapper (and was the reason for us observing any behavior change from #86003 in Rust-GPU).

<hr/>

The codegen test I've added fails without the change to `core::ptr::read` like this (ignore the `v0` mangling, I was using a worktree with it turned on by default, for this):
```llvm
       13: ; core::intrinsics::copy_nonoverlapping::<u8>
       14: ; Function Attrs: inlinehint nonlazybind uwtable
       15: define internal void `@_RINvNtCscK5tvALCJol_4core10intrinsics19copy_nonoverlappinghECsaS4X3EinRE8_25mem_replace_direct_memcpy(i8*` %src, i8* %dst, i64 %count) unnamed_addr #0 {
       16: start:
       17:  %0 = mul i64 %count, 1
       18:  call void `@llvm.memcpy.p0i8.p0i8.i64(i8*` align 1 %dst, i8* align 1 %src, i64 %0, i1 false)
not:17      !~~~~~~~~~~~~~~~~~~~~~                                                                     error: no match expected
       19:  ret void
       20: }
```
With the `core::ptr::read` change, `core::intrinsics::copy_nonoverlapping` doesn't get instantiated and the test passes.

<hr/>

r? `@m-ou-se` cc `@nagisa` (codegen test) `@oli-obk` / `@RalfJung` (miri diagnostic changes)
2021-08-08 13:11:09 +00:00
Eduard-Mihai Burtescu
a1d014bdbc Avoid using the copy_nonoverlapping wrapper through mem::replace. 2021-08-08 13:59:36 +03:00
Frank Steffahn
5c30df5954 Fix intra doc link in hidden doc of Iterator::__iterator_get_unchecked 2021-08-07 13:42:15 +02:00
Yuki Okushi
dba6cb76c2
Rollup merge of #87809 - InnovativeInventor:pointer-typo, r=dtolnay
Fix typo in the ptr documentation

Spotted a minor typo in the docs ;). Pointers are cool!
2021-08-07 01:46:36 +09:00
Max Fan
89a8ba46b8 Fix typo in the ptr documentation 2021-08-05 22:50:56 -04:00
bors
7129033b42 Auto merge of #87462 - ibraheemdev:tidy-file-length-ignore-comment, r=Mark-Simulacrum
Ignore comments in tidy-filelength

Ref https://github.com/rust-lang/rust/issues/60302#issuecomment-652402127
2021-08-06 02:07:01 +00:00
Mara Bos
cdf83c030a Make rustfmt happy. 2021-08-05 12:55:35 +02:00
Mara Bos
1b318a2b49 Remove unnecessary #[unstable] from internal macro.
After this change, all library #![feature]s enabled in core are for
const fns.
2021-08-05 12:55:35 +02:00
Mara Bos
9decf6365d Remove unused langauge #![feature]s from core. 2021-08-05 12:55:35 +02:00
Mara Bos
37d402eadd Remove unused library #![feature]s from core. 2021-08-05 12:55:35 +02:00
Mara Bos
25d0c58e0a Sort and categorize lint and feature attributes in core. 2021-08-05 12:55:33 +02:00
bors
25b7648496 Auto merge of #86155 - alexcrichton:abort-on-unwind, r=nikomatsakis
rustc: Fill out remaining parts of C-unwind ABI

This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:

* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
  unwind". This fixes a longstanding soundness issue where if you
  `panic!()` in an `extern "C"` function defined in Rust that's actually
  UB because the LLVM representation for the function has the `nounwind`
  attribute, but then you unwind.

* Whether or not a function unwinds now mainly considers the ABI of the
  function instead of first checking the panic strategy. This fixes a
  miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
  can still unwind.

* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
  reimplemented. Previously this was done as a small tweak during MIR
  generation, but this has been moved to a separate and dedicated MIR
  pass. This new pass will, for appropriate functions and function
  calls, insert a `cleanup` landing pad for any function call that may
  unwind within a function that is itself not allowed to unwind. Note
  that this subtly changes some behavior from before where previously on
  an unwind which was caught-to-abort it would run active destructors in
  the function, and now it simply immediately aborts the process.

* The `#[unwind]` attribute has been removed and all users in tests and
  such are now using `C-unwind` and `#![feature(c_unwind)]`.

I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
2021-08-04 21:09:53 +00:00
bors
6fe0886723 Auto merge of #87736 - the8472:inline-advance-by, r=Mark-Simulacrum
#[inline] slice::Iter::advance_by

https://github.com/rust-lang/rust/pull/87387#issuecomment-891942661 was marked as a regression. One of the methods in the PR was missing an inline annotation unlike all the other methods on slice iterators.

Let's see if that makes a difference.
2021-08-04 15:39:20 +00:00
bors
7f3dc04644 Auto merge of #87150 - rusticstuff:simplify_wrapping_neg, r=m-ou-se
Make wrapping_neg() use wrapping_sub(), #[inline(always)]

This is a follow-up change to the fix for #75598. It simplifies the implementation of wrapping_neg() for all integer types by just calling 0.wrapping_sub(self) and always inlines it. This leads to much less assembly code being emitted for opt-level≤1 and thus much better performance for debug-compiled code.

Background is [this discussion on the internals forum](https://internals.rust-lang.org/t/why-does-rust-generate-10x-as-much-unoptimized-assembly-as-gcc/14930).
2021-08-04 12:58:31 +00:00
Yuki Okushi
af8c99a235
Rollup merge of #87723 - frogtd:patch-3, r=JohnTitor
Use .contains instead of manual reimplementation.

It's also significantly easier to read.
2021-08-04 08:05:55 +09:00
Yuki Okushi
ad74828b50
Rollup merge of #81797 - yoshuawuyts:stream_from_iter, r=dtolnay
Add `core::stream::from_iter`

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

This_ PR implements `std::stream::from_iter`, as outlined in the _"Converting an Iterator to a Stream"_ section of the [Stream RFC](https://github.com/nellshamrell/rfcs/blob/add-async-stream-rfc/text/0000-async-stream.md#converting-an-iterator-to-a-stream). This function enables converting an `Iterator` to a `Stream` by wrapping each item in the iterator with a `Poll::Ready` instance.

r? `@tmandry`

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

## Example

Being able to convert from an iterator into a stream is useful when refactoring from iterative loops into a more functional adapter-based style. This is fairly common when using more complex `filter` / `map` / `find` chains. In its basic form this conversion looks like this:

**before**
```rust
let mut output = vec![];
for item in my_vec {
    let out = do_io(item).await?;
    output.push(out);
}
```
**after**
```rust
use std::stream;

let output = stream::from_iter(my_vec.iter())
    .map(async |item| do_io(item).await)
    .collect()?;
```

Having a way to convert an `Iterator` to a `Stream` is essential in enabling this flow.

## Implementation Notes

This PR makes use of `unsafe {}` to pin an item. Currently we're having conversations on the libs stream in Zulip how to bring `pin-project` in as a dependency to `core` so we can omit the `unsafe {}`.

This PR also includes a documentation block which references `Stream::next` which currently doesn't exist in the stdlib (originally included in the RFC and PR, but later omitted because of an unresolved issue). `stream::from_iter` can't stabilize before `Stream` does, and there's still a chance we may stabilize `Stream` with a `next` method. So this PR includes documentation referencing that method, which we can remove as part of stabilization if by any chance we don't have `Stream::next`.

## Alternatives Considered

### `impl IntoStream for T: IntoIterator`

An obvious question would be whether we could make it so every iterator can automatically be converted into a stream by calling `into_stream` on it. The answer is: "perhaps, but it could cause type issues". Types like `std::collections` may want to opt to create manual implementations for `IntoStream` and `IntoIter`, which wouldn't be possible if it was implemented through a catch-all trait.

Possibly an alternative such as `impl IntoStream for T: Iterator` could work, but it feels somewhat restrictive. In the end, converting an iterator to a stream is likely to be a bit of a niche case. And even then, **adding a standalone function to convert an `Iterator` into a `Stream` would not be mutually exclusive with a blanket implementation**.

### Naming

The exact name can be debated in the period before stabilization. But I've chosen `stream::from_iter` rather than `stream::iter` because we are _creating a stream from an iterator_ rather than _iterating a stream_. We also expect to add a stream counterpart to `iter::from_fn` later on (blocked on async closures), and having `stream::from_fn` and `stream::from_iter` would feel like a consistent pair. It also has prior art in `async_std::stream::from_iter`.

## Future Directions
### Stream conversions for collections

This is a building block towards implementing `stream/stream_mut/into_stream` methods for `std::collections`, `std::vec`, and more. This would allow even quicker refactorings from using loops to using iterator adapters by omitting the import altogether:

**before**
```rust
use std::stream;

let output = stream::from_iter(my_vec.iter())
    .map(async |item| do_io(item).await)
    .collect()?;
```
**after**
```rust
let output = my_vec
    .stream()
    .map(async |item| do_io(item).await)
    .collect()?;
```
2021-08-04 08:05:50 +09:00
The8472
e44d39a5b7 #[inline] slice::advance_by 2021-08-03 21:32:36 +02:00
Alex Crichton
1c07096a45 rustc: Fill out remaining parts of C-unwind ABI
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:

* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
  unwind". This fixes a longstanding soundness issue where if you
  `panic!()` in an `extern "C"` function defined in Rust that's actually
  UB because the LLVM representation for the function has the `nounwind`
  attribute, but then you unwind.

* Whether or not a function unwinds now mainly considers the ABI of the
  function instead of first checking the panic strategy. This fixes a
  miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
  can still unwind.

* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
  reimplemented. Previously this was done as a small tweak during MIR
  generation, but this has been moved to a separate and dedicated MIR
  pass. This new pass will, for appropriate functions and function
  calls, insert a `cleanup` landing pad for any function call that may
  unwind within a function that is itself not allowed to unwind. Note
  that this subtly changes some behavior from before where previously on
  an unwind which was caught-to-abort it would run active destructors in
  the function, and now it simply immediately aborts the process.

* The `#[unwind]` attribute has been removed and all users in tests and
  such are now using `C-unwind` and `#![feature(c_unwind)]`.

I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
2021-08-03 07:06:19 -07:00
frogtd
499758a285
Use .contains instead of manual reimplementation.
It's also significantly easier to read.
2021-08-03 04:30:44 -04:00
Cameron Steffen
7fc26e9665
Rollup merge of #87690 - sharnoff:mut-ptr-allocated-obj-link, r=Mark-Simulacrum
Add missing "allocated object" doc link to `<*mut T>::add`

The portion of the documentation expecting the link was already there, but it was rendered as "[allocated object]". The added reference is just copied from the documentation for `<*const T>::add`.
2021-08-02 09:36:55 -05:00
Cameron Steffen
b1166e14b6
Rollup merge of #87654 - jesyspa:issue-87238-option-result-doc, r=scottmcm
Add documentation for the order of Option and Result

This resolves issue #87238.
2021-08-02 09:36:50 -05:00
bors
b53a93db2d Auto merge of #87535 - lf-:authors, r=Mark-Simulacrum
rfc3052 followup: Remove authors field from Cargo manifests

Since RFC 3052 soft deprecated the authors field, 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 for contributors, we may as well
remove it from crates in this repo.
2021-08-02 05:49:17 +00:00
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