Now that we require at least LLVM 13, that codegen backend is always
using its intrinsic `fptosi.sat` and `fptoui.sat` conversions, so it
doesn't need the manual implementation. However, the GCC backend still
needs it, so we can move all of that code down there.

The `*-ptr` is rather confusing, and we have the full information for
properly displaying the information.

…rpolation

	modified:   compiler/rustc_passes/src/liveness.rs

	new file:   src/test/ui/type/issue-100584.rs
	new file:   src/test/ui/type/issue-100584.stderr

…er-errors

Display raw pointer as *{mut,const} T instead of *-ptr in errors

The `*-ptr` is rather confusing, and we have the full information for properly displaying the information.

Do not leak type variables from opaque type relation

The "root cause" is that we call `InferCtxt::resolve_vars_if_possible` (3d9dd68) on the types we get back in `TypeError::Sorts` since I added a call to it in `InferCtxt::same_type_modulo_infer`. However if this `TypeError` comes from a `InferCtxt::commit_if_ok`, then it may reference type variables that do not exist anymore, which is problematic.

We avoid this by substituting the `TypeError` with the types we had before being generalized while handling opaques.

This is kinda gross, and I feel like we can get the same issue from other places where we generalize type/const inference variables. Maybe not? I don't know.

Fixes rust-lang#99914
Fixes rust-lang#99970
Fixes rust-lang#100463

…ef-sig-plz, r=lcnr

Attempt to normalize `FnDef` signature in `InferCtxt::cmp`

Stashes a normalization callback in `InferCtxt` so that the signature we get from `tcx.fn_sig(..).subst(..)` in `InferCtxt::cmp` can be properly normalized, since we cannot expect for it to have normalized types since it comes straight from astconv.

This is kind of a hack, but I will say that `@jyn514` found the fact that we present unnormalized types to be very confusing in real life code, and I agree with that feeling. Though altogether I am still a bit unsure about whether this PR is worth the effort, so I'm open to alternatives and/or just closing it outright.

On the other hand, this isn't a ridiculously heavy implementation anyways -- it's less than a hundred lines of changes, and half of that is just miscellaneous cleanup.

This is stacked onto rust-lang#100471 which is basically unrelated, and it can be rebased off of that when that lands or if needed.

---

The code:
```rust
trait Foo { type Bar; }

impl<T> Foo for T {
    type Bar = i32;
}

fn foo<T>(_: <T as Foo>::Bar) {}

fn needs_i32_ref_fn(f: fn(&'static i32)) {}

fn main() {
    needs_i32_ref_fn(foo::<()>);
}
```

Before:
```
   = note: expected fn pointer `fn(&'static i32)`
                 found fn item `fn(<() as Foo>::Bar) {foo::<()>}`
```

After:
```
   = note: expected fn pointer `fn(&'static i32)`
                 found fn item `fn(i32) {foo::<()>}`
```

…ister,antoyo

Move the cast_float_to_int fallback code to GCC

Now that we require at least LLVM 13, that codegen backend is always
using its intrinsic `fptosi.sat` and `fptoui.sat` conversions, so it
doesn't need the manual implementation. However, the GCC backend still
needs it, so we can move all of that code down there.

Point at the string inside literal and mention if we need string inte…

…rpolation

	modified:   compiler/rustc_passes/src/liveness.rs