10831: minor: Unnest `ide::display::navigation_target` module r=Veykril a=Veykril
This module contained multiple submodules before, but those were removed some time ago so there is no point in having this one module two layers deep anymore.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10810: feat: Add toggle to disable cache priming r=jonas-schievink a=lnicola
Even if it doesn't prevent the rest of the features from working, cache priming tends to be quite CPU-intensive and can make people think that the load times are worse than they actually are.
It's also less useful in Code and `rust-tools` because the inlay hints and semantic highlighting trigger quite a bit of computation assuming you have a file open in the editor.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
10821: fix: wrap `inline_call` and `inline_into_callers` if it inlines into the left side of a binary expression r=Veykril a=rainy-me
close#10359
Co-authored-by: rainy-me <github@yue.coffee>
10819: internal: Replace some `Vec` occurences with `Box` r=Veykril a=Veykril
Shaves off ~15mb from self analysis
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10808: fix: show custom check-command r=Veykril a=Florian-Schoenherr
just realized this is a lot cleaner and actually shows something on a custom command,
also debugged it this time.
Co-authored-by: Florian-Schoenherr <65456722+Florian-Schoenherr@users.noreply.github.com>
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>
10796: ide: display static values in hover r=Veykril a=jhgg
Continuation from #10785 - does the same thing, but for `static`'s as well.
Co-authored-by: Jake Heinz <jh@discordapp.com>
10795: Remove unwrap in doc path resolution r=Veykril a=udoprog
I keep hitting this constantly in my project, and I haven't dug very deep into the root cause. But seeing as the project otherwise compiles it appears to be something unsupported is being incorrectly parsed in rust-analyzer which for other cases is handled by returning `None`.
Co-authored-by: John-John Tedro <udoprog@tedro.se>
10799: fix: Fix proc macro ABI version checks r=lnicola a=lnicola
If I'm reading this right, we used to pick `Abi1_55` for `1.54` and `Abi_1_58` for `1.57`.
CC `@alexjg` (just in case I'm misinterpreting the code), CC #10772.
bors r+
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
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>
10789: internal: Check for derive attributes by item path, not `derive` identifier r=Veykril a=Veykril
Prior we only checked if an attribute is the exact `derive` identifier and nothing else to collect derive attributes. That means when we encounter the following:
```rs
#[::core::macros::builtin::derive(Debug, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct ModPath {
pub kind: PathKind,
segments: Vec<Name>,
}
```
We won't actually expand the derive attributes, but instead we just expand the `derive` attribute with our dummy identity expander.
The changes here make it so we actually lookup the attribute path, check if it is the derive attribute and then collect the derives.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
