Thanks to the observation (supported by counting) that the vast majority paths have neither generics no type anchors, and thanks to a new datastructure `ThinVecWithHeader` that is essentially `(T, Box<[U]>)` but with the size of a single pointer, we are able to reach this feat.
This (together with `ThinVecWithHeader`) makes the possibility to shrink `TypeRef`, because most types are paths.
So that given a `TypeRef` we will be able to trace it back to source code.
This is necessary to be able to provide diagnostics for lowering to chalk tys, since the input to that is `TypeRef`.
This means that `TypeRef`s now have an identity, which means storing them in arena and not interning them, which is an unfortunate (but necessary) loss but also a pretty massive change. Luckily, because of the separation layer we have for IDE and HIR, this change never crosses the IDE boundary.
Some types in `core` are conditionally compiled based on
`target_has_atomic` or `target_has_atomic_load_store` without an
argument, for example `AtomicU64`.
This is less noticeable in Cargo projects, where rust-analyzer adds
the output `RUSTC_BOOTSTRAP=1 cargo rustc --print cfg` so it gets the
full set of cfg flags.
This fixes go-to-definition on `std::sync::atomic::AtomicU64` in
non-cargo projects.
E.g.:
```rust
let v;
macro_rules! m { () => { v }; }
```
This was an existing bug, but it was less severe because unless the variable was shadowed it would be correctly resolved. With hygiene however, without this fix the variable is never resolved.
Or macro_rules hygiene, or mixed site hygiene. In other words, hygiene for variables and labels but not items.
The realization that made me implement this was that while "full" hygiene (aka. def site hygiene) is really hard for us to implement, and will likely involve intrusive changes and performance losses, since every `Name` will have to carry hygiene, mixed site hygiene is very local: it applies only to bodies, and we very well can save it in a side map with minor losses.
This fixes one diagnostic in r-a that was about `izip!()` using hygiene (yay!) but it introduces a huge number of others, because of #18262. Up until now this issue wasn't a major problem because it only affected few cases, but with hygiene identifiers referred by macros like that are not resolved at all. The next commit will fix that.
