1537: Less magic completions r=matklad a=marcogroppo
Restrict `if`, `not` and `while` postfix magic completions to boolean expressions and expressions of an unknown type.
(this may be controversial, marking as draft for this reason)
See the discussion in #1526.
Co-authored-by: Marco Groppo <marco.groppo@gmail.com>
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway
1456: Deduplicate method candidates r=matklad a=flodiebold
With trait method completion + autoderef, we were getting a lot of duplicates, which was really annoying...
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Can be used like this:
```
$ cargo run --release -p ra_cli -- \
analysis-bench ../chalk/ \
--complete ../chalk/chalk-engine/src/logic.rs:94:0
loading: 225.970093ms
from scratch: 8.492373325s
no change: 445.265µs
trivial change: 95.631242ms
```
Or like this:
```
$ cargo run --release -p ra_cli -- \
analysis-bench ../chalk/ \
--highlight ../chalk/chalk-engine/src/logic.rs
loading: 209.873484ms
from scratch: 9.504916942s
no change: 7.731119ms
trivial change: 124.984039ms
```
"from scratch" includes initial analysis of the relevant bits of the
project
"no change" just asks the same question for the second time. It
measures overhead on assembling the answer outside of salsa.
"trivial change" doesn't do an actual salsa change, it just advances
the revision. This test how fast is salsa at validating things.
1408: Associated type basics & Deref support r=matklad a=flodiebold
This adds the necessary Chalk integration to handle associated types and uses it to implement support for `Deref` in the `*` operator and autoderef; so e.g. dot completions through an `Arc` work now.
It doesn't yet implement resolution of associated types in paths, though. Also, there's a big FIXME about handling variables in the solution we get from Chalk correctly.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Note that we can't just remove CheckCanceled trait altogether:
sometimes it's useful to check for cancellation while the query is
running! We do this, for example, in the name resolution fixed-point
loop.
1394: Fix hover for pat that shadows items r=matklad a=sinkuu
```rust
fn x() {}
fn y() {
let x = 0i32;
x; // hover on `x` is expected to be `i32`, but the actual result was `fn x()`
}
```
This was because: if [`res.is_empty()`](656a0fa9f9/crates/ra_ide_api/src/hover.rs (L205)), it fallbacks to "index based approach" and adds `fn x()` to `res`, which makes [`res.extend(type_of)` below](656a0fa9f9/crates/ra_ide_api/src/hover.rs (L260-L266)) not happen.
Co-authored-by: Shotaro Yamada <sinkuu@sinkuu.xyz>
Before this commit, `Parse`s for original file ended up two times in
salsa's db: first, when we parse original file, and second, when we
parse macro or a file.
Given that parse trees are the worst ofenders in terms of memory, it
makes sense to make sure we store them only once.
This small fix should improve rust-analyzer resopnsivness for
real-time operations like onEnter handling.
Turns out, salsa's validation can take hundreds of milliseconds, and,
in case no changes were made, it won't be triggering any queries.
Because we check for cancellation in queries, that means that
validation is not cancellable!
What this PR does is injecting check_canceled checks into validation,
by using salsa's event API, which wasn't meant to be used like this,
but, hey, it works!
Here's the onEnter handling before and after this change:
https://youtu.be/7-ffPzgvH7o
