While debugging https://github.com/rust-analyzer/rust-analyzer/issues/7902, I've found that there are some duplicates are produced during the external dependencies lookup.
I've spotted at least some of the `indexed_value.value` duplicated when typed `Arc` and requested the completions for that, so I've also deduped the `IndexedValue`'s to avoid unnecessary computations.
This helps to show `Arc` in the completion suggestions in a zero dependency project and in `hir` module, but we loose it again in the `ide` module.
bors[bot] [Sun, 7 Mar 2021 00:32:56 +0000 (00:32 +0000)]
Merge #7892
7892: Fix TokenStream::from_str for input consisting of a single group with delimiter r=edwin0cheng a=kevinmehall
TokenStream holds a `tt::Subtree` but assumes its `delimiter` is always `None`. In particular, the iterator implementation iterates over the inner `token_trees` and ignores the `delimiter`.
However, `TokenStream::from_str` violated this assumption when the input consists of a single group by producing a Subtree with an outer delimiter, which was ignored as seen by a procedural macro.
`tt::Subtree` is just `pub delimiter: Option<Delimiter>, pub token_trees: Vec<TokenTree>`, so a Subtree that is statically guaranteed not to have a delimiter is just `Vec<TokenTree>`.
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!()
}
Kevin Mehall [Sat, 6 Mar 2021 16:46:32 +0000 (09:46 -0700)]
Refactor TokenStream to hold Vec<TokenTree> instead of tt::Subtree
`TokenStream` assumes that its subtree's delimeter is `None`, and this
should be encoded in the type system instead of having a delimiter field
that is mostly ignored.
`tt::Subtree` is just `pub delimiter: Option<Delimiter>, pub
token_trees: Vec<TokenTree>`, so a Subtree that is statically guaranteed
not to have a delimiter is just Vec<TokenTree>.
Kevin Mehall [Sat, 6 Mar 2021 16:36:22 +0000 (09:36 -0700)]
Fix TokenStream::from_str for input consisting of a single Group
TokenStream holds a `tt::Subtree` but assumes its `delimiter` is always
`None`. In particular, the iterator implementation iterates over the
inner `token_trees` and ignores the `delimiter`.
However, `TokenStream::from_str` violated this assumption when the input
consists of a single Group by producing a Subtree with an outer
delimiter, which was ignored as seen by a procedural macro.
In this case, wrap an extra level of Subtree around it.
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.
projects / rust.git / log