It's a good idea to distinguish between absolute and relative paths at
the type level, to avoid accidental dependency on the cwd, which
really shouldn't matter for rust-analyzer service
4700: Add top level keywords completion r=matklad a=mcrakhman
This fixes the following issue: https://github.com/rust-analyzer/rust-analyzer/issues/4566.
Also added simple logic which filters the keywords which can be used with unsafe on the top level.
Co-authored-by: Mikhail Rakhmanov <rakhmanov.m@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
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>
