10798: ide: show go to for function hover return type r=Veykril a=jhgg
I've found myself wanting this... adds to the hover quick go-to for a function's return type:
This is particularly useful when you are hovering over a function in a long chain, like:
```rust
foo.bar().b$0az().some_trait_fn();
```
where `baz`'s return type is not immediately obvious, but the chain is not long enough to trigger chain inlay hints...
i guess I could just select `foo.bar().baz()` too to get the types too...
Co-authored-by: Jake Heinz <jh@discordapp.com>
10785: ide: show const value in hover r=jhgg a=jhgg
fixes#10783
I think my original attempt was incorrect, because it looks like `HirDisplay` is used in more places than just the hover.
So, I've attempted it again in 312eafe, this time specifically just rendering the value in `hover::render`
pictoral:
Co-authored-by: Jake Heinz <jh@discordapp.com>
Co-authored-by: Jake <jh@discordapp.com>
10563: feat: Make "Generate getter" assist use semantic info r=agluszak a=agluszak
This PR makes "Generate getter" assist use semantic info instead of dealing with types encoded as strings.
Getters for types which are:
- `Copy` no longer return references
- `AsRef<str>` (i.e. `String`) return `&str` (instead of `&String`)
- `AsRef<[T]>` (i.e. `Vec<T>`) return `&[T]` (instead of `&Vec<T>`)
- `AsRef<T>` (i.e. `Box<T>`) return `&T` (instead of `&Box<T>`)
- `Option<T>` return `Option<&T>` (instead of `&Option<T>`)
- `Result<T, E>` return `Result<&T, &E>` (instead of `&Result<T, E>`)
String, Vec, Box and Option were previously handled as special cases.
Closes#10295
Co-authored-by: Andrzej Głuszak <gluszak.andrzej@gmail.com>
10538: fix: matching brace should prefer brace on cursor's right r=Veykril a=codgician
I observed a brace matching issue with the following Rust code:
```rust
let x = (1 + (2 + 3)) * 4;
```
In a situation like `<|>(1 + (2 + 3)) * 4`, the cursor will go to `(1 + (2 + 3)<|>) * 4`, and if user tries to match bracket again it will go like `(1 + <|>(2 + 3)) * 4` while logically the expected result should be `<|>(1 + (2 + 3)) * 4`. This behavior exists in both line cursor style and block cursor style.
This PR fixes this by letting `matching_brace` prefer the brace to cursor's right when the cursor lies between multiple consecutive braces. It **does NOT** fix#1942 but could be related. Please review.
Co-authored-by: codgician <15964984+codgician@users.noreply.github.com>
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>
