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.
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
```
So I thought why not run `npm audit fix`
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
11418: fix: Update dependency, fix Markdown references r=Veykril a=HansAuger
Stumbled across this accidentally while familiarizing myself with the code base.
Update `pulldown-cmark-to-cmark` Fix for #11008
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
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.
Co-authored-by: The0x539 <the0x539@gmail.com>
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+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11397: internal: Refactor completion module split r=Veykril a=Veykril
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.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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).
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
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).
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.
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
