8526: fix: Do not show flyimports in trait or impl declarations r=SomeoneToIgnore a=SomeoneToIgnore
Part of https://github.com/rust-analyzer/rust-analyzer/issues/8518
Removes autoimport suggestions for the case:
> inside trait definitions / impls (trait Trait {$0} / impl Foo {$0}), nothing except the fn, type and const keywords (and the full item completions for trait impls) should appear (currently many types and autoimport suggestions)
`db.trait_solve` reliably produces the same timings for the same input in the same place for me, despite supposedly being cached by Salsa.
In my perception, this is a bit odd, so I've decided to stop at this point and discuss it with people with better knowledge on the topic.
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).
8415: Fix faulty assertion when extracting function with macro call r=matklad a=brandondong
**Reproduction:**
```rust
fn main() {
let n = 1;
let k = n * n;
dbg!(n);
}
```
1. Select the second and third lines of the main function. Use the "Extract into function" code assist.
2. Panic occurs in debug, error is logged in release: "[ERROR ide_assists::handlers::extract_function] assertion failed: matches!(path, ast :: Expr :: PathExpr(_))".
3. Function generates successfully on release where the panic was bypassed.
```rust
fn fun_name(n: i32) {
let k = n * n;
dbg!(n);
}
```
**Cause:**
- The generated function will take `n` as a parameter. The extraction logic needs to search the usages of `n` to determine whether it is used mutably or not. The helper `path_element_of_reference` is called for each usage but the second usage is a macro call and fails the `Expr::PathExpr(_)` match assertion.
- The caller of `path_element_of_reference` does implicitly assume it to be a `Expr::PathExpr(_)` in how it looks at its parent node for determining whether it is used mutably. This logic will not work for macros.
- I'm not sure if there are any other cases besides macros where it could be something other than a `Expr::PathExpr(_)`. I tried various examples and could not find any.
**Fix:**
- Update assertion to include the macro case.
- Add a FIXME to properly handle checking if a macro usage requires mutable access. For now, return false instead of running the existing logic that is tailored for `Expr::PathExpr(_)`'s.
fix: don't spam repeated error messages when `cargo check` fails
Conceptually, using a *message* here is wrong, because this is a
"status", rather than "point in time" thing. But statuses are an LSP
extension, while messages are stable. As a compromise, send message only
for more critical `metadata` failures, and only once per state change.
8436: Fix extract function's mutability of variables outliving the body r=matklad a=brandondong
**Reproduction:**
```rust
fn main() {
let mut k = 1;
let mut j = 2;
j += 1;
k += j;
}
```
1. Select the first to third lines of the main function. Use the "Extract into function" code assist.
2. The output is the following which does not compile because the outlived variable `k` is declared as immutable:
```rust
fn main() {
let (k, j) = fun_name();
k += j;
}
fn fun_name() -> (i32, i32) {
let mut k = 1;
let mut j = 2;
j += 1;
(k, j)
}
```
3. We would instead expect the output to be:
```rust
fn main() {
let (mut k, j) = fun_name();
k += j;
}
```
**Fix:**
- Instead of declaring outlived variables as immutable unconditionally, check for any mutable usages outside of the extracted function.
8460: Revert "Rewrite `#[derive]` removal code to be based on AST" r=jonas-schievink a=jonas-schievink
It breaks some function-like proc macros: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Proc.20macro.20expansion/near/233971916
It also uses attribute indices incorrectly, which causes insufficient attributes to be removed.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Move lots of things around within `hir_ty`. Most notably, all the Chalk-related stuff moves from within `traits/` to the top-level, since Chalk isn't purely a "traits thing" anymore.
8406: Improve indexing of impls r=flodiebold a=flodiebold
Store impls for e.g. &Foo with the ones for Foo instead of the big "other" bucket. This can improve performance and simplifies the HIR impl search a bit.
Store impls for e.g. &Foo with the ones for Foo instead of the big
"other" bucket. This can improve performance and simplifies the HIR impl
search a bit.
8440: Fix crash on syn involving lifetimes returned by Chalk r=flodiebold a=flodiebold
If we get lifetime variables back in autoderef, just immediately replace them by static lifetimes for now. Method resolution doesn't really deal correctly with new variables being introduced (this needs to be fixed more properly).
This fixes `rust-analyzer analysis-stats --with-deps` crashing in the RA repo.
Fix crash on syn involving lifetimes returned by Chalk
If we get lifetime variables back in autoderef, just immediately replace
them by static lifetimes for now. Method resolution doesn't really deal
correctly with new variables being introduced (this needs to be fixed
more properly).
This fixes `rust-analyzer analysis-stats --with-deps` crashing in the RA
repo.
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.
8433: Intern lots of things r=jonas-schievink a=flodiebold
This uses the new interning infrastructure for most type-related things, where it had a positive effect on memory usage and performance. In total, this gives a slight performance improvement and a quite good memory reduction (1119MB->885MB on RA, 1774MB->1188MB on Diesel).