When a method chain ending in `?` causes an E0277 because the
expression's `Result::Err` variant doesn't have a type that can be
converted to the `Result<_, E>` type parameter in the return type,
provide additional context of which parts of the chain can and can't
support the `?` operator.

```
error[E0277]: `?` couldn't convert the error to `String`
  --> $DIR/question-mark-result-err-mismatch.rs:28:25
   |
LL | fn bar() -> Result<(), String> {
   |             ------------------ expected `String` because of this
LL |     let x = foo();
   |             ----- this can be annotated with `?` because it has type `Result<String, String>`
LL |     let one = x
LL |         .map(|s| ())
   |          ----------- this can be annotated with `?` because it has type `Result<(), String>`
LL |         .map_err(|_| ())?;
   |          ---------------^ the trait `From<()>` is not implemented for `String`
   |          |
   |          this can't be annotated with `?` because it has type `Result<(), ()>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following other types implement trait `From<T>`:
             <String as From<char>>
             <String as From<Box<str>>>
             <String as From<Cow<'a, str>>>
             <String as From<&str>>
             <String as From<&mut str>>
             <String as From<&String>>
   = note: required for `Result<(), String>` to implement `FromResidual<Result<Infallible, ()>>`
```

Fix rust-lang#72124.

Fix rust-lang#72124.

Currently, `Handler::fatal` returns `FatalError`. But `Session::fatal`
returns `!`, because it calls `Handler::fatal` and then calls `raise` on
the result. This inconsistency is unfortunate.

This commit changes `Handler::fatal` to do the `raise` itself, changing
its return type to `!`. This is safe because there are only two calls to
`Handler::fatal`, one in `rustc_session` and one in
`rustc_codegen_cranelift`, and they both call `raise` on the result.

`HandlerInner::fatal` still returns `FatalError`, so I renamed it
`fatal_no_raise` to emphasise the return type difference.

They each have a single call site.

They each have a single call site.

Note: the `make_diagnostic_builder` calls in `lib.rs` will be replaced
in a subsequent commit.

`sess` is a terribly misleading name for a `Handler`! This confused me
for a bit.

That's what is mostly used. This commit changes a few `EM` and `E` and
`T` type variables to `G`.

`Diagnostic::new` can be used instead.

These impls are all needed for just a single `IntoDiagnostic` type, not
a family of them.

Note that `ErrorGuaranteed` is the default type parameter for
`IntoDiagnostic`.

By making it generic, instead of only for `EmissionGuarantee = ()`, we
can use it everywhere.

`Handler` is a wrapper around `HanderInner`. Some functions on
on `Handler` just forward to the samed-named functions on
`HandlerInner`.

This commit removes as many of those as possible, implementing functions
on `Handler` where possible, to avoid the boilerplate required for
forwarding. The commit is moderately large but it's very mechanical.

This is weird: `HandlerInner::emit` calls
`HandlerInner::emit_diagnostic`, but only after doing a
`treat-err-as-bug` check. Which is fine, *except* that there are
multiple others paths for an `Error` or `Fatal` diagnostic to be passed
to `HandlerInner::emit_diagnostic` without going through
`HandlerInner::emit`, e.g. `Handler::span_err` call
`Handler::emit_diag_at_span`, which calls `emit_diagnostic`.
So that suggests that the coverage for `treat-err-as-bug` is incomplete.

This commit removes `HandlerInner::emit` and moves the
`treat-err-as-bug` check to `HandlerInner::emit_diagnostic`, so it
cannot by bypassed.

This makes `Handler::fatal` more like `Handler::{err,warn,bug,note}`.

…pressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang#79813 for the tracking issue.

…text, r=compiler-errors

Provide context when `?` can't be called because of `Result<_, E>`

When a method chain ending in `?` causes an E0277 because the expression's `Result::Err` variant doesn't have a type that can be converted to the `Result<_, E>` type parameter in the return type, provide additional context of which parts of the chain can and can't support the `?` operator.

```
error[E0277]: `?` couldn't convert the error to `String`
  --> $DIR/question-mark-result-err-mismatch.rs:27:25
   |
LL | fn bar() -> Result<(), String> {
   |             ------------------ expected `String` because of this
LL |     let x = foo();
   |             ----- this has type `Result<_, String>`
...
LL |         .map_err(|_| ())?;
   |          ---------------^ the trait `From<()>` is not implemented for `String`
   |          |
   |          this can't be annotated with `?` because it has type `Result<_, ()>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following other types implement trait `From<T>`:
             <String as From<char>>
             <String as From<Box<str>>>
             <String as From<Cow<'a, str>>>
             <String as From<&str>>
             <String as From<&mut str>>
             <String as From<&String>>
   = note: required for `Result<(), String>` to implement `FromResidual<Result<Infallible, ()>>`
```

Fix rust-lang#72124.

…ules_2024, r=TaKO8Ki

Implement 2024-edition lifetime capture rules RFC

Implements rust-lang/rfcs#3498.

…compiler-errors

Add support for making lib features internal

We have the notion of an "internal" lang feature: a feature that is never intended to be stabilized, and using which can cause ICEs and other issues without that being considered a bug.

This extends that idea to lib features as well. It is an alternative to rust-lang#115623: instead of using an attribute to declare lib features internal, we simply do this based on the name. Everything ending in `_internals` or `_internal` is considered internal.

Then we rename `core_intrinsics` to `core_intrinsics_internal`, which fixes rust-lang#115597.

…tebank

Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always

It's almost always better, at least in diagnostics, to print `Fn(i32, u32)` instead of `Fn<(i32, u32)>`.

Related to but doesn't fix rust-lang#118225. That needs a separate fix.

…or-diagnostic, r=lcnr

Add `deeply_normalize_for_diagnostics`, use it in coherence

r? lcnr

Normalize trait refs used for coherence error reporting with `-Ztrait-solver=next-coherence`.

Two things:
1. I said before that we can't add this to `TyErrCtxt` because we compute `OverlapResult`s even if there are no diagnostics being emitted, e.g. for a reservation impl.
2. I didn't want to add this to an `InferCtxtExt` trait because I felt it was unnecessary. I don't particularly care about the API though.

…errors

Fix parser ICE when recovering `dyn`/`impl` after `for<...>`

Fixes rust-lang#118564

…-2, r=compiler-errors

Cleanup error handlers some more

A sequel to rust-lang#118470.

r? `@compiler-errors`

bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`

This already wasn't passed in bootstrap.py and the lint itself already warns-by-default for 2 years now and has already been added to the future-incompat group in Rust 1.68.

See rust-lang#79813 for the tracking issue.