3692: Introduce `MacroDefKind::CustomDerive` r=matklad a=edwin0cheng
This PR introduce a new `MacroDefKind` `CustomDerive`. And use a new `ProcMacroExpander` for its expanding. And the expander is a dummy for now.
Related: #3654
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3707: Add ItemScope::visibility_of r=matklad a=edwin0cheng
~This PR implements `HasVisibility` for various constructs and change `Definition::search_scope` to use `Visibility` directly instead of depends on ad-hoc string parsing.~
This PR added `visibility_of` in `ItemScope` and `Module` and use it directly directly instead of depends on ad-hoc string parsing.
And also add a FIXME to indicate that there is a bug which do not search child-submodules in other files recursively in `Definition::search_scope`.
I will submit another PR to fix that bug after this is merged.
cc @flodiebold
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3710: Inlay hints for method chaining pattern r=matklad a=M-J-Hooper
This PR adds inlay hints on method call chains:
It is not only explicit `MethodCall`s where this can be helpful. The heuristic used here is that whenever any expression is followed by a new line and then a dot, it resembles a call chain and type information can be #useful.
Changes:
- A new `InlayKind` for chaining.
- New option for disabling this type of hints.
- Tree traversal rules for identifying the chaining hints.
- VSCode decorators in the extension layer (and associated types).
Notes:
- IntelliJ has additional rules and configuration on this topic. Eg. minimum length of chain to start displaying hints and only displaying distinct types in the chain.
- I am checking for chaining on every `ast::Expr` in the tree; Are there performance concerns there?
This is my first contribution (to RA and to Rust in general) so would appreciate any feedback.
The only issue I can find the references this feature is #2741.
Co-authored-by: Matt Hooper <matthewjhooper94@gmail.com>
3664: Introduce TokenConverter Trait r=matklad a=edwin0cheng
This PR add a `TokenConverter` Trait to share the conversion logic between raw `lexer` token and Syntax Node Token.
Related #2158.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3700: fill match arms with empty block rather than unit tuple r=matklad a=JoshMcguigan
As requested by @Veetaha in #3689 and #3687, this modifies the fill match arms assist to create match arms as an empty block `{}` rather than a unit tuple `()`.
In one test I left one of the pre-existing match arms as a unit tuple, and added a body to another match arm, to demonstrate that the contents of existing match arms persist.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3695: vscode: simplify and refactor config r=matklad a=Veetaha
Removed unnecessary interfaces, changed `cfg` to be a getter to ensure the fresh values any time possible.
Migrated from explicit casts to implicit.
Co-authored-by: veetaha <veetaha2@gmail.com>
3696: vscode: more type safety r=matklad a=Veetaha
3698: Consider references when applying postfix completions r=matklad a=SomeoneToIgnore
Sometimes my RA debugging workflow breaks because `.dbg` is applied to the variable that is used later in the code.
It's safer to consider the refences to avoid this for completions that may trigger the move.
3703: Don't try to enable proposed API's on stable r=matklad a=matklad
bors r+
🤖
Co-authored-by: veetaha <veetaha2@gmail.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3685: Auto import macros r=SomeoneToIgnore a=SomeoneToIgnore
If I got it right, assists test infra does not support multiple crates snippets (2720e2374b/crates/ra_hir_def/src/nameres/tests.rs (L491)) hence no tests added for the macro import.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
3697: update itertools version to 0.9.0 r=matklad a=JoshMcguigan
Updating `itertools` version per [feedback on #3689](https://github.com/rust-analyzer/rust-analyzer/pull/3689#discussion_r396267680) from @SomeoneToIgnore.
Worth noting that `chalk` still uses `itertools` v0.8.2, so perhaps it is worth a PR to update that repo as well so we don't have to build both versions?
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
