Commit graph

31884 commits

Author SHA1 Message Date
Lukas Wirth
70d0b57cf0 Update ide tests 2024-10-21 11:28:19 +02:00
Lukas Wirth
1cdc34fa4a Fix recursive_adt fixture 2024-10-21 11:28:18 +02:00
Noratrieb
6a2b8270c9 Update rustc-hash to version 2
This brings in the new optimized algorithm that was shown to have small performance benefits for
rustc.
2024-10-21 11:28:18 +02:00
bors
9323b53858 Auto merge of #18354 - roife:safe-kw-2, r=lnicola
fix: classify `safe` as a contextual kw

fix #18352
2024-10-20 20:01:48 +00:00
roife
834ccbffba fix: classify safe as a contextual kw 2024-10-21 02:56:21 +08:00
bors
7e0467b322 Auto merge of #18353 - ChayimFriedman2:cargo-lock, r=lnicola
Update Cargo.lock
2024-10-20 15:53:16 +00:00
Chayim Refael Friedman
a55a7b84a3 Update Cargo.lock 2024-10-20 18:50:05 +03:00
bors
6dc5b324ac Auto merge of #18350 - roife:safe-kw-1, r=lnicola
feat: initial support for safe_kw in extern blocks

This PR adds initial support for `safe` keywords in external blocks.

## Changes

1. Parsing static declarations with `safe` kw and `unsafe` kw, as well as functions with `safe` kw in extern_blocks
2. Add `HAS_SAFE_KW ` to `FnFlags`
3. Handle `safe` kw in `is_fn_unsafe_to_call` query
4. Handle safe_kw in unsafe diagnostics
2024-10-20 14:22:31 +00:00
roife
002f6ad6f1 fix: do not emit unsafe diagnositcs for safe statics in extern blocks 2024-10-20 19:49:57 +08:00
roife
9f1e450c4f feat: initial support for safe_kw in extern blocks 2024-10-20 17:12:52 +08:00
bors
687b72c36a Auto merge of #18336 - xuwaters:patch-1, r=lnicola
Fix: Increase TOKEN_LIMIT in hir-expand

Due to the `TOKEN_LIMIT`, rust-analyzer failed to expand macro for `web-sys::WebGl2RenderingContext` https://github.com/rustwasm/wasm-bindgen/blob/main/crates/web-sys/src/features/gen_WebGl2RenderingContext.rs

<img width="780" alt="image" src="https://github.com/user-attachments/assets/3a39f18e-656e-43df-9994-0a0179fa42ac">
<img width="403" alt="image" src="https://github.com/user-attachments/assets/7ae8dcf9-a40a-4070-8623-dd3a953bbf45">

After increasing the `TOKEN_LIMIT`, the `web-sys::WebGl2RenderingContext` can be expanded successfully:
<img width="459" alt="image" src="https://github.com/user-attachments/assets/76a71763-05a5-4f14-a5c9-61fc190c668f">
2024-10-19 05:11:52 +00:00
bors
788e6b50fb Auto merge of #18335 - SomeoneToIgnore:editorconfig-glob, r=lnicola
internal: Fix editorconfig glob

Had been testing Zed's editorconfig branch on r-a and noticed that something was odd with yaml files.

https://spec.editorconfig.org/#glob-expressions

> {s1,s2,s3}

> any of the strings given (separated by commas, can be nested) (But {s1} only matches {s1} literally.)
2024-10-19 04:55:39 +00:00
Wei Xu
cfa5df107a
Increase TOKEN_LIMIT for hir-expand 2024-10-18 17:36:24 -07:00
Kirill Bulatov
36d22a3767 Fix editorconfig glob 2024-10-19 01:10:31 +03:00
bors
3ddfb0da47 Auto merge of #18300 - krobelus:clamp-position-character-2, r=Veykril
Clamp Position::character to line length 2/2

Completes https://github.com/rust-lang/rust-analyzer/pull/18243

I don't think I have permissions to target this on the other PR, so we'll need to rebase manually
2024-10-18 13:53:44 +00:00
Johannes Altmanninger
94a4c3abaa Clamp Position::character to line length
LSP says about Position::character

> If the character value is greater than the line length it defaults back to the line length.

but from_proto::offset() doesn't implement this.

A client might for example request code actions for a whole line by sending
Position::character=99999.  I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.

Technically it should be a warning, not an error but warning is not shown by default so keep
it at error I guess.

Fixes #18240
2024-10-18 15:07:13 +02:00
bors
72b214fbfb Auto merge of #18324 - davidbarsky:davidbarsky/fix-some-node-dependencies, r=lnicola
vscode: update some dependencies

I bumped Typescript and vsce; was a little tired of the warnings when running `vsce`.
2024-10-18 12:48:40 +00:00
David Barsky
cfc5a0ea30 vscode: update some dependencies 2024-10-18 08:43:14 -04:00
David Barsky
1cd7654567 internal: fix lldb-dap unconditionally calling rustc 2024-10-18 08:43:13 -04:00
bors
c116ff6e13 Auto merge of #18320 - davidbarsky:davidbarsky/fix-lldb-dap-calling-rustc, r=Veykril
internal: fix lldb-dap unconditionally calling rustc

Fixes https://github.com/rust-lang/rust-analyzer/issues/18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.

I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
2024-10-18 11:38:01 +00:00
bors
3bda0cc2c0 Auto merge of #18243 - krobelus:clamp-position-character, r=Veykril
Clamp Position::character to line length

LSP says about Position::character

> If the character value is greater than the line length it defaults back to the line length.

but from_proto::offset() doesn't implement this.

A client might for example request code actions for a whole line by sending
Position::character=99999.  I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.

Not sure how to update Cargo.lock (lib/README.md doesn't say how).

Fixes #18240
2024-10-18 11:23:05 +00:00
bors
a40c399a3f Auto merge of #18331 - Veykril:veykril/push-tsolukqqyllz, r=Veykril
internal: Add more trivially `Sized` types to `is_sized` check
2024-10-18 10:55:51 +00:00
Lukas Wirth
c11b45a6bd internal: Add more trivially Sized types to is_sized check 2024-10-18 12:41:14 +02:00
bors
6703d7adb2 Auto merge of #18328 - Veykril:veykril/push-zrzmmyqzqwyr, r=Veykril
fix: Fix CI running analysis-stats incorrectly against the standard libraries

Fixes https://github.com/rust-lang/rust-analyzer/issues/18326
2024-10-18 10:36:15 +00:00
Lukas Wirth
e5af3ae427 fix: Fix CI running analysis-stats incorrectly against the standard libraries 2024-10-18 12:34:55 +02:00
David Barsky
f25cb191a9 internal: fix lldb-dap unconditionally calling rustc 2024-10-17 13:27:15 -04:00
bors
8dd53a3a46 Auto merge of #18317 - lnicola:sync-from-rust, r=Veykril
minor: sync from downstream
2024-10-17 11:18:57 +00:00
Laurențiu Nicola
2fe603efe7 Bump rustc crates 2024-10-17 13:11:12 +02:00
Laurențiu Nicola
7ae97c1ef1 Merge from rust-lang/rust 2024-10-17 10:04:49 +03:00
Laurențiu Nicola
f3fad2af10 Preparing for merge from rust-lang/rust 2024-10-17 10:04:47 +03:00
bors
dd4dac0438 Auto merge of #18315 - varungandhi-src:vg/bump-scip, r=lnicola
Bump version of scip crate

Follow up to https://github.com/sourcegraph/scip/issues/284

Manually verified that SCIP generation works OK for rust-analyzer itself.

cc `@RalfJung`
2024-10-17 05:33:04 +00:00
Varun Gandhi
6db78a82d4 Bump version of scip crate 2024-10-17 13:19:48 +08:00
bors
a439ed8b8a Auto merge of #17990 - Wilfred:local_time_logs, r=Veykril
internal: Use local time when formatting logs

When debugging rust-analyzer and looking at logs, it's much easier to read when the timestamp is in the local timezone.

Before:

    2024-08-28T20:55:38.792321Z  INFO ParseQuery: invoked at R18460

After:

    2024-08-28T13:55:38.792321-07:00  INFO ParseQuery: invoked at R18460
2024-10-16 22:25:28 +00:00
Wilfred Hughes
36b9f09917 internal: Use local time when formatting logs
When debugging rust-analyzer and looking at logs, it's much easier to read
when the timestamp is in the local timezone.

Before:

    2024-08-28T20:55:38.792321Z  INFO ParseQuery: invoked at R18460

After:

    2024-08-28T13:55:38.792321-07:00  INFO ParseQuery: invoked at R18460
2024-10-16 15:22:57 -07:00
bors
848af21981 Auto merge of #131460 - jwong101:default-placement-new, r=ibraheemdev
Optimize `Box::default` and `Arc::default` to construct more types in place

Both the `Arc` and `Box` `Default` impls currently call `T::default()` before allocating, and then moving the resulting `T` into the allocation.

Most `Default` impls are trivial, which should in theory allow
LLVM to construct `T: Default` directly in the `Box` allocation when calling
`<Box<T>>::default()`.

However, the allocation may fail, which necessitates calling `T`'s destructor if it has one.
If the destructor is non-trivial, then LLVM has a hard time proving that it's
sound to elide, which makes it construct `T` on the stack first, and then copy it into the allocation.

Change both of these impls to allocate first, and then call `T::default` into the uninitialized allocation, so that LLVM doesn't have to prove that it's sound to elide the destructor/initial stack copy.

For example, given the following Rust code:

```rust
#[derive(Default, Clone)]
struct Foo {
    x: Vec<u8>,
    z: String,
    y: Vec<u8>,
}

#[no_mangle]
pub fn src() -> Box<Foo> {
    Box::default()
}
```

<details open>
<summary>Before this PR:</summary>

```llvm
`@__rust_no_alloc_shim_is_unstable` = external global i8

; drop_in_place() generated in case the allocation fails

; core::ptr::drop_in_place<playground::Foo>
; Function Attrs: nounwind nonlazybind uwtable
define internal fastcc void `@"_ZN4core3ptr36drop_in_place$LT$playground..Foo$GT$17hff376aece491233bE"(ptr` noalias nocapture noundef readonly align 8 dereferenceable(72) %_1) unnamed_addr #0 personality ptr `@rust_eh_personality` {
start:
  %_1.val = load i64, ptr %_1, align 8
  %0 = icmp eq i64 %_1.val, 0
  br i1 %0, label %bb6, label %"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i"

"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i": ; preds = %start
  %1 = getelementptr inbounds i8, ptr %_1, i64 8
  %_1.val6 = load ptr, ptr %1, align 8, !nonnull !3, !noundef !3
  tail call void `@__rust_dealloc(ptr` noundef nonnull %_1.val6, i64 noundef %_1.val, i64 noundef 1) #8
  br label %bb6

bb6:                                              ; preds = %"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i", %start
  %2 = getelementptr inbounds i8, ptr %_1, i64 24
  %.val9 = load i64, ptr %2, align 8
  %3 = icmp eq i64 %.val9, 0
  br i1 %3, label %bb5, label %"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i.i11"

"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i.i11": ; preds = %bb6
  %4 = getelementptr inbounds i8, ptr %_1, i64 32
  %.val10 = load ptr, ptr %4, align 8, !nonnull !3, !noundef !3
  tail call void `@__rust_dealloc(ptr` noundef nonnull %.val10, i64 noundef %.val9, i64 noundef 1) #8
  br label %bb5

bb5:                                              ; preds = %"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i.i11", %bb6
  %5 = getelementptr inbounds i8, ptr %_1, i64 48
  %.val4 = load i64, ptr %5, align 8
  %6 = icmp eq i64 %.val4, 0
  br i1 %6, label %"_ZN4core3ptr46drop_in_place$LT$alloc..vec..Vec$LT$u8$GT$$GT$17hb5ca95423e113cf7E.exit16", label %"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i15"

"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i15": ; preds = %bb5
  %7 = getelementptr inbounds i8, ptr %_1, i64 56
  %.val5 = load ptr, ptr %7, align 8, !nonnull !3, !noundef !3
  tail call void `@__rust_dealloc(ptr` noundef nonnull %.val5, i64 noundef %.val4, i64 noundef 1) #8
  br label %"_ZN4core3ptr46drop_in_place$LT$alloc..vec..Vec$LT$u8$GT$$GT$17hb5ca95423e113cf7E.exit16"

"_ZN4core3ptr46drop_in_place$LT$alloc..vec..Vec$LT$u8$GT$$GT$17hb5ca95423e113cf7E.exit16": ; preds = %bb5, %"_ZN63_$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$10deallocate17heaa87468709346b1E.exit.i.i.i4.i15"
  ret void
}

; Function Attrs: nonlazybind uwtable
define noalias noundef nonnull align 8 ptr `@src()` unnamed_addr #1 personality ptr `@rust_eh_personality` {
start:

; alloca to place `Foo` in.
  %_1 = alloca [72 x i8], align 8
  call void `@llvm.lifetime.start.p0(i64` 72, ptr nonnull %_1)
  store i64 0, ptr %_1, align 8
  %_2.sroa.4.0._1.sroa_idx = getelementptr inbounds i8, ptr %_1, i64 8
  store ptr inttoptr (i64 1 to ptr), ptr %_2.sroa.4.0._1.sroa_idx, align 8
  %_2.sroa.5.0._1.sroa_idx = getelementptr inbounds i8, ptr %_1, i64 16
  %_3.sroa.4.0..sroa_idx = getelementptr inbounds i8, ptr %_1, i64 32
  call void `@llvm.memset.p0.i64(ptr` noundef nonnull align 8 dereferenceable(16) %_2.sroa.5.0._1.sroa_idx, i8 0, i64 16, i1 false)
  store ptr inttoptr (i64 1 to ptr), ptr %_3.sroa.4.0..sroa_idx, align 8
  %_3.sroa.5.0..sroa_idx = getelementptr inbounds i8, ptr %_1, i64 40
  %_4.sroa.4.0..sroa_idx = getelementptr inbounds i8, ptr %_1, i64 56
  call void `@llvm.memset.p0.i64(ptr` noundef nonnull align 8 dereferenceable(16) %_3.sroa.5.0..sroa_idx, i8 0, i64 16, i1 false)
  store ptr inttoptr (i64 1 to ptr), ptr %_4.sroa.4.0..sroa_idx, align 8
  %_4.sroa.5.0..sroa_idx = getelementptr inbounds i8, ptr %_1, i64 64
  store i64 0, ptr %_4.sroa.5.0..sroa_idx, align 8
  %0 = load volatile i8, ptr `@__rust_no_alloc_shim_is_unstable,` align 1, !noalias !4
  %_0.i.i.i = tail call noalias noundef align 8 dereferenceable_or_null(72) ptr `@__rust_alloc(i64` noundef 72, i64 noundef 8) #8, !noalias !4
  %1 = icmp eq ptr %_0.i.i.i, null
  br i1 %1, label %bb2.i, label %"_ZN5alloc5boxed12Box$LT$T$GT$3new17h0864de14f863a27aE.exit"

bb2.i:                                            ; preds = %start
; invoke alloc::alloc::handle_alloc_error
  invoke void `@_ZN5alloc5alloc18handle_alloc_error17h98142d0d8d74161bE(i64` noundef 8, i64 noundef 72) #9
          to label %.noexc unwind label %cleanup.i

.noexc:                                           ; preds = %bb2.i
  unreachable

cleanup.i:                                        ; preds = %bb2.i
  %2 = landingpad { ptr, i32 }
          cleanup
; call core::ptr::drop_in_place<playground::Foo>
  call fastcc void `@"_ZN4core3ptr36drop_in_place$LT$playground..Foo$GT$17hff376aece491233bE"(ptr` noalias noundef nonnull align 8 dereferenceable(72) %_1) #10
  resume { ptr, i32 } %2

"_ZN5alloc5boxed12Box$LT$T$GT$3new17h0864de14f863a27aE.exit": ; preds = %start

; Copy from stack to heap if allocation is successful
  call void `@llvm.memcpy.p0.p0.i64(ptr` noundef nonnull align 8 dereferenceable(72) %_0.i.i.i, ptr noundef nonnull align 8 dereferenceable(72) %_1, i64 72, i1 false)
  call void `@llvm.lifetime.end.p0(i64` 72, ptr nonnull %_1)
  ret ptr %_0.i.i.i
}

```
</details>

<details>
<summary>After this PR</summary>

```llvm
; Notice how there's no `drop_in_place()` generated as well

define noalias noundef nonnull align 8 ptr `@src()` unnamed_addr #0 personality ptr `@rust_eh_personality` {
start:
; no stack allocation

  %0 = load volatile i8, ptr `@__rust_no_alloc_shim_is_unstable,` align 1
  %_0.i.i.i.i.i = tail call noalias noundef align 8 dereferenceable_or_null(72) ptr `@__rust_alloc(i64` noundef 72, i64 noundef 8) #5
  %1 = icmp eq ptr %_0.i.i.i.i.i, null
  br i1 %1, label %bb3.i, label %"_ZN5alloc5boxed16Box$LT$T$C$A$GT$13new_uninit_in17h80d6355ef4b73ea3E.exit"

bb3.i:                                            ; preds = %start
; call alloc::alloc::handle_alloc_error
  tail call void `@_ZN5alloc5alloc18handle_alloc_error17h98142d0d8d74161bE(i64` noundef 8, i64 noundef 72) #6
  unreachable

"_ZN5alloc5boxed16Box$LT$T$C$A$GT$13new_uninit_in17h80d6355ef4b73ea3E.exit": ; preds = %start
; construct `Foo` directly into the allocation if successful

  store i64 0, ptr %_0.i.i.i.i.i, align 8
  %_8.sroa.4.0._1.sroa_idx = getelementptr inbounds i8, ptr %_0.i.i.i.i.i, i64 8
  store ptr inttoptr (i64 1 to ptr), ptr %_8.sroa.4.0._1.sroa_idx, align 8
  %_8.sroa.5.0._1.sroa_idx = getelementptr inbounds i8, ptr %_0.i.i.i.i.i, i64 16
  %_8.sroa.7.0._1.sroa_idx = getelementptr inbounds i8, ptr %_0.i.i.i.i.i, i64 32
  tail call void `@llvm.memset.p0.i64(ptr` noundef nonnull align 8 dereferenceable(16) %_8.sroa.5.0._1.sroa_idx, i8 0, i64 16, i1 false)
  store ptr inttoptr (i64 1 to ptr), ptr %_8.sroa.7.0._1.sroa_idx, align 8
  %_8.sroa.8.0._1.sroa_idx = getelementptr inbounds i8, ptr %_0.i.i.i.i.i, i64 40
  %_8.sroa.10.0._1.sroa_idx = getelementptr inbounds i8, ptr %_0.i.i.i.i.i, i64 56
  tail call void `@llvm.memset.p0.i64(ptr` noundef nonnull align 8 dereferenceable(16) %_8.sroa.8.0._1.sroa_idx, i8 0, i64 16, i1 false)
  store ptr inttoptr (i64 1 to ptr), ptr %_8.sroa.10.0._1.sroa_idx, align 8
  %_8.sroa.11.0._1.sroa_idx = getelementptr inbounds i8, ptr %_0.i.i.i.i.i, i64 64
  store i64 0, ptr %_8.sroa.11.0._1.sroa_idx, align 8
  ret ptr %_0.i.i.i.i.i
}
```

</details>
2024-10-16 06:36:43 +00:00
Johannes Altmanninger
d42a4e6c88 line-index method to allow clamping column to line length
Part of #18240
2024-10-15 12:14:45 +02:00
bors
418c1365ec Auto merge of #18278 - ShoyuVanilla:never-place, r=Veykril
Do not consider match/let/ref of place that evaluates to ! to diverge, disallow coercions from them too

Resolves #18237
2024-10-15 07:29:55 +00:00
bors
674c01e0d7 Auto merge of #18299 - roife:fix-issue-18298, r=Veykril
fix: incorrect autofix for missing wrapped unit in return expr

fix #18298.

We should insert `Ok(())` or `Some(())` instead of wrapping `return` with variants.
2024-10-15 07:13:44 +00:00
roife
a521702d9c fix: autofix for missing wrapped unit in return expr 2024-10-15 14:23:58 +08:00
bors
0319586ef2 Auto merge of #18297 - ShoyuVanilla:salsa-package-profile, r=davidbarsky
minor: `ra-salsa` in `profile.dev.package`

Since `ra-salsa`'s package name is actually `salsa` it makes the following warning in `cargo` commands;

```
warning: profile package spec `ra-salsa` in profile `dev` did not match any packages
```

and the opt level isn't applied to it.
2024-10-14 16:02:28 +00:00
Shoyu Vanilla
77018bc2b8 minor: ra-salsa in profile.dev.package 2024-10-15 00:53:20 +09:00
Shoyu Vanilla
91293ea4d4 Do not consider match/let/ref of place that evaluates to ! to diverge, disallow coercions from them too 2024-10-15 00:37:40 +09:00
bors
eff79f171b Auto merge of #18292 - roife:fix-issue-17427, r=Veykril
feat: handle self-param outside of methods when renaming

close #17427
2024-10-14 14:51:57 +00:00
roife
1e8a03a56e feat: handle self-param outside of methods when renaming 2024-10-14 22:32:34 +08:00
bors
77d4376e05 Auto merge of #18239 - davidbarsky:davidbarsky/push-lswkwuyrpuqv, r=davidbarsky
chore: rename `salsa` to `ra_salsa`

Laying some groundwork to start before I import the new Salsa crate. Here's why:
1. As part of the migration, `@darichey,` `@Wilfred,` and I will create new Salsa equivalents of the existing databases/query groups. We'll get them to compile crate-by-crate.
2. Once we wrote all equivalents of all queries, we'd start to refactor usage sites of the vendored Salsa to use the new Salsa databases.
3. Starting porting usage sites of old Salsa to the new Salsa.
4. Remove the vendored `ra_salsa`; declare victory.
2024-10-14 14:20:59 +00:00
David Barsky
ccee36e8dd chore: rename salsa to ra_salsa 2024-10-14 10:09:22 -04:00
bors
afe015b8f9 Auto merge of #18216 - davidbarsky:davidbarsky/push-ustyovtqrpoq, r=davidbarsky
internal: switch remaining OpQueues to use named structs

Building atop of https://github.com/rust-lang/rust-analyzer/pull/18195, I switched `GlobalState::fetch_build_data_queue` to use a struct instead of a tuple.

(I didn't switch `fetch_proc_macros_queue` to not return a bool, as the return value is only used in one spot.)
2024-10-14 14:05:42 +00:00
David Barsky
501ef0ee5e internal: switch remaining OpQueues to use named structs 2024-10-14 10:04:04 -04:00
bors
7b2548bd8d Auto merge of #18291 - roife:fix-issue-18212, r=Veykril
feat: respect references.exclude_tests in call-hierarchy

close #18212

### Changes

1. feat: respect `references.exclude_tests` in call-hierarchy
2. Modified the description of `references.exclude_tests`
2024-10-14 12:50:40 +00:00
bors
c560660391 Auto merge of #18275 - darichey:fix-test-case-hang, r=Veykril
Skip #[test_case] expansion

Fixes #18274, although I don't fully understand if this is the best fix (it's not clear to me why this didn't cause issues before https://github.com/rust-lang/rust-analyzer/pull/18085).
2024-10-14 12:36:13 +00:00