ItemTree is per-file, so there is no unique crate associated with it.
This means that it cannot know the active CfgOptions and thus couldn't
handle `cfg_attr`.
Prepare it for `cfg_attr`s by avoiding accessing attributes.
6896: Node-ify lifetimes r=jonas-schievink a=Veykril
Let's see if this passes the tests 🤞
Depends on https://github.com/rust-analyzer/ungrammar/pull/15
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6897: Basic support for macros 2.0 r=jonas-schievink a=jonas-schievink
This adds support for (built-in-only) macros 2.0, and removes some hacks used for builtin derives, which are declared via macros 2.0 in libcore.
First steps for https://github.com/rust-analyzer/rust-analyzer/issues/2248.
Blocked on https://github.com/rust-analyzer/ungrammar/pull/16.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6818: Add Lifetimes to the HIR r=matklad a=Veykril
This doesn't handle resolve yet as I don't know yet how that will be used. I'll get to that once I start moving the lifetime reference PR to the hir.
This also adds a new `hir` name type for lifetimes and labels, `hir::LifetimeName`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6771: Properly attach inner attributes in Attrs::new r=matklad a=Veykril
Properly attach inner and outer attributes to the things they actually belong to in the HIR. ~~I can add some tests for this if wanted once I know where to put them/how to test for this.~~ Put some tests into `hover.rs`.
So the following snippet
```rust
mod foo {
//! Hello
}
```
now shows `Hello` on hover 🎉Fixes#2148
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6698: Attach macro expansion errors to the right file r=jonas-schievink a=jonas-schievink
Previously it attached them to the result of the macro expansion (or, if no result was produced, to the file containing the invocation). Always use the file containing the invocation.
This doesn't seem to have any observable difference, but seems better in theory.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6435: Test Fixture ExplicitRoot + ModuleResolutionRelativePathOutsideRoot. r=matklad a=rickvanprim
Updates `module_resolution_relative_path_outside_root` test to check valid paths outside of the root, by moving the root to a subpath so that paths outside of it are possible. If this would be more appropriate as a new test, or if the original check for an invalid path should be left, I'm happy to update.
Co-authored-by: James Leitch <rickvanprim@gmail.com>
It's very useful when `pub` is equivalent to "this is crate's public
API", let's enforce this!
Ideally, we should enforce it for local `cargo test`, and only during
CI, but that needs https://github.com/rust-lang/cargo/issues/5034.
6324: Improve #[cfg] diagnostics r=jonas-schievink a=jonas-schievink
Unfortunately I ran into https://github.com/rust-analyzer/rust-analyzer/issues/4058 while testing this on https://github.com/nrf-rs/nrf-hal/, so I didn't see much of it in action yet, but it does seem to work.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6307: Add whitelist of safe intrinsics r=frazar a=frazar
This PR should fix#5996, where intrinsic operations where all marked as unsafe.
I'm rather new to this codebase, so I might be doing something *very* wrong. Please forgive me!
In particular, I'm not sure how to "check that we are in extern `rust-intrinsics`" as mentioned [in this comment](https://github.com/rust-analyzer/rust-analyzer/issues/5996#issuecomment-709234802).
Co-authored-by: Francesco Zardi <frazar@users.noreply.github.com>
Declaration names sounds like a name of declaration -- something you
can use for analysis. It empathically isn't, and is just a label
displayed in various UI. It's important not to confuse the two, least
we accidentally mix semantics with UI (I believe, there's already a
case of this in the FamousDefs at least).
6130: Items case quick fix (snake_case / UPPER_SNAKE_CASE / CamelCase) r=matklad a=popzxc
Resolves#4598.
After a third try, it finally works. Boy, it appeared tougher than it seemed.
Initially I thought like "Ha, `rustc` already tells us where idents are named incorrectly. It shouldn't be that hard, should it?".
Well, the problems with the information provided by `rustc` appeared shortly:
- `rustc` warnings are `flycheck` warnings, which are slightly aside from our diagnostics with fixes.
When we map flycheck diagnostic to LSP, we can convert it into a fix, but only if it's marked as `Applicability::MachineApplicable`.
Name case fix is marked `Applicability::MaybeIncorrect`, and for a reason: it only suggest to rename symbol under cursor, without tracking any references.
- Warning spawned by `rustc` are identified by string labels rather than enum. It means that if one day the diagnostic will be renamed in `rustc`, `rust-analyzer` code will still compile, but won't find the required diagnostic by name anymore. If by chance this will happen when some unlucky guy will decide to create their first pull request, they'll be confused by suddenly failing tests (likely) not related to their changes.
- Even if we'll try to build fixes atop of `rustc` warnings, we'll have to do it in the `rust_analyzer::diagnostics::to_proto` module, which is far less
convenient for that matter than `ide` crate.
That's why I decided that it's worth a separate `rust-analyzer` diagnostic, which will implement `DiagnosticWithFix` trait.
After that, I discovered that currently `hir_ty::diagnostics` only check `DefWithBody` types, like function bodies. I had to add support for diagnostics
which look at any `ModuleDef`.
And of course, since I'd added a lot of new functionality, it required extensive testing.
That explains why the diff is so big for a (looking) relatively small feature.
I hope that this PR doesn't only add a small feature, but also creates a base for building another features.
## Example:
P.S. My eyes were bleeding when I had to write the code for the example...
6135: when generating new function, focus on return type instead of body r=matklad a=bnjjj
I made a little change when we use the assist to generate a new function, instead of focusing on the function body, it will focus on return type
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6199: Fix `mut self` not emitting mutable binding on `self` use r=matklad a=Veykril
Prior to this, when `self` in a function is taken by value and bound mutably, its use inside of the method body won't be marked `mutably`.
Fixes#5461
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5917: Add a command to open docs for the symbol under the cursor r=matklad a=zacps
#### Todo
- [ ] Decide if there should be a default keybind or context menu entry
- [x] Figure out how to get the documentation path for methods and other non-top-level defs
- [x] Design the protocol extension. In future we'll probably want parameters for local/remote documentation URLs, so that should maybe be done in this PR?
- [x] Code organisation
- [x] Tests
Co-authored-by: Zac Pullar-Strecker <zacmps@gmail.com>
Previously, "find all references" on a variant field wouldn't find any
references outside the defining module. This is because variant fields
were incorrectly assumed to be private, like struct fields without
explicit visibility, but they actually inherit the enum's visibility.
Currently a method only has defaultness if it is a provided trait
method, but this will change when specialisation is available and may
need to become a concept known to hir.
I opted to go for a 'fewest changes' approach given specialisation is
still under development.
