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.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
11437: [ide_completion] render if a function is async/const/unsafe in completion details r=Veykril a=jhgg
this change renders in the autocomplete detail, whether a function is async/const/unsafe.
i found myself wanting to know this information at a glance, so now it renders here:
Co-authored-by: Jake Heinz <jh@discordapp.com>
11436: fix: renaming modules does not change references by super r=Veykril a=TheDoctor314
Fixes#11289.
Co-authored-by: TheDoctor314 <64731940+TheDoctor314@users.noreply.github.com>
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>
