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.
10738: internal: Do not search through all three namespaces in `ItemScope::name_of` r=Veykril a=Veykril
Brings down `5ms - find_path_prefixed (46 calls)` to `1ms - find_path_prefixed (46 calls)` for me on the `integrated_completion_benchmark`.
Still `O(n)` but this should considerably cut down lookups nevertheless(as shown by the timings already).
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10699: internal: Make CompletionItem `label` and `lookup` fields `SmolStr`s r=Veykril a=Veykril
This replaces a bunch of String clones with SmolStr clones, though also makes a few parts a bit more expensive(mainly things involving `format!`ted strings as labels).
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10704: internal: Short-circuit `descend_into_macros_single` r=Veykril a=Veykril
There is no need to descend everything if all we are interested in is the first mapping.
This bring `descend_into_macros` timing in highlighting in `rust-analyzer/src/config.rs` from `154ms - descend_into_macros (2190 calls)` to `24ms - descend_into_macros (2190 calls)` since we use the single variant there(will regress once we want to highlight multiple namespaces again though).
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10703: internal: Don't check items for macro calls if they have no attributes r=Veykril a=Veykril
Turns out when highlighting we currently populate the Dynmaps of pretty much every item in a file, who would've known that would be so costly...
Shaves off 250 ms for the integrated benchmark on `rust-analyzer/src/config.rs`.
We are still looking at a heft `154ms - descend_into_macros (2190 calls)` but I feel like this is slowly nearing towards just call overhead.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10701: internal: Cache ast::MacroCalls to their expansions in Semantics::descend_into_macros_impl r=Veykril a=Veykril
Saves ~45ms when highlighting `rust-analyzer/src/config.rs` for me
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10686: internal: Add `Semantics::original_ast_node` for upmapping nodes out of macro files r=Veykril a=Veykril
Fixes trying to insert imports into macro expanded files which then do text edits on very wrong text ranges.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10623: internal: replace L_DOLLAR/R_DOLLAR with parenthesis hack r=matklad a=matklad
The general problem we are dealing with here is this:
```
macro_rules! thrice {
($e:expr) => { $e * 3}
}
fn main() {
let x = thrice!(1 + 2);
}
```
we really want this to print 9 rather than 7.
The way rustc solves this is rather ad-hoc. In rustc, token trees are
allowed to include whole AST fragments, so 1+2 is passed through macro
expansion as a single unit. This is a significant violation of token
tree model.
In rust-analyzer, we intended to handle this in a more elegant way,
using token trees with "invisible" delimiters. The idea was is that we
introduce a new kind of parenthesis, "left $"/"right $", and let the
parser intelligently handle this.
The idea was inspired by the relevant comment in the proc_macro crate:
https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html#variant.None
> An implicit delimiter, that may, for example, appear around tokens
> coming from a “macro variable” $var. It is important to preserve
> operator priorities in cases like $var * 3 where $var is 1 + 2.
> Implicit delimiters might not survive roundtrip of a token stream
> through a string.
Now that we are older and wiser, we conclude that the idea doesn't work.
_First_, the comment in the proc-macro crate is wishful thinking. Rustc
currently completely ignores none delimiters. It solves the (1 + 2) * 3
problem by having magical token trees which can't be duplicated:
* https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/TIL.20that.20token.20streams.20are.20magic
* https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Handling.20of.20Delimiter.3A.3ANone.20by.20the.20parser
_Second_, it's not like our implementation in rust-analyzer works. We
special-case expressions (as opposed to treating all kinds of $var
captures the same) and we don't know how parser error recovery should
work with these dollar-parenthesis.
So, in this PR we simplify the whole thing away by not pretending that
we are doing something proper and instead just explicitly special-casing
expressions by wrapping them into real `()`.
In the future, to maintain bug-parity with `rustc` what we are going to
do is probably adding an explicit `CAPTURED_EXPR` *token* which we can
explicitly account for in the parser.
If/when rustc starts handling delimiter=none properly, we'll port that
logic as well, in addition to special handling.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
10629: Add assist for replacing turbofish with explicit type. r=Veykril a=terrynsun
Converts `::<_>` to an explicit type assignment.
```
let args = args.collect::<Vec<String>>();
```
->
```
let args: Vec<String> = args.collect();
```
Closes#10285
Co-authored-by: Terry Sun <terrynsun@gmail.com>
10649: internal: Remove `CompletionKind` in favor of `CompletionItemKind` r=Veykril a=Veykril
and move some more tests around
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
