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:
```rust
#[test]
fn add_type_ascription_function_result() {
check_assist(
add_type_ascription,
r#"
fn make<T>() -> Result<T, &'static str> {}
fn main() {
let x = make()$0;
}
"#,
r#"
fn make<T>() -> Result<T, &'static str> {}
fn main() {
let x: Result<${0:_}, &'static str> = make();
}
"#,
);
}
```
The `Function::ret_type` fn wasn't returning anything much useful so I'm not sure how to identity such scenarios just yet
Co-authored-by: Conrad Ludgate <conradludgate@gmail.com>
7795: Show docs on hover for keywords and primitives r=matklad a=Veykril
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.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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
# Showcase
# Questions
* 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.
Co-authored-by: Luciano Bestia <LucianoBestia@gmail.com>
Co-authored-by: Luciano <31509965+LucianoBestia@users.noreply.github.com>
Co-authored-by: Vladyslav Katasonov <cpud47@gmail.com>
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>
7836: Check for path dev-dependencies with a version number r=lnicola a=lnicola
Closes https://github.com/rust-analyzer/rust-analyzer/pull/7828#issuecomment-788174522.
This looks a bit ugly, but at least fixes an issues where we missed target-specific dependencies.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
7827: Fix proc macro TokenStream::from_str token ids r=vlad20012 a=vlad20012
To be honest, I don't know what it changes from a user perspective.
Internally, this fixes spans (token ids) of a `TokenStream` parsed from a string:
```rust
#[proc_macro_derive(FooDerive)]
pub fn foo_derive(item: TokenStream) -> TokenStream {
"fn foo() {}".parse().unwrap()
}
```
Previously, `TokenStream` was constructed from tokens with incremental ids (that conflicted with call-site tokens). Now they are `-1`.
Co-authored-by: vlad20012 <beskvlad@gmail.com>
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
7829: Bump deps r=matklad a=lnicola
Unfortunately, this brings a bunch of proc macros dep because `cargo-metadata` went full-in on `derive-builder`. I'm not sure what we can do here..
7833: Use chalk_ir::Mutability r=Veykril a=Veykril
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
