Rename CodeMap/FileMap to SourceMap/SourceFile

A first renaming for #51574

52985: cause cycle err on inf trait normalization

Issue: #52985
 - If an existential type is defined, but no user code infers the
concrete type behind the existential type, normalization would
infinitely recurse on this existential type which is only defined in
terms of itself.
  - Instead of raising an inf recurse error, we cause a cycle error to
help highlight that the issue is that the type is only defined in terms
of itself.
  - Three known potential improvements:
    - If type folding itself was exposed as a query, used by
normalization and other mechanisms, cases that would cause infinite recursion would
automatically cause a cycle error.
    - The span for the cycle error should be improved to point to user
code that fails to allow inference of the concrete type of the existential type,
assuming that this error occurs because no user code can allow inference the
concrete type.
    - A mechanism to extend the cycle error with a helpful note would be nice. Currently,
the error is built and maintained by src/librustc/ty/query/plumbing,
with no known way to extend the information that the error gets built
with.

r? @oli-obk

optimize reassignment immutable state

This is the "simple fix" when it comes to checking for reassignment. We just shoot for compatibility with the AST-based checker. Makes no attempt to solve #21232.

I opted for this simpler fix because I didn't want to think about complications [like the ones described here](https://github.com/rust-lang/rust/issues/21232#issuecomment-412219247).

Let's do some profiling measurements.

Fixes #53189

r? @pnkfelix

skip trivial `Sized` predicates

This came to about a 2% win for me in cargo. Small, but hey.

r? @EddyB

now compare-mode can show us the differences

We did not seem to have any!

Don't iterate over all things that are initialized.

Implement Unsized Rvalues

This PR is the first step to implement RFC1909: unsized rvalues (#48055).

## Implemented

- `Sized` is removed for arguments and local bindings. (under `#![feature(unsized_locals)]`)
- Unsized locations are allowed in MIR
- Unsized places and operands are correctly translated at codegen

## Not implemented in this PR

- Additional `Sized` checks:
  - tuple struct constructor (accidentally compiles now)
  - closure arguments at closure generation (accidentally compiles now)
  - upvars (ICEs now)
- Generating vtable for `fn method(self)` (ICEs now)
- VLAs: `[e; n]` where `n` isn't const
- Reduce unnecessary allocations

## Current status

- [x] Fix `__rust_probestack` (rust-lang-nursery/compiler-builtins#244)
  - [x] Get the fix merged
- [x] `#![feature(unsized_locals)]`
  - [x] Give it a tracking issue number
- [x] Lift sized checks in typeck and MIR-borrowck
  - [ ] <del>Forbid `A(unsized-expr)`</del> will be another PR
- [x] Minimum working codegen
- [x] Add more examples and fill in unimplemented codegen paths
- [ ] <del>Loosen object-safety rules (will be another PR)</del>
- [ ] <del>Implement `Box<FnOnce>` (will be another PR)</del>
- [ ] <del>Reduce temporaries (will be another PR)</del>

debug_assert to ensure that from_raw_parts is only used properly aligned

This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by https://github.com/rust-lang/rust/issues/42789 *if* there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently [fail in the rg testsuite](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). So maybe it is worth it, after all.

I have seen the attribute `#[rustc_inherit_overflow_checks]` in some places, does that make it so that the *caller's* debug status is relevant? Is there a similar attribute for `debug_assert!`? That could even subsume `rustc_inherit_overflow_checks`: Something like `rustc_inherit_debug_flag` could affect *all* places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason *not* to handle the debug flag that way? I guess currently we apply debug flags like `cfg` so this is dropped early during the MIR pipeline?

EDIT: I learned from @EddyB that because of how `debug_assert!` works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^

The paragraph described a case where we can't optimize away repetitive
dynamic stack allocation. However, as arielb1 pointed out, it can
actually optimizable by dynamically delaying the stack unwinding.

Use the new Entry::or_default method where possible.

`Self` in type definitions (self_in_typedefs)

This implements the [`self_in_typedefs` feature](https://github.com/rust-lang/rfcs/blob/master/text/2300-self-in-typedefs.md) ([tracking issue 49303](https://github.com/rust-lang/rust/issues/49303)).

r? @EddyB

CC @Centril

Currently type definitions include `struct`, `enum`, `union`, `existential type`.

std: stop backtracing when the frames are full

This is a defensive measure to mitigate the infinite unwind loop seen in #53372.  That case will still repeatedly unwind `__rust_try`, but now it will at least stop when `cx.frames` is full.

r? @alexcrichton

Do not generate assumes for plain integer casts

I gave up on making anything more elegant for now.

r? @EddyB

[NLL] Returns are interesting for free regions

Based on #53088 - creating now to get feedback.

Closes #51175

* Make assigning to the return type interesting.
* Use "returning this value" instead of "return" in error messages.
* Prefer one of the explanations that we have a name for to a generic interesting cause in some cases.
* Treat causes that involve the destination of a call like assignments.

Non-naive implementation of `VecDeque.append`

Replaces the old, simple implementation with a more manual (and **unsafe** 😱) one. I've added 1 more test and verified that it covers all 6 code paths in the function.

This new implementation was about 60% faster than the old naive one when I tried benchmarking it.