1562: Continue support for .await r=matklad a=unrealhoang
- add await expr to ast and HIR Expr
- infer type for `.await`
Co-authored-by: Unreal Hoang <unrealhoang@gmail.com>
* make stuff more type-safe by using `BindPat` instead of just `Pat`
* don't add `mut` into binding hash
* reset shadow counter when we enter a function
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>
1520: Ignore workspace/didChangeConfiguration notifications. r=matklad a=bolinfest
If the client happens to send a `workspace/didChangeConfiguration`
notification, it is nicer if rust-analyzer can just ignore it rather than
crash with an "unhandled notification" error.
Co-authored-by: Michael Bolin <bolinfest@gmail.com>
This appears to have been introduced ages ago in
be742a5877
but has since been removed.
As it stands, it is problematic if multiple instances of the
rust-analyzer LSP are launched during the same VS Code session because
VS Code complains about multiple LSP servers trying to register the
same command.
Most LSP servers workaround this by parameterizing the command by the
process id. For example, this is where `rls` does this:
ff0b9057c8/rls/src/server/mod.rs (L413-L421)
Though `apply_code_action` does not seems to be used, so it seems better
to delete it than to parameterize it.
1515: Trait environment r=matklad a=flodiebold
This adds the environment, i.e. the set of `where` clauses in scope, when solving trait goals. That means that e.g. in
```rust
fn foo<T: SomeTrait>(t: T) {}
```
, we are able to complete methods of `SomeTrait` on the `t`. This affects the trait APIs quite a bit (since every method that needs to be able to solve for some trait needs to get this environment somehow), so I thought I'd do it rather sooner than later ;)
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
1504: Simplify LSP handlers r=matklad a=kjeremy
Takes advantage of protocol inheritance via composition and simplifies some responses via the `From`/`Into` traits.
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
1499: processing attribute #[path] of module r=matklad a=andreevlex
support two cases
- simple name file `foo.rs`
- declaration in mod.rs
#1211
Co-authored-by: Alexander Andreev <andreevlex.as@gmail.com>
1491: More clippy r=matklad a=kjeremy
A few more clippy changes.
I'm a little unsure of the second commit. It's the trivially_copy_pass_by_ref lint and there are a number of places in the code we could use it if it makes sense.
Co-authored-by: Jeremy Kolb <kjeremy@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
Array members are allow to have attributes such as `#[cfg]`.
This is a bit tricky as we don't know if the first expression is an
initializer or a member until we encounter a `;`. This reuses a trick
from `stmt` where we remember if we saw an attribute and then raise an
error if the first expression ends up being an initializer.
This isn't perfect as the error isn't correctly located on the attribute
or initializer; it ends up immediately after the `;`.
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>
My workflow in Visual Studio Code + Rust Analyzer has become:
1. Make a change to Rust source code using all the analysis magic
2. Save the file to trigger `cargo watch`. I have format on save enabled
for all file types so this also runs `rustfmt`
3. Fix any diagnostics that `cargo watch` finds
Unfortunately if the Rust source has any syntax errors the act of saving
will pop up a scary "command has failed" message and will switch to the
"Output" tab to show the `rustfmt` error and exit code.
I did a quick survey of what other Language Servers do in this case.
Both the JSON and TypeScript servers will swallow the error and return
success. This is consistent with how I remember my workflow in those
languages. The syntax error will show up as a diagnostic so it should
be clear why the file isn't formatting.
I checked the `rustfmt` source code and while it does distinguish "parse
errors" from "operational errors" internally they both result in exit
status of 1. However, more catastrophic errors (missing `rustfmt`,
SIGSEGV, etc) will return 127+ error codes which we can distinguish from
a normal failure.
This changes our handler to log an info message and feign success if
`rustfmt` exits with status 1.
Another option I considered was only swallowing the error if the
formatting request came from format-on-save. However, the Language
Server Protocol doesn't seem to distinguish those cases.
1443: cache chalk queries r=flodiebold a=matklad
This gives a significant speedup, because chalk will call these
functions several times even withing a single revision. The only
significant one here is `impl_data`, but I figured it might be good to
cache others just for consistency.
The results I get are:
Before:
from scratch: 16.081457952s
no change: 15.846493ms
trivial change: 352.95592ms
comment change: 361.998408ms
const change: 457.629212ms
After:
from scratch: 14.910610278s
no change: 14.934647ms
trivial change: 85.633023ms
comment change: 96.433023ms
const change: 171.543296ms
Seems like a nice win!
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
This gives a significant speedup, because chalk will call these
functions several times even withing a single revision. The only
significant one here is `impl_data`, but I figured it might be good to
cache others just for consistency.
The results I get are:
Before:
from scratch: 16.081457952s
no change: 15.846493ms
trivial change: 352.95592ms
comment change: 361.998408ms
const change: 457.629212ms
After:
from scratch: 14.910610278s
no change: 14.934647ms
trivial change: 85.633023ms
comment change: 96.433023ms
const change: 171.543296ms
Seems like a nice win!
Now, one can use `let _p = ra_prof::cpu_profiler()` to capture profile
of a block of code.
This is not an out of the box experience, as that relies on gperfools
See the docs on https://github.com/AtheMathmo/cpuprofiler for more!
1432: Make fill_match_arm work with trivial arm r=matklad a=ironyman
Addresses this issue https://github.com/rust-analyzer/rust-analyzer/issues/1399
One minor issue I noticed is that complete_postfix creates an arm like this
```
match E::X {
<|>_ => {},
}
```
but fill_match_arms creates arms like this
```
E::X => (),
```
Co-authored-by: ironyman <ironyman@users.noreply.github.com>
Co-authored-by: Changyu Li <changyl@microsoft.com>
1409: The Fall down of failures r=matklad a=mominul
😁
Replaced all the uses of `failure` crate with `std::error::Error`.
Closes#1400
Depends on rust-analyzer/teraron#1
Co-authored-by: Muhammad Mominul Huque <mominul2082@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>
1406: reuse AnalysisHost in batch analysis r=matklad a=matklad
We do some custom setup in `AnalysisHost`, like setting up LRU size. I figure it's a good idea to not duplicate this work in batch analysis, *if* we want to keep batch and non-batch close.
Long-term, I see a value in keeping batch a separate, lighter weight thing. However, because now we use batch to measure performance, keeping them closer makes more sense.
I'd also like to add ability to get completions by using batch analysis, and that will require ra_ide_api as well.
@flodiebold were there some reason why we haven't started with this approach from the start?
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1404: Fight down failures! r=matklad a=mominul
issue #1400
Now only `ra_tools` crate depends on `failure`, should I also fight those? 😁
Co-authored-by: Muhammad Mominul Huque <mominul2082@gmail.com>
1403: Add alloc -> core dependency r=matklad a=flodiebold
Also a small fix for the ra-emacs-lsp company fix.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
The issue was windows specific -- cancellation caused collection of
bracktraces at some point, and that was slow on windows.
The proper fix here is to make sure that we don't collect bracktraces
unnecessary (which we currently do due to failure), but, as a
temporary fix, let's just not force their collection in the first
place!
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>
1374: Implement `cargo lint` and fix some clippy errors r=alanhdu a=alanhdu
This creates a `cargo lint` command that runs clippy with certain lints disabled. I've also gone ahead and fixed some of the lint errors, although there are many more still to go.
cc #848
Co-authored-by: Alan Du <alanhdu@gmail.com>
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.
1368: Store referece instead of full token tree in tokenbuffer r=matklad a=edwin0cheng
This PR try to minimize the memory allocation in converting `SyntaxNode` to `TokenTree` by using reference isnteead of full token tree in `TokenBuffer`.
Note that the final goal is replace `TokenTree` with TokenBuffer such that there is no conversion between them.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1360: Improve goto definition for MBE r=matklad a=edwin0cheng
This PR improve the macro resolution for goto definition and expression macro invocation by using proper path resolution for external macros.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
We use panics for cancellation, so we could trigger panic while
holding the solver. std::sync::Mutex will be poisoned as a result,
which and all further attempts to use solver (from other threads) will
panic as well.
This commit switches to parking_lot::Mutex which just unlocks on panic.
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
1337: Move syntax errors our of syntax tree r=matklad a=matklad
I am not really sure if it's a good idea, but `SyntaxError` do not really belong to a `SyntaxTree`. So let's just store them on the side?
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1336: Refactor SubtreeSource r=matklad a=edwin0cheng
This PR simplify `SubtreeSource` by removing `SubtreeWalk` and `Querier` and only walk through the top level `TokenTree` when collecting token from source, by comparing two cursors directly.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Very simple approach: For each identifier, set the hash of the range
where it's defined as its 'id' and use it in the VSCode extension to
generate unique colors.
Thus, the generated colors are per-file. They are also quite fragile,
and I'm not entirely sure why. Looks like we need to make sure the
same ranges aren't overwritten by a later request?
1328: Change TokenSource to iteration based r=matklad a=edwin0cheng
This PR change the `TokenSource` trait from random access to be an iteration based trait:
```rust
/// `TokenSource` abstracts the source of the tokens parser operates one.
///
/// Hopefully this will allow us to treat text and token trees in the same way!
pub trait TokenSource {
fn current(&self) -> Token;
/// Lookahead n token
fn lookahead_nth(&self, n: usize) -> Token;
/// bump cursor to next token
fn bump(&mut self);
/// Is the current token a specified keyword?
fn is_keyword(&self, kw: &str) -> bool;
}
/// `TokenCursor` abstracts the cursor of `TokenSource` operates one.
#[derive(Debug, Copy, Clone, Eq, PartialEq)]
pub struct Token {
/// What is the current token?
pub kind: SyntaxKind,
/// Is the current token joined to the next one (`> >` vs `>>`).
pub is_jointed_to_next: bool,
}
```
Note that the refactoring based on this new trait will be separated to incoming PRs
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1316: Simplify code model r=matklad a=matklad
* remove references from types which are now id-based
* remove api/impl separation, as the impl is a tiny fraction of API anyway
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1290: Add Union to code_model r=matklad a=matklad
@flodiebold I am conflicted about two possible implementation approaches:
* we can add a separate `struct Union` to code model
* we can add `fn is_union(&self)` to existing `Struct`
This PR goes with the former approach, because it seems like Unions are sufficiently different in semantics to warrant a separate types. Which is in contrast to Syntax Tree, where both structs and unions share the same node kind, because their syntax is the same.
What would be the right thing to do here?
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1312: Introduce TokenBuffer r=matklad a=edwin0cheng
As discussed in Zulip, this PR Introduce `TokenBuffer` , a safe version of `syn` crate `TokenBuffer` which support cursor based traversal of `tt::TokenTree`. This is the basis of incoming refactoring of `TokenSource` iterator based API.
This PR do the following things:
* Add TokenBuffer in `ra_tt` crate.
* Try to use this new API to refactor the `SubtreeSource` to prove it usage.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1281: Move arm cond to match guard r=matklad a=unrealhoang
I did split the rename to another commit, yet Github UI still show entirely new file change. Please review using commits.
Co-authored-by: Unreal Hoang <unrealhoang@gmail.com>
1299: Use ThemeColor and add support for light themes r=matklad a=lnicola
Part of #1294.
- switch to `ThemeColor`
- add light and high contrast theme definitions
- highlight control flow keywords and `unsafe`
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
1287: Add support of matching literal in mbe r=matklad a=edwin0cheng
This PR adds support of matching literal in mbe , which used in our `T` macro :
```rust
macro_rules! foo {
('(') => {
fn foo() {}
}
}
```
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1286: Add infer for generic default type r=flodiebold a=edwin0cheng
This PR add infer support for generic default type:
```
struct Gen<T=u32> {
val: T
}
```
* add the (unresolved) defaults from the definition to GenericParams
* add a query generic_defaults that resolves those defaults to types and returns a Substs
* add the missing type in `substs_from_path_segment`
* add tests
based on the idea in this [comment](https://github.com/rust-analyzer/rust-analyzer/issues/1099#issuecomment-484206279)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1272: Error out non single root token tree conversion r=matklad a=edwin0cheng
This PR add a check to prevent non single root token tree conversion between token trees and syntax tree.
It should prevent the assert produced in #1267.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Reducing it to 2 was just a failed attempt to see whether that would help fix
some slow cases; in fact, it can create new slow cases by replacing concrete
types by variables.
For Send/Sync/Sized, we don't handle auto traits correctly yet and because they
have a lot of impls, they can easily lead to slowdowns. In the case of
Fn/FnMut/FnOnce, we don't parse the special Fn notation correctly yet and don't
handle closures yet, so we are very unlikely to find an impl.
This is slightly hacky, but maybe more elegant than alternative solutions: We
just use a hardcoded Chalk trait ID which we special-case to have no impls.
1251: Chalk integration improvements r=matklad a=flodiebold
A few improvements that came up while working on where clause support:
- turn `implements` into a query again to improve performance
- allow skipping to a specific function with `analysis-stats`, e.g. `ra_cli analysis-stats --only world_symbols`
- deduplicate impls in impls_for_trait -- previously many impls e.g. from std where repeated many times, this should help performance as well...
- add a `HirDisplay` implementation for TraitRef (not used here anywhere, but useful for debugging)
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
1208: [WIP] Goto for Macro's r=matklad a=Lapz
Adds goto definition for macros. Currently only works for macros in the current crate ~~otherwise it panics~~. Proper macro resolution needs to be added for it to resolve macros in other crates.
Todo
- [X] Allow goto from macro calls
- [X] Fix panics
- [x] Add tests
Co-authored-by: Lenard Pratt <l3np27@gmail.com>
1216: Basic Chalk integration r=matklad a=flodiebold
This replaces the ad-hoc `implements` check by Chalk. It doesn't yet any new functionality (e.g. where clauses aren't passed to Chalk yet). The tests that exist actually work, but it needs some refactoring, currently crashes when running analysis on the RA repo, and depends on rust-lang/chalk#216 which isn't merged yet 😄
The main work here is converting stuff back and forth and providing Chalk with the information it needs, and the canonicalization logic. Since canonicalization depends a lot on the inference table, I don't think we can currently reuse the logic from Chalk, so we need to implement it ourselves; it's not actually that complicated anyway ;) I realized that we need a `Ty::Bound` variant separate from `Ty::Param` -- these are two different things, and I think type parameters inside a function actually need to be represented in Chalk as `Placeholder` types.
~~Currently this crashes in the 'real' world because we don't yet do canonicalization when filtering method candidates. Proper canonicalization needs the inference table (to collapse different inference variables that have already been unified), but we need to be able to call the method candidate selection from the completion code... So I'm currently thinking how to best handle that 😄~~
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
1238: Macro queries r=edwin0cheng a=matklad
In https://github.com/rust-analyzer/rust-analyzer/pull/1231, I've added aggressive clean up of `ast_id_to_node` query.
The result of this query is a `SyntaxTree`, and we don't want to retain syntax trees in memory unless absolutely necessary.
Moreover, `SyntaxTree` has identity equality semantics, meaning that we'll get a diffferent syntax tree for a file after every reparse. That means that `ast_id_to_node` query should not genereally be used in HIR, unless it is behind some kind of salsa firewall, like the `raw` module of name resoulution.
However, that PR resulted in the abysmal performance: turns out we were using ast_id_to_node quite heavily in hir when expanding macros!
So this PR installs the more incremental-friendly query structure:
* converting source to token tree is now a query; changing source without affecting token-trees will now preserve macro expansions
* expand macro (tt -> tt) is now a query as well, so we cache macro expansions *before* parsing them into item lists or expressions, which is nice: we can cache expansion without knowing the calling context!
r? @edwin0cheng
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Currently, when expanding macros, we look at the source code
directly (we invoke ast_id_to_node query via to_node method).
This is less then ideal, because it make us re-expand macros after
every source change.
This commit establishes a salsa-firewall: a query to get macro call's
token tree. Unlike the syntax tree, token tree changes only if we
actually modify the macro itself.
1230: Desugar doc comments to `#[doc = "...."]` attributes in `syntax node` to tt conversion r=matklad a=edwin0cheng
As discussed in [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/MBE.20discussion/near/164446835), this PR desugar doc comments to `#[doc = "...."]` in `syntax node` to tt conversion.
Note that after this PR, all obvious mbe bugs in dogfooding are fixed. (i.e. No parsing or expanding mbe error in `env RUST_LOG=ra_hir=WARN target\release\ra_cli.exe analysis-stats`) 🎉
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1227: Add `default_type` method in `TypeParam` Node r=matklad a=edwin0cheng
This PR add a `default_type` method in `TypeParam` Node which allow future PR to handle #1099 case.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
