Should we deeply normalize during writeback, or at the post-typeck places that need a "structurally resolved" type?

[compiler-errors]

fn foo(x: [u8; 4]) {
    match x[2] {
        b' ' | 0x9..=0xd8 => {
            panic!()
        }
        _ => {}
    }
}

This code currently ICEs with:

error: internal compiler error: broken MIR in DefId(0:3 ~ test[3886]::foo) (Le((*_2), const 216_u8)): unexpected comparison types <usize as std::slice::SliceIndex<[u8]>>::Output and u8
 --> /home/gh-compiler-errors/test.rs:3:16
  |
3 |         b' ' | 0x9..=0xd8 => {
  |                ^^^^^^^^^^
  |

This is because we expect for the types in the writeback results to have been normalized deeply, and other code (e.g. MIR build, MIR validation, late lints, reachability and dead code analysis) expect that Ty::kind calls "just work" without any further normalization.

---

We can either:

1. Deeply normalize during writeback (e.g. compiler-errors/rust@b0600aeb8640239ba4292c9bfc1de60de23283cf), or
2. Normalize at every site that relies on a "structurally resolved" type mentioned above.

[compiler-errors]

Similarly, during writeback we "fix up" some expressions so that we can emit MIR built-in operations for things like add and index. This does not happen during writeback if we have projections, though, e.g.:

const fn first_eq_second(x: [u32; 2]) -> bool {
    x[0] == x[1]
}

This remains a call to Index::index and fails to const-check:

error[E0015]: cannot call non-const operator in constant functions
 --> <source>:2:5
  |
2 |     x[0] == x[1]
  |     ^^^^
  |
  = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants
  = help: add `#![feature(const_trait_impl)]` to the crate attributes to enable

[lcnr]

We currently normalize in writeback after hir typeck with the new solver to avoid dealing with unnormalized projections during lints and in the MIR.