When inlining a function using the Mir inliner, we shouldn't rerun the
various Mir passes on it because the Mir has already been lowered and
that wil break various early Mir passes.

The issue in #50411 is that we've inlined a function with promotions
whose Mir has already been lowered. The promotions are then copied into
the local function and we begin to run passes on their lowered Mir
which causes the ICE.

Fixes #50411

Allow explicit matches on ! without warning

It's now possible to explicitly match on `!` without an unreachable code warning. This seems desirable as promoting explicitness.

Fixes https://github.com/rust-lang/rust/issues/55116.

Prefer unwrap_or_else to unwrap_or in case of function calls/allocations

The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.

An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).

Deprecate the `FxHashMap()` and `FxHashSet()` constructor function hack

Help suggests non-existent package std::os::ext::process::CommandExt

Fixes #39175.

handle underscore bounds in unexpected places

Per the discussion on #54902, I made it a hard error to use lifetime bounds in various places where they used to be permitted:

- `where Foo: Bar<'_>` for example

I also moved error reporting to HIR lowering and added `Error` variants to let us suppress downstream errors that result.

I (imo) improved the error message wording to be clearer, as well.

In the process, I fixed the ICE in #52098.

Fixes #54902
Fixes #52098

support type annot in constants, casts

Fixes #54571
Fixes #54332
Fixes #55183

r? @pnkfelix

In order to output a path that could actually be imported (valid and
visible), we need to handle re-exports correctly.

For example, take `std::os::unix::process::CommandExt`, this trait is
actually defined at `std::sys::unix::ext::process::CommandExt` (at time
of writing).

`std::os::unix` rexports the contents of `std::sys::unix::ext`.
`std::sys` is private so the "true" path to `CommandExt` isn't accessible.

In this case, the visible parent map will look something like this:

(child) -> (parent)
`std::sys::unix::ext::process::CommandExt` -> `std::sys::unix::ext::process`
`std::sys::unix::ext::process` -> `std::sys::unix::ext`
`std::sys::unix::ext` -> `std::os`

This is correct, as the visible parent of `std::sys::unix::ext` is in fact
`std::os`.

When printing the path to `CommandExt` and looking at the current
segment that corresponds to `std::sys::unix::ext`, we would normally
print `ext` and then go to the parent - resulting in a mangled path like
`std::os::ext::process::CommandExt`.

Instead, we must detect that there was a re-export and instead print `unix`
(which is the name `std::sys::unix::ext` was re-exported as in `std::os`).

This can trigger more errors than before. Not sure what is the best
fix here.

Also, avoid shadowing of the `ty` variable by giving the `cast_ty` and
`var_ty` variables different names.  We want to get the user-provided
type from `cast_ty.hir_id`.

Also include a test that was not working previously.

It's really layered atop the core "relate-types" code

This dates from the days before we instantiated user types with
inference variables.