Look at this beauty:

```rust
error: unresolved link to `S::h`
  --> intra-link-errors.rs:51:6
   |
51 | /// [type@S::h]
   |      ^^^^^^^^^ help: to link to the associated function, use its disambiguator: `S::h()`
   |
   = note: this link resolves to the associated function `h`, which is not in the type namespace
```

…space

Before:
```
   = note: this link partially resolves to the struct `S`
   = note: no `fmt` in `S`
```

After:
```
   = note: the struct `S` has no field or associated item named `fmt`
```

Previously, when looking for the associated items for primitives,
rustdoc would look for primitives in the current namespace.
But all primitives are in the type namespace. To fix this, rustdoc now
always looks for primitives in the namespace when considering them as a
stepping stone to the associated item.

However, fixing that bug caused several duplicate errors because rustdoc
now reports the same error in each namespace. To avoid this, rustdoc now
ignores all duplicate errors when issuing them.

…sambiguator

Before:

```
warning: unresolved link to `m`
 --> m.rs:1:6
  |
1 | /// [value@m]
  |      ^^^^^^^
  |
  = note: `#[warn(broken_intra_doc_links)]` on by default
  = note: no item named `m` is in scope
  = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
```

After:

```
warning: unresolved link to `m`
 --> m.rs:1:6
  |
1 | /// [value@m]
  |      ^^^^^^^ help: to link to the macro, use its disambiguator: `m!`
  |
  = note: `#[warn(broken_intra_doc_links)]` on by default
  = note: this link resolves to the macro `m`, which is not in the value namespace
```

- Remove unneeded lifetime parameter
- Comment why some code doesn't use `check_full_res`

Before, it would arbitrarily pick the third-to-last if the last three or
more did not resolve.

This is both more specific and easier to read.

Previously, this called `check_full_res` for values and types, but not
macros. This would result in not showing when there was a partial
resolution for a parent of the item.

This now calls `check_full_res`. Additionally, it checks if there was a
disambiguator, and if so, says that specific kind wasn't found instead
of saying generically 'associated item'.

Moves this detection into `resolution_failure` to avoid doing
unnecessary work and make the control flow a little easier to work with.

ManuallyDrop's documentation tells the user to use MaybeUninit instead
when handling uninitialized data. However, the main functionality of
ManuallyDrop (drop) was not available directly on MaybeUninit. Adding it
makes it easier to switch from one to the other.

Also updates the libc dependency to 0.2.77 (from 0.2.74) as the
constants were only recently added.

Fixes rust-lang#76182

This is an alternative to PR rust-lang#76188

These tokens are not preserved in the AST in certain cases
(e.g. a leading `|` in a pattern or a trailing `+` in a trait bound).

This PR ignores them entirely during the pretty-print/reparse check
to avoid spuriously using the re-parsed tokenstream.

These tests will fall without the next commit.

Apply suggestions from code review

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

These impls were effectively stable. #[unstable] had no effect here,
since both RefUnwindSafe and these types were already stable.

These effectively became stable as soon as the types became stable,
which was in 1.34.0.

This impl was effectively stable. #[unstable] had no effect here,
since both Error and LayoutErr were already stable.

This effectively became stable as soon as LayoutErr became stable, which
was in 1.28.0.

case

This is a work-around for a libc issue:
rust-lang/libc#1888.

This decreases the size of the `Result`s being returned,
improving performance in the common case.

This puts the error message closer to the link, making it easier to see
what went wrong.

'not in scope' -> 'not in `module`'

…ess-fns, r=sfackler

Stabilize core::future::{pending,ready}

This PR stabilizes `core::future::{pending,ready}`, tracking issue rust-lang#70921.

## Motivation

These functions have been on nightly for three months now, and have lived as part of the futures ecosystem for several years. In that time these functions have undergone several iterations, with [the `async-std` impls](https://docs.rs/async-std/1.6.2/async_std/future/index.html) probably diverging the most (using `async fn`, which in hindsight was a mistake).

It seems the space around these functions has been _thoroughly_ explored over the last couple of years, and the ecosystem has settled on the current shape of the functions. It seems highly unlikely we'd want to make any further changes to these functions, so I propose we stabilize.

## Implementation notes

This stabilization PR was fairly straightforward; this feature has already thoroughly been reviewed by the libs team already in rust-lang#70834. So all this PR does is remove the feature gate.

…tebank

Improve suggestions for broken intra-doc links

~~Depends on rust-lang#74489 and should not be merged before that PR.~~ Merged 🎉
~~Depends on rust-lang#75916 and should not be merged before.~~ Merged

Fixes rust-lang#75305.

This does a lot of different things 😆.

- Add `PerNS::into_iter()` so I didn't have to keep rewriting hacks around it. Also add `PerNS::iter()` for consistency. Let me know if this should be `impl IntoIterator` instead.
- Make `ResolutionFailure` an enum instead of a unit variant. This was most of the changes: everywhere that said `ErrorKind::ResolutionFailure` now has to say _why_ the link failed to resolve.
- Store the resolution in case of an anchor failure. Previously this was implemented as variants on `AnchorFailure` which was prone to typos and had inconsistent output compared to the rest of the diagnostics.
- Turn some `Err`ors into unwrap() or panic()s, because they're rustdoc bugs and not user error. These have comments as to why they're bugs (in particular this would have caught rust-lang#76073 as a bug a while ago).
- If an item is not in scope at all, say the first segment in the path that failed to resolve
- If an item exists but not in the current namespaces, say that and suggests linking to that namespace.
- If there is a partial resolution for an item (part of the segments resolved, but not all of them), say the partial resolution and why the following segment didn't resolve.
- Add the `DefId` of associated items to `kind_side_channel` so it can be used for diagnostics (tl;dr of the hack: the rest of rustdoc expects the id of the item, but for diagnostics we need the associated item).
- No longer suggests escaping the brackets for every link that failed to resolve; this was pretty obnoxious. Now it only suggests `\[ \]` if no segment resolved and there is no `::` in the link.
- Add `Suggestion`, which says _what_ to prefix the link with, not just 'prefix with the item kind'.

Places where this is currently buggy:

<details><summary>All outdated</summary>

~~1. When the link has the wrong namespace:~~ Now fixed.

<details>

```rust
/// [type@S::h]
impl S {
	pub fn h() {}
}

/// [type@T::g]
pub trait T {
	fn g() {}
}
```
```
error: unresolved link to `T::g`
  --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:53:6
   |
53 | /// [type@T::g]
   |      ^^^^^^^^^
   |
   = note: this link partially resolves to the trait `T`,
   = note: `T` has no field, variant, or associated item named `g`

error: unresolved link to `S::h`
  --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:48:6
   |
48 | /// [type@S::h]
   |      ^^^^^^^^^
   |
   = note: this link partially resolves to the struct `S`,
   = note: `S` has no field, variant, or associated item named `h`
```
Instead it should suggest changing the disambiguator, the way it currently does for macros:
```
error: unresolved link to `S`
  --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:38:6
   |
38 | /// [S!]
   |      ^^ help: to link to the unit struct, use its disambiguator: `value@S`
   |
   = note: this link resolves to the unit struct `S`, which is not in the macro namespace
```

</details>

2. ~~Associated items for values. It says that the value isn't in scope; instead it should say that values can't have associated items.~~ Fixed.

<details>

```
error: unresolved link to `f::A`
  --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:14:6
   |
14 | /// [f::A]
   |      ^^^^
   |
   = note: no item named `f` is in scope
   = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
```
This is _mostly_ fixed, it now says

```rust
warning: unresolved link to `f::A`
 --> /home/joshua/test-rustdoc/f.rs:1:6
  |
1 | /// [f::A]
  |      ^^^^
  |
  = note: this link partially resolves to the function `f`
  = note: `f` is a function, not a module
```

'function, not a module' seems awfully terse when what I actually mean is '`::` isn't allowed here', though.

</details>

It looks a lot nicer now, it says

```
error: unresolved link to `f::A`
  --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:13:6
   |
13 | /// [f::A]
   |      ^^^^
   |
   = note: `f` is a function, not a module or type, and cannot have associated items
```

3. ~~I'm also not very happy with the second note for this error:~~

<details>
```
error: unresolved link to `S::A`
  --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:19:6
   |
19 | /// [S::A]
   |      ^^^^
   |
   = note: this link partially resolves to the struct `S`,
   = note: `S` has no field, variant, or associated item named `A`
```

but I'm not sure how better to word it.

I ended up going with 'no `A` in `S`' to match `rustc_resolve` but that seems terse as well.

</details>

This now says

```
error: unresolved link to `S::A`
  --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:17:6
   |
17 | /// [S::A]
   |      ^^^^
   |
   = note: the struct `S` has no field or associated item named `A`
```

which I think looks pretty good :)

4. This is minor, but it would be nice to say that `path` wasn't found instead of the full thing:
```
error: unresolved link to `path::to::nonexistent::module`
 --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:8:6
  |
8 | /// [path::to::nonexistent::module]
  |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

It will now look at most 3 paths up (so it reports `path::to` as not in scope), but it doesn't work with arbitrarily many paths.

</details>

~~I recommend only reviewing the last few commits - the first 7 are all from rust-lang#74489.~~ Rebased so that only the relevant commits are shown. Let me know if I should squash the history some more.

r? @estebank

…, r=shepmaster

Add saturating methods for `Duration`

In some project, I needed a `saturating_add` method for `Duration`. I implemented it myself but i thought it would be a nice addition to the standard library as it matches closely with the integers types.

3 new methods have been introduced and are gated by the new `duration_saturating_ops` unstable feature:
* `Duration::saturating_add`
* `Duration::saturating_sub`
* `Duration::saturating_mul`

If have left the tracking issue to `none` for now as I want first to understand if those methods would be acceptable at all. If agreed, I'll update the PR with the tracking issue.

Further more, to match the behavior of integers types, I introduced 2 associated constants:
* `Duration::MIN`: this one is somehow a duplicate from `Duration::zero()` method, but at the time this method was added, `MIN` was rejected as it was considered a different semantic (see rust-lang#72790 (comment)).
* `Duration::MAX`

Both have been gated by the already existing unstable feature `duration_constants`, I can introduce a new unstable feature if needed or just re-use the `duration_saturating_ops`.

We might have to decide whether:
* `MIN` should be replaced by `ZERO`?
* associated constants over methods?

Give better suggestion when const Range*'s are used as patterns

Fixes rust-lang#76191

let me know if there is more/different information you want to show in this case

…it-drop, r=RalfJung

Add MaybeUninit::assume_init_drop.

`ManuallyDrop`'s documentation tells the user to use `MaybeUninit` instead when handling uninitialized data. However, the main functionality of `ManuallyDrop` (`drop`) is not available directly on `MaybeUninit`. Adding it makes it easier to switch from one to the other.

I re-used the `maybe_uninit_extra` feature and tracking issue number (rust-lang#63567), since it seems very related. (And to avoid creating too many features tracking issues for `MaybeUninit`.)

…ess-unstable-trait-impl, r=lcnr

Warn for #[unstable] on trait impls when it has no effect.

Earlier today I sent a PR with an `#[unstable]` attribute on a trait `impl`, but was informed that this attribute has no effect there. (comment: rust-lang#76525 (comment), issue: rust-lang#55436)

This PR adds a warning for this situation. Trait `impl` blocks with `#[unstable]` where both the type and the trait are stable will result in a warning:

```
warning: An `#[unstable]` annotation here has no effect. See issue rust-lang#55436 <rust-lang#55436> for more information.
   --> library/std/src/panic.rs:235:1
    |
235 | #[unstable(feature = "integer_atomics", issue = "32976")]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

---

It detects three problems in the existing code:

1. A few `RefUnwindSafe` implementations for the atomic integer types in `library/std/src/panic.rs`. Example:
https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/std/src/panic.rs#L235-L236
2. An implementation of `Error` for `LayoutErr` in `library/std/srd/error.rs`:
https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/std/src/error.rs#L392-L397
3. `From` implementations for `Waker` and `RawWaker` in `library/alloc/src/task.rs`. Example:
https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/alloc/src/task.rs#L36-L37

Case 3 interesting: It has a bound with an `#[unstable]` trait (`W: Wake`), so appears to have much effect on stable code. It does however break similar blanket implementations. It would also have immediate effect if `Wake` was implemented for any stable type. (Which is not the case right now, but there are no warnings in place to prevent it.) Whether this case is a problem or not is not clear to me. If it isn't, adding a simple `c.visit_generics(..);` to this PR will stop the warning for this case.

…r=Amanieu

Use IOV_MAX and UIO_MAXIOV constants in limit vectored I/O

Also updates the libc dependency to 0.2.77 (from 0.2.74) as the
constants were only recently added.

Related rust-lang#68042, rust-lang#75005

r? @Amanieu (also reviewed rust-lang#75005)

…n514

Ignore rustc_private items from std docs

By ignoring rustc_private items for non local impl block,
this may fix rust-lang#74672 and fix rust-lang#75588 .

This might suppress rust-lang#76529 if it is simple enough for backport.

…chenkov

Ignore `|` and `+` tokens during proc-macro pretty-print check

Fixes rust-lang#76182

This is an alternative to PR rust-lang#76188

These tokens are not preserved in the AST in certain cases
(e.g. a leading `|` in a pattern or a trailing `+` in a trait bound).

This PR ignores them entirely during the pretty-print/reparse check
to avoid spuriously using the re-parsed tokenstream.

…k-Simulacrum

Add a dedicated debug-logging option to config.toml

@Mark-Simulacrum and I were talking in zulip and we found that turning on debug/trace logging in rustc is fairly confusing, as it effectively depends on debug-assertions and is not documented as such. @Mark-Simulacrum mentioned that we should probably have a separate option for logging anyways.

this diff adds that, having the option follow debug-assertions (so everyone's existing config.toml should be fine) and if the option is false

to test I ran ./x.py test <something> twice, once with `debug-logging = false` and once with `debug-logging = true` and made sure i only saw trace's when it was true

…stebank

Fixing memory exhaustion when formatting short code suggestion

Details can be found in issue rust-lang#76597. This PR replaces substractions with `saturating_sub`'s to avoid usize wrapping leading to memory exhaustion when formatting short suggestion messages.