`ProjectWorkspace::to_roots` now returns a new `ProjectRoot` which contains
information regarding whether or not the given path is part of the current
workspace or an external dependency. This information can then be used in
`ra_batch` and `ra_lsp_server` to implement more advanced filtering. This allows
us to filter some unnecessary folders from external dependencies such as tests,
examples and benches.
995: Install and run `cargo watch` if user agrees r=matklad a=Xanewok
This isn't a glorious patch but hopefully is useful 👍 This introduces a default background `cargo watch` task and (separately from that) asks the user on every startup if they want to run `cargo watch` (installs it if it's not available).
r? @matklad does it fit the what you've been thinking about?
Co-authored-by: Igor Matuszewski <xanewok@gmail.com>
993: Fix installing vscode extension on MacOS r=matklad a=funkill
VSCode often installed in MacOS as `Visual Studio Code.app` package and `code` binary located at `Contents/Resources/app/bin` in package. This path not exists in `$PATH` variable and we can't run `code`.
In previous version of `do_run` function all before space was command and all after - arguments. If path or command has spaces, extracting command breaks. To fix this i extracted command to separated argument of function.
All packages can be placed in system app dir (`/Applications`) or user app dir (`~/Applications`). I created helper function for find app in this directories.
Co-authored-by: funkill2 <funkill2@gmail.com>
994: Upgrade ra_vfs to use new Filtering r=matklad a=vipentti
Upgrade `ra_vfs` to `0.2.0` that includes the filtering.
Currently this matches the previous filtering, meaning all roots are filtered
using the same rules.
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
991: Use Marker argument for item parsers r=matklad a=pcpthm
Before doing this for expressions, I found that the pattern (Marker argument) should be applied to the item parsers because visiblity and modifiers are parsed in a separate function.
Fixed some parser bugs:
- Fix pub_expr: `pub 42;` was allowed.
- Fix incorrect parsing of crate::path: incorrectly parsed as `crate` as a visibility.
Co-authored-by: pcpthm <pcpthm@gmail.com>
989: Implement naive version of fill_struct_fields assist r=matklad a=yanchith
Fixes#964
This implements the `fill_struct_fields` assist. Currently only works for named struct fields, but not for tuple structs, because we seem to be missing a `TupleStructLit` (akin to `StructLit`, but for tuple structs). I am happy to implement `TupleStructLit` parsing given some guidance (provided it's really missing) and make the assist work for tuple structs as well. Could do so either in this PR, or another one 🙂
Sorry if I missed something important, this is my first PR for Rust Analyzer.
Btw is there any way to run the assists in emacs?
UPDATE: I just realized that parsing `TupleStructLit` would be quite difficult as it it really similar, if not identical to a function call...
Co-authored-by: yanchith <yanchi.toth@gmail.com>
987: Refactor maybe_item to use Marker argument r=pcpthm a=pcpthm
As suggested at <https://github.com/rust-analyzer/rust-analyzer/pull/980#issuecomment-473659745>.
For expression paring functions, changing signature
- from `fn(&mut Parser) -> Option<CompletedMarker>` to `fn(&mut Parser, Marker) -> Result<CompletedMarker, Marker>`
- from `fn(&mut Parser) -> CompletedMarker` to `fn(&mut Parser, Marker) -> CompletedMarker`
is my plan.
Co-authored-by: pcpthm <pcpthm@gmail.com>
983: support remainder assignment operator r=matklad a=JeanMertz
`%=` was returning errors for me, turns out it wasn't added as a valid assignment operation.
I'm not sure what the best location would be to add a test for this. Please let me know and I'll add one.
Co-authored-by: Jean Mertz <jean@mertz.fm>
968: Macro aware name resoltion r=matklad a=matklad
The first commit lays the ground work for new name resolution, including
* extracting position-indendent items from parse trees
* walking the tree of modules
* old-style macro_rules resolve
cc @pnkfelix: this looks like an API name resolution should interact with.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
