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.
