I.e. the following situation:
```
fn foo() {
mod bar {
fn qux() {
// Prelude path here (e.g. macro use prelude or extern prelude).
}
}
}
```
Those were previously unresolved, because, in order to support `self` and `super` properly, since #15148 we do not ascend block paths when there is a module in between, but only crate def maps register preludes, not block def maps, and we can't change this because block def map prelude can always be overridden by another block. E.g.
```
fn foo() {
struct WithTheSameNameAsPreludeItem;
{
WithTheSameNameAsPreludeItem
}
}
```
Here `WithTheSameNameAsPreludeItem` refer to the item from the top block, but if we would register prelude items in each block the child block would overwrite it incorrectly.
Add a separate markdown file containing the settings.json snippet from
the "Useful Setup Tips". This fixes the rendering and also makes the
text selectable.
Also use double-backticks for `code` rendering.
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.
