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.

…ilee

Update variable name to fix `unused_variables` warning

This PR fixes an `unused_variables` warning within `os.rs` when targeting `espidf`.

…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.

…jubilee

Simplify Default for tuples

Doesn't need a separate block for each element

…ilee

Use OnceCell in cell module documentation

The spanning tree example in the std cell module implementation was created before `OnceCell` was added to Rust so it uses `RefCell`. However, in this case using `OnceCell` seems more appropriate and produces simpler code. As a bonus, this also means that all three cell types are presented in the examples of std cell module.