| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
110: Signature help r=matklad a=kjeremy
@matklad Once this is in shape I would like to add tests. I think a separate PR should be done for returning documentation information and markdown.
Fixes #102
Co-authored-by: Jeremy A. Kolb <[email protected]>
|
| | | |
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
112: brush up docs r=matklad a=matklad
@kjeremy @aochagavia @DJMcNab anything else significant to add here?
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
122: Use rustc-hash crate r=matklad a=mominul
Replace std's HashMap, HashSet with FxHashMap and FxHashSet.
Closes #121
Thanks!
Co-authored-by: Muhammad Mominul Huque <[email protected]>
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
Co-authored-by: Adolfo Ochagavía <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
120: Cleanup grammar generation r=matklad a=ReinierMaas
https://github.com/rust-analyzer/rust-analyzer/blob/31c8ebb743572ef07ac4ca77ddd17eddbcf4b24c/crates/ra_syntax/src/ast/generated.rs#L207-L210
Needed an additional newline before the `pub fn`.
Removing `-` for #114.
Runnning `cargo gen-kinds` to update grammar.
Co-authored-by: Reinier Maas <[email protected]>
Co-authored-by: Reinier Maas <[email protected]>
|
| |
| |
| |
| | |
effect of running cargo gen-kinds
|
|/
|
| |
Removing `-` for #114
|
|\
| |
| |
| |
| |
| |
| |
| | |
115: Format vscode extension and add npm run fix r=matklad a=aochagavia
Co-authored-by: Adolfo Ochagavía <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
106: Add on-enter handler r=matklad a=matklad
Now, typing doc comments is much more pleasant
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| | |
Now, typing doc comments is much more pleasant
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
111: gate on tslint r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
107: Switch to absolute offsets for extend comment word r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|/ / |
|
|/ |
|
|\
| |
| | |
fix readme
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
104: Add vscode extension to CI r=aochagavia a=DJMcNab
Note that this testing is only done on travis - we are only running formatting and linting, so feature parity on appveyor is not required.
CC @aochagavia.
Fixes? #100
Co-authored-by: Daniel McNab <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
103: WIP: refactor vscode extension r=aochagavia a=aochagavia
Todo:
- [x] Add more comments, so other people can find their way in the codebase
- [x] Resolve remaining tslint suggestions
- [ ] Integrate with CI
@matklad The standard configuration of tslint forbids using `console.log` and `console.error`. Is there any reason we are using those or can I remove them? If they are used for debugging purposes I would prefer to remove them and rely on vscode's excellent debugger.
Co-authored-by: Adolfo Ochagavía <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|