…ctually querying it

The source sidebar has a setting to remember whether it should be open or
closed. Previously, this setting was handled in source-script.js, which
is loaded with `defer`, meaning it is often run after the document is rendered.
Since CSS renders the source sidebar as closed by default, changing this
after the initial render results in a relayout.

Instead, handle the setting in storage.js, which is the first script to load
and is the only script that blocks render. This avoids a relayout and means
navigating between files with the sidebar open is faster.

…=jsha

Add macro support in jump to definition feature

Fixes rust-lang#91174.

To do so, I check if the span comes from an expansion, and if so, I infer the original macro `DefId` or `Span` depending if it's a defined in the current crate or not.

There is one limitation due to macro expansion though:

```rust
macro_rules! yolo { () => {}}

fn foo() {
    yolo!();
}
```

In `foo`, `yolo!` won't be linked because after expansion, it is replaced by nothing (which seems logical). So I can't get an item from the `Visitor` from which I could tell if its `Span` comes from an expansion.

I added a test for this specific limitation alongside others.

Demo: https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html

As for the empty macro issue that cannot create a jump to definition, you can see it [here](https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html#35).

r? `@jyn514`

…impl-nll, r=cjgillot

Give name if anonymous region appears in impl signature

Fixes rust-lang#98170

We probably should remove the two unwraps in [`report_general_error`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_borrowck/diagnostics/region_errors.rs.html#683-685), but I have no idea what to provide if those regions are missing, so I've kept those in. Let me know if I should try harder to remove those.

…t-res, r=petrochenkov

Provide a `PathSegment.res` in more cases

I find that in many cases, the `res` associated with a `PathSegment` is `Res::Err` even though the path was fully resolved. A few diagnostics use this `res` and their error messages suffer because of the lack of resolved segment.

This fixes it a bit, but it's obviously not complete and I'm not exactly sure if it's correct.

…bank

Fix trait object reborrow suggestion

Fixes rust-lang#93596

Slightly generalizes the logic we use to suggest fix first implemented in rust-lang#95609, specifically when we have a `Sized` obligation that comes from a struct's unsized tail.

…struct-literal, r=compiler-errors

Point at private fields in struct literal

closes rust-lang#95872

prohibit_generics: don't alloc error string if no error emitted

Noticed unreaded allocs in DHAT.

…umeGomez

rustdoc: optimize loading of source sidebar

The source sidebar has a setting to remember whether it should be open or
closed. Previously, this setting was handled in source-script.js, which
is loaded with `defer`, meaning it is often run after the document is rendered.
Since CSS renders the source sidebar as closed by default, changing this
after the initial render results in a relayout.

Instead, handle the setting in storage.js, which is the first script to load
and is the only script that blocks render. This avoids a relayout and means
navigating between files with the sidebar open is faster.

Demo: https://rustdoc.crud.net/jsha/defer-source-sidebar/src/alloc/ffi/c_str.rs.html

r? `@GuillaumeGomez`

[RFC 2011] Optimize non-consuming operators

Tracking issue: rust-lang#44838
Fifth step of rust-lang#96496

The most non-invasive approach that will probably have very little to no performance impact.

## Current behaviour

Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located.

```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !(
  { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100
) {
  panic!( ... );
}
```

As such, some overhead is likely to occur (Specially with very large chains of conditions).

## New behaviour for non-consuming operators

When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition.

```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !( a > 1 && b < 100 ) {
  { ***try capture `a`*** }
  { ***try capture `b`*** }
  panic!( ... );
}
```

So the possible impact on the runtime execution time will be diminished.

r? `@oli-obk`