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!
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>
10395: Add pub(super) along with pub(crate) and pub as a completion keyword r=lnicola a=azdavis
I've gotten used to typing `pc` in front of items to get `pub(crate)`, but recently I needed `pub(super)`. So I tried typing `ps` and it didn't work. Now it should!
Co-authored-by: Ariel Davis <ariel.z.davis@icloud.com>
This PR copy onEnterRules configurations [from vscode-rust](https://github.com/rust-lang/vscode-rust/blob/master/src/extension.ts#L287) based on discussion in #6254
I understand that the ideal way is to use parser data for this, and probably all other things that language-config do. But since it can't be enabled (or at least it isn't enabled) by default in vscode, I think this is needed (until onEnter becomes official LSP and get vscode support).
People can still configure shortcut and use the parser based onEnter, so it wouldn't harm anyone.
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.
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).
10378: fix: Implement most proc_macro span handling methods r=jonas-schievink a=jonas-schievink
This closes https://github.com/rust-analyzer/rust-analyzer/issues/10368 – some APIs are still missing, but they are either for unstable features or require https://github.com/rust-analyzer/rust-analyzer/issues/9403
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
I made the implementations of `HasChildSource<_>` and `ChildBySource` for `GenericDefId` use their own logic instead of relying on `GenericParams::new`. This in turn means that `GenericParams::new` is unused and can be removed. `SourceMap` becomes also unused because all the rest of the code does is insert into it, so it can be removed too.
This also helps avoid creating a completly new `GenericParams` when `GenericDefId::child_source` and `GenericDefId::child_by_source_to` are called, and also creating a `SourceMap` in `item_tree::lower::Ctx::lower_generic_params`.
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
10357: internal: fix and force-disable block validation ;-( r=matklad a=matklad
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
internal: fix and force-disable block validation ;-(
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