Related to rust-lang#96399

instead of the span of the token after the semicolon

The extra query is unnecessary in the common case of not having fuel.

Co-Authored-By: GuillaumeGomez <guillaume1.gomez@gmail.com>

Nothing actually produces it in this commit.

This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.

This adds the following functions:

* `Option<T>::as_slice(&self) -> &[T]`
* `Option<T>::as_slice_mut(&mut self) -> &[T]`

The `as_slice` and `as_slice_mut` functions benefit from an
optimization that makes them completely branch-free.

Note that the optimization's soundness hinges on the fact that either
the niche optimization makes the offset of the `Some(_)` contents zero
or the mempory layout of `Option<T>` is equal to that of
`Option<MaybeUninit<T>>`.

Add `Option::as_`(`mut_`)`slice`

This adds the following functions:

* `Option<T>::as_slice(&self) -> &[T]`
* `Option<T>::as_mut_slice(&mut self) -> &[T]`

The `as_slice` and `as_mut_slice_mut` functions benefit from an optimization that makes them completely branch-free. ~~Unfortunately, this optimization is not available on by-value Options, therefore the `into_slice` implementations use the plain `match` + `slice::from_ref` approach.~~

Note that the optimization's soundness hinges on the fact that either the niche optimization makes the offset of the `Some(_)` contents zero or the mempory layout of `Option<T>` is equal to that of `Option<MaybeUninit<T>>`.

The idea has been discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Option.3A.3Aas_slice). Notably the idea for the `as_slice_mut` and `into_slice´ methods came from `@cuviper` and `@Sp00ph` hardened the optimization against niche-optimized Options.

The [rust playground](https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=74f8e4239a19f454c183aaf7b4a969e0) shows that the generated assembly of the optimized method is basically only a copy while the naive method generates code containing a `test dx, dx` on x86_64.

---

EDIT from reviewer: ACP is rust-lang/libs-team#150

…tion-macro, r=GuillaumeGomez

rustdoc: search by macro when query ends with `!`

Related to rust-lang#96399

Note: the `never` type alias is tested in [`/tests/rustdoc-js-std/alias-3.js`](https://github.com/notriddle/rust/blob/08ad401633037cc226b3806a3c5f48c2f34703bf/tests/rustdoc-js-std/alias-3.js)

## Before

![image](https://user-images.githubusercontent.com/1593513/219504192-54cc0753-ff97-4a37-ad4a-8ae915181325.png)

## After

![image](https://user-images.githubusercontent.com/1593513/219504251-589a7e11-1e7b-4b7b-879d-1b564080017c.png)

…, r=compiler-errors

Use span of semicolon for eager recovery in expression

Instead of the span of the token after the semicolon. This will hopefully cause fewer errors from overlapping spans.

fixes rust-lang#108242
based on rust-lang#108239

rustc_middle: Remove trait `DefIdTree`

This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.

…tion-fuel, r=WaffleLapkin

Lazily compute crate name for consider_optimizing

The extra query is unnecessary in the common case of not having fuel.

…r-errors

Recover from for-else and while-else

This recovers from attempts at writing for-else or while-else loops, which might help users coming from e.g. Python.
```rs
for _ in 0..0 {
  // ...
} else {
  // ...
}
```
Combined with trying to store it in a let binding, the current diagnostic can be a bit confusing. It mentions let-else and suggests wrapping the loop in parentheses, which the user probably doesn't want. let-else doesn't make sense for `for` and `while` loops, as they are of type `()` (which already is an irrefutable pattern and doesn't need let-else).
<details>
<summary>Current diagnostic</summary>

```rs
error: right curly brace `}` before `else` in a `let...else` statement not allowed
 --> src/main.rs:4:5
  |
4 |     } else {
  |     ^
  |
help: wrap the expression in parentheses
  |
2 ~     let _x = (for _ in 0..0 {
3 |
4 ~     }) else {
  |
```
</details>

Some questions:
- Can the wording for the error message be improved? Would "for...else loops are not allowed" fit better?
- Should we be more "conservative" in case we want to support this in the future (i.e. say "for...else loops are **currently** not allowed/supported")?
- Is there a better way than storing a `&'static str` for the loop type? It is used for substituting the placeholder in the locale file (since it can emit either `for...else` or `while...else`). Maybe there is an enum I could use that I couldn't find

Add `CastKind::Transmute` to MIR

~~Nothing actually produces it in this commit, so I don't know how to test it, but it also means it shouldn't be possible for it to break anything.~~

Includes lowering `transmute` calls to it, so it's used.

Zulip Conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Good.20first.20isssue/near/321849610>