bors[bot] [Sat, 6 Mar 2021 18:44:34 +0000 (18:44 +0000)]
Merge #7894
7894: generate_function assist: convert arg names to lower snake case r=Veykril a=JoshMcguigan
This PR fixes one of the points listed by @TimoFreiberg in #3639. Specifically that all generated argument names should be converted to lower snake case.
```rust
struct BazBaz;
fn foo() {
bar$0(BazBaz);
// ^ when triggering the assist here, you get the output below
}
// BEFORE
fn bar(BazBaz: BazBaz) ${0:-> ()} {
todo!()
}
bors[bot] [Fri, 5 Mar 2021 16:04:49 +0000 (16:04 +0000)]
Merge #7870
7870: Use chalk_ir::AdtId r=Veykril a=Veykril
It's a bit unfortunate that we got two AdtId's now(technically 3 with the alias in the chalk module but that one won't allow pattern matching), one from hir_def and one from chalk_ir(hir_ty). But the hir_ty/chalk one doesn't leave hir so it shouldn't be that bad I suppose. Though if I see this right this will happen for almost all IDs.
I imagine most of the intermediate changes to using chalk ids will turn out not too nice until the refactor is over.
bors[bot] [Tue, 2 Mar 2021 15:28:41 +0000 (15:28 +0000)]
Merge #7824
7824: feat: add type ascription r=matklad a=conradludgate
Based on this conversation: https://twitter.com/rust_analyzer/status/1366092401278922757
Built off of `add_turbo_fish`, finds the current `let` statement, checks if it has type/turbofish already and checks if the rhs function is generic.
There's one case I couldn't figure out how to implement that would be nice:
It's a bit annoying that this requires the `SyntaxNode` and `Semantics` to be pulled through `hover_for_definition` just so we can get the `std` crate but I couldn't think of a better way.
bors[bot] [Tue, 2 Mar 2021 13:32:06 +0000 (13:32 +0000)]
Merge #7335 #7691
7335: added region folding r=matklad a=LucianoBestia
Regions of code that you'd like to be folded can be wrapped with `// #region` and `// #endregion` line comments.
This is called "Region Folding". It is originally available for many languages in VSCode. But Rust-analyzer has its own folding function and this is missing.
With this Pull Request I am suggesting a simple solution.
The regions are a special kind of comments, so I added a bit of code in the comment folding function.
The regex to match are: `^\s*//\s*#?region\b` and `^\s*//\s*#?endregion\b`.
The number of space characters is not important. There is an optional # character. The line can end with a name of the region.
Example:
```rust
// 1. some normal comment
// region: test
// 2. some normal comment
calling_function(x,y);
// endregion: test
```
I added a test for this new functionality in `folding_ranges.rs`.
Please, take a look and comment.
I found that these exact regexes are already present in the file `language-configuration.json`, but I don't find a way to read this configuration. So my regex is hardcoded in the code.
7691: Suggest name in extract variable r=matklad a=cpud36
Generate better default name in extract variable assist as was mentioned in issue #1587
# Currently supported
(in order of declining precedence)
1. Expr is argument to a function; use corresponding parameter name
2. Expr is result of a function or method call; use this function/method's name
3. Use expr type name (if possible)
4. Fallback to `var_name` otherwise
* Should we more aggressively strip known types? E.g. we already strip `&T -> T`; should we strip `Option<T> -> T`, `Result<T, E> -> T`, and others?
* Integers and floats use `var_name` by default. Should we introduce a name, like `i`, `f` etc?
* Can we return a list and suggest a name when renaming(like IntelliJ does)?
* Should we add counters to remove duplicate variables? E.g. `type`, `type1`, type2`, etc.
bors[bot] [Tue, 2 Mar 2021 12:19:50 +0000 (12:19 +0000)]
Merge #7837
7837: Add more information to VSCode extenstion README r=matklad a=IceSentry
A lot of these are duplicated from the documentation or main README. While it's unfortunate to have duplicated information, the current VSCode page is very barebones and doesn't offer much confidence.
This updated README offers a few more links and follows a structure similar to the official rust extension and other popular vscode extensions. The additions are, as much as possible specific to the vscode extension and not rust-analyzer as a LSP.
The note about not using the official extension is also right there at the top because that's a common issue people have when trying it out.
I added the sponsor section since it's common in other extensions README, but I'm not sure if it's necessary
Co-authored-by: Charles Giguere <IceSentry@users.noreply.github.com> Co-authored-by: cgiguere <c.giguere42@gmail.com>
Charles Giguere [Mon, 1 Mar 2021 19:47:54 +0000 (14:47 -0500)]
Add more information to VSCode extenstion README
A lot of these are duplicated from the documentation or main README. While it's unfortunate to have duplicated information, the current VSCode page is very barebones and doesn't offer much confidence.
This updated README offers a few more links and follows a structure similar to the official rust extension and other popular vscode extensions. The additions are, as much as possible specific to the vscode extension and not rust-analyzer as a LSP.
The note about not using the official extension is also right there at the top because that's a common issue people have when trying it out.
I added the sponsor section since it's common in other extensions README, but I'm not sure if it's necessary
bors[bot] [Mon, 1 Mar 2021 18:52:39 +0000 (18:52 +0000)]
Merge #7834
7834: Fix `find_path` when inner items are present r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7750 (but adds a bunch of FIXMEs, because a lot of this code is still wrong in the presence of inner items)
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
projects / rust.git / log