fix: Fix out-of-bounds panic in some macros due to unhandled self_ref
Fixes#16200
I don't fully understand these changes, I just applied and tested the changes suggested in #16200 and they seem to fix the issue on both the repro and my original project.
internal: Simplify implementation of apply_document_changes
While reading through the code base, I stumbled across a piece of code that I found hard to read despite its simple purpose. This is my attempt at making the code easier to understand for future readers.
I won't be offended if this is too minor and not worth your time.
While reading through the code base, I stumbled across a piece of code that I found hard to read despite its simple purpose. This is my attempt at making the code easier to understand for future readers.
I won't be offended if this is too minor and not worth your time.
fix: update VSCode rust-panic problem matcher
Corrected the `rust-panic` task problem matcher for the VSCode Extension to match the new panic message pattern.
From:
```
thread 'main' panicked at 'PANIC_MESSAGE', src/main.rs:L:C
```
To:
```
thread 'main' panicked at src/main.rs:L:C:
PANIC_MESSAGE
```
add test case for negative impl
add a small test case to ensure that we don't emit `trait_impl_redundant_assoc_item` diagnostic for negative impl trait
internal: Update world symbols request definiton, prefer focus range for macros
Prior to this, the symbol search would always jump to the defining macro call, not it jumps to the name in the macro call input if possible. This is a large improvement for assoc items in an attribute impl or trait.
Complete exported macros in `#[macro_use($0)]`
Closes https://github.com/rust-lang/rust-analyzer/issues/15657.
Originally added a test case for incomplete input:
```rust
#[test]
fn completes_incomplete_syntax() {
check(
r#"
//- /dep.rs crate:dep
#[macro_export]
macro_rules! foo {
() => {};
}
//- /main.rs crate:main deps:dep
#[macro_use($0
extern crate dep;
"#,
expect![[r#"
ma foo
"#]],
)
}
```
but couldn't make it pass and removed it 😅 Our current recovering logic doesn't work for token trees and for this code:
```rust
#[macro_use(
extern crate lazy_static;
fn main() {}
```
we ended up with this syntax tree:
```
SOURCE_FILE@0..53
ATTR@0..52
POUND@0..1 "#"
L_BRACK@1..2 "["
META@2..52
PATH@2..11
PATH_SEGMENT@2..11
NAME_REF@2..11
IDENT@2..11 "macro_use"
TOKEN_TREE@11..52
L_PAREN@11..12 "("
WHITESPACE@12..13 "\n"
EXTERN_KW@13..19 "extern"
WHITESPACE@19..20 " "
CRATE_KW@20..25 "crate"
WHITESPACE@25..26 " "
IDENT@26..37 "lazy_static"
SEMICOLON@37..38 ";"
WHITESPACE@38..40 "\n\n"
FN_KW@40..42 "fn"
WHITESPACE@42..43 " "
IDENT@43..47 "main"
TOKEN_TREE@47..49
L_PAREN@47..48 "("
R_PAREN@48..49 ")"
WHITESPACE@49..50 " "
TOKEN_TREE@50..52
L_CURLY@50..51 "{"
R_CURLY@51..52 "}"
WHITESPACE@52..53 "\n"
```
Maybe we can try to parse the token tree in `crates/ide-completion/src/context/analysis.rs` but I'm not sure what's the best way forward.
feat: Implement a rust-analyzer span backed proc-macro server mode
This implements the basic span APIs. Basically anything that doesn't require talking back to the client for information access.
This also commits our syntax fixup marker to use an `ErasedAstFileId` of `!0-1` aka `0xffff_fffe`, instead of using a dummy FileId as a marker, as we need that for the `SourceFile` API to be implementable. The reason as to why the server needs to know about this at all is to prevent it from creating invalid fixup spans which could make r-a panic.
fix: Correctly set and mark the proc-macro spans
This slows down analysis by 2-3s on self for me unfortunately (~2.5% slowdown)
Noisy diff due to two simple refactoring in the first 2 commits. Relevant changes are [7d762d1](7d762d18ed) and [1e1113c](1e1113cf5f) which introduce def site spans and correct marking for proc-macros respectively.
fix: Update metavariable expression implementation
Fixes https://github.com/rust-lang/rust-analyzer/issues/16154
This duplicates behavior of that before and after PR https://github.com/rust-lang/rust/pull/117050 based on the toolchain version. There are some 1.76 nightlies that are still broken (any before that PR basically) but fetching and storing the commit makes little sense to me (opposed to the toolchain version).
