8866: Update salsa r=matklad a=jonas-schievink
This updates salsa to include https://github.com/salsa-rs/salsa/pull/265, and removes all cancellation-related code from rust-analyzer
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
8885: internal: greatly simplify eager macro representation r=jonas-schievink a=jonas-schievink
- Share structures with lazy macros, make both use `MacroCallLoc`.
- Remove `intern_eager_expansion`, `EagerCallLoc`, `EagerMacroId`, and *many* matches on `MacroCallId`.
- Make a lot of FIXMEs obsolete since the code no longer distinguishes between eager and lazy macros.
- Add `EagerCallInfo`, which is `Some` for calls to eager macros and holds the argument or expansion result and the included file.
8887: fix: fix derive collection after unresolved attribute fallback r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/pull/8882#issuecomment-844379170
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8882: internal: resolve attributes in name resolution (minimal version) r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/pull/7049
This should not have any observable effect, since we don't attempt to expand attribute macros yet, and I have implemented a fallback that treats items with unresolved attributes as if the attribute wasn't there.
Derive helpers are not yet resolved. `#![register_{attr,tool}]` are not yet supported.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8813: Get some more array lengths! r=lf- a=lf-
This is built on #8799 and thus contains its changes. I'll rebase it onto master when that one gets merged. It adds support for r-a understanding the length of:
* `let a: [u8; 2] = ...`
* `let a = b"aaa"`
* `let a = [0u8; 4]`
I have added support for getting the values of byte strings, which was not previously there. I am least confident in the correctness of this part and it probably needs some more tests, as we currently have only one test that exercised that part (!).
Fixes#2922.
Co-authored-by: Jade <software@lfcode.ca>
Fix#2922: add unknown length as a condition for a type having unknown.
Incorporate reviews:
* Extract some of the const evaluation workings into functions
* Add fixmes on the hacks
* Add tests for impls on specific array lengths (these work!!! 😁)
* Add tests for const generics (indeed we don't support it yet)
8432: decl_check: consider outer scopes' allows r=jonas-schievink a=lf-
Fix#8417. Also makes it less noisy about no_mangle annotated stuff the
user can do nothing about.
Note: this still is broken with bitfield! macros. A repro in an ignore
test is included here. I believe this bug is elsewhere, and I don't
think I can work around it here.
I would like help filing the remaining bug, as it does actually affect
users, but I don't know how to describe the behaviour (or even if it
is unintended).
Co-authored-by: Jade <software@lfcode.ca>
8443: Rewrite `#[derive]` removal code to be based on AST r=jonas-schievink a=jonas-schievink
We now remove any `#[derive]` before and including the one we want to expand, in the `macro_arg` query.
The same infra will be needed by attribute macros (except we only remove the attribute we're expanding, not any preceding ones).
Part of https://github.com/rust-analyzer/rust-analyzer/issues/8434 (doesn't implement the cfg-expansion yet, because that's more difficult)
8446: Undo path resolution hack for extern prelude r=jonas-schievink a=jonas-schievink
Reverts the change made in https://github.com/rust-analyzer/rust-analyzer/pull/7959
We don't populate the extern prelude for block DefMaps anymore,
so this is unnecessary
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Fix#8417. Also makes it less noisy about no_mangle annotated stuff the
user can do nothing about.
Note: this still is broken with bitfield! macros. A repro in an ignore
test is included here. I believe this bug is elsewhere, and I don't
think I can work around it here.
Rationale: only a minority of variants used almost half the size.
By keeping large members (especially in Option) behind a box
the memory cost is only payed when the large variants are needed.
This reduces the size Vec<Expr> needs to allocate.
8352: Remove dead legacy macro expansion code r=lnicola a=brandondong
I was investigating some unrelated macro issue when I noticed this dead code. This legacy macro expansion logic was changed in https://github.com/rust-analyzer/rust-analyzer/pull/8128.
Co-authored-by: Brandon <brandondong604@hotmail.com>
8245: Properly resolve intra doc links in hover and goto_definition r=matklad a=Veykril
Unfortunately involves a bit of weird workarounds due to pulldown_cmark's incorrect lifetimes on `BrokenLinkCallback`... I should probably open an issue there asking for the fixes to be pushed to a release since they already exist in the repo for quite some time it seems.
Fixes#8258, Fixes#8238
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Bitflags is generally a good dependency -- it's lightweight, well
maintained and embraced by the ecosystem.
I wonder, however, do we really need it? Doesn't feel like it adds much
to be honest.
8322: Access a body's block def maps via a method r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Only one upgradeable read lock can be handed out at the same time, and
we never acquire a non-upgradeable read lock, so this has no benefit
over just using a write lock in the first place.
8266: Fix generic arguments being incorrectly offset in qualified trait casts r=flodiebold a=Veykril
We reverse the segments and generic args of the lowered path after building it, this wasn't accounted for when inserting the self parameter in `Type as Trait` segments.
Fixes#5886
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7907: Autoderef with visibility r=cynecx a=cynecx
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7841.
I am not sure about the general approach here. Right now this simply tries to check whether the autoderef candidate is reachable from the current module. ~~However this doesn't exactly work with traits (see the `tests::macros::infer_derive_clone_in_core` test, which fails right now).~~ see comment below
Refs:
- `rustc_typeck` checking fields: 66ec64ccf3/compiler/rustc_typeck/src/check/expr.rs (L1610)
r? @flodiebold
Co-authored-by: cynecx <me@cynecx.net>
8134: Correct the paths of submodules from the include! macro r=edwin0cheng a=sticnarf
This PR should fix#7846. It mostly follows the instructions from @edwin0cheng in that issue.
Co-authored-by: Yilin Chen <sticnarf@gmail.com>
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>
