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>
- make it possible to get parent trait from method
- add 'obligation' machinery for checking that a type implements a
trait (and inferring facts about type variables from that)
- handle type parameters of traits (to a certain degree)
- improve the hacky implements check to cover enough cases to exercise the
handling of traits with type parameters
- basic canonicalization (will probably also be done by Chalk)
1143: replace usages of `algo::generate` with `iter::successors` from std r=matklad a=Robbepop
Implements #1136
Co-authored-by: Robin Freyler <robin.freyler@gmail.com>
