Tiddo Langerak [Tue, 9 Aug 2022 06:41:56 +0000 (09:41 +0300)]
Feat: extracted method from trait impl is placed in existing impl
Previously, when triggering a method extraction from within a trait
impl block, then this would always create a new impl block for
the struct, even if there already is one. Now, it'll put the extracted
method in the matching existing block if it exists.
bors [Mon, 8 Aug 2022 15:03:39 +0000 (15:03 +0000)]
Auto merge of #12962 - lowr:patch/parse-last-range-pattern, r=Veykril
Parse range patterns in struct and slice without trailing comma
Resolves #12935
This patch includes the support for range patterns in slices, which is unstable (tracked in https://github.com/rust-lang/rust/issues/67264). If it's not desired I can remove it.
bors [Mon, 8 Aug 2022 11:28:42 +0000 (11:28 +0000)]
Auto merge of #12942 - lowr:fix/concat-with-char, r=Veykril
fix: make `concat!` work with char
Fixes #12921
- I avoided making `unquote_str()` take char literals as well because it's depended on by another function `parse_string()` that's only supposed to take strings.
- Even with this patch, we don't output `\0` as `\u{0}` which #12921 pointed out ~~, but we're not actually responsible for serializing it but rowan is~~. They are functionally equivalent and I don't think it'd cause any confusion, but we *could* try escaping them before serialization (for reference, `rustc -Zunpretty=expanded`, which `cargo expand` uses under the hood, [makes use of `str::escape_default()`](https://github.com/rust-lang/rust/blob/3830ecaa8db798d2727cbdfa4ddf314ff938f268/compiler/rustc_ast/src/util/literal.rs#L161).
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
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!`](https://github.com/rust-lang/rust-analyzer/blob/51705698bd66919435e4fcbc25d96bd7fc5583f4/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.
bors [Sat, 6 Aug 2022 13:39:31 +0000 (13:39 +0000)]
Auto merge of #12931 - oxalica:feat/la-arena-apis, r=lnicola
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.
bors [Fri, 5 Aug 2022 13:13:44 +0000 (13:13 +0000)]
Auto merge of #12947 - Veykril:switch-workspace, r=Veykril
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.
bors [Fri, 5 Aug 2022 12:55:36 +0000 (12:55 +0000)]
Auto merge of #12948 - Veykril:classify-ops, r=Veykril
feat: Handle operators like their trait functions in the IDE
Allows hover and goto implementation to work on `?`, indexing brackets, binary operators, prefix operators and `await`. Regarding `await`, hover will continue to show the keyword docs while goto implementation will bring the user to the `poll` function of the `Future` implementation.
Lukas Wirth [Fri, 5 Aug 2022 10:06:31 +0000 (12:06 +0200)]
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.
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
bors [Tue, 2 Aug 2022 19:50:01 +0000 (19:50 +0000)]
Auto merge of #12837 - DorianListens:dscheidt/generate-enum-data, r=Veykril
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.
bors [Tue, 2 Aug 2022 14:08:56 +0000 (14:08 +0000)]
Auto merge of #12880 - palango:while-fixup, r=Veykril
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!
bors [Mon, 1 Aug 2022 10:12:59 +0000 (10:12 +0000)]
Auto merge of #12918 - lowr:fix/doctest-names, r=Veykril
fix: remove whitespaces from doctest names
When rustdoc runs doctests, it removes whitespaces from the tests' path ([code](https://github.com/rust-lang/rust/blob/25bb1c13bd472b75ceebee3b8dcf4dcbc431a8be/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](https://github.com/rust-lang/rust/blob/25bb1c13bd472b75ceebee3b8dcf4dcbc431a8be/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:
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.
Auto merge of #12915 - lnicola:promote-subtree, r=lnicola
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.
projects / rust.git / log