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.
Add wasm32v1-none target (compiler-team/#791)
This is a preliminary implementation of the MCP discussed in [compiler-team#791](https://github.com/rust-lang/compiler-team/issues/791). It's not especially "major" but you know, process! Anyway it adds a new wasm32v1-none target which just pins down a set of wasm features. I think this is close to the consensus that emerged when discussing it on Zulip so I figured I'd sketch to see how hard it is. Turns out not very.
Compiletest: Custom differ
This adds support for a custom differ for compiletests. It’s purely visual and helps produce cleaner output when UI tests fail.
I’m using an environment variable for now since it’s experimental and I don’t want to drill the cli arguments all the way down. Also did a bit of general cleanup while I was at it.
This is how it looks [with debug info silenced](https://github.com/rust-lang/rust/pull/131182) (#131182)
`COMPILETEST_DIFF_TOOL="/usr/bin/env difft --color always --background light --display side-by-side" ./x test tests/ui/parser`
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.
Rollup of 8 pull requests
Successful merges:
- #125205 (Fixup Windows verbatim paths when used with the `include!` macro)
- #131049 (Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection`)
- #131549 (Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function)
- #131731 (add `TestFloatParse` to `tools.rs` for bootstrap)
- #131732 (Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES)
- #132006 (don't stage-off to previous compiler when CI rustc is available)
- #132022 (Move `cmp_in_dominator_order` out of graph dominator computation)
- #132033 (compiletest: Make `line_directive` return a `DirectiveLine`)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Make `line_directive` return a `DirectiveLine`
This reduces the need to juggle raw tuples, and opens up the possibility of moving more parts of directive parsing into `line_directive`.
In order to make the main change possible, this PR also (partly) separates the debugger-command parsing from the main directive parser. That cleanup removes support for `[rev]` in debugger commands, which is not used by any tests.
feat: render docs from aliased type when type has no docs
Trying to close#18344
- [x] ~Find the docs by traversing upwards if the type itself has none but aliasing for another type that might have.~
- [x] Show docs from aliased type.
- [x] Showing description that we are displaying documentation for different definition in hover box.
