| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4234: Support local_inner_macros r=jonas-schievink a=edwin0cheng
This PR implements `#[macro_export(local_inner_macros)]` support.
Note that the rustc implementation is quite [hacky][1] too. :)
[1]: https://github.com/rust-lang/rust/blob/614f273e9388ddd7804d5cbc80b8865068a3744e/src/librustc_resolve/macros.rs#L456
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Fix spacing
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4257: ast::EffectExpr r=matklad a=matklad
closes #4230
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4256: Improve formatting of analyzer status text r=flodiebold a=eminence
The old formatting had everything on 1 line, making it quite hard to read:
requests: 1 textDocument/documentSymbol 2ms 2 textDocument/codeAction 2ms 3 rust-analyzer/inlayHints 20ms 4 textDocument/foldingRange 108ms 6 textDocument/codeLens 66ms 5 textDocument/semanticTokens/range 76ms 8 rust-analyzer/inlayHints 195ms 7 textDocument/semanticTokens 250ms 9 textDocument/semanticTokens/range 108ms
It now looks like this:
```
requests:
* 1 textDocument/documentSymbol 11ms
2 textDocument/codeAction 15ms
3 rust-analyzer/inlayHints 4ms
5 textDocument/foldingRange 3ms
4 textDocument/semanticTokens/range 45ms
6 textDocument/codeLens 182ms
8 rust-analyzer/inlayHints 124ms
7 textDocument/semanticTokens 127ms
9 textDocument/documentHighlight 2ms
10 textDocument/codeAction 3ms
```
Co-authored-by: Andrew Chin <[email protected]>
|
| | | | | |
|
| | |/ /
|/| |
| | |
| | | |
Closes #4255
|
| | | |
| | |
| | |
| | |
| | | |
This reverts commit a5f2b16366f027ad60c58266a66eb7fbdcbda9f9, reversing
changes made to c96b2180c1c4206a0a98c280b4d30897eb116336.
|
| |/ / |
|
| | | | |
| | \ | |
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4220: Introduce LowerCtx r=matklad a=edwin0cheng
This PR introduces `LowerCtx` for path lowering.
After this PR, there are only 2 places remains for using deprecated `Path::from_ast`, which is related to `AstTransform` I am not familiar. I would like to change these in another PR by others ;)
related disscusiion: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Path.3A.3Afrom_src
And also fixed part of https://github.com/rust-analyzer/rust-analyzer/issues/4176#issuecomment-620672930
4240: Bump deps r=matklad a=lnicola
Co-authored-by: Edwin Cheng <[email protected]>
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | | |/ |
|
| | | | |
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4244: Show unsafe trait in hover r=matklad a=DianaNites
Following on #2450 and #4210, for traits.
`unsafe` is the only qualifier they can have, though.
Co-authored-by: Diana <[email protected]>
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4246: Validate uses of self and super r=matklad a=djrenren
This change follows on the validation of the `crate` keyword in paths. It verifies the following things:
`super`:
- May only be preceded by other `super` segments
- If in a `UseItem` then all semantically preceding paths also consist only of `super`
`self`
- May only be the start of a path
Just a note, a couple times while working on this I found myself really wanting a Visitor of some sort so that I could traverse descendants while skipping sub-trees that are unimportant. Iterators don't really work for this, so as you can see I reached for recursion. Considering paths are generally small a fancy debounced visitor probably isn't important but figured I'd say something in case we had something like this lying around and I wasn't using it.
Co-authored-by: John Renner <[email protected]>
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Most of them area. We will separate them out later but this gets them to
show up in the "refactor" menu of vscode.
|
| | | |
| | |
| | |
| | |
| | | |
Even thought we don't return all of these we eventually will so might as
well advertise now.
|
| | | | |
|
| | |/
|/|
| |
| | |
Clippy complained about it and it seems wrong
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | | | |
|
| | | | |
|
| | | | |
|
