Fix URL conflict for std type

Remove LightSpan and use Span directly

Remove warnings/errors from compiler when using typeck_body in rustdoc span map builder

* Rename LightSpan::empty into LightSpan::dummy
* Add Classifier::new_light_span to wrap LightSpan::new_in_file constructor

Add missing root_path when generating links using href

Add documentation and FIXME

Fix invalid generation of HTML in highlight

formatting

Use rustdoc Span in LinkFromSrc directly

Move extra arguments for highlight URL generation into a new ContextInfo struct for better readability

Wrap the span_map tuple index into a type called "LightSpan"

Improve code readability

* Rename Span::from_rustc_span to Span::new
* Rename Span::wrap to Span::wrap_raw
* Improve documentation for Span::wrap_raw

* Rename 'move_span' into 'local_span_to_global_span'
* Add documentation on new arguments/functions

Underline source code links on hover

Update rustdoc tests

Generate links for modules as well

Add test for source code pages URLs

Generate links for methods as well

Ensure that --generate-link-to-definition is only used with HTML output and is unstable

Add an option for the source code link generation

Add links on source types to go to definition

Auto merge of #87768 - rust-lang:core-features-cleanup, r=dtolnay

Core features cleanup

This sorts and categorizes the `#![features]` in `core` and removes unused ones.

This is part of #87766

The following feature attributes were unnecessary and are removed:

```diff
// Library features:
-#![feature(bool_to_option)]
-#![feature(char_indices_offset)]
-#![feature(pin_deref_mut)]
-#![feature(str_split_as_str)]
-#![feature(str_split_inclusive_as_str)]

// Language features:
-#![feature(arbitrary_self_types)]
-#![feature(custom_inner_attributes)]
-#![feature(nll)]
```

Auto merge of #87737 - LeSeulArtichaut:unsafeck-less-freeze, r=oli-obk

Only compute `is_freeze` for layout-constrained ADTs

Places are usually shallow and quick to visit. By contrast, computing `is_freeze` can be much costlier, involving inference and trait solving. Making sure to call `is_freeze` only when necessary should be beneficial for performance in most cases.

See [this comparison](https://perf.rust-lang.org/compare.html?start=81f08a4763e7537b92506fa5a597e6bf774d20cc&end=56a58d347b1c7dd0c2984b8fc3930c408e26fbc2&stat=instructions%3Au) from #87710.

r? `@oli-obk`

Make rustfmt happy.

Remove unnecessary #[unstable] from internal macro.

After this change, all library #![feature]s enabled in core are for
const fns.

Remove unused langauge #![feature]s from core.

Remove unused library #![feature]s from core.

Sort and categorize lint and feature attributes in core.

Auto merge of #87740 - npmccallum:naked_args, r=Amanieu

Disable unused variable lint for naked functions

In most calling conventions, accessing function parameters may require
stack access. However, naked functions have no assembly prelude to set
up stack access.  This is why naked functions may only contain a single
`asm!()` block. All parameter access is done inside the `asm!()` block,
so we cannot validate the liveness of the input parameters. Therefore,
we should disable the lint for naked functions.

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

`@joshtriplett` `@Amanieu` `@haraldh`

Auto merge of #87532 - tlyu:bootstrap-rev-list, r=jyn514

bootstrap.py: use `git rev-list` for robustness

Use `git rev-list` instead of `git log` to be more robust against
UI changes in git. Also, use the full email address for bors,
because `--author` uses a substring match.

Based on #87513, but is separate because it's less minimal and may require additional manual testing.

~Open questions:~
* ~Should the `merge_base` search also use `--first-parent`?~
* ~Do we exclude non-merge commits from bors? There are a few, and I'm not sure what they have in common. Some of them look like squashes, and some look like they're in rollup branches.~

r? `@jyn514`
`@rustbot` label +A-rustbuild +C-cleanup

Auto merge of #87641 - HackAttack:expand-unknown-option-message, r=wesleywiser

Allow more "unknown argument" strings from linker

Some toolchains emit slightly different errors, e.g.

    ppc-vle-gcc: error: unrecognized option '-no-pie'

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.

Disable unused variable lint for naked functions

In most calling conventions, accessing function parameters may require
stack access. However, naked functions have no assembly prelude to set
up stack access.  This is why naked functions may only contain a single
`asm!()` block. All parameter access is done inside the `asm!()` block,
so we cannot validate the liveness of the input parameters. Therefore,
we should disable the lint for naked functions.

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

Add test for naked function unused variables lint

This test proves that naked functions are treated the same as regular
functions regarding unused function parameters. We will change this
behavior in the next patch.

Auto merge of #87695 - tmiasko:gep-opaque-pointers, r=nagisa

Prepare GEP building for opaque pointers

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.

Fix assertions in `coverage-reports` test

Update some `C-unwind` bits and then

Replace LLVMConstInBoundsGEP with LLVMConstInBoundsGEP2*

A custom reimplementation of LLVMConstInBoundsGEP2 is used, since the
LLVM contains a declaration of LLVMConstInBoundsGEP2 but not the
implementation.

Prepare inbounds_gep for opaque pointers

Implement inbounds_gep using LLVMBuildInBoundsGEP2 which takes an
explicit type argument instead of deriving it from a pointer type.

Prepare gep for opaque pointers

Implement gep using LLVMBuildGEP2 which takes an explicit type argument
instead of deriving it from a pointer type.

Prepare struct_gep for opaque pointers

Imlement struct_gep using LLVMBuildStructGEP2 which takes an explicit
type argument instead of deriving it from a pointer type.

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

Auto merge of #86197 - FabianWolff:trailing-whitespace, r=JohnTitor

Remove unnecessary trailing whitespace from error messages

Some error messages currently contain unnecessary trailing whitespace. There are some legitimate reasons for having trailing whitespace in the output, such as for uniform indentation of possibly-empty input lines, but the whitespace I have addressed here occurs in a line used only for spacing, and I see no reason why that should have trailing whitespace (spacing lines inserted in other places also don't have trailing whitespace).

I have also removed a superfluous call to `buffer.putc()`, which has no effect because the same character is already placed there by `draw_col_separator()`.

Use `git diff --ignore-space-at-eol` to see my changes; otherwise the diff is quite large due to the whitespace removed from expected outputs in `src/test/ui/`.

Remove trailing whitespace from error messages

Auto merge of #87026 - FabianWolff:issue-86948, r=estebank

Allow labeled loops as value expressions for `break`

Fixes #86948. This is currently allowed:
```rust
return 'label: loop { break 'label 42; };
break ('label: loop { break 'label 42; });
break 1 + 'label: loop { break 'label 42; };
break 'outer 'inner: loop { break 'inner 42; };
```
But not this:
```rust
break 'label: loop { break 'label 42; };
```
I have fixed this, so that the above now parses as an unlabeled break with a labeled loop as its value expression.

Auto merge of #87712 - est31:line-column-1-based, r=petrochenkov

Proc macro spans: make columns 1 based

This makes proc macro spans consistent with the `column!()` macro as well as `std::panic::Location`, as both are 1-based.

https://github.com/rust-lang/rust/issues/54725#issuecomment-497246753

Auto merge of #87568 - petrochenkov:localevel, r=cjgillot

rustc: Replace `HirId`s with `LocalDefId`s in `AccessLevels` tables

and passes using those tables - primarily privacy checking, stability checking and dead code checking.

All these passes work with definitions rather than with arbitrary HIR nodes.
r? `@cjgillot`
cc `@lambinoo` (#87487)

Auto merge of #87746 - JohnTitor:rollup-zaapqgl, r=JohnTitor

Rollup of 8 pull requests

Successful merges:

 - #81797 (Add `core::stream::from_iter`)
 - #87267 (Remove space after negative sign in Literal to_string)
 - #87663 (Rustdoc accessibility: use an icon for the [-]/[+] controls)
 - #87720 (don't use .into() to convert types to identical types (clippy::useless_conversion))
 - #87723 (Use .contains instead of manual reimplementation.)
 - #87729 (Remove the aarch64 `crypto` target_feature)
 - #87731 (Update cargo)
 - #87734 (Test dropping union fields more)

Failed merges:

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

Rollup merge of #87734 - Smittyvb:more-union-tests, r=LeSeulArtichaut

Test dropping union fields more

Now that #87403 is merged, a few more tests can be added for reads/writes to dropping union fields.

r? ``@LeSeulArtichaut``

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

Only compute `is_freeze` for layout-constrained ADTs

Places are usually shallow and quick to visit. By contrast, computing
`is_freeze` can be much costlier, involving inference and trait
solving. Making sure to call `is_freeze` only when necessary should be
beneficial for performance in most cases.

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.

#[inline] slice::advance_by

Remove invalid suggestion involving Fn trait bound

Use a multipart suggestion for the parentheses

Test dropping union fields more

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

Relax a codegen test

nounwind is no longer emitted but the test still passes

Make simplify_cfg test more consistent

Force it to always use panic=abort which means that all targets should
produce the same MIR now.

Use predefined helper instead of a new one

Move abort_unwinding_calls earlier

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.

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

Make the UTF-8 statement more explicit and explicitly test for it

Add tests

Make columns 1 based