Ubuntu 26.04 has `llvm-22` packages that we can test with.
The `Dockerfile` is otherwise the same as the `llvm-21` runners.

When encountering an inference error where a return type must be known, like when calling `Iterator::sum::<T>()` without specifying `T`, look for all `T` that would satisfy `Sum<S>`. If only one, suggest it.

```
error[E0283]: type annotations needed
  --> $DIR/cannot-infer-iterator-sum-return-type.rs:4:9
   |
LL |     let sum = v
   |         ^^^
...
LL |         .sum(); // `sum::<T>` needs `T` to be specified
   |          --- type must be known at this point
   |
   = note: cannot satisfy `_: Sum<i32>`
help: the trait `Sum` is implemented for `i32`
  --> $SRC_DIR/core/src/iter/traits/accum.rs:LL:COL
  ::: $SRC_DIR/core/src/iter/traits/accum.rs:LL:COL
   |
   = note: in this macro invocation
note: required by a bound in `std::iter::Iterator::sum`
  --> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
   = note: this error originates in the macro `integer_sum_product` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider giving `sum` an explicit type, where the type for type parameter `S` is specified
   |
LL |     let sum: i32 = v
   |            +++++
```

The compiler is unaware of the restricted range of the input, so it is
unable to optimize out the final division and modulus. By doing this
manually, we get a nontrivial performance gain.

This is nitpicky, but the lack of a sensible order has been bugging me.

- Within `mod $name`, put all the typedefs together.
- After that:
  - First, types definitions and their impls.
  - Then the `TyCtxt*` impls, in a sensible order.
    - Likewise, put `TyCtxt::at` before the similar methods.
- Also reflow some overly long lines.

- Use `$crate` more consistently.
- Add a couple of useful comments.
- Remove some unnecessary local variables.

As `maybe_into_query_key`. Partly to use `key` instead of `param`, and
also to make the link to the trait more obvious.

This is more consistent with what the trait is called elsewhere in tree
(specifically compiler-builtins and test-float-parse).

`RawFloat` is currently used specifically for the implementation of the
lemire algorithm, but it is useful for more than that. Split it into
three different traits:

* `Float`: Anything that is reasonably applicable to all floating point
  types.
* `FloatExt`: Items that should be part of `Float` but don't work for
  all float types. This will eventually be merged back into `Float`.
* `Lemire`: Items that are specific to the Lemire algorithm.

`Float` and `FloatExt` are already used by both parsing and printing, so
move them out of `dec2flt` to a new module in `num::imp`. `Int` `Cast`
have the potential to be used more places in the future, so move them
there as well. `Lemire` is the only remaining trait; since it is small,
move it into the `dec2flt` root.

The `fmt::LowerExp` bound is removed from `Float` here since the trait
is moving into a module without `#[cfg(not(no_fp_fmt_parse))]` and it
isn't implemented with that config (it's not easily possible to add
`cfg` attributes to a single supertrait, unfortunately). This isn't a
problem since it isn't actually being used.

`-Zunpretty=expanded,hygiene` was not printing syntax context annotations
for identifiers and lifetimes inside `macro_rules!` bodies. These tokens
are printed via `print_tt()` → `token_to_string_ext()`, which converts
tokens to strings without calling `ann_post()`. This meant that
macro-generated `macro_rules!` definitions with hygienic metavar
parameters (e.g. multiple `$marg` distinguished only by hygiene) were
printed with no way to tell them apart.

This was fixed by adding a match on `token.kind` in `print_tt()` to call
`ann_post()` for `Ident`, `NtIdent`, `Lifetime`, and `NtLifetime`
tokens, matching how `print_ident()` and `print_lifetime()` already
handle AST-level identifiers and lifetimes.

Signed-off-by: Andrew V. Teylu <[email protected]>

Add `unpretty-debug-shadow` test covering macro body tokens that
reference a shadowed variable, and simplify the `unpretty-debug-metavars`
test macro.

Signed-off-by: Andrew V. Teylu <[email protected]>

Co-authored-by: BoxyUwU <[email protected]>

Match the other derive macros in the module (Ord, PartialEq, PartialOrd) by
linking to the section in the trait documentation about how the derive macro
works.

When calling an fn that returns a return type as a returned expression, point at the return type to explain that it affects the expected type.

```
error[E0308]: mismatched types
    --> f56.rs:5:15
     |
   3 | fn main() {
     |          - the call expression's return type is influenced by this return type
   4 |     let a = 0;
   5 |     ptr::read(&a)
     |     --------- ^^ expected `*const ()`, found `&{integer}`
     |     |
     |     arguments to this function are incorrect
     |
     = note: expected raw pointer `*const ()`
                  found reference `&{integer}`
note: function defined here
    --> library/core/src/ptr/mod.rs:1681:21
     |
1681 | pub const unsafe fn read<T>(src: *const T) -> T {
     |                     ^^^^
```