| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4153: Add support for incremental text synchronization r=matklad a=lnicola
Fixes #3762.
This still needs a `ra_vfs` PR, but I want to know I'm on the right track. I tested the change and it didn't crash horribly, but YMMV.
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4227: Report invalid, nested, multi-segment crate-paths r=matklad a=djrenren
There was a bug in the previous path-validating code that didn't detect multi-segment paths that started with `crate`.
```rust
// Successfully reported
use foo::{crate};
// BUG: was not being reported
use foo::{crate::bar};
```
This was due to my confusion about path-associativity. That is, the path with no qualifier is the innermost path, not the outermost. I've updated the code with a lot of comments to explain what's going on.
This bug was discovered when I found an erroneous `ok` test which I reported here:
https://github.com/rust-analyzer/rust-analyzer/issues/4226
This test now fails and has been modified, hopefully in the spirit of the original test, to be correct. Sorry about submitting the bug in the first place!
Co-authored-by: John Renner <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Specifically, things like:
use foo::{crate::bar};
Are now being caught, when before we only caught:
use foo::{crate};
|
| |/ / |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4210: Include function qualifiers in signature r=matklad a=oxalica
Fixes #2450
It seems there's no test for `ra_ide/display/{short_label,function_signature}`. I'm not sure how to setup it.
Manually tested:
<img width="428" alt="Screenshot_20200430_004434" src="https://user-images.githubusercontent.com/14816024/80622769-d6f1c200-8a7b-11ea-91f3-e94bfb2703c5.png">
Co-authored-by: oxalica <[email protected]>
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4178: Validate the location of `crate` in paths r=matklad a=djrenren
**This solution does not fully handle `use` statements. See below**
This pull requests implements simple validation of usages of the `crate` keyword in `Path`s. Specifically it validates that:
- If a `PathSegment` is starts with the `crate` keyword, it is also the first segment of the `Path`
- All other usages of `crate` in `Path`s are considered errors.
This aligns with `rustc`'s rules. Unlike rustc this implementation does not issue a special error message in the case of `::crate` but it does catch the error.
Furthermore, this change does not cover all error cases. Specifically the following is not caught:
```rust
use foo::{crate}
```
This is because this check is context sensitive. From an AST perspective, `crate` is the root of the `Path`. Only by inspecting the full `UseItem` do we see that it is not in fact the root. This problem becomes worse because `UseTree`s are allowed to be arbitrarily nested:
```rust
use {crate, {{crate, foo::{crate}}}
```
So this is a hard problem to solve without essentially a breadth-first search. In a traditional compiler, I'd say this error is most easily found during the AST -> HIR conversion pass but within rust-analyzer I'm not sure where it belongs.
Under the implementation in this PR, such errors are ignored so we're *more correct* just not *entirely correct*.
Co-authored-by: John Renner <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
|/| |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4119: Cache proc-macro dlls r=matklad a=edwin0cheng
This PR try to fix a deadlock in proc-macro srv by not unloading dlls.
Currently we load and unload dlls for each request, however rustc TLS is leaky , such that if we do it a lot of times, all TLS index will be consumed and it will be deadlocked inside panic (it is because panic itself is using TLS too).
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4204: Use specific pattern when translating if-let-else to match r=matklad a=matklad
We *probably* should actually use the same machinery here, as we do
for fill match arms, but just special-casing options and results seems
to be a good first step.
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We *probably* should actually use the same machinery here, as we do
for fill match arms, but just special-casing options and results seems
to be a good first step.
|
| | | | | |
|
| |/ / / |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4161: lsp-types 0.74 r=kjeremy a=kjeremy
* Fixes a bunch of param types to take partial progress into account.
* Will allow us to support insert/replace text in completions
Co-authored-by: kjeremy <[email protected]>
|
| | | |/
| |/|
| | |
| | |
| | | |
* Fixes a bunch of param types to take partial progress into account.
* Will allow us to support insert/replace text in completions
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4193: Make it impossible to forget to add a semantic token type / modifier r=kjeremy a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
4184: Treat comments beginning with four slashes as regular line comments r=kjeremy a=adamrk
Addresses https://github.com/rust-analyzer/rust-analyzer/issues/4040
Co-authored-by: adamrk <[email protected]>
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
4148: Simplify profiler impl (bubble up Option) r=matklad a=Veetaha
Co-authored-by: veetaha <[email protected]>
|
| | | | | | |
|
| | |/ / /
|/| | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4173: Use core instead of std for builtin derive macros r=edwin0cheng a=edwin0cheng
Fixed #4087.
We can't use `$crate` here right now because :
1. We have to able to detect `macro` 2.0 in collecting phase for finding `rustc_builtin_macro` attrs.
2. And we have to make hygiene works for builtin derive macro.
r= @flodiebold
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | |/
| |/| |
|
| |/ /
| |
| |
| |
| | |
So e.g. if we have `fn foo<T: SomeTrait<u32>>() -> T::Item`, we want to lower
that to `<T as SomeTrait<u32>>::Item` and not `<T as SomeTrait<_>>::Item`.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4155: Precompute expected type during completion r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |/ |
|
