10846: fix: qualify struct name in struct constructor completion r=Veykril a=andrewleverette
* Alter `add_struct_literal` method signature to take an optional module path
* Update `render_literal` method to use a qualified
Relates to issue #10771
Side note: This is my first contribution. Any feedback is welcome!
Co-authored-by: Andrew Leverette <andrewleverette@gmail.com>
10840: fix: Omit generic defaults for types in hover messages r=jonas-schievink a=Veykril
Fixes#9198
We have ranged hovers now which query specifically for the type of an expression/pattern, so if interested in seeing the default, the user can use that functionality instead.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10834: Make lint groups work correctly with `warningsAsInfo` and `warningsAsHint` r=Veykril a=Emilgardis
this change makes it possible to specify
```json
{
"rust-analyzer.diagnostics.warningsAsInfo": ["unused"],
}
```
to make all lints in the `unused` group show as info, etc.
Co-authored-by: Emil Gardström <emil.gardstrom@gmail.com>
10809: fix: don't discard formatting of `use` lines r=Veykril a=iDawer
Use mutable syntax trees in `merge_imports`, `split_imports`. This tries to resolve#9013. But I haven't much managed to simplify code of merging.
Also resolve#9361. It reuses a use tree under the cursor so that comments+indentation are preserved. Merged trees are just appended to the end.
This touches bunch of tests. I removed the sorting of use trees as it needs a proper implementation that takes into account comments and line wrapping. I think it is rustfmt's job or at least until we get a close implementation.
Co-authored-by: iDawer <ilnur.iskhakov.oss@outlook.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>
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>
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>
10781: internal: Do not use reference search in `runnables::related_tests` r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10778: internal: Skip test/bench attr expansion in resolution instead of collection r=Veykril a=Veykril
This way we skip any path resolving to the test and bench attributes instead of just the lone identifiers(which could very well point to non-builtin attributes).
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10769: Add proc macro ABI for rustc 1.58 r=lnicola a=alexjg
This fixes#10766.
I do have some concerns here. The proc macro server API has added three methods to `TokenStream` which I don't really know how to implement in `RustcServer`. Namely `expand_expr`, `before`, and `after`. You'll see that these are currently `unimplemented!` in `crates/proc_macro_server/src/abis/abi_1_58/rustc_server.rs`. I don't have the expertise to fill in the blanks here, it may be necessary to pull in someone who knows a bit more about the proc macro crate.
I think this will only be a problem when actually attempting to expand a macro, so this is probably strictly better than not including the updated ABI at all.
Co-authored-by: Alex Good <alex@memoryandthought.me>
Revert "Fix `impl_trait` function to emit correct ast"
This reverts commit 55a4813151.
Fix `impl_def_from_trait`
It now generates the correct `ast::Impl` using
`generate_trait_impl_text` and parses it to form the right node (copied
from the private fn 'make::ast_from_text').
Cargo will always output something on success:
```
$ cargo check --message-format=json
{"reason":"compiler-artifact", ... snipped ... }
{"reason":"build-finished","success":true}
```
However, rustc does not output anything on success:
```
$ rustc --error-format=json main.rs
$ echo $?
0
```
Restore the behaviour prior to #10517, where an exit code of 0 is
considered good even if nothing is written to stdout.
This enables custom overrideCommand values that use rustc rather than
cargo.
10689: Handle pub tuple fields in tuple structs r=Veykril a=adamrk
The current implementation will throw a parser error for tuple structs
that contain a pub tuple field. For example,
```rust
struct Foo(pub (u32, u32));
```
is valid Rust, but rust-analyzer will throw a parser error. This is
because the parens after `pub` is treated as a visibility context.
Allowing a tuple type to follow `pub` in the special case when we are
defining fields in a tuple struct can fix the issue.
I guess this is a really minor case because there's not much reason
for having a tuple type within a struct tuple, but it is valid rust syntax...
Co-authored-by: Adam Bratschi-Kaye <ark.email@gmail.com>
The current implementation will throw a parser error for tuple structs
that contain a pub tuple field. For example,
```rust
struct Foo(pub (u32, u32));
```
is valid Rust, but rust-analyzer will throw a parser error. This is
because the parens after `pub` is treated as a visibility context.
Allowing a tuple type to follow `pub` in the special case when we are
defining fields in a tuple struct can fix the issue.
