Rollup merge of #87731 - ehuss:update-cargo, r=ehuss

Update cargo

11 commits in d21c22870e58499d6c31f1bef3bf1255eb021666..cc17afbb0067b1f57d8882640f63b2168d5b7624
2021-07-26 20:23:21 +0000 to 2021-08-02 20:28:08 +0000
- Stabilize the rust-version field (rust-lang/cargo#9732)
- Remove nbsp characters. (rust-lang/cargo#9751)
- Update unstable documentation TOC. (rust-lang/cargo#9750)
- Some minor updates for package/publish package selection. (rust-lang/cargo#9749)
- Bump to 0.57.0, update changelog (rust-lang/cargo#9748)
- Stabilize `[env]` sections (rust-lang/cargo#9411)
- doc: Clarify [doc].browser docs, document PathAndArgs better (rust-lang/cargo#9747)
- Bump cargo-util version. (rust-lang/cargo#9745)
- Make clippy happy (rust-lang/cargo#9736)
- Fix typo in features doc (rust-lang/cargo#9737)
- doc test supports silent output (rust-lang/cargo#9730)

Rollup merge of #87729 - adamgemmell:dev/deprecate-crypto, r=Amanieu

Remove the aarch64 `crypto` target_feature

The subfeatures `aes` or `sha2` should be used instead.

This can't yet be done for ARM targets as some LLVM intrinsics still require `crypto`.

Also update the runtime feature detection tests in `library/std` to mirror the updates in `stdarch`. This also helps https://github.com/rust-lang/rust/issues/86941

r? ``@Amanieu``

Rollup merge of #87723 - frogtd:patch-3, r=JohnTitor

Use .contains instead of manual reimplementation.

It's also significantly easier to read.

Rollup merge of #87720 - matthiaskrgr:clippy_into, r=jyn514

don't use .into() to convert types to identical types (clippy::useless_conversion)

Example:
let _x: String = String::from("hello world").into();

Rollup merge of #87663 - GuillaumeGomez:rustdoc-brace-minus-brace, r=notriddle

Rustdoc accessibility: use an icon for the [-]/[+] controls

This is a reopening of #87207 with improvement for the way of generating the `background-image` CSS property.

I quote from the original PR:

> This way, we can show the plus and minus buttons on screens, while voice
> control will read off actual words "Collapse" and "Expand" instead of reading
> "open brace minus close brace" and "open brace plus close brace".

Part of #87059

r? ``@notriddle``

Rollup merge of #87267 - dtolnay:negspace, r=Aaron1011

Remove space after negative sign in Literal to_string

Negative proc macro literal tokens used to be printed with a space between the minus sign and the magnitude. That's because `impl ToString for Literal` used to convert the Literal into a TokenStream, which splits the minus sign into a separate Punct token.

```rust
Literal::isize_unsuffixed(-10).to_string()  // "- 10"
```

This PR updates the ToString impl to directly use `rustc_ast::token::Lit`'s ToString, which matches the way Rust negative numbers are idiomatically written without a space.

```rust
Literal::isize_unsuffixed(-10).to_string()  // "-10"
```

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()?;
```

Auto merge of #86400 - FabianWolff:issue-85735, r=estebank

Remove invalid suggestion involving `Fn` trait bound

This pull request closes #85735. The actual issue is a duplicate of #21974, but #85735 contains a further problem, which is an invalid suggestion if `Fn`/`FnMut`/`FnOnce` trait bounds are involved: The suggestion code checks whether the trait bound ends with `>` to determine whether it has any generic arguments, but the `Fn*` traits have a special syntax for generic arguments that doesn't involve angle brackets. The example given in #85735:
```rust
trait Foo {}
impl<'a, 'b, T> Foo for T
where
    T: FnMut(&'a ()),
    T: FnMut(&'b ()), {

    }
```
currently produces:
```
error[E0283]: type annotations needed
   --> src/lib.rs:4:8
    |
4   |       T: FnMut(&'a ()),
    |          ^^^^^^^^^^^^^ cannot infer type for type parameter `T`
    |
    = note: cannot satisfy `T: FnMut<(&'a (),)>`
help: consider specifying the type arguments in the function call
    |
4   |     T: FnMut(&'a ())::<Self, Args>,
    |                     ^^^^^^^^^^^^^^

error: aborting due to previous error
```
which is incorrect, because there is no function call, and applying the suggestion would lead to a parse error. With my changes, I get:
```
error[E0283]: type annotations needed
   --> test.rs:4:8
    |
4   |     T: FnMut(&'a ()),
    |        ^^^^^^^^^^^^^ cannot infer type for type parameter `T`
    |
   ::: [...]/library/core/src/ops/function.rs:147:1
    |
147 | pub trait FnMut<Args>: FnOnce<Args> {
    | ----------------------------------- required by this bound in `FnMut`
    |
    = note: cannot satisfy `T: FnMut<(&'a (),)>`

error: aborting due to previous error
```
i.e. I have added a check to prevent the invalid suggestion from being issued for `Fn*` bounds, while the underlying issue #21974 remains for now.

Remove invalid suggestion involving Fn trait bound

Simplify usage of CSS background-image

Remove space after negative sign in Literal to_string

Auto merge of #87515 - crlf0710:trait_upcasting_part2, r=bjorn3

Trait upcasting coercion (part2)

This is the second part of trait upcasting coercion implementation.

Currently this is blocked on #86264 .

The third part might be implemented using unsafety checking

r? `@bjorn3`

Update cargo

Auto merge of #86338 - JohnTitor:issue-86162, r=estebank

Do not suggest impl traits as type arguments

Fixes #86162

Use empty string instead of single space

Pull the "Expand" / "Collapse" text to the end of the line, instead of start

Rustdoc accessibility: use an icon for the [-]/[+] controls

This way, we can show the plus and minus buttons on screens, while voice
control will read off actual words "Collapse" and "Expand" instead of reading
"open brace minus close brace" and "open brace plus close brace".

Part of #87059

Update aarch64 runtime feature detection tests

Remove crypto composite feature from allowed aarch64 features.

Prefer using AES/SHA2 features directly.

Update `stdarch` to deprecate `crypto` aarch64 target_feature

Use `has_impl_trait` where possible

Do not suggest impl traits as type arguments

Auto merge of #87725 - JohnTitor:rollup-2ywcpuk, r=JohnTitor

Rollup of 8 pull requests

Successful merges:

 - #87645 (Properly find owner of closure in THIR unsafeck)
 - #87646 (Fix a parser ICE on invalid `fn` body)
 - #87652 (Validate that naked functions are never inlined)
 - #87685 (Write docs for SyncOnceCell From and Default impl)
 - #87693 (Add `aarch64-apple-ios-sim` as a possible target to the manifest)
 - #87708 (Add convenience method for handling ipv4-mapped addresses by canonicalizing them)
 - #87711 (Correct typo)
 - #87716 (Allow generic SIMD array element type)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #87716 - calebzulawski:master, r=workingjubilee

Allow generic SIMD array element type

Fixes the following:
```rust
#[repr(simd)]
struct V<T>([T; 4]);
```

cc ``@workingjubilee``

Rollup merge of #87711 - noproto:patch-1, r=GuillaumeGomez

Correct typo

Rollup merge of #87708 - the8472:canonical_v6, r=dtolnay

Add convenience method for handling ipv4-mapped addresses by canonicalizing them

This simplifies checking common properties in an address-family-agnostic
way since #86335 commits to not checking IPv4 semantics
of IPv4-mapped addresses in the `Ipv6Addr` property methods.

Rollup merge of #87693 - badboy:enable-ios-sim-target-manifest, r=Mark-Simulacrum

Add `aarch64-apple-ios-sim` as a possible target to the manifest

This should allow rustup and similar to actually make use of this new
target now.

r? ```@Mark-Simulacrum```

Followup to #85782

Rollup merge of #87685 - notriddle:lazy-from-docs, r=dtolnay

Write docs for SyncOnceCell From and Default impl

Part of #51430

Rollup merge of #87652 - npmccallum:naked_inline, r=Amanieu

Validate that naked functions are never inlined

Reject all uses of the inline attribute on naked functions.

https://github.com/rust-lang/rfcs/pull/2774
https://github.com/rust-lang/rfcs/pull/2972

cc `@joshtriplett` `@tmiasko` `@Amanieu`

Rollup merge of #87646 - JohnTitor:fix-parser-ice, r=oli-obk

Fix a parser ICE on invalid `fn` body

Fixes #87635
A better fix would add a check for `fn` body on `expected_one_of_not_found` but I haven't come up with a graceful way. Any idea?
r? ```@oli-obk``` ```@estebank```

Rollup merge of #87645 - LeSeulArtichaut:issue-87414, r=oli-obk

Properly find owner of closure in THIR unsafeck

Previously, when encountering a closure in a constant, the THIR unsafeck gets invoked on the owner of the constant instead of the constant itself, producing cycles.
Supersedes #87492. ```@FabianWolff``` thanks for your work on that PR, I copied your test file and added you as a co-author.

Fixes #87414.
r? ```@oli-obk```

Use .contains instead of manual reimplementation.

It's also significantly easier to read.

don't use .into() to convert types to identical types (clippy::useless_conversion)

Example:
let _x: String = String::from("hello world").into();

Auto merge of #87033 - FabianWolff:issue-87017, r=estebank

Provide a suggestion when trying to destructure a `Vec` as a slice

Fixes #87017.

r? `@estebank`

Auto merge of #87262 - dtolnay:negative, r=Aaron1011

Support negative numbers in Literal::from_str

proc_macro::Literal has allowed negative numbers in a single literal token ever since Rust 1.29, using https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.isize_unsuffixed and similar constructors.

```rust
let lit = proc_macro::Literal::isize_unsuffixed(-10);
```

However, the suite of constructors on Literal is not sufficient for all use cases, for example arbitrary precision floats, or custom suffixes in FFI macros.

```rust
let lit = proc_macro::Literal::f64_unsuffixed(0.101001000100001000001000000100000001); // :(
let lit = proc_macro::Literal::i???_suffixed(10ulong); // :(
```

For those, macros construct the literal using from_str instead, which preserves arbitrary precision, custom suffixes, base, and digit grouping.

```rust
let lit = "0.101001000100001000001000000100000001".parse::<Literal>().unwrap();
let lit = "10ulong".parse::<Literal>().unwrap();
let lit = "0b1000_0100_0010_0001".parse::<Literal>().unwrap();
```

However, until this PR it was not possible to construct a literal token that is **both** negative **and** preserving of arbitrary precision etc.

This PR fixes `Literal::from_str` to recognize negative integer and float literals.

Allow generic SIMD array element type

Auto merge of #86335 - CDirkx:ipv4-in-ipv6, r=dtolnay

Commit to not supporting IPv4-in-IPv6 addresses

Stabilization of the `ip` feature has for a long time been blocked on the question of whether Rust should support handling "IPv4-in-IPv6" addresses: should the various `Ipv6Address` property methods take IPv4-mapped or IPv4-compatible addresses into account. See also the IPv4-in-IPv6 Address Support issue #85609 and #69772 which originally asked the question.

# Overview

In the recent PR #85655 I proposed changing `is_loopback` to take IPv4-mapped addresses into account, so `::ffff:127.0.0.1` would be recognized as a looback address. However, due to the points that came up in that PR, I alternatively propose the following: Keeping the current behaviour and commit to not assigning any special meaning for IPv4-in-IPv6 addresses, other than what the standards prescribe. This would apply to the stable method `is_loopback`, but also to currently unstable methods like `is_global` and `is_documentation` and any future methods. This is implemented in this PR as a change in documentation, specifically the following section:

> Both types of addresses are not assigned any special meaning by this implementation, other than what the relevant standards prescribe. This means that an address like `::ffff:127.0.0.1`, while representing an IPv4 loopback address, is not itself an IPv6 loopback address; only `::1` is. To handle these so called "IPv4-in-IPv6" addresses, they have to first be converted to their canonical IPv4 address.

# Discussion

In the discussion for or against supporting IPv4-in-IPv6 addresses the question what would be least surprising for users of other languages has come up several times. At first it seemed most big other languages supported IPv4-in-IPv6 addresses (or at least considered `::ffff:127.0.0.1` a loopback address). However after further investigation it appears that supporting IPv4-in-IPv6 addresses comes down to how a language represents addresses. .Net and Go do not have a separate type for IPv4 or IPv6 addresses, and do consider `::ffff:127.0.0.1` a loopback address. Java and Python, which do have separate types, do not consider `::ffff:127.0.0.1` a loopback address. Seeing as Rust has the separate `Ipv6Addr` type, it would make sense to also not support IPv4-in-IPv6 addresses. Note that this focuses on IPv4-mapped addresses, no other language handles IPv4-compatible addresses.

Another issue that was raised is how useful supporting these IPv4-in-IPv6 addresses would be in practice. Again with the example of `::ffff:127.0.0.1`, considering it a loopback address isn't too useful as to use it with most of the socket APIs it has to be converted to an IPv4 address anyway. From that perspective it would be better to instead provide better ways for doing this conversion like stabilizing `to_ipv4_mapped` or introducing a `to_canonical` method.

A point in favour of not supporting IPv4-in-IPv6 addresses is that that is the behaviour Rust has always had, and that supporting it would require changing already stable functions like `is_loopback`. This also keeps the documentation of these functions simpler, as we only have to refer to the relevant definitions in the IPv6 specification.

# Decision

To make progress on the `ip` feature, a decision needs to be made on whether or not to support IPv4-in-IPv6 addresses.
There are several options:

- Keep the current implementation and commit to never supporting IPv4-in-IPv6 addresses (accept this PR).
- Support IPv4-in-IPv6 addresses in some/all `IPv6Addr` methods (accept PR #85655).
- Keep the current implementation and but not commit to anything yet (reject both this PR and PR #85655), this entire issue will however come up again in the stabilization of several methods under the `ip` feature.

There are more options, like supporting IPv4-in-IPv6 addresses in `IpAddr` methods instead, but to my knowledge those haven't been seriously argued for by anyone.

There is currently an FCP ongoing on PR #85655. I would ask the libs team for an alternative FCP on this PR as well, which if completed means the rejection of PR #85655, and the decision to commit to not supporting IPv4-in-IPv6 addresses.

If anyone feels there is not enough evidence yet to make the decision for or against supporting IPv4-in-IPv6 addresses, let me know and I'll do whatever I can to resolve it.

Validate that naked functions are never inlined

Reject all uses of the inline attribute on naked functions.

rust-lang/rfcs#2774
rust-lang/rfcs#2972

Another one

Correct typo

Auto merge of #87628 - estebank:unmet-explicit-lifetime-bound, r=oli-obk

Point at unmet explicit lifetime obligation bound

r? `@oli-obk`

Split off of #85799.

Auto merge of #87706 - RalfJung:miri, r=RalfJung

update miri

Fixes https://github.com/rust-lang/rust/issues/87703
Cc `@rust-lang/miri` r? `@ghost`

Add convenience for handling ipv4-mapped addresses by canonicalizing them

This simplifies checking common properties in an address-family-agnostic
way since since #86335 commits to not checking IPv4 semantics
of IPv4-mapped addresses in the `Ipv6Addr` property methods.

Auto merge of #87705 - ehuss:update-mdbook, r=Mark-Simulacrum

Update mdbook.

This fixes a significant rendering regression in 0.4.11 for code blocks, see https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0412.

Various adjustments to historic tests and documents.

Added tests.

Added page to Unstable Book.

Small refactorings for miri.

Implement pointer casting.

Run rustfix in `pattern-slice-vec.rs` UI test

update miri

Update mdbook.

Auto merge of #87698 - camsteffen:rollup-yvjfc26, r=camsteffen

Rollup of 6 pull requests

Successful merges:

 - #86176 (Implement a `explicit_generic_args_with_impl_trait` feature gate)
 - #87654 (Add documentation for the order of Option and Result)
 - #87659 (Fix invalid suggestions for non-ASCII characters in byte constants)
 - #87673 (Tweak opaque type mismatch error)
 - #87687 (Inline some macros)
 - #87690 (Add missing "allocated object" doc link to `<*mut T>::add`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

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`.

Rollup merge of #87687 - camsteffen:inline-macros, r=oli-obk

Inline some macros

I factored out some macros that are not really necessary.

Rollup merge of #87673 - estebank:opaque-ty-mismatch, r=davidtwco

Tweak opaque type mismatch error

Rollup merge of #87659 - FabianWolff:issue-87397, r=davidtwco

Fix invalid suggestions for non-ASCII characters in byte constants

Fixes #87397.

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.

Rollup merge of #86176 - nbdd0121:explicit-generic-args, r=jackh726

Implement a `explicit_generic_args_with_impl_trait` feature gate

Implements #83701

When this gate is enabled, explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from  `impl Trait`

So code like this will be accepted:
```rust
#![feature(explicit_generic_args_with_impl_trait)]

fn foo<T: ?Sized>(_f: impl AsRef<T>) {}
fn main() {
    foo::<str>("".to_string());
}
```

Auto merge of #87248 - RalfJung:ctfe-partial-overwrite, r=oli-obk

CTFE: throw unsupported error when partially overwriting a pointer

Currently, during CTFE, when a write to memory would overwrite parts of a pointer, we make the remaining parts of that pointer "uninitialized". This is probably not what users expect, so if this ever happens they will be quite confused about why some of the data just vanishes for seemingly no good reason.
So I propose we change this to abort CTFE when that happens, to at last avoid silently doing the wrong thing.
Cc https://github.com/rust-lang/rust/issues/87184

Our CTFE test suite still seems to pass. However, we should probably crater this, and I want to do some tests with Miri as well.

Auto merge of #87625 - nielx:fix/libz-sys-1.1.3, r=Mark-Simulacrum

Update libz-sys to 1.1.3

This update to libz-sys allows rustc to be cross-compiled for Haiku (Tier 3 platform).

Add `aarch64-apple-ios-sim` as a possible target to the manifest

This should allow rustup and similar to actually make use of this new
target now.

Auto merge of #87297 - ZuseZ4:new_build_flags, r=Mark-Simulacrum

add two new build flags to build clang and enable llvm plugins

Based on the discussion here: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Add.20configure.20flag.20to.20build.20clang/near/246439138

It allows building clang (which already is part of the llvm-project) based on the same llvm version which we use to build rustc.
It also allows enabling llvm's plugin interface, which is required for https://enzyme.mit.edu/.

There is no further integration beside of this basic build support.

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.

Implement a `explicit_generic_args_with_impl_trait` feature gate

When this gate is enabled, explicit generic arguments can be specified even
if `impl Trait` is used in argument position. Generic arguments can only be
specified for explicit generic parameters but not for the synthetic type
parameters from  `impl Trait`

Add missing "allocated object" doc link

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

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`

Rollup merge of #87644 - Flying-Toast:vec-remove-note, r=the8472

Recommend `swap_remove` in `Vec::remove` docs

I was able to increase the performance (by 20%!) of my project by changing a `Vec::remove` call to `Vec::swap_remove` in a hot function. I think we should explicitly put a note in the Vec::remove docs to guide people in the right direction so they don't make a similar oversight.

Rollup merge of #87633 - Amanieu:fix-86063, r=Mark-Simulacrum

Update compiler_builtins to fix i128 shift/mul on thumbv6m

Fixes #86063

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

Rollup merge of #87608 - Aaron1011:remove-system-library, r=Mark-Simulacrum

Remove unused field `Session.system_library_path`

Rollup merge of #87504 - ehuss:update-mdbook, r=Mark-Simulacrum

Update mdbook.

Just a few minor changes.  The changelog may be found at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md, for changes from 0.4.8 to 0.4.11.

Rollup merge of #87468 - calebcartwright:update-rustfmt, r=Mark-Simulacrum

Update rustfmt

Believe this gets everything back in order as both push and pull are working fine again. May do another small sync in the near future for my own sanity, but going forward will try to get on the same recurring cadence that clippy follows

Rollup merge of #87282 - pietroalbini:refactor-extended, r=Mark-Simulacrum

Ensure `./x.py dist` adheres to `build.tools`

According to `config.toml.example`, the way to produce dist artifacts for both the compiler and a *subset* of tools would be to enable the extended build and manually specify the list of tools to build:

```toml
[build]
extended = true
tools = ["cargo", "rustfmt"]
```

This works as expected for `./x.py build` and `./x.py install`, but *not* for `./x.py dist`. Before this PR `./x.py dist` simply ignored the contents of `build.tools`, building just rustc/rustdoc if `build.extended = false` and all of the tools otherwise. This PR does two things:

* Changes `./x.py dist extended` to only build the tools defined in `build.tools`, if `build.tools` is not empty. The rest of the extended step was refactored to simplify the code.
* Changes how dist jobs for tools are gated: instead of `assert!(builder.config.extended)` to prevent tools from being built with `build.extended = false`, tools are simply built by default depending on `build.extended` and `build.tools`. This also enables to **explicitly** dist tools even with `build.extended = false`.

This PR is best reviewed commit-by-commit.

Fixes #86436

Rollup merge of #86936 - CDirkx:ipv6-multicast, r=JohnTitor

Add documentation for `Ipv6MulticastScope`

Adds basic documentation to the unstable `Ipv6MulticastScope`, as well as marking it `#[non_exhaustive]` because future IETF RFCs may introduce additional scopes. The documentation mentions this in a section "Stability Guarantees":

> /// Not all possible values for a multicast scope have been assigned.
/// Future RFCs may introduce new scopes, which will be added as variants to this enum;
/// because of this the enum is marked as `#[non_exhaustive]`.

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

Rollup merge of #86509 - CDirkx:os_str, r=m-ou-se

Move `os_str_bytes` to `sys::unix`

Followup to #84967, with `OsStrExt` and `OsStringExt` moved out of `sys_common`, there is no reason anymore for `os_str_bytes` to live in `sys_common` and not in sys. This pr moves it to the location `sys::unix::os_str` and reuses the code on other platforms via `#[path]` (as is common in `sys`) instead of importing.

Rollup merge of #86439 - CDirkx:ip-protocol-assignment, r=m-ou-se

Remove `Ipv4Addr::is_ietf_protocol_assignment`

This PR removes the unstable method `Ipv4Addr::is_ietf_protocol_assignment`, as I suggested in https://github.com/rust-lang/rust/issues/85612#issuecomment-847863404. The method was added in #60145, as far as I can tell primarily for the implementation of `Ipv4Addr::is_global` (addresses reserved for IETF protocol assignment are not globally reachable unless otherwise specified).

The method was added in 2019, but I haven't been able to find any open-source code using this method so far. I'm also having a hard time coming up with a usecase for specifically this method; knowing that an address is reserved for future protocols doesn't allow you to do much with it, especially since now some of those addresses are indeed assigned to a protocol and have their own behaviour (and might even be defined to be globally reachable, so if that is what you care about it is always more accurate to call `!is_global()`, instead of `is_ietf_protocol_assignment()`).

Because of these reasons, I propose removing the method (or alternatively make it a private helper for `is_global`) and also not introduce `Ipv6Addr::is_ietf_protocol_assignment` and `IpAddr::is_ietf_protocol_assignment` in the future.

Rollup merge of #86183 - inquisitivecrystal:env-nul, r=m-ou-se

Change environment variable getters to error recoverably

This PR changes the standard library environment variable getter functions to error recoverably (i.e. not panic) when given an invalid value.

On some platforms, it is invalid for environment variable names to contain `'\0'` or `'='`, or for their values to contain `'\0'`. Currently, the standard library panics when manipulating environment variables with names or values that violate these invariants. However, this behavior doesn't make a lot of sense, at least in the case of getters. If the environment variable is missing, the standard library just returns an error value, rather than panicking. It doesn't make sense to treat the case where the variable is invalid any differently from that. See the [internals thread](https://internals.rust-lang.org/t/why-should-std-var-panic/14847) for discussion. Thus, this PR changes the functions to error recoverably in this case as well.

If desired, I could change the functions that manipulate environment variables in other ways as well. I didn't do that here because it wasn't entirely clear what to change them to. Should they error silently or do something else? If someone tells me how to change them, I'm happy to implement the changes.

This fixes #86082, an ICE that arises from the current behavior. It also adds a regression test to make sure the ICE does not occur again in the future.

`@rustbot` label +T-libs
r? `@joshtriplett`

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.

Inline make_if macro

Inline create_maybe_get_coercion_reason macro

Auto merge of #86031 - ssomers:btree_lazy_iterator, r=Mark-Simulacrum

BTree: lazily locate leaves in rangeless iterators

BTree iterators always locate both the first and last leaf edge and often only need either one, i.e., whenever they are traversed in a single direction, like in for-loops and in the common use of `iter().next()` or `iter().next_back()` to retrieve the first or last key/value-pair (#62924). It's fairly easy to avoid because the iterators with this disadvantage already are quite separate from other iterators.

r? `@Mark-Simulacrum`

Write docs for SyncOnceCell From and Default impl

Auto merge of #87622 - pietroalbini:bump-bootstrap, r=Mark-Simulacrum

Bump bootstrap compiler to 1.55

Changing the cfgs for stdarch is missing, but my understanding is that we don't need to do it as part of this PR?

r? `@Mark-Simulacrum`

Auto merge of #81825 - voidc:pidfd, r=joshtriplett

Add Linux-specific pidfd process extensions (take 2)

Continuation of #77168.
I addressed the following concerns from the original PR:

- make `CommandExt` and `ChildExt` sealed traits
- wrap file descriptors in `PidFd` struct representing ownership over the fd
- add `take_pidfd` to take the fd out of `Child`
- close fd when dropped

Tracking Issue: #82971

Update const_slice_first_last_not_mut stable version.

bump bootstrap compiler to 1.55

Auto merge of #87664 - devnexen:netbsd_sanitizers_support, r=nagisa

netbsd x86_64 arch enable supported sanitizers.

Add documentation for the order of Option and Result

Auto merge of #87546 - rusticstuff:issue87450-take-two, r=davidtwco

Bail on any found recursion when expanding opaque types

Fixes #87450. More of a bandaid because it does not fix the exponential complexity of the type folding used for opaque type expansion.

Auto merge of #87449 - matthiaskrgr:clippyy_v2, r=nagisa

more clippy::complexity fixes

(also a couple of clippy::perf fixes)

Check whether clone3 syscall exists in pidfd test

Add dummy FileDesc struct for doc target

Do not call getpid wrapper after fork in tests

The test calls libc::getpid() in the pre_exec hook and asserts that the returned value is different from the PID of the parent.
However, libc::getpid() returns the wrong value.
Before version 2.25, glibc caches the PID of the current process with the goal of avoiding additional syscalls.
The cached value is only updated when the wrapper functions for fork or clone are called.
In PR #81825 we switch to directly using the clone3 syscall.
Thus, the cache is not updated and getpid returns the PID of the parent.
source: https://man7.org/linux/man-pages/man2/getpid.2.html#NOTES

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 https://github.com/dtolnay/colorous/blob/a4131708e2f05d2377964981896ff62dbc9b027b/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]`
```

Fix unused sync::atomic import on targets without atomics

Auto merge of #85782 - badboy:build-ios-sim-target, r=Mark-Simulacrum

Build aarch64-apple-ios-sim as part of the full macOS build

Part of the [MCP 428](https://github.com/rust-lang/compiler-team/issues/428) to promote this target to Tier 2.

This adds the aarch64-apple-ios-sim target as a tier 2 target, currently cross-compiled from our x86_64 apple builders. The compiler team has approved the addition per the MCP noted above, and the infrastructure team has not raised concerns with this addition at this time (as the CI time impact is expected to be minimal; this is only building std).

add two new build flags to build clang and enable llvm plugins