7880: Honor snippet capability when using the extract function assist r=lnicola a=Arthamys
This fixes issue #7793
Co-authored-by: san <san@alien.parts>
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.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7862: Remove incorrect broken test r=jonas-schievink a=jonas-schievink
`Struct` cannot be named at all in that position, since `super` doesn't
resolve to the block scope
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
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>
