8514: Add more profiling spans into type inference r=matklad a=SomeoneToIgnore
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/8503
I've added a minimal set of spans to remove `???` and showcase the underlying issue:
<img width="1552" alt="image" src="https://user-images.githubusercontent.com/2690773/114722983-f2181900-9d42-11eb-821d-9e93ded5f81f.png">
`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.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
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>
8354: Distinguishing between different operators in semantic highlighting r=matklad a=chetankhilosiya
Co-authored-by: Chetan Khilosiya <chetan.khilosiya@gmail.com>
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.
Co-authored-by: Brandon <brandondong604@hotmail.com>
8496: Exclude nightly tag from git describe to fix version string r=lnicola a=lnicola
Otherwise if we run `git describe` on the release day we pick up the `nightly` tag from the previous release.
changelog fix
bors r+
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
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.
8469: Remove assertion in impl collection r=flodiebold a=flodiebold
This condition should always be true for *valid* code, but of course
there might be invalid code or things that we can't currently resolve.
Fixes#8464.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
This condition should always be true for *valid* code, but of course
there might be invalid code or things that we can't currently resolve.
Fixes#8464.
8463: Support macros in pattern position r=jonas-schievink a=jonas-schievink
This was fairly easy, because patterns are limited to bodies, so almost all changes were inside body lowering.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
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.
Co-authored-by: Brandon <brandondong604@hotmail.com>
