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).
bors[bot] [Tue, 1 Feb 2022 23:05:28 +0000 (23:05 +0000)]
Merge #11322
11322: Extract function also extracts comments r=Vannevelj a=Vannevelj
Fixes #9011
The difficulty I came across is that the original assist works from the concept of a `ast::StmtList`, a node, but that does not allow me to (easily) represent comments, which are tokens. To combat this, I do a whole bunch of roundtrips: from the `ast::StmtList` I retrieve the `NodeOrToken`s it encompasses.
I then cast all `Node` ones back to a `Stmt` so I can apply indentation to it, after which it is again parsed as a `NodeOrToken`.
Lastly, I add a new `make::` api that accepts `NodeOrToken` rather than `StmtList` so we can write the comment tokens.
bors[bot] [Mon, 31 Jan 2022 16:03:23 +0000 (16:03 +0000)]
Merge #11388
11388: fix: Fix proc-macro server not using the supplied span in Ident::new r=Veykril a=Veykril
This makes the hack introduced by https://github.com/rust-analyzer/rust-analyzer/pull/10899 obsolete.
For async-trait specifically, (unfortunately, but technically correct) due to how async-trait works, the self local now renders white, as it now resolves to the `__self` local introduced by the attribute.
bors[bot] [Mon, 31 Jan 2022 11:16:22 +0000 (11:16 +0000)]
Merge #11182
11182: fix: don't panic on seeing an unexpected offset r=Veykril a=dimbleby
Intended as a fix, or at least a sticking plaster, for #11081.
I have arranged that [offset()](https://github.com/rust-analyzer/rust-analyzer/blob/1ba9a924d7b161c52e605e157ee16d582e4a8684/crates/ide_db/src/line_index.rs#L105-L107) returns `Option<TextSize>` instead of going out of bounds; other changes are the result of following the compiler after doing this.
Perhaps there's still an issue here - I suppose the server and client have gotten out of sync and that probably shouldn't happen in the first place? I see that https://github.com/rust-analyzer/rust-analyzer/issues/10138#issuecomment-913727554 suggests what sounds like a more substantial fix which I think might be aimed in this direction. So perhaps that one should be left open to cover such things?
Meanwhile, I hope that not-crashing is a good improvement: and I can confirm that it works out just fine in the repro I have at #11081.
Co-authored-by: David Hotham <david.hotham@metaswitch.com>
bors[bot] [Fri, 28 Jan 2022 13:21:24 +0000 (13:21 +0000)]
Merge #11365
11365: Add a way to disable dll copying for users of proc_macro_srv library r=lnicola a=vlad20012
We use `ra_ap_proc_macro_srv` library in IntelliJ Rust in order to expand proc macros. We need a way to disable [DLL copying to a temp dir on Windows](https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/proc_macro_srv/src/dylib.rs#L166) behavior because it causes issues like https://github.com/intellij-rust/intellij-rust/issues/7709. Unlike RA, file locking is not an issue for IntelliJ Rust because we copy DLLs to a temp dir before calling the expander.
git 2.35 introduces a [change in behavior](https://github.com/git/git/blob/89bece5c8c96f0b962cfc89e63f82d603fd60bed/Documentation/RelNotes/2.35.0.txt#L330-L333) that breaks this check.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
bors[bot] [Wed, 26 Jan 2022 17:35:51 +0000 (17:35 +0000)]
Merge #11347
11347: fix: Fix resolution of eager macro contents r=jonas-schievink a=jonas-schievink
Eager macros resolve and expand any contained macro invocations before they are expanded. The logic for this was previously pretty broken: any nameres failure would be reported as a generic macro expansion error, so this didn't work correctly with the fixed-point resolution loop. This manifested as spurious errors whenever a non-legacy macro was used in an eager macro (that means *any* path with more than one segment).
After an intense staring contest with the abyss, this PR fixes the basic logic, but some bugs still remain (particularly around `$crate`). As a side-effect, this PR moves `ModPath` into `hir_expand`.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
projects / rust.git / log