1668: Reduce code duplication in lexer r=matklad a=eupn
During an investigation of a fix for #1218, I stumbled upon some code duplication in the lexer.
Co-authored-by: Evgenii P <eupn@protonmail.com>
1661: Parse function parameters attributes r=matklad a=eupn
Fixes#1397. The [RFC-2565](https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md) specifies `#[attributes]` to function parameters:
```rust
fn foo(#[attr] a, #[unused] b, #[must_use] ...) {
// ...
}
```
This PR adds those attributes into grammar and to the parser, extending corresponding inline tests.
Co-authored-by: Evgenii P <eupn@protonmail.com>
1662: architecture.md: "finish not Y" -> "finish node Y" r=matklad a=eupn
Is this a typo?
Co-authored-by: eupn <36292692+eupn@users.noreply.github.com>
1652: Improve type hints behavior r=matklad a=SomeoneToIgnore
This PR fixed the following type hints issues:
* Restructures the `InlayKind` enum contents based on the discussion here: https://github.com/rust-analyzer/rust-analyzer/pull/1606#issuecomment-515968055
* Races described in #1639
* Caches the latest decorations received for each file to show them the next time the file is opened (instead of a new server request)
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
1648: Optimize parsing a little r=lnicola a=lnicola
This is the change from https://github.com/rust-analyzer/rust-analyzer/issues/1643#issuecomment-517979911. In the long run we should probably take a different approach, but until then this provides a decent speed-up (10.5s vs 11.5s according to `ra_cli analysis-stats`.
EDIT: Does the profiling part make sense? I'm not sure if all parsing happens before the type inference begins or it's lazy.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
1634: Implement .await completion for futures r=flodiebold a=eupn
Closes#1263 with completion for `.await` syntax for types that are implementing `std::future::Future` trait.
r? @flodiebold
Co-authored-by: Evgenii P <eupn@protonmail.com>
