bors[bot] [Mon, 14 Feb 2022 21:07:41 +0000 (21:07 +0000)]
Merge #11369
11369: feat: Add type hint for keyword expression hovers r=Veykril a=danii
Adds the return type of keywords to tool-tips where it makes sense. This applies to: `if`, `else`, `match`, `loop`, `unsafe` and `await`. Thanks to `@Veykril` for sharing the idea of putting return type highlighting on other keywords!
Jonas Goronczy [Sat, 12 Feb 2022 22:21:41 +0000 (23:21 +0100)]
Extract struct from enum variant filters generics
Extracting a struct from an enum variant now filters out only the
generic parameters necessary for the new struct.
Bounds will be copied to the new struct, but unneeded ones are not
filtered out.
Extracting bounds in a where clause are still not implemented.
bors[bot] [Sat, 12 Feb 2022 12:48:46 +0000 (12:48 +0000)]
Merge #11444
11444: feat: Fix up syntax errors in attribute macro inputs to make completion work more often r=flodiebold a=flodiebold
This implements the "fix up syntax nodes" workaround mentioned in #11014. It isn't much more than a proof of concept; I have only implemented a few cases, but it already helps quite a bit.
Some notes:
- I'm not super happy about how much the fixup procedure needs to interact with the syntax node -> token tree conversion code (e.g. needing to share the token map). This could maybe be simplified with some refactoring of that code.
- It would maybe be nice to have the fixup procedure reuse or share information with the parser, though I'm not really sure how much that would actually help.
Maybe Waffle [Sun, 6 Feb 2022 15:56:25 +0000 (18:56 +0300)]
Pass required features to cargo when using run action
When using `F1`->`Rust Analyzer: Run` action on an `example`, pass its
`required-features` to `cargo run`. This allows to run examples that
were otherwise impossible to run with RA.
bors[bot] [Sun, 6 Feb 2022 14:28:27 +0000 (14:28 +0000)]
Merge #11420
11420: fix two vulneabilities (moderate: 1, high: 1) by running npm audit r=lnicola a=HansAuger
Again me getting familiar with the code base :D
I noticed npm warning about two vulnerabilities
```
markdown-it <12.3.2
Severity: moderate
Uncontrolled Resource Consumption in markdown-it - https://github.com/advisories/GHSA-6vfc-qv3f-vr6c
fix available via `npm audit fix`
node_modules/markdown-it
vsce 1.26.0 - 2.6.3
Depends on vulnerable versions of markdown-it
node_modules/vsce
simple-get 3.0.0 - 3.1.0
Severity: high
Exposure of Sensitive Information in simple-get - https://github.com/advisories/GHSA-wpg7-2c88-r8xv
fix available via `npm audit fix`
node_modules/simple-get
```
bors[bot] [Sat, 5 Feb 2022 11:54:07 +0000 (11:54 +0000)]
Merge #11412
11412: fix: Include `fn`/`type`/`const` keyword in trait impl completion item source ranges r=Veykril a=The0x539
Fixes #11301
If the user has typed, say, `fn de` while implementing `Default`, or `type Ta` when implementing `Deref`, then the resulting completion suggestion will replace the entire "line", which, on its own, is fine.
However, the use of `ctx.source_range()` in this code was meant that `source_range` field of the `CompletionItem` covers only the identifier and not the preceding keyword.
Over in `rust_analyzer::to_proto::completion_item`, this caused the LSP completion response to be broken up into a text edit that replaces `de` with `fn default() -> Self {` and then an entry in `additional_text_edits` to remove the extra `fn`.
I'm pretty sure that using the field like that is (slightly) out of [spec](https://microsoft.github.io/language-server-protocol/specifications/specification-3-17/#completionItem):
> Edits must not overlap [...] with the main edit
> Additional text edits should be used to change text **unrelated to the current cursor position**
VS Code supports `additionalTextEdits` in such a way that this doesn't seem like a problem, so has gone largely unnoticed.
The various LSP clients I've tried, however, do not, and as a result this bug has been haunting me for ages.
bors[bot] [Thu, 3 Feb 2022 16:30:01 +0000 (16:30 +0000)]
Merge #11403
11403: internal: Shrink `mbe::ExpandError` and `mbe::ParseError` r=Veykril a=Veykril
Also fixes https://github.com/rust-analyzer/rust-analyzer/issues/10051, as we no longer emit an empty diagnostic in some expansion cases which seems to trip up vscode for some reason. Using `compile_error!("")` will still trigger the vscode bug.
bors r+
Currently our completion infra is split into several modules, each trying to do completions for something specific. This "something" is rather unstructured as it stands now, we have a module for `flyimporting path` completions, `unqualified` and `qualified path` completions, modules for `pattern position` completions that only try to complete extra things for patterns that aren't done in the path modules, `attribute` completions that again only try to add builtin attribute completions without adding the normal path completions and a bunch of other special "entity" completions like lifetimes, method call/field access, function param cloning, ... which serve a more specific purpose than the previous listed ones.
As is evident, the former mentioned ones have some decent overlap which requires extra filtering in them so that they don't collide with each other duplicating a bunch of completions(which we had happen in the past at times).
Now this overlap mostly happens with path completions(and keyword completions as well in some sense) which gives me the feeling that having `qualified` and `unqualified` path completions be separate from the rest gives us more troubles than benefits in the long run.
So this is an attempt at changing this structure to instead still go by rough entity for special cases, but when it comes to paths we instead do the module split on the "path kinds"/"locations"(think pattern, type, expr position etc) that exist. This goes hand in hand with the test refactoring I have done that moved tests to "location oriented" modules as well as the `CompletionContext` refactoring that actually already started splitting the context up for path kinds.
This PR moves some path completions out of the `qualified` and `unqualified` path modules namely attribute, visibility, use and pattern paths.
bors[bot] [Thu, 3 Feb 2022 12:21:18 +0000 (12:21 +0000)]
Merge #11399
11399: Fix assoc type shorthand from method bounds r=flodiebold a=flodiebold
In code like this:
```rust
impl<T> Option<T> {
fn as_deref(&self) -> T::Target where T: Deref {}
}
```
when trying to resolve the associated type `T::Target`, we were only
looking at the bounds on the impl (where the type parameter is defined),
but the method can add additional bounds that can also be used to refer
to associated types. Hence, when resolving such an associated type, it's
not enough to just know the type parameter T, we also need to know
exactly where we are currently.
This fixes #11364 (beta apparently switched some bounds around).
Florian Diebold [Thu, 3 Feb 2022 11:43:15 +0000 (12:43 +0100)]
Fix assoc type shorthand from method bounds
In code like this:
```rust
impl<T> Option<T> {
fn as_deref(&self) -> T::Target where T: Deref {}
}
```
when trying to resolve the associated type `T::Target`, we were only
looking at the bounds on the impl (where the type parameter is defined),
but the method can add additional bounds that can also be used to refer
to associated types. Hence, when resolving such an associated type, it's
not enough to just know the type parameter T, we also need to know
exactly where we are currently.
This fixes #11364 (beta apparently switched some bounds around).
projects / rust.git / log