Commit graph

32265 commits

Author SHA1 Message Date
bors
ae3f89f794 Auto merge of #131572 - cuviper:ub-index_range, r=thomcc
Avoid superfluous UB checks in `IndexRange`

`IndexRange::len` is justified as an overall invariant, and
`take_prefix` and `take_suffix` are justified by local branch
conditions. A few more UB-checked calls remain in cases that are only
supported locally by `debug_assert!`, which won't do anything in
distributed builds, so those UB checks may still be useful.

We generally expect core's `#![rustc_preserve_ub_checks]` to optimize
away in user's release builds, but the mere presence of that extra code
can sometimes inhibit optimization, as seen in #131563.
2024-10-17 22:18:24 +00:00
David Barsky
f25cb191a9 internal: fix lldb-dap unconditionally calling rustc 2024-10-17 13:27:15 -04:00
bors
d74d828457 Auto merge of #130223 - LaihoE:faster_str_replace, r=thomcc
optimize str.replace

Adds a fast path for str.replace for the ascii to ascii case. This allows for autovectorizing the code. Also should this instead be done with specialization? This way we could remove one branch. I think it is the kind of branch that is easy to predict though.

Benchmark for the fast path (replace all "a" with "b" in the rust wikipedia article, using criterion) :
| N        | Speedup | Time New (ns) | Time Old (ns) |
|----------|---------|---------------|---------------|
| 2        | 2.03    | 13.567        | 27.576        |
| 8        | 1.73    | 17.478        | 30.259        |
| 11       | 2.46    | 18.296        | 45.055        |
| 16       | 2.71    | 17.181        | 46.526        |
| 37       | 4.43    | 18.526        | 81.997        |
| 64       | 8.54    | 18.670        | 159.470       |
| 200      | 9.82    | 29.634        | 291.010       |
| 2000     | 24.34   | 81.114        | 1974.300      |
| 20000    | 30.61   | 598.520       | 18318.000     |
| 1000000  | 29.31   | 33458.000     | 980540.000    |
2024-10-17 16:20:02 +00:00
Giga Bowser
c5b4fcebcc Re-use code for wrapping/unwrapping return types 2024-10-17 10:04:28 -04:00
bors
6cbfed8ee6 Auto merge of #131832 - lnicola:sync-from-ra, r=lnicola
Subtree update of `rust-analyzer`

r? `@ghost`
2024-10-17 13:51:48 +00: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
e85a8739ae Auto merge of #129582 - nbdd0121:unwind, r=nnethercote
Make destructors on `extern "C"` frames to be executed

This would make the example in #123231 print "Noisy Drop". I didn't mark this as fixing the issue because the behaviour is yet to be spec'ed.

Tracking:

- https://github.com/rust-lang/rust/issues/74990
2024-10-17 04:34:51 +00: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
bors
0402da4cbf Auto merge of #18265 - kouhe3:master, r=Veykril
Add support for LLDB-DAP
2024-10-14 12:21:42 +00:00
bors
9f1f5cd8f6 Auto merge of #18252 - ShoyuVanilla:issue-15799, r=Veykril
fix: Do not consider mutable usage of deref to `*mut T` as deref_mut

Fixes #15799

We are doing some heuristics for deciding whether the given deref is deref or deref_mut here;

5982d9c420/crates/hir-ty/src/infer/mutability.rs (L182-L200)

But this heuristic is erroneous if we are dereferencing to a mut ptr and normally those cases are filtered out here as builtin;

5982d9c420/crates/hir-ty/src/mir/lower/as_place.rs (L165-L177)

Howerver, this works not so well if the given dereferencing is double dereferencings like the case in the #15799.

```rust
struct WrapPtr(*mut u32);

impl core::ops::Deref for WrapPtr {
    type Target = *mut u32;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

fn main() {
    let mut x = 0u32;
    let wrap = WrapPtr(&mut x);
    unsafe {
        **wrap = 6;
    }
}
```

Here are two - outer and inner - dereferences here, and the outer dereference is marked as deref_mut because there is an assignment operation.
And this deref_mut marking is propagated into the inner dereferencing.
In the later MIR lowering, the outer dereference is filtered out as it's expr type is `*mut u32`, but the expr type in the inner dereference is an ADT, so this false-mutablility is not filtered out.

This PR cuts propagation of this false mutablilty chain if the expr type is mut ptr.
Since this happens before the resolve_all, it may have some limitations when the expr type is determined as mut ptr at the very end of inferencing, but I couldn't find simple fix for it 🤔
2024-10-14 12:07:31 +00:00
bors
513b514818 Auto merge of #18242 - Veykril:veykril/push-tnynzqsmtnqw, r=Veykril
internal: Don't resolve extern crates in import fix point resolution

The fix point loop won't progress them given the potential extern crate candidates are set up at build time.
2024-10-14 11:52:17 +00:00
bors
1e302c81a8 Auto merge of #18229 - mrkajetanp:rustfmt-path, r=Veykril
fix: Join rustfmt overrideCommand with project root

When providing a custom rustfmt command, join it with the project root instead of the workspace root. This fixes rust-analyzer getting the wrong invocation path in projects containing subprojects.

This makes the behaviour consistent with how a custom path provided in rust-analyzer.procMacro.server behaves already.

Resolves issue #18222
2024-10-14 11:37:56 +00:00
bors
574c89155b Auto merge of #18217 - ChayimFriedman2:cast-unknown-ptr, r=Veykril
fix: Comment out cast checks for unknown ptr kind

Just like we don't check for types containing unknown.

Fixes #18214.

See also https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Another.20case.20of.20.2318064.3F.
2024-10-14 11:24:08 +00:00
bors
4717b2bb14 Auto merge of #18152 - CryZe:highlight-async-block-exit-points, r=Veykril
feat: Highlight exit points of async blocks

Async blocks act similar to async functions in that the await keywords are related, but also act like functions where the exit points are related.

Fixes #18147
2024-10-14 11:09:33 +00:00
bors
b5187ab853 Auto merge of #18226 - SabrinaJewson:fix-impl-use, r=Veykril
Correctly parse `use` in generic parameters

Fixes: #18225
2024-10-14 10:40:37 +00:00
bors
1b9e2cb713 Auto merge of #126557 - GrigorenkoPV:vec_track_caller, r=joboet
Add `#[track_caller]` to allocating methods of `Vec` & `VecDeque`

Part 4 in a lengthy saga.
r? `@joshtriplett` because they were the reviewer the last 3 times.
`@bors` rollup=never "[just in case this has perf effects, Vec is hot](https://github.com/rust-lang/rust/pull/79323#issuecomment-731866746)"

This was first attempted in #79323 by `@nvzqz.` It got approval from `@joshtriplett,` but rotted with merge conflicts and got closed.

Then it got picked up by `@Dylan-DPC-zz` in #83359. A benchmark was run[^perf], the results (after a bit of thinking[^thinking]) were deemed ok[^ok], but there was a typo[^typo] and the PR was made from a wrong remote in the first place[^remote], so #83909 was opened instead.

By the time #83909 rolled around, the methods in question had received some optimizations[^optimizations], so another perf run was conducted[^perf2]. The results were ok[^ok2]. There was a suggestion to add regression tests for panic behavior [^tests], but before it could be addressed, the PR fell victim to merge conflicts[^conflicts] and died again[^rip].

3 years have passed, and (from what I can tell) this has not been tried again, so here I am now, reviving this old effort.

Given how much time has passed and the fact that I've also touched `VecDeque` this time, it probably makes sense to
`@bors` try `@rust-timer`

[^perf]: https://github.com/rust-lang/rust/pull/83359#issuecomment-804450095
[^thinking]: https://github.com/rust-lang/rust/pull/83359#issuecomment-805286704
[^ok]: https://github.com/rust-lang/rust/pull/83359#issuecomment-812739031
[^typo]: https://github.com/rust-lang/rust/pull/83359#issuecomment-812750205
[^remote]: https://github.com/rust-lang/rust/pull/83359#issuecomment-814067119
[^optimizations]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813736593
[^perf2]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813825552
[^ok2]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813831341
[^tests]: https://github.com/rust-lang/rust/pull/83909#issuecomment-825788964
[^conflicts]: https://github.com/rust-lang/rust/pull/83909#issuecomment-851173480
[^rip]: https://github.com/rust-lang/rust/pull/83909#issuecomment-873569771
2024-10-14 02:33:40 +00:00
Giga Bowser
43b95ae4fc Add wrap/unwrap return type in Option 2024-10-13 10:53:38 -04:00
bors
e15b6f9005 Auto merge of #125679 - clarfonthey:escape_ascii, r=joboet
Optimize `escape_ascii` using a lookup table

Based upon my suggestion here: https://github.com/rust-lang/rust/pull/125340#issuecomment-2130441817

Effectively, we can take advantage of the fact that ASCII only needs 7 bits to make the eighth bit store whether the value should be escaped or not. This adds a 256-byte lookup table, but 256 bytes *should* be small enough that very few people will mind, according to my probably not incontrovertible opinion.

The generated assembly isn't clearly better (although has fewer branches), so, I decided to benchmark on three inputs: first on a random 200KiB, then on `/bin/cat`, then on `Cargo.toml` for this repo. In all cases, the generated code ran faster on my machine. (an old i7-8700)

But, if you want to try my benchmarking code for yourself:

<details><summary>Criterion code below. Replace <code>/home/ltdk/rustsrc</code> with the appropriate directory.</summary>

```rust
#![feature(ascii_char)]
#![feature(ascii_char_variants)]
#![feature(const_option)]
#![feature(let_chains)]
use core::ascii;
use core::ops::Range;
use criterion::{criterion_group, criterion_main, Criterion};
use rand::{thread_rng, Rng};

const HEX_DIGITS: [ascii::Char; 16] = *b"0123456789abcdef".as_ascii().unwrap();

#[inline]
const fn backslash<const N: usize>(a: ascii::Char) -> ([ascii::Char; N], Range<u8>) {
    const { assert!(N >= 2) };

    let mut output = [ascii::Char::Null; N];

    output[0] = ascii::Char::ReverseSolidus;
    output[1] = a;

    (output, 0..2)
}

#[inline]
const fn hex_escape<const N: usize>(byte: u8) -> ([ascii::Char; N], Range<u8>) {
    const { assert!(N >= 4) };

    let mut output = [ascii::Char::Null; N];

    let hi = HEX_DIGITS[(byte >> 4) as usize];
    let lo = HEX_DIGITS[(byte & 0xf) as usize];

    output[0] = ascii::Char::ReverseSolidus;
    output[1] = ascii::Char::SmallX;
    output[2] = hi;
    output[3] = lo;

    (output, 0..4)
}

#[inline]
const fn verbatim<const N: usize>(a: ascii::Char) -> ([ascii::Char; N], Range<u8>) {
    const { assert!(N >= 1) };

    let mut output = [ascii::Char::Null; N];

    output[0] = a;

    (output, 0..1)
}

/// Escapes an ASCII character.
///
/// Returns a buffer and the length of the escaped representation.
const fn escape_ascii_old<const N: usize>(byte: u8) -> ([ascii::Char; N], Range<u8>) {
    const { assert!(N >= 4) };

    match byte {
        b'\t' => backslash(ascii::Char::SmallT),
        b'\r' => backslash(ascii::Char::SmallR),
        b'\n' => backslash(ascii::Char::SmallN),
        b'\\' => backslash(ascii::Char::ReverseSolidus),
        b'\'' => backslash(ascii::Char::Apostrophe),
        b'\"' => backslash(ascii::Char::QuotationMark),
        0x00..=0x1F => hex_escape(byte),
        _ => match ascii::Char::from_u8(byte) {
            Some(a) => verbatim(a),
            None => hex_escape(byte),
        },
    }
}

/// Escapes an ASCII character.
///
/// Returns a buffer and the length of the escaped representation.
const fn escape_ascii_new<const N: usize>(byte: u8) -> ([ascii::Char; N], Range<u8>) {
    /// Lookup table helps us determine how to display character.
    ///
    /// Since ASCII characters will always be 7 bits, we can exploit this to store the 8th bit to
    /// indicate whether the result is escaped or unescaped.
    ///
    /// We additionally use 0x80 (escaped NUL character) to indicate hex-escaped bytes, since
    /// escaped NUL will not occur.
    const LOOKUP: [u8; 256] = {
        let mut arr = [0; 256];
        let mut idx = 0;
        loop {
            arr[idx as usize] = match idx {
                // use 8th bit to indicate escaped
                b'\t' => 0x80 | b't',
                b'\r' => 0x80 | b'r',
                b'\n' => 0x80 | b'n',
                b'\\' => 0x80 | b'\\',
                b'\'' => 0x80 | b'\'',
                b'"' => 0x80 | b'"',

                // use NUL to indicate hex-escaped
                0x00..=0x1F | 0x7F..=0xFF => 0x80 | b'\0',

                _ => idx,
            };
            if idx == 255 {
                break;
            }
            idx += 1;
        }
        arr
    };

    let lookup = LOOKUP[byte as usize];

    // 8th bit indicates escape
    let lookup_escaped = lookup & 0x80 != 0;

    // SAFETY: We explicitly mask out the eighth bit to get a 7-bit ASCII character.
    let lookup_ascii = unsafe { ascii::Char::from_u8_unchecked(lookup & 0x7F) };

    if lookup_escaped {
        // NUL indicates hex-escaped
        if matches!(lookup_ascii, ascii::Char::Null) {
            hex_escape(byte)
        } else {
            backslash(lookup_ascii)
        }
    } else {
        verbatim(lookup_ascii)
    }
}

fn escape_bytes(bytes: &[u8], f: impl Fn(u8) -> ([ascii::Char; 4], Range<u8>)) -> Vec<ascii::Char> {
    let mut vec = Vec::new();
    for b in bytes {
        let (buf, range) = f(*b);
        vec.extend_from_slice(&buf[range.start as usize..range.end as usize]);
    }
    vec
}

pub fn criterion_benchmark(c: &mut Criterion) {
    let mut group = c.benchmark_group("escape_ascii");

    group.sample_size(1000);

    let rand_200k = &mut [0; 200 * 1024];
    thread_rng().fill(&mut rand_200k[..]);
    let cat = include_bytes!("/bin/cat");
    let cargo_toml = include_bytes!("/home/ltdk/rustsrc/Cargo.toml");

    group.bench_function("old_rand", |b| {
        b.iter(|| escape_bytes(rand_200k, escape_ascii_old));
    });
    group.bench_function("new_rand", |b| {
        b.iter(|| escape_bytes(rand_200k, escape_ascii_new));
    });

    group.bench_function("old_bin", |b| {
        b.iter(|| escape_bytes(cat, escape_ascii_old));
    });
    group.bench_function("new_bin", |b| {
        b.iter(|| escape_bytes(cat, escape_ascii_new));
    });

    group.bench_function("old_cargo_toml", |b| {
        b.iter(|| escape_bytes(cargo_toml, escape_ascii_old));
    });
    group.bench_function("new_cargo_toml", |b| {
        b.iter(|| escape_bytes(cargo_toml, escape_ascii_new));
    });

    group.finish();
}

criterion_group!(benches, criterion_benchmark);
criterion_main!(benches);
```

</details>

My benchmark results:

```
escape_ascii/old_rand   time:   [1.6965 ms 1.7006 ms 1.7053 ms]
Found 22 outliers among 1000 measurements (2.20%)
  4 (0.40%) high mild
  18 (1.80%) high severe
escape_ascii/new_rand   time:   [1.6749 ms 1.6953 ms 1.7158 ms]
Found 38 outliers among 1000 measurements (3.80%)
  38 (3.80%) high mild
escape_ascii/old_bin    time:   [224.59 µs 225.40 µs 226.33 µs]
Found 39 outliers among 1000 measurements (3.90%)
  17 (1.70%) high mild
  22 (2.20%) high severe
escape_ascii/new_bin    time:   [164.86 µs 165.63 µs 166.58 µs]
Found 107 outliers among 1000 measurements (10.70%)
  43 (4.30%) high mild
  64 (6.40%) high severe
escape_ascii/old_cargo_toml
                        time:   [23.397 µs 23.699 µs 24.014 µs]
Found 204 outliers among 1000 measurements (20.40%)
  21 (2.10%) high mild
  183 (18.30%) high severe
escape_ascii/new_cargo_toml
                        time:   [16.404 µs 16.438 µs 16.483 µs]
Found 88 outliers among 1000 measurements (8.80%)
  56 (5.60%) high mild
  32 (3.20%) high severe
```

Random: 1.7006ms => 1.6953ms (<1% speedup)
Binary: 225.40µs => 165.63µs (26% speedup)
Text: 23.699µs => 16.438µs (30% speedup)
2024-10-13 14:05:50 +00:00
roife
b7ed8150a3 feat: respect references.exclude_tests in call-hierarchy 2024-10-13 05:19:28 +08:00
bors
d7628c0a8b Auto merge of #18281 - darichey:async-subprocess, r=lnicola
Run subprocesses async in vscode extension

Extensions should not block the vscode extension host. Replace uses of `spawnSync` with `spawnAsync`, a convenience wrapper around `spawn`.

These `spawnSync`s are unlikely to cause a real issue in practice, because they spawn very short-lived processes, so we aren't blocking for very long. That said, blocking the extension host is poor practice, and if they _do_ block for too long for whatever reason, vscode becomes useless.
2024-10-12 07:45:15 +00:00
bors
b551482c41 Auto merge of #18289 - darichey:fix-relative-buildfiles, r=lnicola
Fix panic when json project has relative buildfile paths

The `build_file` path may be relative to the workspace root.
2024-10-12 07:30:26 +00:00
David Richey
eded3a8e29 Fix panic when json project has relative buildfile paths 2024-10-12 02:25:40 -05:00
bors
5c5a5b0fa8 Auto merge of #131045 - compiler-errors:remove-unnamed_fields, r=wesleywiser
Retire the `unnamed_fields` feature for now

`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.

However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.

Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041

Tracking:
* https://github.com/rust-lang/rust/issues/49804

[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
2024-10-11 13:11:13 +00:00
David Richey
0260e41283 Run subprocesses async in vscode extension 2024-10-10 20:44:13 -05:00
bors
43d42e7e58 Auto merge of #131453 - onur-ozkan:llvm-ci-check-for-rustc-ci, r=Kobzol
disable `download-rustc` if LLVM submodule has changes in CI

We can't use CI rustc while using in-tree LLVM (which happens in LLVM submodule update PRs) and this PR handles that by ignoring CI-rustc in CI and failing in non-CI environments.
2024-10-10 08:31:30 +00:00
bors
c07f824d93 Auto merge of #131466 - matthiaskrgr:rollup-3qtz83x, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #123951 (Reserve guarded string literals (RFC 3593))
 - #130827 (Library: Rename "object safe" to "dyn compatible")
 - #131383 (Add docs about slicing slices at the ends)
 - #131403 (Fix needless_lifetimes in rustc_serialize)
 - #131417 (Fix methods alignment on mobile)
 - #131449 (Decouple WASIp2 sockets from WasiFd)
 - #131462 (Mention allocation errors for `open_buffered`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-10 01:12:11 +00:00
David Richey
3d6acb3d60 Skip #[test_case] expansion 2024-10-09 19:34:08 -05:00
Matthias Krüger
e1694498b5
Rollup merge of #131462 - cuviper:open_buffered-error, r=RalfJung
Mention allocation errors for `open_buffered`

This documents that `File::open_buffered` may return an error on allocation failure.
2024-10-09 23:03:50 +02:00