1167: Added instructions for Sublime Text 3 setup r=matklad a=OtaK
Hey all!
I'm a Sublime Text 3 user and I wrote instructions to make `rust-analyzer` work with it.
So far works flawlessly, barring the missing features, which is fine (and not the point of this PR).
Great work <3
Thanks,
Mathieu
Co-authored-by: Mathieu Amiot <amiot.mathieu@gmail.com>
1148: Add token_tree_to_xxx functions r=matklad a=edwin0cheng
<del>As discus in PR #1147 , this PR added a `mbe::MacroKind` .
Currently only 2 kind of macro are supported, `SourceFile` and `Block`.</del>
Added following functions for `tt::TokenTree` and `ast::Node` conversion:
* token_tree_to_expr
* token_tree_to_pat
* token_tree_to_ty
* token_tree_to_macro_stmts
* token_tree_to_macro_items
And added two new syntax kind:
* MACRO_ITEMS
* MACRO_STMTS
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1164: Fix missing last token in mbe $repeat parsing r=matklad a=edwin0cheng
The `mbe parser` incorrectly eat one more token in $repeat parsing, described in #1141.
Remove incorrect token eating, and add related test.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1161: Add mbe 'item' matcher r=matklad a=edwin0cheng
Add `item` matcher in `ra_mbe` , and added corresponding `item()` parser in `ra_syntax`.
This PR also help PR #1148 for `Items` parsing.
And hopefully fix#1149 ?!
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1145: Fix#1099, plug self type type parameters in infer_path_expr r=flodiebold a=edwin0cheng
As discussed in #1099, this PR try to "plug" a `self type` type parameters in `infer_path_expr`.
All the cases in 1099 was fixed and tested.
And luckily, this PR fixed bug #1030 again and make the test output correct.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1158: cleanup cancellation r=matklad a=matklad
Now that we explicitelly exit the reading loop on exit notification,
we can assume that the sender is always alive
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1153: "Restart server" command r=jrvidal a=jrvidal
The only tricky aspect is that fact that once the `exit` command has been received, we no longer need to join on the reader thread.
Also, I think `terminateProcesses.sh` was not working properly. In fact, the very same script from the vscode language server implementation is not working either! It's because of that I noticed the reader thread issue 😮
Co-authored-by: Roberto Vidal <vidal.roberto.j@gmail.com>
1157: Add mbe stmt matcher r=matklad a=edwin0cheng
Add `stmt` matcher in `ra_mbe` , and added corresponding `stmt()` parser in `ra_syntax`.
This PR also help PR #1148 for `MarcoKind::Items` parsing.
Note:
* According [the book](https://doc.rust-lang.org/reference/macros-by-example.html), mbe `stmt` matcher will only match statement without the trailing semicolon
* `item` is a valid statement.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1144: Refactor method candidate generation a bit r=flodiebold a=flodiebold
This fixes the order in which candidates are chosen a bit (not completely though, as the ignored test demonstrates), and makes autoderef work with trait methods.
As a side effect, this also makes completion of trait methods work :)
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
This fixes the order in which candidates are chosen a bit (not completely
though, as the ignored test demonstrates), and makes autoderef work with trait
methods. As a side effect, this also makes completion of trait methods work :)
1137: Adds support for multiple editor workspaces on initialization r=matklad a=jrvidal
OK, so this "simple hack" turned out to be way more contrived than I expected 😂
### What works
This patch only handles multi-folder editor workspaces _on initialization_.
* I've found that modifying the layout of a workspace in VSCode just reloads the extension, so this hack should be enough for now.
* Not sure about how emacs-lsp behaves, but we fallback gracefully to the mono-folder workspace, so it should be fine.
### What doesn't work
* [x] `cargo watch` can only watch a single root folder with a `Cargo.toml`. I've left this part untouched but we could either warn that it's not supported or launch _multiple_ `cargo-watch` processes.
* [x] The `rust-analyzer/runnables` command is not functional, since we don't send the correct `cwd`.
* [x] Should we add some happy path test to `heavy_tests`?
* [ ] Going from a single `root` to multiple `roots` leaves us with a couple of `n * m` loops that smell a bit. The number of folders in the editor workspace is probably low though.
Co-authored-by: Roberto Vidal <vidal.roberto.j@gmail.com>
1138: Add L_DOLLAR and R_DOLLAR r=matklad a=edwin0cheng
As discussion in issue https://github.com/rust-analyzer/rust-analyzer/issues/1132 and PR #1125 , this PR add 2 `Syntax::Kind` : `L_DOLLAR` and `R_DOLLAR` for representing `Delimiter::None` in mbe and proc_marco. By design, It should not affect the final syntax tree, and will be discard in `TreeSink`.
My original idea is handling these 2 tokens case by case, but i found that they will appear in every place in the parser (imagine `tt` matcher). So this PR only handle it in `Parser::do_bump` and `Parser::start`, although It will not fix the `expr` matcher executing order problem in original idea.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1120: More trait infrastructure r=matklad a=flodiebold
This adds enough trait infrastructure to be able to make some deductions about type variables when resolving trait methods, while at the same time doing as little as possible that will be later replaced by Chalk 😄
E.g. (as the tests show) if we have
```rust
trait Trait<T> { fn method(self) -> T }
impl Trait<u32> for S {}
...
S.method()
```
we can infer that the return type is `u32`. On the other hand the unification logic is so primitive that we can't handle e.g. `impl<T> Trait<T> for S<T>`.
It's all quite hacky, I plan to refactor the parts that will stay, while hopefully the other parts will be replaced soon 🙂 In particular, we need to handle 'containers' (impls and trait defs) more cleanly, and I need to reorganize the method resolution / type inference code...
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
