`CompilerError` has `CompilationFailed` and `ICE` variants, which seems
reasonable at first. But the way it identifies them is flawed:
- If compilation errors out, i.e. `RunCompiler::run` returns an `Err`,
  it uses `CompilationFailed`, which is reasonable.
- If compilation panics with `FatalError`, it catches the panic and uses
  `ICE`. This is sometimes right, because ICEs do cause `FatalError`
  panics, but sometimes wrong, because certain compiler errors also
  cause `FatalError` panics. (The compiler/rustdoc/clippy/whatever just
  catches the `FatalError` with `catch_with_exit_code` in `main`.)

In other words, certain non-ICE compilation failures get miscategorized
as ICEs. It's not possible to reliably distinguish the two cases, so
this commit merges them. It also renames the combined variant as just
`Failed`, to better match the existing `Interrupted` and `Skipped`
variants.

Here is an example of a non-ICE failure that causes a `FatalError`
panic, from `tests/ui/recursion_limit/issue-105700.rs`:
```
 #![recursion_limit="4"]
 #![invalid_attribute]
 #![invalid_attribute]
 #![invalid_attribute]
 #![invalid_attribute]
 #![invalid_attribute]
 //~^ERROR recursion limit reached while expanding

 fn main() {{}}
```

When these extra directives were ported over as part of rust-lang#112300, it made sense
to introduce `iter_header_extra` and pass them in as an extra argument.

But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own
purposes, it's slightly simpler to move the coverage special-case code directly
into `iter_header` as well. This lets us get rid of `iter_header_extra`.

Noticed these while doing something else. There's no practical change, but it's preferable to use `DUMMY_SP` as little as possible, particularly when we have perfectlly useful `Span`s available.

It showed up with 3% execution time in a compiler profile.

…nethercote

Add "algebraic" fast-math intrinsics, based on fast-math ops that cannot return poison

Setting all of LLVM's fast-math flags makes our fast-math intrinsics very dangerous, because some inputs are UB. This set of flags permits common algebraic transformations, but according to the [LangRef](https://llvm.org/docs/LangRef.html#fastmath), only the flags `nnan` (no nans) and `ninf` (no infs) can produce poison.

And this uses the algebraic float ops to fix rust-lang#120720

cc `@orlp`

unstable-book: Separate testing and production sanitizers

This is a redo of [this PR](rust-lang#108942). Left the commit as before (except for reflowing to 80-width), since it already got approved.

…rError, r=oli-obk

Merge `CompilerError::CompilationFailed` and `CompilerError::ICE`.

`CompilerError` has `CompilationFailed` and `ICE` variants, which seems reasonable at first. But the way it identifies them is flawed:
- If compilation errors out, i.e. `RunCompiler::run` returns an `Err`, it uses `CompilationFailed`, which is reasonable.
- If compilation panics with `FatalError`, it catches the panic and uses `ICE`. This is sometimes right, because ICEs do cause `FatalError` panics, but sometimes wrong, because certain compiler errors also cause `FatalError` panics. (The compiler/rustdoc/clippy/whatever just catches the `FatalError` with `catch_with_exit_code` in `main`.)

In other words, certain non-ICE compilation failures get miscategorized as ICEs. It's not possible to reliably distinguish the two cases, so this commit merges them. It also renames the combined variant as just `Failed`, to better match the existing `Interrupted` and `Skipped` variants.

Here is an example of a non-ICE failure that causes a `FatalError` panic, from `tests/ui/recursion_limit/issue-105700.rs`:
```
 #![recursion_limit="4"]
 #![invalid_attribute]
 #![invalid_attribute]
 #![invalid_attribute]
 #![invalid_attribute]
 #![invalid_attribute]
 //~^ERROR recursion limit reached while expanding

 fn main() {{}}
```

r? `@spastorino`

Move the extra directives for `Mode::CoverageRun` into `iter_header`

When these extra directives were ported over as part of rust-lang#112300, it made sense to introduce `iter_header_extra` and pass them in as an extra argument.

But now that rust-lang#120881 has added a `mode` parameter to `iter_header` for its own purposes, it's slightly simpler to move the coverage special-case code directly into `iter_header` as well. This lets us get rid of `iter_header_extra`.

Allow AST and HIR visitors to return `ControlFlow`

Alternative to rust-lang#108598.

Since rust-lang/libs-team#187 was rejected, this implements our own version of the `Try` trait (`VisitorResult`) and the `try` macro (`try_visit`). Since this change still allows visitors to return `()`, no changes have been made to the existing ones. They can be done in a separate PR.

Drive-by `DUMMY_SP` -> `Span` and fmt changes

Noticed these while doing something else. There's no practical change, but it's preferable to use `DUMMY_SP` as little as possible, particularly when we have perfectlly useful `Span`s available.

…rieb

Remove an old hack for rustdoc

Since rust-lang#78696 has been resolved

…thlin

Make `is_nonoverlapping` `#[inline]`

It showed up with 3% execution time in a compiler profile.

backlink to rust-lang#120848

r? `@saethlin`