Run stable `fmt` & `cargo` through `rustup`
`cargo test -p ide-assists` fails on Windows/x64/nightly:
```shell
> rustup self update
info: checking for self-updates
rustup unchanged - 1.25.1
> rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: checking for self-updates
stable-x86_64-pc-windows-msvc unchanged - rustc 1.62.1 (e092d0b6b 2022-07-16)
nightly-x86_64-pc-windows-msvc unchanged - rustc 1.64.0-nightly (affe0d3a0 2022-08-05)
info: cleaning up downloads & tmp directories
> rustup show
Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\stanc\.rustup
installed toolchains
--------------------
stable-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)
active toolchain
----------------
nightly-x86_64-pc-windows-msvc (default)
rustc 1.64.0-nightly (affe0d3a0 2022-08-05)
> cargo test -p ide-assists
test tests::sourcegen::sourcegen_assists_docs ... FAILED
failures:
---- tests::sourcegen::sourcegen_assists_docs stdout ----
thread 'tests::sourcegen::sourcegen_assists_docs' panicked at 'Failed to run rustfmt from toolchain 'stable'. Please run `rustup component add rustfmt --toolchain stable` to install it.', crates\sourcegen\src\lib.rs:141:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
tests::sourcegen::sourcegen_assists_docs
test result: FAILED. 1576 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.82s
error: test failed, to rerun pass '-p ide-assists --lib'
```
After some investigation it seemed that [`cmd!`](51705698bd/crates/sourcegen/src/lib.rs (L139)) didn't execute the expected (stable) rustfmt.
A simple `xshell` test failed too:
```rust
use xshell::{cmd, Shell};
fn main() {
let sh = &Shell::new().unwrap();
sh.set_var("RUSTUP_TOOLCHAIN", "stable");
let version = cmd!(sh, "rustfmt --version").read().unwrap_or_default();
println!("{version}");
}
```
Bypassing `xshell` and using `Command` directly failed too:
```rust
use std::process::{Command, Stdio};
fn main() {
let child = Command::new("rustfmt")
.arg("--version")
.stdin(Stdio::null())
.stdout(Stdio::piped())
.env("RUSTUP_TOOLCHAIN", "stable")
.spawn()
.expect("failed to start");
let output = child.wait_with_output().unwrap();
let version = String::from_utf8_lossy(&output.stdout);
println!("{version}");
}
```
Spawning `cargo +stable fmt version` [failed too](https://github.com/rust-lang/rustup/issues/3036) with `error: no such subcommand: +stable`.
Only `rustup run stable` worked fine for both `cargo` and `fmt`.
Thanks to `@lnicola` for a live investigation session, hints and tips.
Add more constructors and entry-APIs for la-arena
`la-arena` on crates.io is quite helpful when just a thin wrapper for Vec with u32 indices is needed.
But the current API is not ergonomic enough.
This PR
- Adds `ArenaMap::new`. Not sure why only `Arena` has it now.
- Adds `Arena{,Map}::with_capacity` for known-size storage.
- Adds entry-API for `ArenaMap` for easier `.entry(idx).or_default().push(value)` or `.entry(idx).or_insert(...)` operations.
Don't switch workspace on vfs file changes from libraries
When r-a starts up, it starts switching the workspace before all vfs
events have been processed which causes us to switch workspace multiple
times until all vfs changes have been processed. This scales with the
size of the project and its dependencies. If workspace files from
dependencies as well as the sysroot get loaded, we shouldn't switch
the workspace as those have no impact on the project workspace.
When r-a starts up, it starts switching the workspace before all vfs
events have been processed which causes us to switch workspace multiple
times until all vfs changes have been processed. This scales with the
size of the project and its dependencies. If workspace files from
dependencies as well as the sysroot get loaded, we shouldn't switch
the workspace as those have no impact on the project workspace.
feat: Only flycheck workspace that belongs to saved file
Supercedes https://github.com/rust-lang/rust-analyzer/pull/11038
There is still the problem that all the diagnostics are cleared, only clearing diagnostics of the relevant workspace isn't easily doable though I think, will have to dig into that
feat: support associated values in "Generate Enum Variant" assist
This change adds support for associated values to the "Generate Enum Variant" assist.
I've split the implementation out into 4 steps to make code review easier:
- Add "add_variant" support to the structural ast editing system in `edit_in_place`
- Migrate `generate_enum_variant` to use structural ast editing instead of string manipulation
- Support tuple fields
- Support record fields
Please let me know if I should leave the commits as-is, or squash before merging.
Fixes#12797
Add syntax fixup for while loops
Part of https://github.com/rust-lang/rust-analyzer/issues/12777
This is a first iteration to gather some feedback. In particular I'm not sure if the curly braces should be added here, but I couldn't get the test to work without them. Any hints welcome!
fix: Fix r-a spelling in some places
User-facing change: All commands are now rendered as "rust-analyzer: Command" rather than "Rust Analyzer: Command".
Alternative to https://github.com/rust-lang/rust-analyzer/pull/12910
Potentially controversial, since other extensions don't do this, so I won't self-approve.
fix: remove whitespaces from doctest names
When rustdoc runs doctests, it removes whitespaces from the tests' path ([code](25bb1c13bd/src/librustdoc/doctest.rs (L951))). See https://github.com/rust-lang/rust/pull/89422 for details.
Interestingly enough, "Run doctest" has been working without much problem even though rust-analyzer hasn't followed the change. This is because cargo passes the test name to rustdoc via `--test-args` option, and then rustdoc [splits it by whitespace](25bb1c13bd/src/librustdoc/config.rs (L513-L514)); the last element of the split test name **always** matches the test name that rustdoc generates.
However, it may run other tests unexpectedly (to be precise, this has long since been a thing because of the split). Consider the following example:
```rust
struct A<T, U>(T, U);
struct B<T, U>(T, U);
/// ```
/// doctest here
/// ```
impl<T, U> A<T, U> {}
/// ```
/// doctest here
/// ```
impl<T, U> B<T, U> {}
```
When you "Run doctest" either of the two, rustdoc considers "U>" one of the test specs and both doctests are run. This patch fixes it by following rustdoc and removing the whitespace from the doctests' name.
internal: Update `xtask promote` and release instructions
Update `xtask` for the subtree workflow. This doesn't explain how to do a `rust -> RA` sync, since that's definitely more involved, but will probably only happen rarely.
