167: Attempt to extract useful comments from function signatures r=matklad a=kjeremy
I'm trying to extract useful function comments for signature info. This will also be useful for hover. This is a WIP (and actually works pretty well!) but I don't think it's the right approach long term so some guidance would be appreciated so that we could also get comments for say types and variable instances etc.
Currently `test_fn_signature_with_simple_doc` fails due to a bug in `extend` but we probably shouldn't use this approach anyway. Maybe comments should be attached to nodes somehow? I'm also thinking that maybe the markdown bits should live in the language server.
Thoughts?
Co-authored-by: Jeremy A. Kolb <jkolb@ara.com>
176: Move completio to ra_analysis r=matklad a=matklad
While we should handle completion for isolated file, it's better
achieved by using empty Analysis, rather than working only with &File:
we need memoization for type inference even inside a single file.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
While we should handle completion for isolated file, it's better
achieved by using empty Analysis, rather than working only with &File:
we need memoization for type inference even inside a single file.
This is a first step towards queryifing completion and resolve.
Some code currently duplicates ra_editor: the plan is to move all
completion from ra_editor, but it'll take more than one commit.
157: Introduce ModuleId r=matklad a=matklad
Previously, module was synonym with a file, and so a module could have
had several parents. This commit introduces a separate module concept,
such that each module has only one parent, but a single file can
correspond to different modules.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Previously, module was synonym with a file, and so a module could have
had several parents. This commit introduces a separate module concept,
such that each module has only one parent, but a single file can
correspond to different modules.
156: Cargo Update run r=kjeremy a=kjeremy
Bump relative-path to 0.4.0
Failure 0.1.3 to fix leak with downcast
Updated everything else too
Co-authored-by: Jeremy A. Kolb <jkolb@ara.com>
138: Fix some clippy lints r=matklad a=alanhdu
I went ahead and fixed all the clippy lints (there were a couple I thought would be better unfixed and added `cfg` statements to allow them) and also re-enabled clippy and rustfmt in CI.
They were disabled with `no time to explain, disable clippy checks`, so hopefully this won't go against whatever the reason at the time was 😆.
One question about the CI though: right now, it's an allowed failure that runs against the latest nightly each time. Would it be better to pin it to a specific nightly (or use the `beta` versions) to lower the churn?
Co-authored-by: Alan Du <alanhdu@gmail.com>
143: Implement Find All References and Rename for local variables r=matklad a=kjeremy
Expose `find_all_refs` in `Analysis`. This currently only works for local variables.
Use this in the LSP to implement find all references and rename.
Co-authored-by: Jeremy A. Kolb <jkolb@ara.com>
128: Add a test to verify if the generated codes are up-to-date. r=matklad a=mominul
This test checks if the generated codes are up-to-date every time during `cargo test`.
I have confirmed that the test works by manually editing the `grammar.ron` file.
Closes#126
Thanks!
Co-authored-by: Muhammad Mominul Huque <mominul2082@gmail.com>
127: Improve folding r=matklad a=aochagavia
I was messing around with adding support for multiline comments in folding and ended up changing a bunch of other things.
First of all, I am not convinced of folding groups of successive items. For instance, I don't see why it is worthwhile to be able to fold something like the following:
```rust
use foo;
use bar;
```
Furthermore, this causes problems if you want to fold a multiline import:
```rust
use foo::{
quux
};
use bar;
```
The problem is that now there are two possible folds at the same position: we could fold the first use or we could fold the import group. IMO, the only place where folding groups makes sense is when folding comments. Therefore I have **removed folding import groups in favor of folding multiline imports**.
Regarding folding comments, I made it a bit more robust by requiring that comments can only be folded if they have the same flavor. So if you have a bunch of `//` comments followed by `//!` comments, you will get two separate fold groups instead of a single one.
Finally, I rewrote the API in such a way that it should be trivial to add new folds. You only need to:
* Create a new FoldKind
* Add it to the `fold_kind` function that converts from `SyntaxKind` to `FoldKind`
Fixes#113
Co-authored-by: Adolfo Ochagavía <github@adolfo.ochagavia.xyz>
Implements a pretty barebones function signature help mechanism in
the language server.
Users can use `Analysis::resolve_callback()` to get basic information
about a call site.
Fixes#102
116: Collapse comments upon join r=matklad a=aochagavia
Todo:
- [x] Write tests
- [x] Resolve fixmes
- [x] Implement `comment_start_length` using the parser
I left a bunch of questions as fixmes. Can someone take a look at them? Also, I would love to use the parser to calculate the length of the leading characters in a comment (`//`, `///`, `//!`, `/*`), so any hints are greatly appreciated.
Co-authored-by: Adolfo Ochagavía <aochagavia92@gmail.com>
Co-authored-by: Adolfo Ochagavía <github@adolfo.ochagavia.xyz>
118: Remove error publishing through publishDecorations r=matklad a=aochagavia
The errors are already reported by `publishDiagnostics`
Closes#109
Co-authored-by: Adolfo Ochagavía <aochagavia92@gmail.com>
98: WIP: Add resolve_local_name to resolve names in a function scope r=kjeremy a=kjeremy
First step to resolving #80
Co-authored-by: Jeremy A. Kolb <jkolb@ara.com>
93: Support leading pipe in match arms r=matklad a=DJMcNab
This adds support for match arms of the form:
```rust
<...>
| X | Y => <...>,
| X => <...>,
| 1..2 => <...>,
etc
```
# Implementation discussion
This just naïvely 'eats' a leading pipe if one is available. The equivalent line in the reference `libsyntax` is in [`parse_arm`](441519536c/src/libsyntax/parse/parser.rs (L3552)).
As noted in the comment linked above, this feature was formally introduced as a result of rust-lang/rfcs#1925. This feature is in active use in the [`rust-analyzer` codebase](c87fcb4ea5/crates/ra_syntax/src/syntax_kinds/generated.rs (L231))
I have added some tests for this feature, but maybe more would be required
EDIT: Always looking for feedback - is this PR description over-engineered?
Co-authored-by: Daniel McNab <36049421+djmcnab@users.noreply.github.com>
