Auto merge of #74590 - jyn514:timing, r=Mark-Simulacrum

Add some timing info to rustdoc

There are various improvements, but the main one is to time each pass
that rustdoc performs (`rustdoc::passes`).

Before, these were the top five timings for `cargo doc` on the cargo
repository:

```
+---------------------------------+-----------+-----------------+----------+------------+
| Item                            | Self time | % of total time | Time     | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown>                       | 854.70ms  | 20.888          | 2.47s    | 744823     |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate                    | 795.29ms  | 19.436          | 848.00ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry           | 256.73ms  | 6.274           | 279.49ms | 518344     |
+---------------------------------+-----------+-----------------+----------+------------+
| resolve_crate                   | 240.56ms  | 5.879           | 242.86ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| hir_lowering                    | 146.79ms  | 3.587           | 146.79ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
```

Now the timings are:

```
+---------------------------------+-----------+-----------------+----------+------------+
| Item                            | Self time | % of total time | Time     | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown>                       | 1.40s     | 22.662          | 3.73s    | 771430     |
+---------------------------------+-----------+-----------------+----------+------------+
| collect-trait-impls             | 1.34s     | 21.672          | 2.87s    | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate                    | 1.21s     | 19.577          | 1.28s    | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| build extern trait impl         | 704.66ms  | 11.427          | 1.07s    | 21893      |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry           | 354.84ms  | 5.754           | 391.81ms | 544919     |
+---------------------------------+-----------+-----------------+----------+------------+
```

The goal is to help me debug regressions like https://github.com/rust-lang/rust/pull/74518#issuecomment-661498214 (currently I have _no_ idea what could have gone wrong).

r? @eddyb or @Mark-Simulacrum

Auto merge of #75815 - jyn514:ambiguous-primitives, r=guillaumegomez

Report an ambiguity if both modules and primitives are in scope for intra-doc links

Closes https://github.com/rust-lang/rust/issues/75381

- Add a new `prim@` disambiguator, since both modules and primitives are in the same namespace
- Refactor `report_ambiguity` into a closure

Additionally, I noticed that rustdoc would previously allow `[struct@char]` if `char` resolved to a primitive (not if it had a DefId). I fixed that and added a test case.

I also need to update libstd to use `prim@char` instead of `type@char`. If possible I would also like to refactor `ambiguity_error` to use `Disambiguator` instead of its own hand-rolled match - that ran into issues with `prim@` (I updated one and not the other) and it would be better for them to be in sync.

Auto merge of #75505 - Dylan-DPC:feature/arc_new, r=KodrAus

Add Arc::new_cyclic

Rework of #72443

References #75861

cc @Diggsey @RalfJung

r? @KodrAus

Auto merge of #75855 - jyn514:no-cfg-doc, r=ollie27

Use allow(unused_imports) instead of cfg(doc) for imports used only for intra-doc links

This prevents links from breaking when items are re-exported in a
different crate and the original isn't being documented.

Spotted in https://github.com/rust-lang/rust/pull/75832#discussion_r475275837 (thanks ollie!)

r? @ollie27

Auto merge of #75865 - JohnTitor:rollup-yxia6d2, r=JohnTitor

Rollup of 10 pull requests

Successful merges:

 - #75819 (Use intra-doc-links in `core::{char, macros, fmt}`)
 - #75821 (Switch to intra-doc links in `std::macros`)
 - #75825 (Fix typo in documentation of i32 wrapping_abs())
 - #75826 (Corrected Misleading documentation for derived Ord/PartialOrd implementation )
 - #75831 (doc: Prefer https link for wikipedia URLs)
 - #75844 (publish-toolstate: show more context on HTTP error)
 - #75847 (Switch to intra-doc links in `std::collections`)
 - #75851 (Switch to intra-doc links in `core::array`)
 - #75856 (more tool clippy fixes)
 - #75859 (doc: Fix typo in std::process::Child documentation)

Failed merges:

r? @ghost

Don't import atomics unless supported by the platform

Fix bad rebase

Had to use -Xignore-whitespace-conflicts to avoid awful conflicts, but
that threw off the indentation

Use underscores instead of spaces

Time how long it takes to render HTML

xpy fmt

Time running the global context

Separate `run_global_ctxt` into a separate function

Remove redundant timing for query

Time loading all crates, not each individual crate

Add some timing info to rustdoc

There are various improvements, but the main one is to time each pass
that rustdoc performs (`rustdoc::passes`).

Before, these were the top five timings for `cargo doc` on the cargo
repository:

```
+---------------------------------+-----------+-----------------+----------+------------+
| Item                            | Self time | % of total time | Time     | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown>                       | 854.70ms  | 20.888          | 2.47s    | 744823     |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate                    | 795.29ms  | 19.436          | 848.00ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry           | 256.73ms  | 6.274           | 279.49ms | 518344     |
+---------------------------------+-----------+-----------------+----------+------------+
| resolve_crate                   | 240.56ms  | 5.879           | 242.86ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| hir_lowering                    | 146.79ms  | 3.587           | 146.79ms | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
```

Now the timings are:

```
+---------------------------------+-----------+-----------------+----------+------------+
| Item                            | Self time | % of total time | Time     | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown>                       | 1.40s     | 22.662          | 3.73s    | 771430     |
+---------------------------------+-----------+-----------------+----------+------------+
| collect-trait-impls             | 1.34s     | 21.672          | 2.87s    | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate                    | 1.21s     | 19.577          | 1.28s    | 1          |
+---------------------------------+-----------+-----------------+----------+------------+
| build extern trait impl         | 704.66ms  | 11.427          | 1.07s    | 21893      |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry           | 354.84ms  | 5.754           | 391.81ms | 544919     |
+---------------------------------+-----------+-----------------+----------+------------+
```

Rollup merge of #75859 - jrheard:patch-2, r=jonas-schievink

doc: Fix typo in std::process::Child documentation

Nearly done reading stdlib docs, found another small typo, here's a PR!

r? @steveklabnik

Rollup merge of #75856 - matthiaskrgr:more_clippy, r=Dylan-DPC

more tool clippy fixes

r? @Dylan-DPC

Rollup merge of #75851 - camelid:patch-2, r=jyn514

Switch to intra-doc links in `core::array`

Part of #75080.

@rustbot modify labels: A-intra-doc-links T-doc T-rustdoc

Rollup merge of #75847 - camelid:patch-1, r=dtolnay

Switch to intra-doc links in `std::collections`

Part of #75080.

@rustbot modify labels: A-intra-doc-links T-doc T-rustdoc

Rollup merge of #75844 - ehuss:publish-toolstate-httperror, r=Mark-Simulacrum

publish-toolstate: show more context on HTTP error

The default display for HTTPError in Python does not include the request body. For GitHub API, the body includes more details about the error (like rate limiting). This could help diagnosing errors like this: https://github.com/rust-lang/rust/pull/75815#issuecomment-678798158

Rollup merge of #75831 - lzutao:https, r=Dylan-DPC

doc: Prefer https link for wikipedia URLs

A tiny changes.

Rollup merge of #75826 - ayushmishra2005:misleading_documentation_for_derived_Ord_PartialOrd, r=KodrAus

Corrected Misleading documentation for derived Ord/PartialOrd implementation

Corrected Misleading documentation for derived Ord/PartialOrd implementation

Fixes #75620

Rollup merge of #75825 - jrheard:patch-1, r=steveklabnik

Fix typo in documentation of i32 wrapping_abs()

Hi!

I was reading through the std library docs and noticed that this section flowed a bit oddly; comparing it against https://doc.rust-lang.org/std/primitive.i32.html#method.wrapping_div and https://doc.rust-lang.org/std/primitive.i32.html#method.wrapping_neg , I noticed that those two pieces of documentation used a semicolon here.

This is my first time submitting a PR to this repo. Am I doing this right? Are tiny typo-fix PRs like this worth submitting, or are they not a good use of time?

Thank you!

Rollup merge of #75821 - camelid:intra-doc-links-for-std-macros, r=jyn514

Switch to intra-doc links in `std::macros`

Part of #75080.

---

* Switch to intra-doc links in `std::macros`
* Fix typo in module docs
* Link to `std::io::stderr` instead of `std::io::Stderr` to match the
  link text
* Link to `std::io::stdout`

---

@rustbot modify labels: A-intra-doc-links T-doc T-rustdoc

Rollup merge of #75819 - LeSeulArtichaut:core-intra-docs-2, r=jyn514

Use intra-doc-links in `core::{char, macros, fmt}`

Helps with #75080.
r? @jyn514

xpy fmt

Document prim@ and primitive@

Update primitive test to match the new behavior

Convert str -> prim@str in `std`

Convert from str -> prim@str for `alloc`

Disambiguate char -> prim@char for `core`

This also changes human intuition -> intuition. 'human intuition' sounds
vaguely menacing.

Report an ambiguity if both modules and primitives are in scope

- Add a new `prim@` disambiguator, since both modules and primitives are
in the same namespace
- Refactor `report_ambiguity` into a closure

Additionally, I noticed that rustdoc would previously allow
`[struct@char]` if `char` resolved to a primitive (not if it had a
DefId). I fixed that and added a test case.

Auto merge of #75817 - LeSeulArtichaut:proc_macro-docs, r=jyn514

Use intra-doc link in `proc_macro`

Yep. One link.

Helps with #75080.
r? @jyn514

add issue number

doc: Fix typo in std::process::Child documentation

Auto merge of #74489 - jyn514:assoc-items, r=manishearth,petrochenkov

Fix intra-doc links for associated items

@Manishearth and I found that links of the following sort are broken:
```rust
$ cat str_from.rs
/// [`String::from`]
pub fn foo() {}
$ rustdoc str_from.rs
warning: `[String::from]` cannot be resolved, ignoring it.
 --> str_from.rs:4:6
  |
4 | /// [`String::from`]
  |      ^^^^^^^^^^^^^^ cannot be resolved, ignoring
```
It turns out this is because the current implementation only looks at inherent impls (`impl Bar {}`) and traits _for the item being documented_. Note that this is not the same as the item being _linked_ to. So this code would work:

```rust
pub trait T1 {
    fn method();
}

pub struct S;
impl T1 for S {
    /// [S::method] on method
    fn method() {}
}
```

but putting the documentation on `trait T1` would not.

~~I realized that writing it up that my fix is only partially correct: It removes the inherent impls code when it should instead remove the `trait_item` code.~~ Fixed.

Additionally, I discovered while writing this there is some ambiguity: you could have multiple methods with the same name, but for different traits:

```rust
pub trait T1 {
    fn method();
}

pub trait T2 {
    fn method();
}

/// See [S::method]
pub struct S;
```

Rustdoc should give an ambiguity error here, but since there is currently no way to disambiguate the traits (https://github.com/rust-lang/rust/issues/74563) it does not (https://github.com/rust-lang/rust/pull/74489#issuecomment-673878404).

There is a _third_ ambiguity that pops up: What if the trait is generic and is implemented multiple times with different generic parameters? In this case, my fix does not do very well: it thinks there is only one trait instantiated and links to that trait:

```
/// [`String::from`] -- this resolves to https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.from
pub fn foo() {}
```

However, every `From` implementation has a method called `from`! So the browser picks a random one. This is not the desired behavior, but it's not clear how to avoid it.

To be consistent with the rest of intra-doc links, this only resolves associated items from traits that are in scope. This required changes to rustc_resolve to work cross-crate; the relevant commits are prefixed with `resolve: `. As a bonus, considering only traits in scope is slightly faster. To avoid re-calculating the traits over and over, rustdoc uses a cache to store the traits in scope for a given module.

unstable-book-gen: fix clippy::single_char_pattern and clippy::iter_skip_next

Use allow(unused_imports) instead of cfg(doc)

This prevents links from breaking when items are re-exported in a
different crate and the original isn't being documented.

unicode_table_generator: fix clippy::writeln_empty_string, clippy::useless_format, clippy:::for_kv_map

tidy: remove redundant variable from check_if_error_code_is_test_in_explanation

Use intra-doc-links in `core::{char, macros, fmt}`

linkcheckr: fix clippy::redundant_static_lifetimes and clippy::single_char_pattern

expand-yaml-anchors: fix clippy::match_ref_pats and clippy::redundant_closure

resolve: Add comments to `traits_in_scope`

Switch to intra-doc links in `core::array`

Auto merge of #75656 - tirr-c:match-suggest-semi, r=estebank

Provide better spans for the match arm without tail expression

Resolves #75418.

Applied the same logic in the `if`-`else` type mismatch case.

r? @estebank

Switch to intra-doc links in `std::collections`

Auto merge of #72449 - ecstatic-morse:const-float-bitcast, r=RalfJung

Const floating point bitcasts and classification

Makes the `f32` and `f64` methods described in #72447 and #72505 unstably const.

r? @RalfJung

publish-toolstate: show more context on HTTP error

Fix `compile-flags` directive

Co-authored-by: Ralf Jung <post@ralfj.de>

Auto merge of #75028 - MrModder:master, r=steveklabnik

Document that slice refers to any pointer type to a sequence

I was recently confused about the way slices are represented in memory. The necessary information was not available in the std-docs directly, but was a mix of different material from the reference and book.

This PR should clear up the definition of slices a bit more in the documentation. Especially the fact that the term slice refers to the pointer/reference type, e.g. `&[T]`, and not `[T]`.
It also documents that slice pointers are twice the size of pointers to `Sized` types, as this concept may be unfamiliar to users coming from other languages that do not have the concept of "fat pointers" (especially C/C++).

I've documented why this was important to me and my findings in [this blog post](https://codecrash.me/understanding-rust-slices).

r? @lcnr

Auto merge of #74238 - RalfJung:offset_from, r=oli-obk

stabilize ptr_offset_from

This stabilizes ptr::offset_from, and closes https://github.com/rust-lang/rust/issues/41079. It also removes the deprecated `wrapping_offset_from`. This function was deprecated 19 days ago and was never stable; given an FCP of 10 days and some waiting time until FCP starts, that leaves at least a month between deprecation and removal which I think is fine for a nightly-only API.

Regarding the open questions in https://github.com/rust-lang/rust/issues/41079:
* Should offset_from abort instead of panic on ZSTs? -- As far as I know, there is no precedent for such aborts. We could, however, declare this UB. Given that the size is always known statically and the check thus rather cheap, UB seems excessive.
* Should there be more methods like this with different restrictions (to allow nuw/nsw, perhaps) or that return usize (like how isize-taking offset is more conveniently done with usize-taking add these days)? -- No reason to block stabilization on that, we can always add such methods later.

Also nominating the lang team because this exposes an intrinsic.

The stabilized method is best described [by its doc-comment](https://github.com/RalfJung/rust/blob/56d4b2d69abb93e4f0ca79471deca7aaaaeca214/src/libcore/ptr/const_ptr.rs#L227). The documentation forgot to mention the requirement that both pointers must "have the same provenance", aka "be derived from pointers to the same allocation", which I am adding in this PR. This is a precondition that [Miri already implements](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a3b9d0a07a01321f5202cd99e9613480) and that, should LLVM ever obtain a `psub` operation to subtract pointers, will likely be required for that operation (following the semantics in [this paper](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf)).

bump stable version

Co-authored-by: Josh Stone <cuviper@gmail.com>

remove an unused feature flag

Revert changed paragraph about slice definition.

This reverts part of commit e6c83dd57b920d2069797736ae0a1c9fe14a97cb.
As requested by @steveklabnik .

Auto merge of #75816 - LeSeulArtichaut:core-intra-docs, r=jyn514

Use intra-doc-links in `core::{raw, ffi, pin}`

Helps with #75080.
r? @jyn514

Misleading documentation for derived Ord/PartialOrd implementation for enums #75620

Auto merge of #75789 - matthiaskrgr:clippy_compiletest, r=Dylan-DPC

compiletest: fix a couple clippy lint findings

Prefer https link for wikipedia URLs

Auto merge of #75465 - Aaron1011:feature/short-fn-def-span, r=estebank

Use smaller def span for functions

Currently, the def span of a function encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.

This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function

```rust
pub fn foo<T>(val: T) -> T { val }
```

now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).

Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:

```rust
trait Foo {
    fn bar();
}
```

the function definition `Foo::bar` has a `def_span` of `fn bar();`

This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.

We continue to use the full span (including the body) in a few of
places:

* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
  emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.

All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.

Auto merge of #75813 - petrochenkov:feature/incr-def-path-table, r=Aaron1011

Lazy decoding of DefPathTable from crate metadata (non-incremental case)

The is the half of https://github.com/rust-lang/rust/pull/74967 that doesn't touch incremental-related structures.
We are still decoding def path hashes eagerly if we are in incremental mode.

The incremental part of https://github.com/rust-lang/rust/pull/74967 feels hacky, but I'm not qualified enough to suggest improvements. I'll reassign it so someone else once this PR lands.
@Aaron1011, I wasn't asking you to do this split because I wasn't sure that it's feasible (or simple to do).

r? @Aaron1011

Fix typo in documentation of i32 wrapping_abs()

Auto merge of #73526 - cuviper:rust-llvm11, r=nikic

Upgrade to LLVM 11 (rc2)

This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.

Add missing links

Auto merge of #73084 - Aaron1011:feature/new-recursive-expand, r=petrochenkov

Re-land PR #72388:  Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`

PR #72388 allowed us to preserve the original `TokenStream` in more cases during proc-macro expansion, but had to be reverted due to a large number of regressions (See #72545 and #72622). These regressions fell into two categories

1. Missing handling for `Group`s with `Delimiter::None`, which are inserted during `macro_rules!` expansion (but are lost during stringification and re-parsing). A large number of these regressions were due to `syn` and `proc-macro-hack`, but several crates needed changes to their own proc-macro code.
2. Legitimate hygiene issues that were previously being masked by stringification. Some of these were relatively benign (e.g. [a compiliation error](https://github.com/paritytech/parity-scale-codec/pull/210) caused by misusing `quote_spanned!`). However, two crates had intentionally written unhygenic `macro_rules!` macros, which were able to access identifiers that were not passed as arguments (see https://github.com/rust-lang/rust/issues/72622#issuecomment-636402573).

All but one of the Crater regressions have now been fixed upstream (see https://hackmd.io/ItrXWRaSSquVwoJATPx3PQ?both). The remaining crate (which has a PR pending at https://github.com/sammhicks/face-generator/pull/1) is not on `crates.io`, and is a Yew application that seems unlikely to have any reverse dependencies.

As @petrochenkov mentioned in https://github.com/rust-lang/rust/issues/72545#issuecomment-638632434, not re-landing PR #72388 allows more crates to write unhygenic `macro_rules!` macros, which will eventually stop compiling. Since there is only one Crater regression remaining, since additional crates could write unhygenic `macro_rules!` macros in the time it takes that PR to be merged.

Add missing intra-doc link

Switch to intra-doc links in `std::macros`

Also:
* Fix typo in module docs
* Link to `std::io::stderr` instead of `std::io::Stderr` to match the
  link text
* Link to `std::io::stdout`

Use smaller def span for functions

Currently, the def span of a funtion encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.

This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function

```rust
pub fn foo<T>(val: T) -> T { val }
```

now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).

Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:

```rust
trait Foo {
    fn bar();
}```

the function definition `Foo::bar` has a `def_span` of `fn bar();`

This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.

We continue to use the full span (including the body) in a few of
places:

* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
  emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
* The 'unconditional recursion' lint uses the full span to show
  additional context for the recursive call.

All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.

Add backwards-compat hack for certain '$name' tokens

See issue #74616

Recursively expand `TokenKind::Interpolated` (take 2)

Fixes #68430

This is a re-attempt of PR #72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.

Write coverage filenames in Version3 format

Match scalar-pair-bool more flexibly for LLVM 11

LLVM 11 started using `phi` and `select` for `fn pair_i32_bool`, which
is still valid, but harder to match than the simple instructions we were
getting before. We'll just check that the unpacked args are directly
referenced in any way, and call it good.

Apply suggestions from code review

Flatten the INC definition to one line.

Co-authored-by: lzutao <taolzu@gmail.com>

Expand RISCV pseudo-instructions to match LLVM 11

Upgrade to LLVM 11 (rc2)

Don't make clang use gcc's include-fixed

This was breaking `#include_next <limits.h>`, such that we weren't
getting definitions of `PATH_MAX` and `_POSIX_ARG_MAX`.

Test new floating point bit casts

Use intra-doc link in `proc_macro`

Use intra-doc-links in `core::{raw, ffi, pin}`

Add `#![feature(const_float_classify)]` for `f64::classify` and friends

Add `#![feature(const_float_bits_conv)]` for `f64::to_bits` and friends

Auto merge of #75171 - amosonn:new_zeroed_slice, r=Amanieu

New zeroed slice

Add to #63291 the methods

```rust
impl<T> Box<[T]> { pub fn new_zeroed_slice(len: usize) -> Box<[MaybeUninit<T>]> {…} }
impl<T> Rc<[T]> { pub fn new_zeroed_slice(len: usize) -> Rc<[MaybeUninit<T>]> {…} }
impl<T> Arc<[T]> { pub fn new_zeroed_slice(len: usize) -> Arc<[MaybeUninit<T>]> {…} }
```

as suggested in https://github.com/rust-lang/rust/issues/63291#issuecomment-605511675 .

Also optimize `{Rc, Arc}::new_zeroed` to use `alloc_zeroed`, otherwise they are no more efficient than using `new_uninit` and zeroing the memory manually (which was the original implementation).

rustc_metadata: Move some code around to merge impls of `CrateMetadataRef`

Do not forget capacity when collecting def path hashes

Lazy decoding of DefPathTable from crate metadata (non-incremental case)

Auto merge of #74566 - lzutao:guard, r=petrochenkov

Gate if-let guard feature

Enhanced on #74315. That PR is in crater queue so I don't want to push to it.

Close  #74232
cc #51114

Auto merge of #75783 - denisvasilik:intra-doc-links-core-alloc, r=jyn514

Move to intra-doc links for library/core/src/alloc/{layout, global, mod}.rs

Helps with #75080. The files already contained intra-doc links, so there are only minor changes.

@rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc

Known issues:

* [`handle_alloc_error`]: Link from `core` to `alloc` could not be resolved.
* [`slice`]: slice is a primitive type, but could not be resolved; had to use [`crate::slice`] instead.

fix dead links to wrapping_offset_from

remove feature gate from tests

stabilize ptr_offset_from

remove deprecated wrapping_offset_from

offset_from: also document same-provenance requirement

Auto merge of #75795 - matthiaskrgr:cargotest_clippy, r=Dylan-DPC

cargotest: fix clippy warnings

Fixes clippy::redundant_static_lifetimes and clippy::toplevel_ref_arg
I also replaced some .expect("") calls with .unwrap()s since there was no message passed by the .expect() anyway.

Link to primitive instead of module

compiletest: fix a couple clippy lint findings

Auto merge of #75790 - LeSeulArtichaut:std-intra-doc, r=jyn514

Use intra-doc-links in `std::sync::*`

Helps with #75080.
r? @jyn514

Auto merge of #75776 - GuillaumeGomez:missing-doc-examples-lint-improvements, r=jyn514

Missing doc examples lint improvements

Fixes #75719.

To be merged after #75718 (only the two last commits are from this PR).

Since you already reviewed #75718, I'll set you as reviewer here as well. :)

r? @jyn514

Auto merge of #75772 - tmiasko:io-maybe-no, r=dtolnay

Remove unused `Maybe` wrapper around raw standard streams

* Remove result type from raw standard streams constructors
* Make raw standard stream constructors const
* Remove wrapper type handling absent raw standard streams

cargo checked with:

```shell
env CC=true ./x.py check library/std/ \
  --target i686-unknown-linux-gnu \
  --target wasm32-unknown-emscripten \
  --target wasm32-wasi \
  --target x86_64-fortanix-unknown-sgx \
  --target x86_64-pc-windows-gnu \
  --target x86_64-unknown-cloudabi \
  --target x86_64-unknown-hermit \
  --target x86_64-unknown-linux-gnu \
  --target x86_64-uwp-windows-gnu \
  --target x86_64-wrs-vxworks
```

Note: Last target doesn't compile currently.

rustdoc: Only resolve traits in scope

rustdoc: Cache traits implemented by a type

This avoids taking the slow path several thousand times in a row.

- Fallback to all traits if the traits in scope are unknown
- Use a rustdoc thread_local cache instead of a query

The set of traits implemented by a type is not stable across crates:
there could be new traits added in a new crate.

- Use DocContext instead of a thread-local