10180: Fix resolution for inherent array methods r=flodiebold a=yotamofek
My second attempt at fixing #9992 , previous attempt was here: #10017 , but the logic was broken.
I know that this is not an ideal solution.... that would require, IIUC, a pretty big overhaul of the const generics handling in `rust-analyzer`. But, given that some of the array methods were/are being stabilized (e.g. https://github.com/rust-lang/rust/pull/87174 ), I think it'll be very beneficial to `rust-analyzer` users to have some preliminary support for them. (I know it's something I've been running into quite a lot lately :) )
As far as my limited understanding of this project's architecture goes, I think this isn't the worst hack in the world, and shouldn't be too much of a hassle to undo if/when const generics become better supported. If the maintainers deem this approach viable, I'll want to add some comments, emphasizing the purpose of this code, and that it should be removed at some point in the future.
10165: update to tracing-tree 0.1.10, which does not pull in syn r=matklad a=davidbarsky
I've updated tracing-tree to 0.1.10, which does not pull in syn and proc-macro2 (thanks for [the PR](https://github.com/davidbarsky/tracing-tree/pull/32), `@matklad!).`
It took a little bit more work than I expected to land https://github.com/davidbarsky/tracing-tree/issues/33, but I should get that done this week. However, I didn't want to keep y'all waiting, so here's _some_ of the changes that should hopefully improve your compile times.
10152: feat: Add completion for raw identifiers r=matklad a=nabakin
![rust_analyzer_pr](https://user-images.githubusercontent.com/894305/132110362-c21b713d-acaf-4a6d-9749-ff812172cbce.gif)
Adds support for valid Rust completion of raw identifiers.
Previously, code completion of fields made via raw identifiers would not re-insert those raw identifiers, resulting in invalid Rust code. Now, code completion of fields made via raw identifiers do re-insert those raw identifiers, resulting in valid Rust code.
The same is true for all code completion instances for fields and compatible Rust identifiers.
10157: Add section on configuring compilation errors when using `rust-project.json` r=matklad a=dozzman
When using `rust-project.json` to specify the project workspace, flychecks are disabled. It is not mentioned that they can be re-enabled by specifying a custom checking command using the `checkOnSave.overrideCommand` configuration. This additional section makes it clear that using `rust-project.json` disables flychecks and how to enable them either using `cargo check` (as an example) or (more likely) a custom command which emits json error messages.
Further information can be found at this forum thread:
This issue was not caused by us not being able to expand the macro (we can do that just fine). Instead, body lowering deliberately aborted lowering of a statement macro expansion when the expansion causes errors, citing some hygiene-related issue with recovery (`@edwin0cheng` if you remember what exactly the issue was I'd be happy to take a look).
Simply removing that code path doesn't cause any tests to fail, and makes completions in macros work better ("completion after `.`" is not the only thing that now works better, we also get better highlighting in incomplete macro calls).
Just to be sure, lets merge this after tomorrow's release.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10155: Minor: replace old name `CrateDefMap` in comments r=jonas-schievink a=toyboot4e
This PR replaces the old name `CrateDefMap` in comments with the new name `DefMap`. The renaming was done in [57a82fb0](https://github.com/rust-analyzer/rust-analyzer/commit/57a82fb0) (Jan 2021).
I didn't touch the working code ([CrateDefMapQueryQuery][QQ]). Thank you.
10139: Fix replacing for loops over ranges with for_each. r=yotamofek a=yotamofek
Previously, the assist would turn this:
```rust
for x in 0..92 {
...
}
```
into the syntactically incorrect code below:
```rust
0..92.for_each(|x| ...)
```
This fixes the assist by parenthesizing range expressions.
The problem was pretty simple, since we go through the ancestors we first try to expand the macro call node we are in since in attributed items these are valid syntaxnodes instead of TokenTrees, we then fail the expansion since the expansion only exists in the attribute expanded file and therefor skip the attribute expansion due to returning immediately. So instead of breaking out we just continue looking up the ancestors.
10103: fix: make "find references" multi-token mapping aware r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/10070
I was hoping that this would fix "find references" on salsa queries, but salsa emits multiple defs sharing the same span (the trait method, and an impl of that trait).
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9954: feat: Show try operator propogated types on ranged hover r=matklad a=Veykril
Basically this just shows the type of the inner expression of the `?` expression as well as the type of the expression that the `?` returns from:
![Code_wIrCxMqLH9](https://user-images.githubusercontent.com/3757771/130111025-f7ee0742-214a-493b-947a-b4a671e4be92.png)
Unless both of these types are `core::result::Result` in which case we show the error types only.
![Code_Xruw5FCBNI](https://user-images.githubusercontent.com/3757771/130111024-f9caef82-92e4-4070-b3dd-f2ff9e5d87a9.png)
If both types are `core::option::Option` with different type params we do not show this special hover either as it would be pointless(instead fallback to default type hover)
Very much open to changes to the hover text here(I suppose we also want to show the actual type of the `?` expression, that is its output type?).
The DNF construction code created expressions that were combined in a way that made us "forget" to make their contents valid DNF again. This PR fixes that by flattening nested `any(any())` and `all(all())` predicates. There was also a typo that led to a redundant call to `make_nnf` instead of the correct recursive call to `make_dnf` (but this didn't seem to break/fix anything).
This also adds some light property testing, though I'm not really sure this is the best way to do it.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Improves the struct generated by `extract_struct_from_enum_variant`.
Summary of changes:
- Indent the generated struct and enum to the same indent level
- Preserve comments & attributes from the enum variant (something I missed when doing the same thing for the variant fields)
- Use enum's visibility for fields without any visibility, instead of filling it in with `pub`
fn main() {
let a = 1;
let b = 2;
let c = 3;
let foo = Foo { <|> };
}
```
Before we would insert
```rust
Foo {
a: (),
b: (),
c: (),
}
```
now we would insert
```rust
Foo {
a,
b,
c: ()
}
```
Aleksey Kladov [Mon, 30 Aug 2021 16:39:19 +0000 (19:39 +0300)]
feat: improve CPU usage
closes #9922
Turned out to be trivial after preliminary refactor.
The intended behavior is that we schedule cache priming once ws become
quiescent (that is, we fully load cargo project), and we continue to
rschedule it until it completes (priming might get cancelled by user
typing into a file).