4857: Fix invalid shorthand initialization diagnostic for tuple structs r=jonas-schievink a=OptimalStrategy
Initializing tuple structs explicitly, like in the example below, produces a "Shorthand struct initialization" diagnostic that leads to a compilation error when applied:
```rust
struct S(usize);
fn main() {
let s = S { 0: 0 }; // OK, but triggers the diagnostic
// let s = S { 0 }; // Compilation error
}
```
This PR adds a check that the field name is not a literal.
Co-authored-by: OptimalStrategy <george@usan-podgornov.com>
Co-authored-by: OptimalStrategy <17456182+OptimalStrategy@users.noreply.github.com>
4833: Separating parsing of `for` in predicates and types r=matklad a=matthewjasper
We now correctly accept `for<'a> (&'a F): Fn(&'a str)` in a where clause and correctly reject `for<'a> &'a u32` as a type.
Co-authored-by: Matthew Jasper <mjjasper1@gmail.com>
4849: Make known paths use `core` instead of `std` r=matklad a=jonas-schievink
I'm not sure if this causes problems today, but it seems like it easily could, if rust-analyzer processes the libstd sources for the right `--target` and that target is a `#![no_std]`-only target.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
4819: Add an FST index to `ImportMap` and use it to speed up auto import r=matklad a=jonas-schievink
For the importing crate, we still use the symbol index, but I've modified it to only look at files that comprise that crate (instead of the whole workspace).
Oh, and since now the symbol query limit is respected correctly, it's possible that some results from the local crate now disappear if there are many matches.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/4763
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
4834: In field patterns, don't highlight local binding as a field r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
