Commit graph

31875 commits

Author SHA1 Message Date
bors
ab2c8412f6 Auto merge of #130987 - thejpster:revise-arm-platform-notes-soft-float, r=ehuss
Revise arm platform notes regarding soft float

This PR updates the Arm microcontroller platform docs to recommend `-fpregs` instead of `+soft-float` as [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60-Ctarget-feature.3D.2Bsoft-float.60.20considered.20harmful)
2024-10-21 14:31:44 +00:00
bors
c610286d8b Auto merge of #130628 - workingjubilee:clean-up-result-ffi-guarantees, r=RalfJung
Finish stabilization of `result_ffi_guarantees`

The internal linting has been changed, so all that is left is making sure we stabilize what we want to stabilize.
2024-10-21 08:38:45 +00:00
bors
3fcc523a39 Auto merge of #130950 - compiler-errors:yeet-eval, r=BoxyUwU
Continue to get rid of `ty::Const::{try_}eval*`

This PR mostly does:

* Removes all of the `try_eval_*` and `eval_*` helpers from `ty::Const`, and replace their usages with `try_to_*`.
* Remove `ty::Const::eval`.
* Rename `ty::Const::normalize` to `ty::Const::normalize_internal`. This function is still used in the normalization code itself.
* Fix some weirdness around the `TransmuteFrom` goal.

I'm happy to split it out further; for example, I could probably land the first part which removes the helpers, or the changes to codegen which are more obvious than the changes to tools.

r? BoxyUwU

Part of https://github.com/rust-lang/rust/issues/130704
2024-10-21 03:46:28 +00:00
bors
bf1f48372a Auto merge of #120869 - devnexen:update_fbsd_ci, r=Mark-Simulacrum
ci update freebsd version proposal, freebsd 12 being eol

raising to the lowest still active supported freebsd version.
From 13.1 (already eol too), freebsd introduces a cpu affinity layer
with linux. It also introduces a api compatible copy_file_range which
can be used like its linux's counterpart.
The former is essential to build https://github.com/rust-lang/rust/pull/120589, therefore breaks the backward
compatibility with the previous FreeBSD releases.

Blocked on https://github.com/rust-lang/rust/issues/130465
2024-10-21 00:13:09 +00:00
bors
0143324a70 Auto merge of #131957 - GuillaumeGomez:rm-unused, r=notriddle
Remove unused `recoverable` argument in collect_intra_doc_links

r? `@notriddle`
2024-10-20 05:58:20 +00:00
bors
a5901dc75e Auto merge of #131958 - Zalathar:rollup-gkuk3n1, r=Zalathar
Rollup of 4 pull requests

Successful merges:

 - #131876 (compiler: Use LLVM's Comdat support)
 - #131941 (compiletest: disambiguate html-tidy from rust tidy tool)
 - #131942 (compiler: Adopt rust-analyzer impls for `LayoutCalculatorError`)
 - #131945 (rustdoc: Clean up footnote handling)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-20 03:34:09 +00:00
Stuart Cook
6c07d1e40d
Rollup merge of #131945 - aDotInTheVoid:footnote-time, r=notriddle
rustdoc: Clean up footnote handling

Best reviewed commit by commit.

Extracts footnote handling logic into it's own file (first commit) and then makes that file slightly nicer to read/understand.

No functional changes, but lays the groundwork for making more changes to footnotes (eg #131901, #131946)
2024-10-20 14:06:05 +11:00
Stuart Cook
d6350f60f7
Rollup merge of #131942 - workingjubilee:reduce-haruspicy, r=lukas-code,lnicola
compiler: Adopt rust-analyzer impls for `LayoutCalculatorError`

We're about to massively churn the internals of `rustc_abi`. To minimize the immediate and future impact on rust-analyzer, as a subtree that depends on this crate, grow some API on `LayoutCalculatorError` that reflects their uses of it. This way we can nest the type in theirs, and they can just call functions on it without having to inspect and flatten-out its innards.
2024-10-20 14:06:04 +11:00
Stuart Cook
405740c4a8
Rollup merge of #131941 - lolbinarycat:compiletest-need-html-tidy, r=clubby789
compiletest: disambiguate html-tidy from rust tidy tool

when i first saw this error message i was very confused, i thought it was talking about `src/tools/tidy`.  now it should be much more clear what tool should be installed.
2024-10-20 14:06:03 +11:00
Stuart Cook
39251759dc
Rollup merge of #131876 - workingjubilee:llvm-c-c-c-comdat, r=Zalathar
compiler: Use LLVM's Comdat support

Acting on these long-ago issues:
- https://github.com/rust-lang/rust/issues/46437
- https://github.com/rust-lang/rust/issues/68955
2024-10-20 14:06:03 +11:00
Jubilee Young
90ec8053c2 rust-analyzer: Nest LayoutCalculatorError in hir_ty::LayoutError 2024-10-19 11:09:24 -07:00
bors
652565f8f1 Auto merge of #131211 - bjorn3:rust_abi_follow_c_rules, r=nikic,jieyouxu
Return values larger than 2 registers using a return area pointer

LLVM and Cranelift disagree about how to return values that don't fit in the registers designated for return values. LLVM will force the entire return value to be passed by return area pointer, while Cranelift will look at each IR level return value independently and decide to pass it in a register or not, which would result in the return value being passed partially in registers and partially through a return area pointer.

While Cranelift may need to be fixed as the LLVM behavior is generally more correct with respect to the surface language, forcing this behavior in rustc itself makes it easier for other backends to conform to the Rust ABI and for the C ABI rustc already handles this behavior anyway.

In addition LLVM's decision to pass the return value in registers or using a return area pointer depends on how exactly the return type is lowered to an LLVM IR type. For example `Option<u128>` can be lowered as `{ i128, i128 }` in which case the x86_64 backend would use a return area pointer, or it could be passed as `{ i32, i128 }` in which case the x86_64 backend would pass it in registers by taking advantage of an LLVM ABI extension that allows using 3 registers for the x86_64 sysv call conv rather than the officially specified 2 registers.

This adjustment is only necessary for the Rust ABI as for other ABI's the calling convention implementations in rustc_target already ensure any return value which doesn't fit in the available amount of return registers is passed in the right way for the current target.

Helps with https://github.com/rust-lang/rustc_codegen_cranelift/issues/1525
cc https://github.com/bytecodealliance/wasmtime/issues/9250
2024-10-19 14:21:46 +00:00
bors
d908c3d6f5 Auto merge of #131816 - Zalathar:profiler-feature, r=Kobzol
Make `profiler_builtins` an optional dependency of sysroot, not std

This avoids unnecessary rebuilds of std (and the compiler) when `build.profiler` is toggled off or on.

Fixes #131812.

---

Background: The `profiler_builtins` crate has been an optional dependency of std (behind a cargo feature) ever since it was added back in #42433. But as far as I can tell that has only ever been a convenient way to force the crate to be built, not a genuine dependency.

The side-effect of this false dependency is that toggling `build.profiler` causes a rebuild of std and the compiler, which shouldn't be necessary. This PR therefore makes `profiler_builtins` an optional dependency of the dummy sysroot crate (#108865), rather than a dependency of std.

What makes this change so small is that all of the necessary infrastructure already exists. Previously, bootstrap would enable the `profiler` feature on the sysroot crate, which would forward that feature to std. Now, enabling that feature directly enables sysroot's `profiler_builtins` dependency instead.

---

I believe this is more of a bootstrap change than a libs change, so tentatively:
r? bootstrap
2024-10-19 10:55:40 +00:00
bors
85239cafab Auto merge of #131362 - Kobzol:ci-free-runners-linux-4c, r=Mark-Simulacrum
CI: use free runners for 4-core Linux jobs

It looks like the [free runners](https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories) already have the same spec as the `4c` custom "large" runner (4 cores, 16 GiB of memory, Ubuntu 20.04).

try-job: arm-android
try-job: armhf-gnu
try-job: dist-aarch64-linux
try-job: dist-android
try-job: dist-arm-linux
try-job: dist-armhf-linux
try-job: dist-armv7-linux
try-job: dist-i586-gnu-i586-i686-musl
try-job: dist-i686-linux
try-job: dist-loongarch64-linux
try-job: dist-loongarch64-musl
try-job: dist-ohos
try-job: dist-powerpc-linux
try-job: dist-powerpc64-linux
try-job: dist-powerpc64le-linux
try-job: dist-riscv64-linux
try-job: dist-s390x-linux
try-job: dist-various-1
try-job: dist-various-2
try-job: dist-x86_64-freebsd
try-job: dist-x86_64-illumos
try-job: dist-x86_64-netbsd
try-job: mingw-check
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-gnu-stable
try-job: x86_64-gnu-aux
try-job: x86_64-gnu-debug
try-job: x86_64-gnu-nopt
2024-10-18 08:24:09 +00:00
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
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
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
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
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