10430: fix: Fix rename trying to edit the same range multiple times for certain macro inputs r=Veykril a=Veykril
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10324
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10403: feat: Add semantic token modifier for crate root r=Veykril a=lhvy
Resolves#9073
I managed to implement crate root highlighting for crates mentioned specifically by name (e.g. `serde` in `use serde::Serialize;`), but not for crates referred to with `crate` or `super`. How could I implement this?
> P.S. I'm participating in [Hacktoberfest 2021](https://hacktoberfest.digitalocean.com/). If this PR is up to standard and merged, I'd appreciate if the `hacktoberfest-accepted` label could be added. Thanks!
Co-authored-by: lhvy <me@lhvy.dev>
10406: internal: Restructure syntax element highlighting into node and token branches r=Veykril a=Veykril
Gets rid of all the unseemly unwraps
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10398: Give defaultLibrary semantic token modifier to items from standard library r=Veykril a=lhvy
Fixes#8999, fixes#2155
`builtInCrates` could be an alternate name to `defaultLibrary`, which one is better?
> P.S. I'm participating in [Hacktoberfest 2021](https://hacktoberfest.digitalocean.com/). If this PR is up to standard and merged, I'd appreciate if the `hacktoberfest-accepted` label could be added. Thanks!
Co-authored-by: lhvy <me@lhvy.dev>
Co-authored-by: Lucas <me@lhvy.dev>
10400: fix: fix format string highlighting for `todo!` and `unimplemented!` r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/10394
These macros require us to see through the `const_format_args!` invocation the panic macros generate, for that we have to add it to our supported built-in macros.
I've also made the macros in the test `#[macro_export]` (turns out they didn't all resolve correctly before this), which changes the output slightly.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10399: minor: don't drop binders when doing autoderef r=lnicola a=iDawer
This fixes#10396 panic introduced in #10373
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
10389: fix: use the right `HirFileId` when expanding macros in fn parameters r=Veykril a=SkiFire13
Fixes#10388
Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
10181: Begining of lsif r=HKalbasi a=HKalbasi
This PR adds a `lsif` command to cli, which can be used as `rust-analyzer lsif /path/to/project > dump.lsif`. It now generates a valid, but pretty useless lsif (only supports folding ranges). The propose of this PR is to discussing about the structure of lsif generator, before starting anything serious.
cc `@matklad` #8696#3098
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
10385: Make `extern crate test;` work r=jonas-schievink a=jonas-schievink
This implements support for dependencies that are not added to the extern prelude of a crate, and add the `test` crate from the sysroot as such a dependency.
This does mean we now index `test` on startup, but I didn't notice much of a difference (and also, r-a can be used while it is still indexing).
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6714
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10375: minor: Use SmallVec<[_; 1]> in `descend_into_macros_impl` r=Veykril a=Veykril
A lot of descends don't actually descend in which case we don't wanna allocate
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Consider these expples
{ 92 }
async { 92 }
'a: { 92 }
#[a] { 92 }
Previously the tree for them were
BLOCK_EXPR
{ ... }
EFFECT_EXPR
async
BLOCK_EXPR
{ ... }
EFFECT_EXPR
'a:
BLOCK_EXPR
{ ... }
BLOCK_EXPR
#[a]
{ ... }
As you see, it gets progressively worse :) The last two items are
especially odd. The last one even violates the balanced curleys
invariant we have (#10357) The new approach is to say that the stuff in
`{}` is stmt_list, and the block is stmt_list + optional modifiers
BLOCK_EXPR
STMT_LIST
{ ... }
BLOCK_EXPR
async
STMT_LIST
{ ... }
BLOCK_EXPR
'a:
STMT_LIST
{ ... }
BLOCK_EXPR
#[a]
STMT_LIST
{ ... }
Originally we tried to maintain the invariant that `{}` always match.
That is, that in the parse tree the pair of corresponding `{}` is always
first and last tokens of some nodes.
We had the code to validate that, but apparently it's been broken for
**years** since we introduced tokens/nodes split. Fixing it now makes
some tests fail.
It's unclear if we want to keep this invariant: there's a strong
motivation for breaking it in the following case:
```
use std::{ // unclosed paren
fn main() {
}
} // don't actually want to pair up this with the one from `use`
```
So let's fix the code, but disable it for the time being
Previously we swapped to events in the buffer, but that might be wrong
if there aer `forward_parent` links pointing to the swapped-out node.
Let's do the same via parent links instead, keeping the nodes in place
10334: Give rustfmt spawn error context. r=jonas-schievink a=aDotInTheVoid
This mean if you misconfigure to
```json
{
"rust-analyzer.rustfmt.overrideCommand": [
"./nonono"
]
}
```
The error message is
```
[Error - 17:54:33] Request textDocument/formatting failed.
Message: Failed to spawn "./nonono"
Code: -32603
```
instead of
```
[Error - 17:56:12] Request textDocument/formatting failed.
Message: No such file or directory (os error 2)
Code: -32603
```
I'm not sure how to test this, or if it needs a test.
Co-authored-by: Nixon Enraght-Moony <nixon.emoony@gmail.com>
10105: RfC: Use `todo!()` instead of `()` for missing fields r=jonas-schievink a=jo-so
Most commonly a field of a struct can be initialized with its default value than an empty tuple.
Co-authored-by: Jörg Sommer <joerg@jo-so.de>
10332: minor: Allow overwriting RUST_BACKTRACE for the server manually r=jonas-schievink a=Veykril
Trying to figure out why we aren't getting backtraces for windows builds from CI, this let's one set the backtraces to `FULL`
Might be cc https://github.com/rust-lang/rust/issues/87481
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10284: internal: definition based hover functions r=Veykril a=HKalbasi
This is part of #10181 but since it is blocked and `hover.rs` is moving quickly so will cause conflicts, I submitted this PR.
This PR extract some parts of `hover` to `find_definition` (maybe this need to be moved to some other file?) and `hover_for_definition`, with those functions I will be able to calculate definition of every token, and calculate hover (and probably other queries) for each definition only once.
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
The code here is intentionally dense and does exactly what is written.
Explaining semantic difference between Rust 2015 and 2018 doesn't help
with understanding syntax. Better to just add more targeted tests.
With this patch, in these examples
```rust
fn main() {
"⊞$0";
}
```
```rust
struct S {
д$0 u8
}
```
entering ':' character in `$0` places shouldn't cause panics.
10257: assists: turn while into loop r=Veykril a=agluszak
Implements an assist to turn a `while` loop into a `loop` loop, as requested in #10214.
I'm not sure sure what the guidelines are regarding naming assists convert_x_to_y vs replace_x_with_y.
This is my first commit to rust-analyzer :D Thank you `@matklad` for your awesome Explaining rust-analyzer series <3
Closes#10214
Co-authored-by: Andrzej Głuszak <gluszak.andrzej@gmail.com>
# This is the 1st commit message:
add multi-token mappings for hover
# The commit message #2 will be skipped:
# make fallback an Option instead of vec
# The commit message #3 will be skipped:
# fix indentation
10204: feat: Show the type of what is being dereferenced in a deref expression. r=theo-lw a=theo-lw
Addresses issue #10106.
In-progress - I'm trying to figure out why `hover_deref_expr_with_coercion` is failing.
Co-authored-by: Teddy_Wang <wangtheo662@gmail.com>
10230: fix: fix expansion order for fn-like macros and attributes in token descending r=Veykril a=Veykril
Second attempt(now with a test 🎉).
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10115
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10213: minor: Improve resilience of match checking r=flodiebold a=iDawer
In bug condition the match checking strives to recover giving false no-error diagnostic.
Suggested in https://github.com/rust-analyzer/rust-analyzer/pull/9105#discussion_r644656085
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
Should fix#10090, #10046, #10179.
This is only a workaround, but the proper fix requires some bigger
refactoring (also related to fixing #10058), and this at least prevents
the crash.
10177: fix: Treat path dependencies like workspace members r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/9070
Fixes diagnostics not showing up in path dependencies.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
The generated code with `()` doesn't compile in most of the cases. To signal
the developer there's something to do, fill in `todo!()`.
Because the file *missing_fields.rs* contains the string `todo!()` it needs
an exception for the test *check_todo*.
10152: feat: Add completion for raw identifiers r=matklad a=nabakin
Adds support for valid Rust completion of raw identifiers.
Previously, code completion of fields made via raw identifiers would not re-insert those raw identifiers, resulting in invalid Rust code. Now, code completion of fields made via raw identifiers do re-insert those raw identifiers, resulting in valid Rust code.
The same is true for all code completion instances for fields and compatible Rust identifiers.
Co-authored-by: Blake Wyatt <894305+nabakin@users.noreply.github.com>
10154: feat: Complete `#![recursion_limit = "N"]` instead of `#![recursion_limit = N]` r=lnicola a=hkmatsumoto
Currently ra emits `#![recursion_limit = 128]`, but this should rather be `#![recursion_limit = "128"]`
Co-authored-by: Hirochika Matsumoto <git@hkmatsumoto.com>
FragmentKind played two roles:
* entry point to the parser
* syntactic category of a macro call
These are different use-cases, and warrant different types. For example,
macro can't expand to visibility, but we have such fragment today.
This PR introduces `ExpandsTo` enum to separate this two use-cases.
I suspect we might further split `FragmentKind` into `$x:specifier` enum
specific to MBE, and a general parser entry point, but that's for
another PR!
10146: fix: use placeholder as default type in `Generate function` and `Extract into function`. r=matklad a=iDawer
Closes#10123
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
10139: Fix replacing for loops over ranges with for_each. r=yotamofek a=yotamofek
Previously, the assist would turn this:
```rust
for x in 0..92 {
...
}
```
into the syntactically incorrect code below:
```rust
0..92.for_each(|x| ...)
```
This fixes the assist by parenthesizing range expressions.
Co-authored-by: Yotam Ofek <yotam.ofek@gmail.com>
9954: feat: Show try operator propogated types on ranged hover r=matklad a=Veykril
Basically this just shows the type of the inner expression of the `?` expression as well as the type of the expression that the `?` returns from:
Unless both of these types are `core::result::Result` in which case we show the error types only.
If both types are `core::option::Option` with different type params we do not show this special hover either as it would be pointless(instead fallback to default type hover)
Very much open to changes to the hover text here(I suppose we also want to show the actual type of the `?` expression, that is its output type?).
Fixes#9931
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
10095: internal: Augment panic context when resolving path r=jonas-schievink a=jonas-schievink
Should help with debugging https://github.com/rust-analyzer/rust-analyzer/issues/10084 and similar issues.
Might have a perf impact since the string is created on every function call.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10097: fix: Allow inherent impls for arrays r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/9992 (method resolution of these methods still does not work)
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10091: fix: fix "disjunction in conjunction" panic r=matklad a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10073
The DNF construction code created expressions that were combined in a way that made us "forget" to make their contents valid DNF again. This PR fixes that by flattening nested `any(any())` and `all(all())` predicates. There was also a typo that led to a redundant call to `make_nnf` instead of the correct recursive call to `make_dnf` (but this didn't seem to break/fix anything).
This also adds some light property testing, though I'm not really sure this is the best way to do it.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10092: feat: Improve `extract_struct_from_enum_variant` output r=matklad a=DropDemBits
Improves the struct generated by `extract_struct_from_enum_variant`.
Summary of changes:
- Indent the generated struct and enum to the same indent level
- Preserve comments & attributes from the enum variant (something I missed when doing the same thing for the variant fields)
- Use enum's visibility for fields without any visibility, instead of filling it in with `pub`
Co-authored-by: DropDemBits <r3usrlnd@gmail.com>
10076: Use struct init shorthand when applicable in fill struct fields assist r=matklad a=nathanwhit
This PR tweaks the fill struct fields assist to use the struct init shorthand when a local variable with a matching name and type is in scope.
For example:
```rust
struct Foo {
a: usize,
b: i32,
c: char,
}
fn main() {
let a = 1;
let b = 2;
let c = 3;
let foo = Foo { <|> };
}
```
Before we would insert
```rust
Foo {
a: (),
b: (),
c: (),
}
```
now we would insert
```rust
Foo {
a,
b,
c: ()
}
```
Co-authored-by: nathan.whitaker <nathan.whitaker01@gmail.com>
closes#9922
Turned out to be trivial after preliminary refactor.
The intended behavior is that we schedule cache priming once ws become
quiescent (that is, we fully load cargo project), and we continue to
rschedule it until it completes (priming might get cancelled by user
typing into a file).
Group related stuff together, use only on path for parsing extern blocks
(they actually have modifiers).
Perhaps we should get rid of items_without_modifiers altogether? Better
to handle these kinds on diagnostics in validation layer...
10005: Extend `CargoConfig.unset_test_crates` r=matklad a=regexident
This is to allow for efficiently disabling `#[cfg(test)]` on all crates (by passing `unset_test_crates: UnsetTestCrates::All`) without having to first load the crate graph, when using rust-analyzer as a library.
(FYI: The change doesn't seem to be covered by any existing tests.)
Co-authored-by: Vincent Esche <regexident@gmail.com>
10080: internal: don't shut up the compiler when it says the code's buggy r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
10066: internal: improve compile times a bit r=matklad a=matklad
I wanted to *quickly* remove `smol_str = {features = "serde"}`, and figured out that the simplest way to do that is to replace our straightforward proc macro serialization with something significantly more obscure.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
9970: feat: Implement attribute input token mapping, fix attribute item token mapping r=Veykril a=Veykril
The token mapping for items with attributes got overwritten partially by the attributes non-item input, since attributes have two different inputs, the item and the direct input both.
This PR gives attributes a second TokenMap for its direct input. We now shift all normal input IDs by the item input maximum(we maybe wanna swap this see below) similar to what we do for macro-rules/def. For mapping down we then have to figure out whether we are inside the direct attribute input or its item input to pick the appropriate mapping which can be done with some token range comparisons.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/9867
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10030: fix: Fix multiple derives in one attribute not expanding all in expand_macro r=Veykril a=Veykril
It's probably better to only expand the exact derive the cursor is on(if possible) instead of all derives in the attribute the cursor is one.
follow up to #10029
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10029: internal: Improve expand_macro r=Veykril a=Veykril
- Adds a few more newlines to the output making it more readable
- Fixes a bug with multiple derives not being expandable
There seems to be an issue with multiple derives in one attribute only showing the expansion of the last derive which I'll have to investigate.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9944: internal: introduce in-place indenting API r=matklad a=iDawer
Introduce `edit_in_place::Indent` that uses mutable tree API and intended to replace `edit::AstNodeEdit`.
Closes#9903
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
10001: Sort enum variant r=Veykril a=vsrs
A small fix to the problem noted by `@lnicola` :
> 
>
> (note the slight inconsistency here: to sort the variants of `Animal` I have to select the enum name, but to sort the fields of `Cat` I have to select the fields themselves)
Co-authored-by: vsrs <vit@conrlab.com>
9989: Fix two more “a”/“an” typos (this time the other way) r=lnicola a=steffahn
Follow-up to #9987
you guys are still merging these fast 😅
_this time I thought – for sure – that I’d get this commit into #9987 before it’s merged…_
Co-authored-by: Frank Steffahn <frank.steffahn@stu.uni-kiel.de>
It's good that rust-analyzer doesn't belly-up on a panic in some random
assist.
It is less good that rust-analyzer devs only know that the assists are
buggy when they are actively looking at the logs.
9972: refactor : function generation assists r=Veykril a=mahdi-frms
Separated code generation from finding position for generated code. This will be ground work for introducing static associated function generation.
Co-authored-by: mahdi-frms <mahdif1380@outlook.com>
