Auto merge of #83050 - osa1:issue83048, r=matthewjasper

Run analyses before thir-tree dumps

Fixes #83048

Auto merge of #83408 - ijackson:expose-splitinclusive, r=dtolnay

Expose str::SplitInclusive in alloc and therefore in std

This seems to have been omitted from the beginning when this feature was first introduced in 86bf96291d82.  Most users won't need to name this type which is probably why this wasn't noticed in the meantime.

See #83372 for a different but related bug.

### Notes for reviewers

I think I have got this right but TBH I am not very familiar with the relationship between core and std and so on.  <strike>I also haven't don't any kind of test (not even a build) yet.  I will do a local docs build to see that the type now appears in the std docs.</strike>  I did a local docs build and it has made this type appear as `std::str::SplitInclusive` as expected

The linkification of the return value from `str::split_inclusive` teleports me to the online url for `core::str::SplitInclusive`.  I think this may be a rustdoc anomaly (similar to #79630 maybe) but I am not sure.  Perhaps it means I haven't done the `std` -> `core` referrence correctly.

I made this insta-stable since it seems like simply a bug.  Please LMK if that is not right.  *(edited to add:)* In particular, IDK how this ought to relate to the (?)current release process.

Auto merge of #75384 - JulianKnodt:cg_def, r=varkor,lcnr

implement `feature(const_generics_defaults)`

Implements const generics defaults `struct Example<const N: usize=3>`, as well as a query for getting the default of a given const-parameter's def id. There are some remaining FIXME's but they were specified as not blocking for merging this PR. This also puts the defaults behind the unstable feature gate `#![feature(const_generics_defaults)]`.

~~This currently creates a field which is always false on `GenericParamDefKind` for future use when
consts are permitted to have defaults. I'm not sure if this is exactly what is best for adding default parameters, but I mimicked the style of type defaults, so hopefully this is ok.~~

r? `@lcnr`

Bump alloc::str::SplitInclusive to 1.53.0 release

Auto merge of #83432 - Dylan-DPC:rollup-4z5f6al, r=Dylan-DPC

Rollup of 9 pull requests

Successful merges:

 - #83051 (Sidebar trait items order)
 - #83313 (Only enable assert_dep_graph when query-dep-graph is enabled.)
 - #83353 (Add internal io::Error::new_const to avoid allocations.)
 - #83391 (Allow not emitting `uwtable` on Android)
 - #83392 (Change `-W help` to display edition level.)
 - #83393 (Codeblock tooltip position)
 - #83399 (rustdoc: Record crate name instead of using `None`)
 - #83405 (Slight visual improvements to warning boxes in the docs)
 - #83415 (Remove unnecessary `Option` wrapping around `Crate.module`)

Failed merges:

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

Rollup merge of #83415 - camelid:remove-crate-module-option, r=jyn514

Remove unnecessary `Option` wrapping around `Crate.module`

I'm wondering if it was originally there so that we could `take` the
module which enables `after_krate` to take an `&Crate`. However, the two
impls of `after_krate` only use `Crate.name`, so we can pass just the
name instead.

Rollup merge of #83405 - r00ster91:deprecated_emoji, r=GuillaumeGomez

Slight visual improvements to warning boxes in the docs

First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the [`text-shadow`](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow#browser_compatibility).
For consistency the microscope has the black border too.
Alternatively I had `drop-shadow(0px 0px 1px black);` in mind but its [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()#browser_compatibility) doesn't look as good and the blurry shadow probably doesn't look as good either.

Then, I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum.
But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. _only supported on Unix_). These are currently blue.

I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform, your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance "This is available since 1.0.0". None of the current three box types (unstable, deprecated and portability) are that.

I think purple is a better fit for it because it's kind of in the middle between "use it" and "don't use it". Deprecated is definitely "don't use it". To illustrate this better, here's a color spectrum:

Blue = friendly,  "use it".
Red = danger, "don't use it".

And the purple in the middle (the color that the portability box now has) probably represents "use it if you have to", so it's not entirely friendly and not entirely a danger. That is why I think it fits.

However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes.

This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes:

Rollup merge of #83399 - camelid:rustdoc-priv-link-from-crate, r=jyn514

rustdoc: Record crate name instead of using `None`

Fixes #83365.

r? `@jyn514`

Rollup merge of #83393 - GuillaumeGomez:codeblock-tooltip-position, r=Nemo157

Codeblock tooltip position

The codeblocks tooltips were misplaced. Normally, there is no top margin applied to a tooltip unless the codeblock is the first element of the doc block. The CSS rule was too vague though, applying it to all tooltips where the codeblock was the first child of its parent. Which can be easily seen with lists:

Before:


After:


r? ``@Nemo157``

Rollup merge of #83392 - ehuss:w-help-edition, r=varkor

Change `-W help` to display edition level.

`-W help` was not honoring the `--edition` flag when displaying the default lint level. It was using the edition for sorting, but not for the final display.

This isn't important right now as there aren't any edition-specific lint levels. Also, the `declare_lint` macro is broken and doesn't even allow setting them right now. However, I figure it wouldn't hurt to fix this before I forget about it, in case edition-specific lints are ever used in the future.

Rollup merge of #83391 - hyd-dev:uwtable, r=alexcrichton

Allow not emitting `uwtable` on Android

`uwtable` is marked as required on Android, so it can't be disabled via `-C force-unwind-tables=no`. However, I found that the reason it's marked as required was to resolve a [backtrace issue in Gecko](https://github.com/rust-lang/rust/issues/49867), and I haven't find any other reasons that make it required ([yet](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Unwind.20tables.20are.20strictly.20required.20on.20Windows.20and.20Android)). Therefore, I assume it's safe to turn it off if a (nice) backtrace is not needed, and submit this PR to allow `-C force-unwind-tables=no` when targeting Android.

Note that I haven't tested this change on Android as I don't have an Android environment for testing.

Rollup merge of #83353 - m-ou-se:io-error-avoid-alloc, r=nagisa

Add internal io::Error::new_const to avoid allocations.

This makes it possible to have a io::Error containing a message with zero allocations, and uses that everywhere to avoid the *three* allocations involved in `io::Error::new(kind, "message")`.

The function signature isn't perfect, because it needs a reference to the `&str`. So for now, this is just a `pub(crate)` function. Later, we'll be able to use `fn new_const<MSG: &'static str>(kind: ErrorKind)` to make that a bit better. (Then we'll also be able to use some ZST trickery if that would result in more efficient code.)

See https://github.com/rust-lang/rust/issues/83352

Rollup merge of #83313 - cjgillot:assert, r=michaelwoerister

Only enable assert_dep_graph when query-dep-graph is enabled.

This is a debugging option. The only effect should be on rustc tests.

r? ``@michaelwoerister``

Rollup merge of #83051 - GuillaumeGomez:sidebar-trait-items-order, r=CraftSpider,jyn514

Sidebar trait items order

We were actually sorting `Symbol` and not `String`, creating a completely invalid sort result. I added a test to prevent regressions.

r? ``@jyn514``

Update to not have extra match

Auto merge of #82994 - camelid:rename-source-to-span, r=jyn514

Rename `source` to `span` and `span` to `source`

- Rename `clean::Item.source` to `span`
- Rename `clean::Span::span()` to `clean::Span::inner()`
- Rename `rustdoc_json_types::Item.source` to `span`
- rustdoc-json: Rename `Import.span` to `Import.source`

*See also the [discussion on Zulip][z] (this is a bit more than discussed in
that conversation, but all the changes are related).*

r? `@jyn514`

[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/get.20span.20of.20file.20from.20name/near/229603729

Remove another unnecessary `Option`

The previous changes mean that we can now remove this `Option`.

Remove unnecessary `Option` wrapping around `Crate.module`

I'm wondering if it was originally there so that we could `take` the
module which enables `after_krate` to take an `&Crate`. However, the two
impls of `after_krate` only use `Crate.name`, so we can pass just the
name instead.

Tweak docs

Co-authored-by: Joshua Nelson <joshua@yottadb.com>

Update with comments

Update with comments

A bunch of nits fixed, and a new test for pretty printing the AST.

Add query for const_param_default

Update tests

progress, stuff compiles now

Some refactoring

Add has_default to GenericParamDefKind::Const

This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults

Update const_generics:default locations

Previously just ignored them, now actually do something about them.

Fix using type check instead of value

Add parsing

This adds all the necessary changes to lower const-generics defaults from parsing.

Change P<Expr> to AnonConst

This matches the arguments passed to instantiations of const generics, and makes it specific to
just anonymous constants.

Attempt to fix lowering bugs

Fix comment.

Use &str instead of String

Add test to enforce sidebar trait items order

Fix sidebar trait items sort

Auto merge of #83177 - erikdesjardins:zstassign, r=oli-obk

Remove assignments to ZST places instead of marking ZST return place as unused

partially reverts #83118

requested by `@tmiasko` in https://github.com/rust-lang/rust/pull/83118#issuecomment-799692574

r? `@oli-obk`

Expose str::SplitInclusive in alloc and therefore in std

This seems to have been omitted from the beginning when this feature
was first introduced in 86bf96291d82.

Most users won't need to name this type which is probably why this
wasn't noticed in the meantime.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Slight visual improvements to warning boxes in the docs

Auto merge of #83260 - durin42:llvm-update, r=nagisa

rustc: changes to allow an llvm update

This lets LLVM be built using 2b5f3f446f36, which is only a few weeks old. The next change in LLVM (5de2d189e6ad) breaks rustc again by removing a function that's exposed into the Rust code, but I'll file a bug about that separately.

Please scrutinize the `thinLTOResolvePrevailingInIndex` call, as I'm not at all sure an empty config is right.

I'm also suspicious that a specific alignment could be specified in the call to CreateAtomicCmpXchg, but I don't know enough to figure that out.

Thanks!

Auto merge of #82271 - Aaron1011:debug-refcell, r=m-ou-se

Add `debug-refcell` feature to libcore

See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614
for some background discussion

This PR adds a new off-by-default feature `debug-refcell` to libcore.
When enabled, this feature stores additional debugging information in
`RefCell`. This information is included in the panic message when
`borrow()` or `borrow_mut()` panics, to make it easier to track down the
source of the issue.

Currently, we store the caller location for the earliest active borrow.
This has a number of advantages:
* There is only a constant amount of overhead per `RefCell`
* We don't need any heap memory, so it can easily be implemented in core
* Since we are storing the *earliest* active borrow, we don't need any
  extra logic in the `Drop` implementation for `Ref` and `RefMut`

Limitations:
* We only store the caller location, not a full `Backtrace`. Until
  we get support for `Backtrace` in libcore, this is the best tha we can
do.
* The captured location is only displayed when `borrow()` or
  `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()`
  or `try_borrow_mut().unwrap()`, this extra information will be lost.

To make testing easier, I've enabled the `debug-refcell` feature by
default. I'm not sure how to write a test for this feature - we would
need to rebuild core from the test framework, and create a separate
sysroot.

Since this feature will be off-by-default, users will need to use
`xargo` or `cargo -Z build-std` to enable this feature. For users using
a prebuilt standard library, this feature will be disabled with zero
overhead.

I've created a simple test program:

```rust
use std::cell::RefCell;

fn main() {
    let _ = std::panic::catch_unwind(|| {
        let val = RefCell::new(true);
        let _first = val.borrow();
        let _second = val.borrow();
        let _third = val.borrow_mut();
    });

    let _ = std::panic::catch_unwind(|| {
        let val  = RefCell::new(true);
        let first = val.borrow_mut();
        drop(first);

        let _second = val.borrow_mut();

        let _thid = val.borrow();
    });
}
```

which produces the following output:

```
thread 'main' panicked at 'already borrowed: BorrowMutError at refcell_test.rs:6:26', refcell_test.rs:8:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'already mutably borrowed: BorrowError at refcell_test.rs:16:27', refcell_test.rs:18:25
```

Don't push the crate name onto the `Cache.stack`

Now that we record the crate's name in its `clean::Item`, pushing the
crate name onto the `stack` causes duplicate paths. E.g., the URL
generated for the path `::foo::bar::baz` would be something like

    ../foo/foo/bar/baz

With this commit, the URL is corrected to

    ../foo/bar/baz

Auto merge of #83398 - JohnTitor:rollup-om80krv, r=JohnTitor

Rollup of 7 pull requests

Successful merges:

 - #80705 (Update Source Code Pro and include italics)
 - #81917 (Update RELEASES.md for 1.51.0)
 - #82732 (Remove theme.js file)
 - #83356 (rustdoc: Replace pair of `Option`s with an enum)
 - #83384 (rename :pat2018 -> :pat2015)
 - #83385 (:arrow_up: rust-analyzer)
 - #83389 (add rust-analyzer rustc_private option in librustdoc Cargo.toml)

Failed merges:

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

rustdoc: Record crate name instead of using `None`

Rollup merge of #83389 - njasm:test_rustdoc, r=jyn514

add rust-analyzer rustc_private option in librustdoc Cargo.toml

This addition will allow to have code completion while hacking rustdoc with rust-analyzer.

more info: https://rust-analyzer.github.io/manual.html#rust-analyzer.rustcSource

r? `@jyn514`

Rollup merge of #83385 - lnicola:rust-analyzer-2021-03-22, r=jonas-schievink

:arrow_up: rust-analyzer

Rollup merge of #83384 - mark-i-m:rename-pat2018, r=joshtriplett

rename :pat2018 -> :pat2015

as requested by T-lang on zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873

No functional changes here... just renaming.

r? `@nikomatsakis`

Rollup merge of #83356 - camelid:rustdoc-option-to-enum, r=GuillaumeGomez

rustdoc: Replace pair of `Option`s with an enum

They are never both `None` or both `Some`, so it makes more sense to use
an enum so that we "make impossible states impossible".

Rollup merge of #82732 - GuillaumeGomez:remove-theme-file, r=Nemo157

Remove theme.js file

Fixes #82616.

The first commit moves the `theme.js` file into `main.js`, which requires to also run a small `.replace` on the `main.js` content.

The second commit is just a small cleanup to centralize DOM ids.

Since it removes a file from rustdoc output: cc `@rust-lang/docs-rs`

cc `@jsha`
r? `@jyn514`

Rollup merge of #81917 - rust-lang:relnotes-1.51.0, r=Mark-Simulacrum

Update RELEASES.md for 1.51.0

### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.51.0/RELEASES.md)

r? `@Mark-Simulacrum`
cc `@rust-lang/release`

Rollup merge of #80705 - tspiteri:italic-and-update-SourceCodePro, r=GuillaumeGomez

Update Source Code Pro and include italics

Fixes #65502.

#65665, a similar PR to this was merged but reverted because of https://github.com/rust-lang/rust/pull/65665#issuecomment-556860510.

The issue in that comment is the upstream issue https://github.com/adobe-fonts/source-code-pro/issues/217 which should now be fixed in the upstream since [2.032R-ro/1.052R-it/1.012R-VAR release](https://github.com/adobe-fonts/source-code-pro/releases/tag/2.032R-ro/1.052R-it/1.012R-VAR), so I think this can now be merged.

A couple of notes from the original PR:
* Since this PR changes the font set, I think docs.rs would have to be updated if this PR is merged.
* The fonts have a double extension (.ttf.woff); this is to keep the names consistent with the upstream font release which does that to distinguish these from the .otf.woff files (Source Code Pro otf renders poorly on older Windows system apps).

only run RemoveZsts at mir-opt-level 3 and above

Add GUI test to enforce tooltip position

Fix codeblock tooltip position

Allow not emitting `uwtable` on Android

Err if the debugging options are not passed.

Change `-W help` to display edition level.

Auto merge of #79278 - mark-i-m:stabilize-or-pattern, r=nikomatsakis

Stabilize or_patterns (RFC 2535, 2530, 2175)

closes #54883

This PR stabilizes the or_patterns feature in Rust 1.53.

This is blocked on the following (in order):
- [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021
- [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705)
    - It looks like we will need to pursue some sort of edition-based transition for `:pat`.
- [x] Nomination and discussion by T-lang
- [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100).
- [ ] An FCP on stabilization

EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177

missing newline at eof

add key rustc_private for package metadata for rust-analyzer in librustdoc

cleanup: add some comments per review feedback

:arrow_up: rust-analyzer

Only enable assert_dep_graph when query-dep-graph is enabled.

rename :pat2018 -> :pat215

Add `debug-refcell` feature to libcore

See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614
for some background discussion

This PR adds a new off-by-default feature `debug-refcell` to libcore.
When enabled, this feature stores additional debugging information in
`RefCell`. This information is included in the panic message when
`borrow()` or `borrow_mut()` panics, to make it easier to track down the
source of the issue.

Currently, we store the caller location for the earliest active borrow.
This has a number of advantages:
* There is only a constant amount of overhead per `RefCell`
* We don't need any heap memory, so it can easily be implemented in core
* Since we are storing the *earliest* active borrow, we don't need any
  extra logic in the `Drop` implementation for `Ref` and `RefMut`

Limitations:
* We only store the caller location, not a full `Backtrace`. Until
  we get support for `Backtrace` in libcore, this is the best tha we can
do.
* The captured location is only displayed when `borrow()` or
  `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()`
  or `try_borrow_mut().unwrap()`, this extra information will be lost.

To make testing easier, I've enabled the `debug-refcell` feature by
default. I'm not sure how to write a test for this feature - we would
need to rebuild core from the test framework, and create a separate
sysroot.

Since this feature will be off-by-default, users will need to use
`xargo` or `cargo -Z build-std` to enable this feature. For users using
a prebuilt standard library, this feature will be disabled with zero
overhead.

I've created a simple test program:

```rust
use std::cell::RefCell;

fn main() {
    let _ = std::panic::catch_unwind(|| {
        let val = RefCell::new(true);
        let _first = val.borrow();
        let _second = val.borrow();
        let _third = val.borrow_mut();
    });

    let _ = std::panic::catch_unwind(|| {
        let val  = RefCell::new(true);
        let first = val.borrow_mut();
        drop(first);

        let _second = val.borrow_mut();

        let _thid = val.borrow();
    });
}
```

which produces the following output:

```
thread 'main' panicked at 'already borrowed: BorrowMutError { location: Location { file: "refcell_test.rs", line: 6, col: 26 } }', refcell_test.rs:8:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'already mutably borrowed: BorrowError { location: Location { file: "refcell_test.rs", line: 16, col: 27 } }', refcell_test.rs:18:25
```

Auto merge of #83376 - Dylan-DPC:rollup-s2fsjwj, r=Dylan-DPC

Rollup of 7 pull requests

Successful merges:

 - #82374 (Add license metadata for std dependencies)
 - #82683 (Document panicking cases for integer division and remainder)
 - #83272 (Clarify non-exact length in the Iterator::take documentation)
 - #83338 (Fix test for #82270)
 - #83351 (post-drop-elab check-const: explain why we still check qualifs)
 - #83367 (Improve error message for unassigned query provider)
 - #83372 (SplitInclusive is public API)

Failed merges:

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

Rollup merge of #83372 - eggyal:split-inclusive, r=Mark-Simulacrum

SplitInclusive is public API

Rollup merge of #83367 - richkadel:query-err-msg, r=jyn514

Improve error message for unassigned query provider

Fixes: #83122
r? `@jyn514`

This implements the change we agreed on. Thanks!

Rollup merge of #83351 - RalfJung:precise-const-drop, r=oli-obk

post-drop-elab check-const: explain why we still check qualifs

r? `@oli-obk`

Rollup merge of #83338 - asquared31415:asm-syntax-test-fix, r=Dylan-DPC

Fix test for #82270

Fixes a test in #82270 to require the arm llvm component

Rollup merge of #83272 - kornelski:takedocs, r=dtolnay

Clarify non-exact length in the Iterator::take documentation

There's an example which demonstrates incomplete length case, but it'd be best to explain it right from the start.

Rollup merge of #82683 - jturner314:int-div-rem-doc-panic, r=nikomatsakis

Document panicking cases for integer division and remainder

This PR documents the cases when integer division and remainder operations panic. These operations panic in two cases: division by zero and overflow.

It's surprising that these operations always panic on overflow, unlike most other arithmetic operations, which panic on overflow only when `debug_assertions` is enabled. The panic on overflow for the remainder is also surprising because a return value of `0` would be reasonable in this case. ("Overflow" occurs only for `MIN % -1`.) Since the panics on overflow are somewhat surprising, they should be documented.

I guess it's worth asking: is panic on overflow (even when `debug_assertions` is disabled) the intended behavior? If not, what's the best way forward?

Rollup merge of #82374 - clehner:licenses, r=joshtriplett

Add license metadata for std dependencies

These five crates are in the dependency tree of `std` but lack license metadata:
- `alloc`
- `core`
- `panic_abort`
- `panic_unwind`
- `unwind`

Querying the dependency tree of `std` is a useful thing to be able to do, since these crates will typically be linked into Rust binaries. Tools show the license fields missing, as seen in https://github.com/rust-lang/rust/issues/67014#issuecomment-782704534. This PR adds the license field for the five crates, based on the license of the `std` package and this repo as a whole. I also added the `repository` and `descriptions` fields, since those seem useful. For `description`, I copied text from top-level comments for the respective modules - except for `unwind` which has none.

I also note that https://github.com/rust-lang/rust/pull/73530 attempted to add license metadata for all crates in this repo, but was rejected because there was question about some of them. I hope that this smaller change, focusing only on the runtime dependencies, will be easier to review.

cc `@Mark-Simulacrum` `@Lokathor`

Auto merge of #83273 - cjgillot:endecode, r=michaelwoerister

Simplify encoder and decoder

Extracted from https://github.com/rust-lang/rust/pull/83036 and https://github.com/rust-lang/rust/pull/82780.

Auto merge of #82680 - jturner314:div_euclid-docs, r=JohnTitor

Fix inequality in docs for div_euclid

This commit fixes the statement of the inequality that the Euclidean remainder satisfies. (The remainder is guaranteed to be less than abs(rhs), not rhs.) It also rewords the documentation to make it a little easier to read.

(You might wonder why I've written `abs(rhs)` instead of `rhs.abs()`. Two reasons: first, the `rem_euclid` docs use `abs(rhs)` instead of `rhs.abs()`, and second, the absolute value here is the mathematical absolute value, not the the `.abs()` operation which may overflow.)

SplitInclusive is public API

Auto merge of #82855 - jyn514:no-temporaries, r=GuillaumeGomez

Avoid temporary allocations in `render_assoc_item`

`render_assoc_item` came up as very hot in a profile of rustdoc on
`bevy`.  This avoids some temporary allocations just to calculate the
length of the header.

This should be a strict improvement, since all string formatting was
done twice before.

cc #82845

Improve error message for unassigned query provider

Fixes: 83122

Auto merge of #83360 - Dylan-DPC:rollup-17xulpv, r=Dylan-DPC

Rollup of 9 pull requests

Successful merges:

 - #80193 (stabilize `feature(osstring_ascii)`)
 - #80771 (Make NonNull::as_ref (and friends) return refs with unbound lifetimes)
 - #81607 (Implement TrustedLen and TrustedRandomAccess for Range<integer>, array::IntoIter, VecDequeue's iterators)
 - #82554 (Fix invalid slice access in String::retain)
 - #82686 (Move `std::sys::unix::platform` to `std::sys::unix::ext`)
 - #82771 (slice: Stabilize IterMut::as_slice.)
 - #83329 (Cleanup LLVM debuginfo module docs)
 - #83336 (Fix ICE with `use clippy::a::b;`)
 - #83350 (Download a more recent LLVM version if `src/version` is modified)

Failed merges:

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

Update tests

These tests were added to master after I made my changes.

Remove redundant docs

...and add docs to the types instead of the fields that hold the types.

Bump rustdoc-json format version

The rustdoc-json-types renames are breaking changes.

rustdoc-json: Rename `Import.span` to `Import.source`

* It is called `source` in rustc and the rest of rustdoc
* It is not a span, rather it is the source of the import

Rename `rustdoc_json_types::Item.source` to `span`

Rename `clean::Span::span()` to `clean::Span::inner()`

Otherwise you get a lot of instances of `item.span.span()`, which is
just plain confusing. `item.span.inner()` conveys the correct meaning of
"get the type that `clean::Span` wraps".

Rename `clean::Item.source` to `span`

Its type is called `clean::Span`, and also the name in the rest of
rustdoc and rustc for this kind of field is `span`.

Rollup merge of #83350 - jyn514:llvm-version, r=Mark-Simulacrum

Download a more recent LLVM version if `src/version` is modified

When bumping the bootstrap version, the name of the generated LLVM
shared object file is changed, even though it's the same contents as
before. If bootstrap tries to use an older version, it will get linking
errors:

```
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
   Compiling rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" ... lots of args ...
  = note: /usr/bin/ld: cannot find -lLLVM-12-rust-1.53.0-nightly
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: could not compile `rustdoc-tool`
```

Helps with https://github.com/rust-lang/rust/issues/81930.

Rollup merge of #83336 - camelid:tool-mod-ice, r=petrochenkov

Fix ICE with `use clippy::a::b;`

Fixes #83317.

Rollup merge of #83329 - camelid:debuginfo-doc-cleanup, r=davidtwco

Cleanup LLVM debuginfo module docs

- Move debuginfo docs from `doc.rs` module to `doc.md` file
- Cleanup LLVM debuginfo module docs

Rollup merge of #82771 - emilio:iter-mut-as-slice, r=m-ou-se

slice: Stabilize IterMut::as_slice.

Much like #72584.

As per #58957 there's no blocker for this, and I wanted to use this
today :-)

Closes #58957

Rollup merge of #82686 - CDirkx:unix-platform, r=m-ou-se

Move `std::sys::unix::platform` to `std::sys::unix::ext`

This moves the operating system dependent alias `platform` (`std::os::{linux, android, ...}`) from `std::sys::unix` to `std::sys::unix::ext` (a.k.a. `std::os::unix`), removing the need for compatibility code in `unix_ext` when documenting on another platform.

This is also a step in making it possible to properly move `std::sys::unix::ext` to `std::os::unix`, as ideally `std::sys` should not depend on the rest of `std`.

Rollup merge of #82554 - SkiFire13:fix-string-retain-unsoundness, r=m-ou-se

Fix invalid slice access in String::retain

As noted in #78499, the previous fix was technically still unsound because it accessed elements of a slice outside its bounds (even though they were still inside the same allocation). This PR addresses that concern by switching to a dropguard approach.

Rollup merge of #81607 - the8472:trustedrandomaccess-all-the-things, r=m-ou-se

Implement TrustedLen and TrustedRandomAccess for Range<integer>, array::IntoIter, VecDequeue's iterators

This should make some `FromIterator` and `.zip()` specializations applicable in a few more cases.

``@rustbot`` label libs-impl

Rollup merge of #80771 - thomcc:nonnull-refmut, r=dtolnay

Make NonNull::as_ref (and friends) return refs with unbound lifetimes

# Rationale:

1. The documentation for all of these functions claims that this is what the functions already do, as they all come with this comment:

    > You must enforce Rust's aliasing rules, *since the returned lifetime 'a is arbitrarily chosen* and does not necessarily reflect the actual lifetime of the data...

    So I think it's just a bug that they weren't this way already. Note that had it not been for this part, I wouldn't be making this PR, so if we decide we won't take this change, I'll follow it up with a docs PR to fix this.

2. This is how the equivalent raw pointer functions behave.

    They also take `self` and not `&self`/`&mut self`, but that can't be changed compatibly at this point. This is the next best thing.

3. Without this fix, often code that uses these methods will find it has to expand the lifetime of the result.

    (I can't speak for others but even in unsafe-heavy code, needing to do this unexpectedly is a huge red flag -- if Rust thinks something should have a specific lifetime, I assume it's for a reason)

### Can this cause existing code to be unsound?

I'm confident this can't cause new unsoundness since the reference exists for at most its lifetime, but you get a borrow checker error if you do something that would require/allow the reference to exist past its lifetime.

Additionally, the aliasing rules of a reference only applies while the reference exists.

This *must* be the case, as it is required by the rules used by safe code. (That said, the documentation in this file sort of contradicts it, but I think it's just ambiguity between the lifetime `'a` in `&'a T` and lifetime of the `&'a T` reference itself...)

We are increasing the lifetime of these references, but they should already have hard bounds on that lifetime, or they'd have borrow checker errors.

(CC ``@RalfJung`` because I have gone and done the mistake where I say something definitive about aliasing in Rust which is honestly outside the group of things I should make definitive comments about).

# Caveats

1. This is insta-stable (except for on the unstable functions ofc). I don't think there's any other alternative.

2. I don't believe this is a breaking change in practice. In theory someone could be assigning `NonNull::as_ref` to a function pointer of type `fn(&NonNull<T>) -> &T`. Now they'd need to use a slightly different function pointer type which is (probably) incompatible. This seems pathological, but I guess crater could be used if there are concerns.

3. This has no tests. The old version didn't either that I saw. I could add some stuff that fails to compile without it, if that would be useful.

4. Sometimes the NLL borrow checker gives up and decides lifetimes live till the end of the scope, as opposed to the range where they're used. If this change can cause this to happen more, then my soundness rationale is wrong, and it's likely breaking.

    In practice this seems super unlikely.

Anyway. That was a lot of typing.

Fixes https://github.com/rust-lang/rust/issues/80183

Rollup merge of #80193 - zseri:stabilize-osstring-ascii, r=m-ou-se

stabilize `feature(osstring_ascii)`

This PR stabilizes `feature(osstring_ascii)`.

Fixes #70516.

Auto merge of #79846 - the8472:inplace-tra, r=m-ou-se

Use TrustedRandomAccess for in-place iterators where possible

This can speed up in-place iterators containing simple casts and transmutes from `Copy` types to any type of same size. `!Copy` types can't be optimized since `TrustedRandomAccess`  isn't implemented for those iterators.

```
 name                  on.b ns/iter     o1.b ns/iter     diff ns/iter   diff %  speedup
 vec::bench_transmute  20 (40000 MB/s)  12 (66666 MB/s)            -8  -40.00%   x 1.67
```

disable debug assertions in codegen test

Bump slice_iter_mut_as_slice stable version.

Auto merge of #82834 - nikic:mutable-noalias, r=nagisa

Enable mutable noalias for LLVM >= 12

Enable mutable noalias by default on LLVM 12, as previously known miscompiles have been resolved. Now it's time to find the next one ;)

 * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior.
 * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision.
 * `noalias` is not emitted for types that are `!Unpin`, as a heuristic for self-referential structures (see #54878 and #63818).

rustdoc: Replace pair of `Option`s with an enum

They are never both `None` or both `Some`, so it makes more sense to use
an enum so that we "make impossible states impossible".

Fix ICE with `use clippy::a::b;`

Fix typos

Co-authored-by: the8472 <the8472@users.noreply.github.com>

post-drop-elab check-const: explain why we still check qualifs

Update doc/reference submodule

In particular this pulls in an update to the auto-deref
recursion_limit example, to no longer rely on the Freeze query.

Don't compute optimized PointerKind for unoptimized builds

This saves us both the Freeze/Unpin queries, and avoids placing
noalias attributes, which have a compile-time impact on LLVM
even in optnone builds (due to always_inline functions).

add codegen test