9614: Parse input expressions for dbg! invocations in remove_dbg r=Veykril a=Veykril
Instead of inspecting the input tokentree manually, parse the input as `,` delimited expressions instead and act on that. This simplifies the assist quite a bit.
Fixes#8455
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9600: fix: Single-line and nested blocks in the `unwrap_block` assist r=Veykril a=patrick-gu
Fixes#8411
Rework the system for stripping whitespace and braces in the unwrap_block assist to allow correct unwrapping of blocks such as:
```rust
{ $0 0 }
```
into
```rust
0
```
and nested blocks, such as:
```rust
$0{
{
3
}
}
```
into
```rust
{
3
}
```
This is done by creating the `update_expr_string_with_pat` function (along with `update_expr_string` and `update_expr_string_without_newline`), which strips whitespace and braces in a way that ensures that only whitespace and a maximum of one brace are removed from the start and end of the expression string.
I have also created several tests to ensure that this functionality works correctly.
Co-authored-by: patrick-gu <55641350+patrick-gu@users.noreply.github.com>
9550: Proc macro multi abi proof of concept r=matklad a=alexjg
#8925 was irritating me so I thought I would have a bash at fixing it. What I've done here is copy the `crates/proc_macro_srv/src/proc_macro` code (which is copied from `<RUST>/library/proc_macro`) to `crates/proc_macro_srv/src/proc_macro_nightly` and the modified the nightly version to include the changes from https://github.com/rust-analyzer/rust-analyzer/pull/9047 and aeb7b183a2
This gives us the code to support both stable and nightly ABIs. Then we use the `proc_macro_api::version::read_dylib_info` to determine which version of the ABI to load when creating a `ProcMacroLibraryLibLoading` (which is now an enum).
This seems to work for me. The code could be cleaned up but I wanted to see if the approach makes sense before I spend more time on it.
I've split the change into two commits, the first is just copying and modifying the `proc_macro` crate, the second contains most of the interesting work around figuring out which ABI to use.
Co-authored-by: Alex Good <alex@memoryandthought.me>
Co-authored-by: alexjg <alex@memoryandthought.me>
In rust-analyzer, we avoid defualt impls for types which don't have
sensible, "empty" defaults. In particular, we avoid using invalid
indices for defaults and similar hacks.
Rather than a "Stable" and "Nightly" ABI we instead name ABIs based on
the version of the rust compiler in which they were introduced. We place
these ABIs in a new module - `proc_macro_srv::abis` - where we also add
some mchinery to abstract over ABIs. This should make it easy to add new
ABIs at a later date as the rust compiler evolves.
9535: internal: remove proc macro management thread r=jonas-schievink a=jonas-schievink
Communication with the proc macro server process has always happened one request at a time, so the additional thread isn't really needed (it just forwarded each request, and sent back the response). This removes some indirection that was a bit hard to understand (a channel was allocated and sent over another channel to return the response).
Hope I'm not missing anything here
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9569: internal: Explicitly check for reference locals or fields in Name classification r=Veykril a=Veykril
Closes#7524
Inlines all the calls to reference related name classification as well as emits both goto definition targets for field shorthands.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
This treats the consts generated by older synstructure versions like
unnamed consts. We should remove this at some point (at least after
Chalk has switched).
9567: remove unneded special case r=matklad a=matklad
bors r+
🤖
9568: feat: add 'for' postfix completion r=lnicola a=mahdi-frms
![Peek 2021-07-11 16-45](https://user-images.githubusercontent.com/62165556/125194692-a0aaf780-e267-11eb-952a-81de7955d9a1.gif)
adds #9561
used ```ele``` as identifier for each element in the iteration
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>