10440: Fix Clippy warnings and replace some `if let`s with `match` r=Veykril a=arzg
I decided to try fixing a bunch of Clippy warnings. I am aware of this project’s opinion of Clippy (I have read both [rust-lang/clippy#5537](https://github.com/rust-lang/rust-clippy/issues/5537) and [rust-analyzer/rowan#57 (comment)](https://github.com/rust-analyzer/rowan/pull/57#discussion_r415676159)), so I totally understand if part of or the entirety of this PR is rejected. In particular, I can see how the semicolons and `if let` vs `match` commits provide comparatively little benefit when compared to the ensuing churn.
I tried to separate each kind of change into its own commit to make it easier to discard certain changes. I also only applied Clippy suggestions where I thought they provided a definite improvement to the code (apart from semicolons, which is IMO more of a formatting/consistency question than a linting question). In the end I accumulated a list of 28 Clippy lints I ignored entirely.
Sidenote: I should really have asked about this on Zulip before going through all 1,555 `if let`s in the codebase to decide which ones definitely look better as `match` :P
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
10456: fix: Avoid cycle when lowering predicates for associated item lookup r=flodiebold a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10386
(the salsa bug persists, but this lets us avoid it by fixing the underlying bug)
This reimplements the rustc logic in b27661eb33/compiler/rustc_typeck/src/collect.rs (L556): When resolving an associated type `T::Item`, we've previously lowered all predicates that could affect `T`, but we actually have to look only at those predicates whose traits define an associated type of the right name.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
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
