feature: teach rust-analyzer to discover `linked_projects`
This PR's been a long-time coming, but like the title says, it introduces server-side project discovery and removes the extension hooks I previously introduced. I don't think this PR is ready to land, but here are the things I'm feeling squishy about:
- I don't think I like the idea of introducing the `cargo-metadata` command-but-for-everything-else in the `flycheck` module, but the progress reporting infrastructure was too convenient to pass up. Happy to move it elsewhere.
Here are the things I _know_ I need to change:
- For progress reporting, I'm extracting from a `serde_json::Value` that corresponds to `tracing_subsciber::fmt::Layer`'s JSON output. I'd like to make this a bit more structured/documented than the current nonsense I wrote.
- The progress reporting currently hardcodes "Buck"; it should be deriving that from the previously mentioned more-structured-output.
- This doesn't handle *reloading* when a corresponding buildfile is changed. It should be doing that.
<details>
<summary>Anyway, here's a video of rust-analyzer discovering a Buck target.</summary>
https://github.com/rust-lang/rust-analyzer/assets/2067774/be6cd9b9-2c9a-402d-847f-05f860a91df1
</details>
feat: Add incorrect case diagnostics for enum variant fields and all variables/params
Updates the incorrect case diagnostic to check:
1. Fields of enum variants. Example:
```rust
enum Foo {
Variant { nonSnake: u8 }
}
```
2. All variable bindings, instead of just let bindings and certain match arm patters. Examples:
```rust
match 1 { nonSnake => () }
match 1 { nonSnake @ 1 => () }
match 1 { nonSnake1 @ nonSnake2 => () } // slightly cursed, but these both introduce new
// bindings that are bound to the same value.
const ONE: i32 = 1;
match 1 { nonSnake @ ONE } // ONE is ignored since it is not a binding
match Some(1) { Some(nonSnake) => () }
struct Foo { field: u8 }
match (Foo { field: 1 } ) {
Foo { field: nonSnake } => ();
}
struct Foo { nonSnake: u8 } // diagnostic here, at definition
match (Foo { nonSnake: 1 } ) { // no diagnostic here...
Foo { nonSnake } => (); // ...or here, since these are not where the name is introduced
}
for nonSnake in [] {}
struct Foo(u8);
for Foo(nonSnake) in [] {}
```
3. All parameter bindings, instead of just top-level binding identifiers. Examples:
```rust
fn func(nonSnake: u8) {} // worked before
struct Foo { field: u8 }
fn func(Foo { field: nonSnake }: Foo) {} // now get diagnostic for nonSnake
```
This is accomplished by changing the way binding identifier patterns are filtered:
- Previously, all binding idents were skipped, except a few classes of "good" binding locations that were checked.
- Now, all binding idents are checked, except field shorthands which are skipped.
Moving from a whitelist to a blacklist potentially makes the analysis more brittle:
If new pattern types are added in the future where ident pats don't introduce new names, then they may incorrectly create diagnostics.
But the benefit of the blacklist approach is simplicity: I think a whitelist approach would need to recursively visit patterns to collect renaming candidates?
Trigger VSCode to rename after extract variable assist is applied
When the user applies the "Extract Variable" assist, the cursor is
positioned at the newly inserted variable. This commit adds a command
to the assist that triggers the rename action in VSCode. This way, the
user can quickly rename the variable after applying the assist.
Fixes part of: #17579https://github.com/user-attachments/assets/4cf38740-ab22-4b94-b0f1-eddd51c26c29
I haven't yet looked at the module or function extraction assists yet.
Implement symbol interning infra
Will fix https://github.com/rust-lang/rust-analyzer/issues/15590
My unsafe-fu is not the best but it does satisfy miri.
There is still some follow up work to do, notably a lot of places using strings instead of symbols/names, most notably the token tree.
Fill out target-spec metadata for all targets
**What does this PR try to resolve?**
This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](https://github.com/rust-lang/wg-cargo-std-aware/issues/87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`.
**How should we test and review this PR?**
Check that a given target-spec metadata has been updated with:
```
$ ./x.py build library/std
$ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options
```
**Additional Information**
A few things to note:
* Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build
* There's no rush for this to be merged. I understand that the format for this is not finalised yet.
* Related: #120745
Merge Apple `std::os` extensions modules into `std::os::darwin`
The functionality available on Apple platforms are very similar, and were (basically) duplicated for each platform.
This PR rectifies that by merging the code into one module.
Ultimately, I've done this to fix `./x build library --target=aarch64-apple-tvos,aarch64-apple-watchos,aarch64-apple-visionos`, as that currently fails because of dead code warnings.
Publically exposing these to tvOS/watchOS/visionOS targets is considered in https://github.com/rust-lang/rust/pull/123723, but that seems to be dragging out, and in any case I think it makes sense to do the refactor separately from stabilization.
r? libs
Fixes https://github.com/rust-lang/rust/issues/121640 and https://github.com/rust-lang/rust/issues/124825.
Gate the type length limit check behind a nightly flag
Effectively disables the type length limit by introducing a `-Zenforce-type-length-limit` which defaults to **`false`**, since making the length limit actually be enforced ended up having a worse fallout than expected. We still keep the code around, but the type length limit attr is now a noop (except for its usage in some diagnostics code?).
r? `@lcnr` -- up to you to decide what team consensus we need here since this reverses an FCP decision.
Reopens#125460 (if we decide to reopen it or keep it closed)
Effectively reverses the decision FCP'd in #125507Closes#127346
Only track mentioned places for jump threading
This PR aims to reduce the state space size in jump threading and dataflow const-prop opts.
The current implementation walks the types of all locals, and creates a place for each possible projection. This can easily lead to a large number of places and tracked values, most being useless to the actual pass.
With this PR, we instead collect places that appear syntactically in the MIR (first commit). However, this is not sufficient (second commit), and we miss places that we could track in aggregate assignments. The third commit tracks such assignments to mirror place projections, see the inline comment.
This is complementary to https://github.com/rust-lang/rust/pull/127036
r? `@oli-obk`
