10423: Internal: refactor for mdbook plugin r=Veykril a=HKalbasi
This PR is for upstreaming changes that I made for mdbook plugin. Changes are adding inlay hints to `StaticIndex` and changing some functions for working around privacy of crates.
Aside this, is it okay if I bring the plugin in tree? It is a simple binary crate. I feel it will better maintained here and become resistant to api changes.
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
This renames `descend_into_macros` to `descend_into_macros_single` and `descend_into_macros_many` into `descend_into_macros`.
However, this does not touch a function in `SemanticsImpl` of same name.
10467: Optimize CodeLens for references/impls r=Veykril a=ericsampson
Don't do unnecessary work.
Followup to #10447 . cc `@Veykril`
Co-authored-by: Eric Sampson <esampson@eaze.com>
10440: Fix Clippy warnings and replace some `if let`s with `match` r=Veykril a=arzg
I decided to try fixing a bunch of Clippy warnings. I am aware of this project’s opinion of Clippy (I have read both [rust-lang/clippy#5537](https://github.com/rust-lang/rust-clippy/issues/5537) and [rust-analyzer/rowan#57 (comment)](https://github.com/rust-analyzer/rowan/pull/57#discussion_r415676159)), so I totally understand if part of or the entirety of this PR is rejected. In particular, I can see how the semicolons and `if let` vs `match` commits provide comparatively little benefit when compared to the ensuing churn.
I tried to separate each kind of change into its own commit to make it easier to discard certain changes. I also only applied Clippy suggestions where I thought they provided a definite improvement to the code (apart from semicolons, which is IMO more of a formatting/consistency question than a linting question). In the end I accumulated a list of 28 Clippy lints I ignored entirely.
Sidenote: I should really have asked about this on Zulip before going through all 1,555 `if let`s in the codebase to decide which ones definitely look better as `match` :P
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
10403: feat: Add semantic token modifier for crate root r=Veykril a=lhvy
Resolves#9073
I managed to implement crate root highlighting for crates mentioned specifically by name (e.g. `serde` in `use serde::Serialize;`), but not for crates referred to with `crate` or `super`. How could I implement this?
> P.S. I'm participating in [Hacktoberfest 2021](https://hacktoberfest.digitalocean.com/). If this PR is up to standard and merged, I'd appreciate if the `hacktoberfest-accepted` label could be added. Thanks!
Co-authored-by: lhvy <me@lhvy.dev>
10398: Give defaultLibrary semantic token modifier to items from standard library r=Veykril a=lhvy
Fixes#8999, fixes#2155
`builtInCrates` could be an alternate name to `defaultLibrary`, which one is better?
> P.S. I'm participating in [Hacktoberfest 2021](https://hacktoberfest.digitalocean.com/). If this PR is up to standard and merged, I'd appreciate if the `hacktoberfest-accepted` label could be added. Thanks!
Co-authored-by: lhvy <me@lhvy.dev>
Co-authored-by: Lucas <me@lhvy.dev>
10181: Begining of lsif r=HKalbasi a=HKalbasi
This PR adds a `lsif` command to cli, which can be used as `rust-analyzer lsif /path/to/project > dump.lsif`. It now generates a valid, but pretty useless lsif (only supports folding ranges). The propose of this PR is to discussing about the structure of lsif generator, before starting anything serious.
cc `@matklad` #8696#3098
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
Consider these expples
{ 92 }
async { 92 }
'a: { 92 }
#[a] { 92 }
Previously the tree for them were
BLOCK_EXPR
{ ... }
EFFECT_EXPR
async
BLOCK_EXPR
{ ... }
EFFECT_EXPR
'a:
BLOCK_EXPR
{ ... }
BLOCK_EXPR
#[a]
{ ... }
As you see, it gets progressively worse :) The last two items are
especially odd. The last one even violates the balanced curleys
invariant we have (#10357) The new approach is to say that the stuff in
`{}` is stmt_list, and the block is stmt_list + optional modifiers
BLOCK_EXPR
STMT_LIST
{ ... }
BLOCK_EXPR
async
STMT_LIST
{ ... }
BLOCK_EXPR
'a:
STMT_LIST
{ ... }
BLOCK_EXPR
#[a]
STMT_LIST
{ ... }
10284: internal: definition based hover functions r=Veykril a=HKalbasi
This is part of #10181 but since it is blocked and `hover.rs` is moving quickly so will cause conflicts, I submitted this PR.
This PR extract some parts of `hover` to `find_definition` (maybe this need to be moved to some other file?) and `hover_for_definition`, with those functions I will be able to calculate definition of every token, and calculate hover (and probably other queries) for each definition only once.
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
# This is the 1st commit message:
add multi-token mappings for hover
# The commit message #2 will be skipped:
# make fallback an Option instead of vec
# The commit message #3 will be skipped:
# fix indentation
10204: feat: Show the type of what is being dereferenced in a deref expression. r=theo-lw a=theo-lw
Addresses issue #10106.
In-progress - I'm trying to figure out why `hover_deref_expr_with_coercion` is failing.
Co-authored-by: Teddy_Wang <wangtheo662@gmail.com>
