8083: Track source file IDs in source mapping of Attrs r=jonas-schievink a=Veykril
Fixes the panics/incorrect injection highlighting of outline module declarations until we figure out a nicer source mapping strategy for attributes.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8065: Better handling of block doc comments r=Veykril a=Veykril
Moves doc string processing to `Attrs::docs`, as we need the indent info from all comments before being able to know how much to strip
Closes#7774
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8063: couple clippy::complexity fixes r=matklad a=matthiaskrgr
avoid redundant `.into()` calls to convert T into identical T (`let x: String = String::from("hello").into();`)
use `if let Some(x)` instead of `.is_some()` + `.unwrap()`
don't clone Copy types
remove redundant wrapped ?s: `Some(Some(3)?)` can just be `Some(3)`
use `.map(|x| y)` instead of `and_then(|x| Some(y)` on `Option`s
Co-authored-by: Matthias Krüger <matthias.krueger@famsik.de>
7900: show function params in completion detail r=matklad a=JoshMcguigan
This resolves#7842 by updating the detail for function completions from `-> T` to `fn(T, U) -> V`. I added an expicit unit test for this, `ide_completion::render::fn_detail_includes_args_and_return_type`, which passes.
Lots of other unit tests fail (~60 of them) due to this change, although I believe the failures are purely cosmetic (they were testing the exact format of this output). I'm happy to go update those tests, but before I do that I'd like to make sure this is in fact the format we want for the detail?
edit - I realized `UPDATE_EXPECT=1 cargo test` automatically updates `expect!` tests. Big 👍 to whoever worked on that! So I'll go ahead and update all these tests soon. But I still would like to confirm `fn(T, U) -> V` is the desired content in the `detail` field.
8000: Use hir formatter for hover text r=matklad a=oxalica
Fix#2765 , (should) fix#4665
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
Co-authored-by: oxalica <oxalicc@pm.me>
7970: Fix incorrect diagnostics for failing built in macros r=jonas-schievink a=brandondong
**Reproduction:**
1. Use a built in macro in such a way that rust-analyzer fails to expand it. For example:
**lib.rs**
```
include!("<valid file but without a .rs extension so it is not indexed by rust-analyzer>");
```
2. rust-analyzer highlights the macro call and says the macro itself cannot be resolved even though include! is in the standard library (unresolved-macro-call diagnostic).
3. No macro-error diagnostic is raised.
**Root cause for incorrect unresolved-macro-call diagnostic:**
1. collector:collect_macro_call is able to resolve include! in legacy scope but the expansion fails. Therefore, it's pushed into unexpanded_macros to be retried with module scope.
2. include! fails at the resolution step in collector:resolve_macros now that it's using module scope. Therefore, it's retained in unexpanded_macros.
3. Finally, collector:finish tries resolving the remaining unexpanded macros but only with module scope. include! again fails at the resolution step so a diagnostic is created.
**Root cause for missing macro-error diagnostic:**
1. In collector:resolve_macros, directive.legacy is None since eager expansion failed in collector:collect_macro_call. The macro_call_as_call_id fails to resolve since we're retrying in module scope. Therefore, collect_macro_expansion is not called for the macro and no macro-error diagnostic is generated.
**Fix:**
- In collector:collect_macro_call, do not add failing built-in macros to the unexpanded_macros list and immediately raise the macro-error diagnostic. This is in contrast to lazy macros which are resolved in collector::resolve_macros and later expanded in collect_macro_expansion where a macro-error diagnostic may be raised.
Co-authored-by: Brandon <brandondong604@hotmail.com>
Co-authored-by: brandondong <brandondong604@hotmail.com>
7778: Fix lowering trailing self paths in UseTrees r=Veykril a=Veykril
Noticed that hovering over `self` in a use tree like `use foo::bar::{self}` showing documentation and such for the current module instead of `bar`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7804: Introduce TypeCtor::Scalar r=lnicola a=Veykril
`TypeCtor::Int(..) | TypeCtor::Float(..) | TypeCtor::Char | TypeCtor::Bool` => `TypeCtor::Scalar(..)`, in this case we can actually just straight up use `chalk_ir::Scalar` already since its just a POD without any IDs or anything.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7426: Create all `ModuleId`s through a `DefMap` method r=jonas-schievink a=jonas-schievink
`ModuleId` needs to be able to represent blocks, and only the
associated `DefMap` will know how to construct that `ModuleId`
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7359: ItemTree: store a mapping from blocks to inner items r=jonas-schievink a=jonas-schievink
To do name resolution within block expressions, we need to know which inner items are located inside each block expression. This adds such a mapping to `ItemTree`, replacing the previous one, which was seemingly unused other than to access all the inner items.
This also assigns `AstId`s to block expressions, which is needed to store the mapping in salsa.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7336: Rename `CrateDefMap` to `DefMap` r=matklad a=jonas-schievink
I propose handling local items by computing a `DefMap` for every block expression, using the regular (early) name resolution algorithm. The result of that will be a `DefMap` that has a reference to the parent `DefMap`, which is either the one computed for the containing block expression, or the crate's root `DefMap`. Name resolution will fall back to a name in the parent `DefMap` if it cannot be resolved in the inner block.
The `DefMap`s computed for block expressions will go through a separate query that can be garbage-collected much more aggressively, since these `DefMap`s should be cheap to compute and are never part of a crate's public API.
The first step towards that is to make `CrateDefMap` not specific to crates anymore, hence this rename (if this plans sounds reasonable).
cc https://github.com/rust-analyzer/rust-analyzer/issues/7325 and https://github.com/rust-analyzer/rust-analyzer/issues/1165
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7276: Remove map module from la-arena public API r=lnicola a=arzg
It’s unlikely that more items will be added to the module, so it’s simpler for users if `ArenaMap` is re-exported and the module made private.
This doesn’t compile for the same reason that #7275 doesn’t:
> This pull request doesn’t compile because dependencies on la-arena go through crates.io, so existing dependencies on the crate are referencing an old version. As such, this PR will only compile once a new la-arena version has been published.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
7110: Deduplicate macros when offering completion r=matklad a=AdnoC
Closes https://github.com/rust-analyzer/rust-analyzer/issues/7081
When iterating over the names within the `hir_def::resolver::Scope` for a module, track what macros are in the `hir_def::item_scope::ItemScope::legacy_macros` collection for the module. When iterating over names from the prelude, do not proccess the name if it had been in the `legacy_macros` collection.
This is implemented with a `FxHashSet` in the `Scope::process_names` function that is populated when iterating over `legacy_macros` and checked when iterating over the prelude.
Alternative implementation could instead query the `legacy_macros` `FxHashMap` directly when processing names in the prelude.
Also, I'd like to add a test for this, but I'm not sure where it could be added.
Co-authored-by: AdnoC <adam.r.cutler@gmail.com>
7145: Proper handling $crate Take 2 [DO NOT MERGE] r=edwin0cheng a=edwin0cheng
Similar to previous PR (#7133) , but improved the following things :
1. Instead of storing the whole `ExpansionInfo`, we store a similar but stripped version `HygieneInfo`.
2. Instread of storing the `SyntaxNode` (because every token we are interested are IDENT), we store the `TextRange` only.
3. Because of 2, we now can put it in Salsa.
4. And most important improvement: Instead of computing the whole frames every single time, we compute it recursively through salsa: (Such that in the best scenario, we only need to compute the first layer of frame)
```rust
let def_site = db.hygiene_frame(info.def.file_id);
let call_site = db.hygiene_frame(info.arg.file_id);
HygieneFrame { expansion: Some(info), local_inner, krate, call_site, def_site }
```
The overall speed compared to previous PR is much faster (65s vs 45s) :
```
[WITH old PR]
Database loaded 644.86ms, 284mi
Crates in this dir: 36
Total modules found: 576
Total declarations: 11153
Total functions: 8715
Item Collection: 15.78s, 91562mi
Total expressions: 240721
Expressions of unknown type: 2635 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 865
Inference: 49.84s, 250747mi
Total: 65.62s, 342310mi
rust-analyzer -q analysis-stats . 66.72s user 0.57s system 99% cpu 1:07.40 total
[WITH this PR]
Database loaded 665.83ms, 284mi
Crates in this dir: 36
Total modules found: 577
Total declarations: 11188
Total functions: 8743
Item Collection: 15.28s, 84919mi
Total expressions: 241229
Expressions of unknown type: 2637 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 868
Inference: 30.15s, 135293mi
Total: 45.43s, 220213mi
rust-analyzer -q analysis-stats . 46.26s user 0.74s system 99% cpu 47.294 total
```
*HOWEVER*, it is still a perf regression (35s vs 45s):
```
[WITHOUT this PR]
Database loaded 657.42ms, 284mi
Crates in this dir: 36
Total modules found: 577
Total declarations: 11177
Total functions: 8735
Item Collection: 12.87s, 72407mi
Total expressions: 239380
Expressions of unknown type: 2643 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 868
Inference: 22.88s, 97889mi
Total: 35.74s, 170297mi
rust-analyzer -q analysis-stats . 36.71s user 0.63s system 99% cpu 37.498 total
```
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7140: Store trait associated items in fst r=matklad a=SomeoneToIgnore
Store imported traits' associated function/methods and constants into `ImportMap.fst` and pefrorm the imports search on them.
This is a first step towards trait autoimport during completion functionality, the way I see it, after this PR, only a few major things are left to be done:
* store all traits' assoc items into fst, not only the ones in scope, as we do now. Any code pointers on how to do this are welcome 😄
* adjust a few modules in completions crate (`dot.rs`, `qualified_path.rs` at least) to query the import map, reusing the `import_assets` logic heavily
==
With the current import and autoimport implementations, it looks like for a single query, we're either interested in either associated items lookup or in all other `fst` contents lookup, but never both simultaneously.
I would rather not split `fst` in two but add another `Query` parameter to separate those, but let me know if you have any ideas.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
1) the set of attributes for all variants of an enum, and
2) the set of attributes for all fields of a variant.
This avoids the current n^2 behavior when rendering completion for variants, which
prevents completion for enums with large numbers of variants.
7133: Proper handling $crate and local_inner_macros r=jonas-schievink a=edwin0cheng
This PR introduces `HygineFrames` to store the macro definition/call site hierarchy in hyginee and when resolving `local_inner_macros` and `$crate`, we use the token to look up the corresponding frame and return the correct value.
See also: https://rustc-dev-guide.rust-lang.org/macro-expansion.html#hygiene-and-hierarchies
fixe #6890 and #6788
r? @jonas-schievink
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Added the error message to the doc for the UnresolvedProcMacro
diagnostic, explaining that either enabling the procMacro setting
or disabling this diagnostic should make the warnings go away.
7010: Update ungrammar for const block patterns r=matklad a=Veykril
Fixes#6848
Adds const blocks and const block patterns to the AST and parses them.
Blocked on https://github.com/rust-analyzer/ungrammar/pull/17/, will merge that PR there once this one gets the OK so I can remove the local ungrammar dependency path and fix the Cargo.lock.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6921: Higher-ranked trait bounds for where clauses r=flodiebold a=Veykril
There is a slight problem with this which is also noted in a FIXME now but `LifetimeParameters` of these ForLifetime where clauses allocate the lifetimes in the corresponding arena as if they were lifetimes of the item itself and not just the clause they belong to. I wasn't entirely sure what I could do about this but given nothing really uses lifetimes like that currently I figured it might be fine? Open to suggestions for that problem.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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>
