| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
294: Bump languageserver-types to 0.53.0 to support LSP 3.14.0 r=matklad a=kjeremy
See: https://microsoft.github.io/language-server-protocol/specification#version_3_14_0
Co-authored-by: Jeremy A. Kolb <[email protected]>
|
|/
|
|
| |
See: https://microsoft.github.io/language-server-protocol/specification#version_3_14_0
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
273: Add a test to ensure that we can parse each file r=matklad a=DJMcNab
Note that this has a non-spurious failure in ra_analysis/src/mock_analysis.
Probably fixes #195.
If my understanding is correct, fixes #214 and fixes #225.
Co-authored-by: DJMcNab <[email protected]>
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
This approach is correct, but it needs an addition to Restrictions too
This reverts commit ad00d0c8a5f64142e6636e8b048204c8f8982f4a.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
TODO: Fix this when the block like macro is in expression position
E.g. `test(test!{})` currently parses
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
I'm not certain that this is correct, so extra eyes would be good
|
| | |
|
| |
| |
| |
| | |
Note that this has a non-spurious failure in ra_analysis/src/mock_analysis
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
291: File module source does not depend on syntax r=matklad a=matklad
Fixes this problem: https://github.com/rust-analyzer/rust-analyzer/pull/289#issuecomment-448398571
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
289: WIP: fix accidently quadratic behavior r=matklad a=matklad
we've recmoputed item map every time previously :man_facepalming: :man_facepalming: :man_facepalming:
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|/ / |
|
| |
| |
| |
| | |
cc #288
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
286: move thread worker to a separate crate r=matklad a=matklad
Going to tackle https://github.com/rust-analyzer/rust-analyzer/issues/243, this is a refactoring towards that goal
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
284: By default, log only to stderr, and not to disk. r=matklad a=eminence
This fixes a common problem when running under VS Code, the user doesn't have permissions to create a `log` directory in the CWD.
The old behavior can be re-enabled by setting `RA_INTERNAL_MODE=1`
Fixes #282
Co-authored-by: Andrew Chin <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
This fixes a common problem when running under VS Code, the user
doesn't have permissions to create a `log` directory in the CWD.
The old behavior can be re-enabled by setting RA_INTERNAL_MODE=1
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
283: Docs r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
280: Fixed cast expression parsing in ra_syntax. r=matklad a=ruabmbua
Fixes #279
Related to https://github.com/rust-analyzer/rust-analyzer/pull/273
The cast expression expected any type via types::type_() function,
but the language spec does only allow TypeNoBounds (types without direct extra bounds
via `+`).
**Example:**
```rust
fn test() {
6i8 as i32 + 5;
}
```
This fails, because the types::type_() function which should parse the type after the
as keyword is greedy, and takes the plus sign after path types as extra type bounds.
My proposed fix is to replace the not implemented `type_no_plus()` just calls (`type_()`)
function, which is used at several places. The replacement is `type_with_bounds_cond(p: &mut Parser, allow_bounds: bool)`, which passes the condition to relevant sub-parsers.
This function is then called by `type_()` and the new public `type_no_bounds()`.
Co-authored-by: Roland Ruckerbauer <[email protected]>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cast expression expected any type via types::type_() function,
but the language spec does only allow TypeNoBounds (types without direct extra bounds
via `+`).
**Example:**
```rust
fn test() {
6i8 as i32 + 5;
}
```
This fails, because the types::type_() function which should parse the type after the
as keyword is greedy, and takes all plus sign after path types as extra.
My proposed fix is to replace the not implemented `type_no_plus()` just calls (`type_()`)
function, which is used at several places. The replacement is `type_with_bounds_cond(p: &mut Parser, allow_bounds: bool)`, which passes the condition to relevant sub-parsers.
This function is then called by `type_()` and the new public `type_no_bounds()`.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
277: use new clear-terminal feature r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
276: Extract and rename AtomEdit and Edit into ra_text_edit r=matklad a=vemoo
As discused in #105
Co-authored-by: Bernardo <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
275: Update ARCHITECTURE.md r=matklad a=h-michael
I am still not familiar with the code base, so mostly I quote crate's comments.
Co-authored-by: Hirokazu Hata <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
274: Add crates/*/target to gitignore r=matklad a=h-michael
I am using rls and rust-analyzer together.
Rls creates cache in `crates/*/target`, so I would like to add it to gitignore as well.
Co-authored-by: Hirokazu Hata <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
272: use \b as word boundary when expanding single word in comments r=matklad a=vemoo
as discused in #266
Co-authored-by: Bernardo <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
271: Implement format hook r=matklad a=DJMcNab
Tentatively: fixes #155.
However, this does add all changes in staged files, which might not be desirable. However, I think we can't solve that without explicit support in rustfmt for it, so it should be fine.
Co-authored-by: DJMcNab <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|