| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
|\ \
| | |
| | | |
GitHub releases
|
|/ / |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2815: Report macro calls as functions r=matklad a=kjeremy
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
2816: Add macro_rules item snippet r=matklad a=memoryruins
An user trying out rust-analyzer mentioned to me that they missed `rls-vscode`'s [macro_rules snippet](https://github.com/rust-lang/rls-vscode/blob/c2293a63d4adc76ab714a5c6d0a2e9c7b7be77ed/snippets/rust.json#L60)
![2020-01-12_17-47-34](https://user-images.githubusercontent.com/6868531/72227227-fcf46480-3567-11ea-9e3b-2f7319d127f7.gif)
Co-authored-by: memoryruins <[email protected]>
|
| |/ / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
2768: Rename VS Code extension to rust-analyzer r=matklad a=matklad
I want to merge this before release on Monday, such that we can give heads up on twitter
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2788: Fix file_structure() to recognize macro_rules! r=flodiebold a=ruabmbua
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/2774.
Not sure what to do about classifying macro definitions. Maybe make all macro invocations a function invocation?
Co-authored-by: Roland Ruckerbauer <[email protected]>
|
| | | |
|
| | |
| | |
| | |
| | | |
macro call and macro definition
|
| | | |
|
|/ /
| |
| |
| | |
where first token != "macro_rules"
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
2814: Update crates r=matklad a=kjeremy
Adds a new dependency on autocfg 1.0. There are pending PRs against indexmap, crossbeam and rand to bring them up.
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2712: Supporting extend selection inside macro calls r=edwin0cheng a=edwin0cheng
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2807: Use attr location for builtin derive in goto-implementation r=matklad a=edwin0cheng
This PR is use attribute location for builtin derive in `ImplBlock`'s NavigationTarget such that the goto-implementation will goto to a correct position.
Related to #2531
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
2809: Qualify paths in 'fill match arms' assist r=matklad a=flodiebold
Co-authored-by: Florian Diebold <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2803: Fix various names, e.g. Iterator not resolving in core prelude r=matklad a=flodiebold
Basically, `Iterator` is re-exported via several steps, which happened to not be
resolved yet when we got to the prelude import, but since the name resolved to
the reexport from `core::iter` (just to no actual items), we gave up trying to
resolve it further.
Maybe part of the problem is that we can have
`PartialResolvedImport::Unresolved` or `PartialResolvedImport::Indeterminate`
with `None` in all namespaces, and handle them differently.
Fixes #2683.
Co-authored-by: Florian Diebold <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Basically, `Iterator` is re-exported via several steps, which happened to not be
resolved yet when we got to the prelude import, but since the name resolved to
the reexport from `core::iter` (just to no actual items), we gave up trying to
resolve it further.
Maybe part of the problem is that we can have
`PartialResolvedImport::Unresolved` or `PartialResolvedImport::Indeterminate`
with `None` in all namespaces, and handle them differently.
Fixes #2683.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2727: Qualify paths in 'add impl members' r=flodiebold a=flodiebold
This makes the 'add impl members' assist qualify paths, so that they should resolve to the same thing as in the definition. To do that, it adds an algorithm that finds a path to refer to any item from any module (if possible), which is actually probably the more important part of this PR :smile: It handles visibility, reexports, renamed crates, prelude etc.; I think the only thing that's missing is support for local items. I'm not sure about the performance, since it takes into account every location where the target item has been `pub use`d, and then recursively goes up the module tree; there's probably potential for optimization by memoizing more, but I think the general shape of the algorithm is necessary to handle every case in Rust's module system.
~The 'find path' part is actually pretty complete, I think; I'm still working on the assist (hence the failing tests).~
Fixes #1943.
Co-authored-by: Florian Diebold <[email protected]>
Co-authored-by: Florian Diebold <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|