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 <john@jrenner.net>
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 <edwin0cheng@gmail.com>
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 <aleksey.kladov@gmail.com>
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 <kjeremy@gmail.com>
4193: Make it impossible to forget to add a semantic token type / modifier r=kjeremy a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
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 <edwin0cheng@gmail.com>
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`.
4113: Support returning non-hierarchical symbols r=matklad a=kjeremy
If `hierarchicalDocumentSymbolSupport` is not true in the client capabilites
then it does not support the `DocumentSymbol[]` return type from the
`textDocument/documentSymbol` request and we must fall back to `SymbolInformation[]`.
This is one of the few requests that use the client capabilities to
differentiate between return types and could cause problems for clients.
See https://github.com/microsoft/language-server-protocol/pull/538#issuecomment-442510767 for more context.
Found while looking at #144
4136: add support for cfg feature attributes on expression #4063 r=matklad a=bnjjj
close issue #4063
4141: Fix typo r=matklad a=Veetaha
4142: Remove unnecessary async from vscode language client creation r=matklad a=Veetaha
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: veetaha <veetaha2@gmail.com>
