Commit Graph

13862 Commits

Author SHA1 Message Date
Matthias Krüger
f6b699c9c0
Rollup merge of #131595 - fmease:rustdoc-json-mv-obj-safe-dyn-compat, r=aDotInTheVoid
rustdoc-JSON: Rename "object safe" to "dyn compatible"

~~Blocked: Sits atop #131594. Only the last commit is relevant.~~ (rebased)

Part of #130852.

r? aDotInTheVoid or rustdoc
2024-10-17 12:07:20 +02:00
Matthias Krüger
21c57f5490
Rollup merge of #128391 - cafce25:issue-128390, r=lcnr
Change orphan hint from "only" to "any uncovered type inside..."

Fix #128390
2024-10-17 12:07:19 +02:00
lcnr
6cf4cb8484 bless mir-opt tests 2024-10-17 10:22:55 +02:00
Julian Frimmel
a35ed2f9eb
Use rust-lld instead of avr-gcc as the linker
This fixes the [build error] caused by the `avr-gcc` (used as linker)
not being available in the Rust CI. This is a viable solution, which
shows the wrong/right behavior and, since no functions from `libgcc` are
called, does not produce errors. This was discussed [here]. Another
small problem is, that `lld` doesn't link the correct startup-code by
default. This is not a problem for this test (since it does not actually
use anything the startup code is needed for (no variables, no stack, no
interrupts)), but this causes the `main`-function to be removed by the
default flag `--gc-sections`. Therefore the `rmake`-driver also adds the
linker flag `--entry=main` to mark the `main`-function as the entry
point and thus preventing it from getting removed. The code would work
on a real AVR device.

[build error]: https://github.com/rust-lang/rust/pull/131755#issuecomment-2415127952
[here]: https://github.com/rust-lang/rust/pull/131755#issuecomment-2416469675
2024-10-17 09:00:08 +02:00
bors
06d261daf6 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
beetrees
3ea91c05db
Always specify llvm_abiname for RISC-V targets 2024-10-17 02:07:02 +01:00
León Orell Valerian Liehr
2e6f3bd1d3
rustdoc-JSON: Rename "object safe" to "dyn compatible" 2024-10-16 23:00:49 +02:00
bors
798fb83f7d Auto merge of #131797 - matthiaskrgr:rollup-lzpze2k, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #130989 (Don't check unsize goal in MIR validation when opaques remain)
 - #131657 (Rustfmt `for<'a> async` correctly)
 - #131691 (Delay ambiguous intra-doc link resolution after `Cache` has been populated)
 - #131730 (Refactor some `core::fmt` macros)
 - #131751 (Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe)
 - #131753 (Unify `secondary_span` and `swap_secondary_and_primary` args in `note_type_err`)
 - #131776 (Emscripten: Xfail backtrace ui tests)
 - #131777 (Fix trivially_copy_pass_by_ref in stable_mir)
 - #131778 (Fix needless_lifetimes in stable_mir)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-16 20:50:53 +00:00
Matthew Maurer
0e73095169 llvm: Tolerate propagated range metadata
llvm/llvm-project#91101 propagates range information across inlining,
resulting in more metadata in this test. Tolerate the range metadata if
it appears.
2024-10-16 18:38:26 +00:00
Matthias Krüger
c8ec8e6989
Rollup merge of #131776 - hoodmane:emscripten-xfail-backtrace-tests, r=jieyouxu
Emscripten: Xfail backtrace ui tests

It is possible to link libunwind and use the normal backtrace code, but it fails to symbolize stack traces. I investigated and could get the list of instruction pointers and symbol names, but I'm not sure how to use the dwarf info to map from instruction pointer to source location. In any case, fixing this is not a high priority.

See https://github.com/rust-lang/rust/issues/131738

r?jieyouxu
2024-10-16 20:15:55 +02:00
Matthias Krüger
3b8fd5f895
Rollup merge of #131751 - compiler-errors:structurally-resolve, r=lcnr
Rename `can_coerce` to `may_coerce`, and then structurally resolve correctly in the probe

We need to structurally resolve the lhs and rhs of the coercion. Also, renaming the method so it's less ambiguous about what it's doing... the word "may" gives more clear signal that it has false positives imo.

r? lcnr
2024-10-16 20:15:54 +02:00
Matthias Krüger
87c31feab8
Rollup merge of #131691 - GuillaumeGomez:intra-doc-link-filter-out-2, r=notriddle
Delay ambiguous intra-doc link resolution after `Cache` has been populated

Fixes https://github.com/rust-lang/rust/issues/130233.

I was getting nowhere with #130278. I took a wrong turn at some point and ended making way too many changes so instead I started again back from 0 and this time it worked out as expected.

r? ```@notriddle```
2024-10-16 20:15:53 +02:00
Matthias Krüger
b6a085a16e
Rollup merge of #130989 - compiler-errors:unsize-opaque, r=estebank
Don't check unsize goal in MIR validation when opaques remain

Similarly to `mir_assign_valid_types`, let's just skip when there are opaques. Fixes #130921.
2024-10-16 20:15:52 +02:00
bors
7342830c05 Auto merge of #131792 - matthiaskrgr:rollup-480nwg4, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #130822 (Add `from_ref` and `from_mut` constructors to `core::ptr::NonNull`.)
 - #131381 (Implement edition 2024 match ergonomics restrictions)
 - #131594 (rustdoc: Rename "object safe" to "dyn compatible")
 - #131686 (Add fast-path when computing the default visibility)
 - #131699 (Try to improve error messages involving aliases in the solver)
 - #131757 (Ignore lint-non-snake-case-crate#proc_macro_ on targets without unwind)
 - #131783 (Fix explicit_iter_loop in rustc_serialize)
 - #131788 (Fix mismatched quotation mark)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-16 17:58:25 +00:00
Michael Goulet
99d5f3b280 Stop inverting expectation in normalization errors 2024-10-16 13:44:56 -04:00
Matthias Krüger
06cd22ceab
Rollup merge of #131788 - dufucun:master, r=lqd
Fix mismatched quotation mark
2024-10-16 19:18:33 +02:00
Matthias Krüger
1014970462
Rollup merge of #131757 - c6c7:fixup-lint-non-snake-case-crate, r=jieyouxu
Ignore lint-non-snake-case-crate#proc_macro_ on targets without unwind

The lint-non-snake-case-crate test may emit a warning in stderr if the target does not support unwinding

```
warning: building proc macro crate with `panic=abort` may crash the compiler should the proc-macro panic
```

Consequently, the test will fail on targets that don't support unwinding as written.

This change modifies the expected stderr for lint-non-snake-case-crate in the proc_macro_ to ignore lines that indicate a warning was emitted.
2024-10-16 19:18:32 +02:00
Matthias Krüger
aac91f75e3
Rollup merge of #131699 - compiler-errors:better-errors-for-projections, r=lcnr
Try to improve error messages involving aliases in the solver

1. Treat aliases as rigid only if it may not be defined and it's well formed (i.e. for projections, its trait goal is satisfied).
2. Record goals that are related to alias normalization under a new `GoalKind`, so we can look into them in the `BestObligation` visitor.
3. Try to deduplicate errors due to self types of goals that are un-normalizable aliases.

r? lcnr
2024-10-16 19:18:32 +02:00
Matthias Krüger
70477487b1
Rollup merge of #131594 - fmease:rustdoc-mv-obj-safe-dyn-compat, r=notriddle
rustdoc: Rename "object safe" to "dyn compatible"

Supersedes #126554:

1. In line with [T-lang's latest resolution](https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118).
2. More comprehensive: Not only updates user-facing text but also source code.

Part of #130852.

Doesn't update rustdoc-JSON (will be filed separately).

r? `@notriddle` (rust-lang/lang-team#286) `@GuillaumeGomez` (for visibility)
2024-10-16 19:18:31 +02:00
Matthias Krüger
c1ed1f133e
Rollup merge of #131381 - Nadrieril:min-match-ergonomics, r=pnkfelix
Implement edition 2024 match ergonomics restrictions

This implements the minimalest version of [match ergonomics for edition 2024](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html). This minimal version makes it an error to ever reset the default binding mode. The implemented proposal is described precisely [here](https://hackmd.io/zUqs2ISNQ0Wrnxsa9nhD0Q#RFC-3627-nano), where it is called "RFC 3627-nano".

Rules:
- Rule 1C: When the DBM (default binding mode) is not `move` (whether or not behind a reference), writing `mut`, `ref`, or `ref mut` on a binding is an error.
- Rule 2C: Reference patterns can only match against references in the scrutinee when the DBM is `move`.

This minimal version is forward-compatible with the main proposals for match ergonomics 2024: [RFC3627](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html) itself, the alternative [rule 4-early variant](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html), and [others](https://hackmd.io/zUqs2ISNQ0Wrnxsa9nhD0Q). The idea is to give us more time to iron out a final proposal.

This includes a migration lint that desugars any offending pattern into one that doesn't make use of match ergonomics. Such patterns have identical meaning across editions.

This PR insta-stabilizes the proposed behavior onto edition 2024.

r? `@ghost`

Tracking:

- https://github.com/rust-lang/rust/issues/123076
2024-10-16 19:18:30 +02:00
Matthias Krüger
1817de609b
Rollup merge of #130822 - bjoernager:non-null-from-ref, r=dtolnay
Add `from_ref` and `from_mut` constructors to `core::ptr::NonNull`.

Relevant tracking issue: #130823

The `core::ptr::NonNull` type should have the convenience constructors `from_ref` and `from_mut` for parity with `core::ptr::from_ref` and `core::ptr::from_mut`.

Although the type in question already implements `From<&T>` and `From<&mut T>`, these new functions also carry the ability to be used in constant expressions (due to not being behind a trait).
2024-10-16 19:18:30 +02:00
Julian Frimmel
bb8db13892
Simplify test and make it more reliable
The new `rmake`-content asserts the exact assembly sequence for the loop
preventing false-negatives if some instructions would change and thus
the label offset might need to change.
2024-10-16 18:58:17 +02:00
Julian Frimmel
ab008414d4
Convert to a rmake-test
Since the `tests/assembly` use `emit=asm`, the issue is not observable
as reported in the linked issue. Therefore the existing test case is
converted and a simple `rmake`-test is added. The test only checks, if
the correct `rjmp`-offset is used.
2024-10-16 18:58:17 +02:00
dufucun
682bca30cc
Fix mismatched quotation mark 2024-10-17 00:16:19 +08:00
Charles Celerier
8991fd4bed Ignore lint-non-snake-case-crate#proc_macro_ on targets without unwind
The lint-non-snake-case-crate test may emit a warning in stderr if the
target does not support unwinding

```
warning: building proc macro crate with `panic=abort` may crash the compiler should the proc-macro panic
```

Consequently, the test will fail on targets that don't support unwinding
as written.

This change prevents lint-non-snake-case-crate#proc_macro_ from running
on targets that don't support unwind by using the needs-unwind
directive.
2024-10-16 10:55:49 -04:00
bors
bed75e7c21 Auto merge of #131767 - cuviper:bump-stage0, r=Mark-Simulacrum
Bump bootstrap compiler to 1.83.0-beta.1

https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday
2024-10-16 14:40:08 +00:00
León Orell Valerian Liehr
6d82559bc1
rustdoc: Rename "object safe" to "dyn compatible" 2024-10-16 15:53:49 +02:00
Hood Chatham
476ea45c68 Emscripten: Xfail backtrace ui tests
It is possible to link libunwind and use the normal backtrace code, but it fails
to symbolize stack traces. I investigated and could get the list of instruction
pointers and symbol names, but I'm not sure how to use the dwarf info to map
from instruction pointer to source location. In any case, fixing this is
probably not a high priority.

See https://github.com/rust-lang/rust/issues/131738
2024-10-16 12:22:14 +02:00
Urgau
e0e1e35a48
Rollup merge of #131771 - Urgau:cfg-target-131759, r=jieyouxu
Handle gracefully true/false in `cfg(target(..))` compact

This PR handles gracefully `true`/`false` in `cfg(target(..))` compact instead of ICE.

r? `@nnethercote`
Fixes #131759
2024-10-16 12:03:45 +02:00
Urgau
43a142e4d0
Rollup merge of #131764 - Zalathar:double-dir, r=jieyouxu
Fix unnecessary nesting in run-make test output directories

Run-make tests were using `output_base_name` to determine their output directory, which results in a redundant subdirectory (e.g. `$build/test/run-make/<foo>/<foo>/`) because that method is intended to produce the name of an individual file.

The previous attempt to fix this double-nesting tried adding a special case in `output_base_dir`, which had the side-effect of breaking up-to-date checking for run-make tests, and had to be reverted in #131681.

The fix is simply to call `output_base_dir` directory, which gives the desired directory without any redundant part.

r? jieyouxu
2024-10-16 12:03:44 +02:00
Urgau
329e570460
Rollup merge of #131754 - compiler-errors:bivariance-bivariance, r=estebank
Don't report bivariance error when nesting a struct with field errors into another struct

We currently have logic to avoid reporting lifetime bivariance ("lifetime parameter ... is never used") errors when a struct has field resolution errors. However, this doesn't apply transitively. This PR implements a simple visitor to do so.

This was reported [here](https://twitter.com/fasterthanlime/status/1846257921086165033) since a `derive(Deserialize, Serialize)` ends up generating helper structs which have bivariant lifetimes due to containing the offending struct (that's being derived on).
2024-10-16 12:03:43 +02:00
Urgau
5eb8636989 Handle gracefully true/false in cfg(target(..)) compact 2024-10-16 09:41:49 +02:00
bors
1f67a7aa8d 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
Josh Stone
acb09bf741 update bootstrap configs 2024-10-15 20:30:23 -07:00
Zalathar
4cf0475eeb Fix unnecessary nesting in run-make test output directories 2024-10-16 12:40:25 +11:00
Michael Goulet
c7730989de Don't check unsize goal in MIR validation when opaques remain 2024-10-15 21:01:42 -04:00
Michael Goulet
9070abab4b Structurally resolve in may_coerce 2024-10-15 20:44:39 -04:00
Michael Goulet
e3eba2d920 Don't structurally resolve in may_coerce 2024-10-15 20:44:39 -04:00
Michael Goulet
f956dc2e77 Bless tests 2024-10-15 20:42:17 -04:00
Michael Goulet
0ead25c4a9 Register a dummy candidate for failed structural normalization during candiate assembly 2024-10-15 20:42:17 -04:00
Michael Goulet
8528387743 Be better at reporting alias errors 2024-10-15 20:42:17 -04:00
Michael Goulet
fd2038d344 Make sure the alias is actually rigid 2024-10-15 20:42:17 -04:00
bors
e7c0d27507 Auto merge of #131747 - compiler-errors:rollup-0fnymws, r=compiler-errors
Rollup of 7 pull requests

Successful merges:

 - #129794 (uefi: Implement getcwd and chdir)
 - #130568 (Make some float methods unstable `const fn`)
 - #131521 (rename RcBox to RcInner for consistency)
 - #131701 (Don't report `on_unimplemented` message for negative traits)
 - #131705 (Fix most ui tests on emscripten target)
 - #131733 (Fix uninlined_format_args in stable_mir)
 - #131734 (Update `arm64e-apple-tvos` maintainer)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-15 19:55:10 +00:00
Michael Goulet
68885216b6 Don't report bivariance error when nesting a struct with field errors into another struct 2024-10-15 14:58:54 -04:00
Michael Goulet
fc1ad2e21c
Rollup merge of #131705 - hoodmane:fix-emscripten-tests, r=jieyouxu
Fix most ui tests on emscripten target

To fix the linker errors, we need to set the output extension to `.js` instead of `.wasm`. Setting the output to a `.wasm` file puts Emscripten into standalone mode which is effectively a distinct target. We need to set the runner to be `node` as well.

This fixes most of the ui tests. I fixed 4 additional tests with simple problems:

- `intrinsics/intrinsic-alignment.rs` -- Two `#[cfg]` macros match for Emscripten so we got duplicate definition
- `structs-enums/rec-align-u64.rs` -- same problem
- `issues/issue-12699.rs` -- hangs so I disabled it
- `process/process-sigpipe.rs` -- Not expected to work on Emscripten so I disabled it

Resolves #131666.

There are 7 more failing tests. I'll try to investigate more and see if I can fix them or at least understand why they happen.

- abi/numbers-arithmetic/return-float.rs (problem with [wasm treatment of noncanonical floats](https://webassembly.github.io/spec/core/exec/numerics.html#nan-propagation)?)
- async-await/issue-60709.rs -- linker error related to memcpy. Possible Emscripten bug?
- backtrace/dylib-dep.rs -- Says "Not supported"
- backtrace/line-tables-only.rs -- Says "Not supported"
- no_std/no-std-unwind-binary.rs -- compiler says `error: lang item required, but not found: eh_catch_typeinfo`
- structs-enums/enum-rec/issue-17431-6.rs -- One of the two compiler errors is missing
- test-attrs/test-passed.rs

    r?workingjubilee r?jieyouxu
2024-10-15 12:33:37 -04:00
Michael Goulet
6558e3470b
Rollup merge of #131701 - compiler-errors:negative-bounds-on-unimplemented, r=lcnr
Don't report `on_unimplemented` message for negative traits

Kinda useless change but it was affecting my ability to read error messages when experimenting with negative bounds.
2024-10-15 12:33:36 -04:00
Michael Goulet
1c799ff05e
Rollup merge of #131521 - jdonszelmann:rc, r=joboet
rename RcBox to RcInner for consistency

Arc uses ArcInner too (created in collaboration with `@aDotInTheVoid` and `@WaffleLapkin` )
2024-10-15 12:33:36 -04:00
Michael Goulet
2f3f001423
Rollup merge of #130568 - eduardosm:const-float-methods, r=RalfJung,tgross35
Make some float methods unstable `const fn`

Some float methods are now `const fn` under the `const_float_methods` feature gate.

I also made some unstable methods `const fn`, keeping their constness under their respective feature gate.

In order to support `min`, `max`, `abs` and `copysign`, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval (cc `@RalfJung).`

Tracking issue: https://github.com/rust-lang/rust/issues/130843

```rust
impl <float> {
    // #[feature(const_float_methods)]
    pub const fn recip(self) -> Self;
    pub const fn to_degrees(self) -> Self;
    pub const fn to_radians(self) -> Self;
    pub const fn max(self, other: Self) -> Self;
    pub const fn min(self, other: Self) -> Self;
    pub const fn clamp(self, min: Self, max: Self) -> Self;
    pub const fn abs(self) -> Self;
    pub const fn signum(self) -> Self;
    pub const fn copysign(self, sign: Self) -> Self;

    // #[feature(float_minimum_maximum)]
    pub const fn maximum(self, other: Self) -> Self;
    pub const fn minimum(self, other: Self) -> Self;

    // Only f16/f128 (f32/f64 already const)
    pub const fn is_sign_positive(self) -> bool;
    pub const fn is_sign_negative(self) -> bool;
    pub const fn next_up(self) -> Self;
    pub const fn next_down(self) -> Self;
}
```

r? libs-api

try-job: dist-s390x-linux
2024-10-15 12:33:35 -04:00
bors
a0c2aba29a Auto merge of #130654 - lcnr:stabilize-coherence-again, r=compiler-errors
stabilize `-Znext-solver=coherence` again

r? `@compiler-errors`

---

This PR stabilizes the use of the next generation trait solver in coherence checking by enabling `-Znext-solver=coherence` by default. More specifically its use in the *implicit negative overlap check*. The tracking issue for this is https://github.com/rust-lang/rust/issues/114862. Closes #114862.

This is a direct copy of #121848 which has been reverted due to a hang in `nalgebra`: #130056. This hang should have been fixed by #130617 and #130821. See the added section in the stabilization report containing user facing changes merged since the original FCP.

## Background

### The next generation trait solver

The new solver lives in [`rustc_trait_selection::solve`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/solve/mod.rs) and is intended to replace the existing *evaluate*, *fulfill*, and *project* implementation. It also has a wider impact on the rest of the type system, for example by changing our approach to handling associated types.

For a more detailed explanation of the new trait solver, see the [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/solve/trait-solving.html). This does not stabilize the current behavior of the new trait solver, only the behavior impacting the implicit negative overlap check. There are many areas in the new solver which are not yet finalized. We are confident that their final design will not conflict with the user-facing behavior observable via coherence. More on that further down.

Please check out [the chapter](https://rustc-dev-guide.rust-lang.org/solve/significant-changes.html) summarizing the most significant changes between the existing and new implementations.

### Coherence and the implicit negative overlap check

Coherence checking detects any overlapping impls. Overlapping trait impls always error while overlapping inherent impls result in an error if they have methods with the same name. Coherence also results in an error if any other impls could exist, even if they are currently unknown. This affects impls which may get added to upstream crates in a backwards compatible way and impls from downstream crates.

Coherence failing to detect overlap is generally considered to be unsound, even if it is difficult to actually get runtime UB this way. It is quite easy to get ICEs due to bugs in coherence.

It currently consists of two checks:

The [orphan check] validates that impls do not overlap with other impls we do not know about: either because they may be defined in a sibling crate, or because an upstream crate is allowed to add it without being considered a breaking change.

The [overlap check] validates that impls do not overlap with other impls we know about. This is done as follows:
- Instantiate the generic parameters of both impls with inference variables
- Equate the `TraitRef`s of both impls. If it fails there is no overlap.
- [implicit negative]: Check whether any of the instantiated `where`-bounds of one of the impls definitely do not hold when using the constraints from the previous step. If a `where`-bound does not hold, there is no overlap.
- *explicit negative (still unstable, ignored going forward)*: Check whether the any negated `where`-bounds can be proven, e.g. a `&mut u32: Clone` bound definitely does not hold as an explicit `impl<T> !Clone for &mut T` exists.

The overlap check has to *prove that unifying the impls does not succeed*. This means that **incorrectly getting a type error during coherence is unsound** as it would allow impls to overlap: coherence has to be *complete*.

Completeness means that we never incorrectly error. This means that during coherence we must only add inference constraints if they are definitely necessary. During ordinary type checking [this does not hold](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=01d93b592bd9036ac96071cbf1d624a9), so the trait solver has to behave differently, depending on whether we're in coherence or not.

The implicit negative check only considers goals to "definitely not hold" if they could not be implemented downstream, by a sibling, or upstream in a backwards compatible way. If the goal is is "unknowable" as it may get added in another crate, we add an ambiguous candidate: [source](bea5bebf3d/compiler/rustc_trait_selection/src/solve/assembly/mod.rs (L858-L883)).

[orphan check]: fd80c02c16/compiler/rustc_trait_selection/src/traits/coherence.rs (L566-L579)
[overlap check]: fd80c02c16/compiler/rustc_trait_selection/src/traits/coherence.rs (L92-L98)
[implicit negative]: fd80c02c16/compiler/rustc_trait_selection/src/traits/coherence.rs (L223-L281)

## Motivation

Replacing the existing solver in coherence fixes soundness bugs by removing sources of incompleteness in the type system. The new solver separately strengthens coherence, resulting in more impls being disjoint and passing the coherence check. The concrete changes will be elaborated further down. We believe the stabilization to reduce the likelihood of future bugs in coherence as the new implementation is easier to understand and reason about.

It allows us to remove the support for coherence and implicit-negative reasoning in the old solver, allowing us to remove some code and simplifying the old trait solver. We will only remove the old solver support once this stabilization has reached stable to make sure we're able to quickly revert in case any unexpected issues are detected before then.

Stabilizing the use of the next-generation trait solver expresses our confidence that its current behavior is intended and our work towards enabling its use everywhere will not require any breaking changes to the areas used by coherence checking. We are also confident that we will be able to replace the existing solver everywhere, as maintaining two separate systems adds a significant maintainance burden.

## User-facing impact and reasoning

### Breakage due to improved handling of associated types

The new solver fixes multiple issues related to associated types. As these issues caused coherence to consider more types distinct, fixing them results in more overlap errors. This is therefore a breaking change.

#### Structurally relating aliases containing bound vars

Fixes https://github.com/rust-lang/rust/issues/102048. In the existing solver relating ambiguous projections containing bound variables is structural. This is *incomplete* and allows overlapping impls. These was mostly not exploitable as the same issue also caused impls to not apply when trying to use them. The new solver defers alias-relating to a nested goal, fixing this issue:
```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait Trait {}

trait Project {
    type Assoc<'a>;
}

impl Project for u32 {
    type Assoc<'a> = &'a u32;
}

// Eagerly normalizing `<?infer as Project>::Assoc<'a>` is ambiguous,
// so the old solver ended up structurally relating
//
//     (?infer, for<'a> fn(<?infer as Project>::Assoc<'a>))
//
// with
//
//     ((u32, fn(&'a u32)))
//
// Equating `&'a u32` with `<u32 as Project>::Assoc<'a>` failed, even
// though these types are equal modulo normalization.
impl<T: Project> Trait for (T, for<'a> fn(<T as Project>::Assoc<'a>)) {}

impl<'a> Trait for (u32, fn(&'a u32)) {}
//[next]~^ ERROR conflicting implementations of trait `Trait` for type `(u32, for<'a> fn(&'a u32))`
```

A crater run did not discover any breakage due to this change.

#### Unknowable candidates for higher ranked trait goals

This avoids an unsoundness by attempting to normalize in `trait_ref_is_knowable`, fixing https://github.com/rust-lang/rust/issues/114061. This is a side-effect of supporting lazy normalization, as that forces us to attempt to normalize when checking whether a `TraitRef` is knowable: [source](47dd709bed/compiler/rustc_trait_selection/src/solve/assembly/mod.rs (L754-L764)).

```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait IsUnit {}
impl IsUnit for () {}

pub trait WithAssoc<'a> {
    type Assoc;
}

// We considered `for<'a> <T as WithAssoc<'a>>::Assoc: IsUnit`
// to be knowable, even though the projection is ambiguous.
pub trait Trait {}
impl<T> Trait for T
where
    T: 'static,
    for<'a> T: WithAssoc<'a>,
    for<'a> <T as WithAssoc<'a>>::Assoc: IsUnit,
{
}
impl<T> Trait for Box<T> {}
//[next]~^ ERROR conflicting implementations of trait `Trait`
```
The two impls of `Trait` overlap given the following downstream crate:
```rust
use dep::*;
struct Local;
impl WithAssoc<'_> for Box<Local> {
    type Assoc = ();
}
```

There a similar coherence unsoundness caused by our handling of aliases which is fixed separately in https://github.com/rust-lang/rust/pull/117164.

This change breaks the [`derive-visitor`](https://crates.io/crates/derive-visitor) crate. I have opened an issue in that repo: nikis05/derive-visitor#16.

### Evaluating goals to a fixpoint and applying inference constraints

In the old implementation of the implicit-negative check, each obligation is [checked separately without applying its inference constraints](bea5bebf3d/compiler/rustc_trait_selection/src/traits/coherence.rs (L323-L338)). The new solver instead [uses a `FulfillmentCtxt`](bea5bebf3d/compiler/rustc_trait_selection/src/traits/coherence.rs (L315-L321)) for this, which evaluates all obligations in a loop until there's no further inference progress.

This is necessary for backwards compatibility as we do not eagerly normalize with the new solver, resulting in constraints from normalization to only get applied by evaluating a separate obligation. This also allows more code to compile:
```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait Mirror {
    type Assoc;
}
impl<T> Mirror for T {
    type Assoc = T;
}

trait Foo {}
trait Bar {}

// The self type starts out as `?0` but is constrained to `()`
// due to the where-clause below. Because `(): Bar` is known to
// not hold, we can prove the impls disjoint.
impl<T> Foo for T where (): Mirror<Assoc = T> {}
//[current]~^ ERROR conflicting implementations of trait `Foo` for type `()`
impl<T> Foo for T where T: Bar {}

fn main() {}
```
The old solver does not run nested goals to a fixpoint in evaluation. The new solver does do so, strengthening inference and improving the overlap check:
```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait Foo {}
impl<T> Foo for (u8, T, T) {}
trait NotU8 {}
trait Bar {}
impl<T, U: NotU8> Bar for (T, T, U) {}

trait NeedsFixpoint {}
impl<T: Foo + Bar> NeedsFixpoint for T {}
impl NeedsFixpoint for (u8, u8, u8) {}

trait Overlap {}
impl<T: NeedsFixpoint> Overlap for T {}
impl<T, U: NotU8, V> Overlap for (T, U, V) {}
//[current]~^ ERROR conflicting implementations of trait `Foo`
```

### Breakage due to removal of incomplete candidate preference

Fixes #107887. In the old solver we incompletely prefer the builtin trait object impl over user defined impls. This can break inference guidance, inferring `?x` in `dyn Trait<u32>: Trait<?x>` to `u32`, even if an explicit impl of `Trait<u64>` also exists.

This caused coherence to incorrectly allow overlapping impls, resulting in ICEs and a theoretical unsoundness. See https://github.com/rust-lang/rust/issues/107887#issuecomment-1997261676. This compiles on stable but results in an overlap error with `-Znext-solver=coherence`:

```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
struct W<T: ?Sized>(*const T);

trait Trait<T: ?Sized> {
    type Assoc;
}

// This would trigger the check for overlap between automatic and custom impl.
// They actually don't overlap so an impl like this should remain possible
// forever.
//
// impl Trait<u64> for dyn Trait<u32> {}
trait Indirect {}
impl Indirect for dyn Trait<u32, Assoc = ()> {}
impl<T: Indirect + ?Sized> Trait<u64> for T {
    type Assoc = ();
}

// Incomplete impl where `dyn Trait<u32>: Trait<_>` does not hold, but
// `dyn Trait<u32>: Trait<u64>` does.
trait EvaluateHack<U: ?Sized> {}
impl<T: ?Sized, U: ?Sized> EvaluateHack<W<U>> for T
where
    T: Trait<U, Assoc = ()>, // incompletely constrains `_` to `u32`
    U: IsU64,
    T: Trait<U, Assoc = ()>, // incompletely constrains `_` to `u32`
{
}

trait IsU64 {}
impl IsU64 for u64 {}

trait Overlap<U: ?Sized> {
    type Assoc: Default;
}
impl<T: ?Sized + EvaluateHack<W<U>>, U: ?Sized> Overlap<U> for T {
    type Assoc = Box<u32>;
}
impl<U: ?Sized> Overlap<U> for dyn Trait<u32, Assoc = ()> {
//[next]~^ ERROR conflicting implementations of trait `Overlap<_>`
    type Assoc = usize;
}
```

### Considering region outlives bounds in the `leak_check`

For details on the `leak_check`, see the FCP proposal #119820.[^leak_check]

[^leak_check]: which should get moved to the dev-guide :3

In both coherence and during candidate selection, the `leak_check` relies on the region constraints added in `evaluate`. It therefore currently does not register outlives obligations: [source](ccb1415eac/compiler/rustc_trait_selection/src/traits/select/mod.rs (L792-L810)). This was likely done as a performance optimization without considering its impact on the `leak_check`. This is the case as in the old solver, *evaluatation* and *fulfillment* are split, with evaluation being responsible for candidate selection and fulfillment actually registering all the constraints.

This split does not exist with the new solver. The `leak_check` can therefore eagerly detect errors caused by region outlives obligations. This improves both coherence itself and candidate selection:

```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait LeakErr<'a, 'b> {}
// Using this impl adds an `'b: 'a` bound which results
// in a higher-ranked region error. This bound has been
// previously ignored but is now considered.
impl<'a, 'b: 'a> LeakErr<'a, 'b> for () {}

trait NoOverlapDir<'a> {}
impl<'a, T: for<'b> LeakErr<'a, 'b>> NoOverlapDir<'a> for T {}
impl<'a> NoOverlapDir<'a> for () {}
//[current]~^ ERROR conflicting implementations of trait `NoOverlapDir<'_>`

// --------------------------------------

// necessary to avoid coherence unknowable candidates
struct W<T>(T);

trait GuidesSelection<'a, U> {}
impl<'a, T: for<'b> LeakErr<'a, 'b>> GuidesSelection<'a, W<u32>> for T {}
impl<'a, T> GuidesSelection<'a, W<u8>> for T {}

trait NotImplementedByU8 {}
trait NoOverlapInd<'a, U> {}
impl<'a, T: GuidesSelection<'a, W<U>>, U> NoOverlapInd<'a, U> for T {}
impl<'a, U: NotImplementedByU8> NoOverlapInd<'a, U> for () {}
//[current]~^ conflicting implementations of trait `NoOverlapInd<'_, _>`
```

### Removal of `fn match_fresh_trait_refs`

The old solver tries to [eagerly detect unbounded recursion](b14fd2359f/compiler/rustc_trait_selection/src/traits/select/mod.rs (L1196-L1211)), forcing the affected goals to be ambiguous. This check is only an approximation and has not been added to the new solver.

The check is not necessary in the new solver and it would be problematic for caching. As it depends on all goals currently on the stack, using a global cache entry would have to always make sure that doing so does not circumvent this check.

This changes some goals to error - or succeed - instead of failing with ambiguity. This allows more code to compile:

```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence

// Need to use this local wrapper for the impls to be fully
// knowable as unknowable candidate result in ambiguity.
struct Local<T>(T);

trait Trait<U> {}
// This impl does not hold, but is ambiguous in the old
// solver due to its overflow approximation.
impl<U> Trait<U> for Local<u32> where Local<u16>: Trait<U> {}
// This impl holds.
impl Trait<Local<()>> for Local<u8> {}

// In the old solver, `Local<?t>: Trait<Local<?u>>` is ambiguous,
// resulting in `Local<?u>: NoImpl`, also being ambiguous.
//
// In the new solver the first impl does not apply, constraining
// `?u` to `Local<()>`, causing `Local<()>: NoImpl` to error.
trait Indirect<T> {}
impl<T, U> Indirect<U> for T
where
    T: Trait<U>,
    U: NoImpl
{}

// Not implemented for `Local<()>`
trait NoImpl {}
impl NoImpl for Local<u8> {}
impl NoImpl for Local<u16> {}

// `Local<?t>: Indirect<Local<?u>>` cannot hold, so
// these impls do not overlap.
trait NoOverlap<U> {}
impl<T: Indirect<U>, U> NoOverlap<U> for T {}
impl<T, U> NoOverlap<Local<U>> for Local<T> {}
//~^ ERROR conflicting implementations of trait `NoOverlap<Local<_>>`
```

### Non-fatal overflow

The old solver immediately emits a fatal error when hitting the recursion limit. The new solver instead returns overflow. This both allows more code to compile and is results in performance and potential future compatability issues.

Non-fatal overflow is generally desirable. With fatal overflow, changing the order in which we evaluate nested goals easily causes breakage if we have goal which errors and one which overflows. It is also required to prevent breakage due to the removal of `fn match_fresh_trait_refs`, e.g. [in `typenum`](https://github.com/rust-lang/trait-system-refactor-initiative/issues/73).

#### Enabling more code to compile

In the below example, the old solver first tried to prove an overflowing goal, resulting in a fatal error. The new solver instead returns ambiguity due to overflow for that goal, causing the implicit negative overlap check to succeed as `Box<u32>: NotImplemented` does not hold.
```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
//[current] ERROR overflow evaluating the requirement

trait Indirect<T> {}
impl<T: Overflow<()>> Indirect<T> for () {}

trait Overflow<U> {}
impl<T, U> Overflow<U> for Box<T>
where
    U: Indirect<Box<Box<T>>>,
{}

trait NotImplemented {}

trait Trait<U> {}
impl<T, U> Trait<U> for T
where
    // T: NotImplemented, // causes old solver to succeed
    U: Indirect<T>,
    T: NotImplemented,
{}

impl Trait<()> for Box<u32> {}
```

#### Avoiding hangs with non-fatal overflow

Simply returning ambiguity when reaching the recursion limit can very easily result in hangs, e.g.
```rust
trait Recur {}
impl<T, U> Recur for ((T, U), (U, T))
where
    (T, U): Recur,
    (U, T): Recur,
{}

trait NotImplemented {}
impl<T: NotImplemented> Recur for T {}
```
This can happen quite frequently as it's easy to have exponential blowup due to multiple nested goals at each step. As the trait solver is depth-first, this immediately caused a fatal overflow error in the old solver. In the new solver we have to handle the whole proof tree instead, which can very easily hang.

To avoid this we restrict the recursion depth after hitting the recursion limit for the first time. We also **ignore all inference constraints from goals resulting in overflow**. This is mostly backwards compatible as any overflow in the old solver resulted in a fatal error.

### sidenote about normalization

We return ambiguous nested goals of `NormalizesTo` goals to the caller and ignore their impact when computing the `Certainty` of the current goal. See the [normalization chapter](https://rustc-dev-guide.rust-lang.org/solve/normalization.html) for more details.This means we apply constraints resulting from other nested goals and from equating the impl header when normalizing, even if a nested goal results in overflow. This is necessary to avoid breaking the following example:
```rust
trait Trait {
    type Assoc;
}

struct W<T: ?Sized>(*mut T);
impl<T: ?Sized> Trait for W<W<T>>
where
    W<T>: Trait,
{
    type Assoc = ();
}

// `W<?t>: Trait<Assoc = u32>` does not hold as
// `Assoc` gets normalized to `()`. However, proving
// the where-bounds of the impl results in overflow.
//
// For this to continue to compile we must not discard
// constraints from normalizing associated types.
trait NoOverlap {}
impl<T: Trait<Assoc = u32>> NoOverlap for T {}
impl<T: ?Sized> NoOverlap for W<T> {}
```

#### Future compatability concerns

Non-fatal overflow results in some unfortunate future compatability concerns. Changing the approach to avoid more hangs by more strongly penalizing overflow can cause breakage as we either drop constraints or ignore candidates necessary to successfully compile. Weakening the overflow penalities instead allows more code to compile and strengthens inference while potentially causing more code to hang.

While the current approach is not perfect, we believe it to be good enough. We believe it to apply the necessary inference constraints to avoid breakage and expect there to not be any desirable patterns broken by our current penalities. Similarly we believe the current constraints to avoid most accidental hangs. Ignoring constraints of overflowing goals is especially useful, as it may allow major future optimizations to our overflow handling. See [this summary](https://hackmd.io/ATf4hN0NRY-w2LIVgeFsVg) and the linked documents in case you want to know more.

### changes to performance

In general, trait solving during coherence checking is not significant for performance. Enabling the next-generation trait solver in coherence does not impact our compile time benchmarks. We are still unable to compile the benchmark suite when fully enabling the new trait solver.

There are rare cases where the new solver has significantly worse performance due to non-fatal overflow, its reliance on fixpoint algorithms and the removal of the `fn match_fresh_trait_refs` approximation. We encountered such issues in [`typenum`](https://crates.io/crates/typenum) and believe it should be [pretty much as bad as it can get](https://github.com/rust-lang/trait-system-refactor-initiative/issues/73).

Due to an improved structure and far better caching, we believe that there is a lot of room for improvement and that the new solver will outperform the existing implementation in nearly all cases, sometimes significantly. We have not yet spent any time micro-optimizing the implementation and have many unimplemented major improvements, such as fast-paths for trivial goals.

### Unstable features

#### Unsupported unstable features

The new solver currently does not support all unstable features, most notably `#![feature(generic_const_exprs)]`, `#![feature(associated_const_equality)]` and `#![feature(adt_const_params)]` are not yet fully supported in the new solver. We are confident that supporting them is possible, but did not consider this to be a priority. This stabilization introduces new ICE when using these features in impl headers.

#### fixes to `#![feature(specialization)]`

- fixes #105782
- fixes #118987

#### fixes to `#![feature(type_alias_impl_trait)]`

- fixes #119272
- https://github.com/rust-lang/rust/issues/105787#issuecomment-1750112388
- fixes #124207

### Important changes since the original FCP

https://github.com/rust-lang/rust/pull/127574 changes the coherence unknowable candidate to only apply if all the super trait bounds may hold. This allows more code to compile and fixes a regression in `pyella`

https://github.com/rust-lang/rust/pull/130617 bails with ambiguity if the query response would contain too many non-region inference variables. This should only be triggered in case the result contains a lot of ambiguous aliases in which case further constraining the goal should resolve this.

https://github.com/rust-lang/rust/pull/130821 adds caching to a lot of type folders, which is necessary to handle exponentially large types and handles the hang in `nalgebra` together with #130617.

## This does not stabilize the whole solver

While this stabilizes the use of the new solver in coherence checking, there are many parts of the solver which will remain fully unstable. We may still adapt these areas while working towards stabilizing the new solver everywhere. We are confident that we are able to do so without negatively impacting coherence.

### goals with a non-empty `ParamEnv`

Coherence always uses an empty environment. We therefore do not depend on the behavior of `AliasBound` and `ParamEnv` candidates. We only stabilizes the behavior of user-defined and builtin implementations of traits. There are still many open questions there.

### opaque types in the defining scope

The handling of opaque types - `impl Trait` - in both the new and old solver is still not fully figured out. Luckily this can be ignored for now. While opaque types are reachable during coherence checking by using `impl_trait_in_associated_types`, the behavior during coherence is separate and self-contained. The old and new solver fully agree here.

### normalization is hard

This stabilizes that we equate associated types involving bound variables using deferred-alias-equality. We also stop eagerly normalizing in coherence, which should not have any user-facing impact.

We do not stabilize the normalization behavior outside of coherence, e.g. we currently deeply normalize all types during writeback with the new solver. This may change going forward

### how to replace `select` from the old solver

We sometimes depend on getting a single `impl` for a given trait bound, e.g. when resolving a concrete method for codegen/CTFE. We do not depend on this during coherence, so the exact approach here can still be freely changed going forward.

## Acknowledgements

This work would not have been possible without `@compiler-errors.` He implemented large chunks of the solver himself but also and did a lot of testing and experimentation, eagerly discovering multiple issues which had a significant impact on our approach. `@BoxyUwU` has also done some amazing work on the solver. Thank you for the endless hours of discussion resulting in the current approach. Especially the way aliases are handled has gone through multiple revisions to get to its current state.

There were also many contributions from - and discussions with - other members of the community and the rest of `@rust-lang/types.` This solver builds upon previous improvements to the compiler, as well as lessons learned from `chalk` and `a-mir-formality`. Getting to this point  would not have been possible without that and I am incredibly thankful to everyone involved. See the [list of relevant PRs](https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Amerged+label%3AWG-trait-system-refactor+-label%3Arollup+closed%3A%3C2024-03-22+).
2024-10-15 14:21:34 +00:00
Guillaume Gomez
2b9e41c128 Improve documentation for intra-doc links computation 2024-10-15 15:42:53 +02:00
Hood Chatham
1d6643c4f6 Fix most ui tests on emscripten target
To fix the linker errors, we need to set the output extension to `.js` instead
of `.wasm`. Setting the output to a `.wasm` file puts Emscripten into standalone
mode which is effectively a distinct target. We need to set the runner to be
`node` as well.

This fixes most of the ui tests. I fixed a few more tests with simple problems:
- `intrinsics/intrinsic-alignment.rs` and `structs-enums/rec-align-u64.rs` --
Two `#[cfg]` macros match for Emscripten so we got a duplicate definition of
`mod m`.
- `issues/issue-12699.rs` -- Seems to hang so I disabled it
- `process/process-sigpipe.rs` -- Not expected to work on Emscripten so I
disabled it
2024-10-15 14:25:55 +02:00
bors
f79fae3069 Auto merge of #131723 - matthiaskrgr:rollup-krcslig, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #122670 (Fix bug where `option_env!` would return `None` when env var is present but not valid Unicode)
 - #131095 (Use environment variables instead of command line arguments for merged doctests)
 - #131339 (Expand set_ptr_value / with_metadata_of docs)
 - #131652 (Move polarity into `PolyTraitRef` rather than storing it on the side)
 - #131675 (Update lint message for ABI not supported)
 - #131681 (Fix up-to-date checking for run-make tests)
 - #131702 (Suppress import errors for traits that couldve applied for method lookup error)
 - #131703 (Resolved python deprecation warning in publish_toolstate.py)
 - #131710 (Remove `'apostrophes'` from `rustc_parse_format`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-15 11:50:31 +00:00
Mateusz Maćkowski
d11a9702ab
Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES 2024-10-15 13:28:39 +02:00
lcnr
30ec8bb5e9 update test description 2024-10-15 13:26:59 +02:00
lcnr
7aeb07a583 remove unnecessary revisions 2024-10-15 13:26:59 +02:00
lcnr
d3f982d466 rebase and update fixed crashes 2024-10-15 13:11:00 +02:00
lcnr
1a9d2d82a5 stabilize -Znext-solver=coherence 2024-10-15 13:11:00 +02:00
Julian Frimmel
db6c736da3
Allow the compiler to select any register 2024-10-15 12:30:55 +02:00
Julian Frimmel
652ba6699c
Add check-annotations ensuring correct label
The issue was, that the disassembled label was placed one instruction
further down than expected. Therefore the test annotations check, that
the label is placed above the loop-contents (writing the one value, then
writing the other one).
2024-10-15 12:23:35 +02:00
Julian Frimmel
da44e3fdce
Start test case for rjmp regression test
This commit introduces a minimal `![no_core]`-test case running on AVR,
that contains the MCWE mentioned in [129301]. The test case itself does
not have any assertions yet, but it shows the minimal set an language
items necessary within the test case.

[129301]: https://github.com/rust-lang/rust/issues/129301#issuecomment-2301399472
2024-10-15 12:22:37 +02:00
Eduardo Sánchez Muñoz
c09ed3e767 Make some float methods unstable const fn
Some float methods are now `const fn` under the `const_float_methods` feature gate.

In order to support `min`, `max`, `abs` and `copysign`, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval.
2024-10-15 10:46:33 +02:00
bors
88f311479d Auto merge of #131724 - matthiaskrgr:rollup-ntgkkk8, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #130608 (Implemented `FromStr` for `CString` and `TryFrom<CString>` for `String`)
 - #130635 (Add `&pin (mut|const) T` type position sugar)
 - #130747 (improve error messages for `C-cmse-nonsecure-entry` functions)
 - #131137 (Add 1.82 release notes)
 - #131328 (Remove unnecessary sorts in `rustc_hir_analysis`)
 - #131496 (Stabilise `const_make_ascii`.)
 - #131706 (Fix two const-hacks)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-15 05:02:38 +00:00
Matthias Krüger
731e360d15
Rollup merge of #130747 - folkertdev:c-cmse-nonsecure-entry-error-messages, r=compiler-errors
improve error messages for `C-cmse-nonsecure-entry` functions

fixes https://github.com/rust-lang/rust/issues/81347

tracking issue: https://github.com/rust-lang/rust/issues/75835

brings error messages and testing for `C-cmse-nonsecure-entry` in line with `C-cmse-nonsecure-call`.

r? `@compiler-errors`
2024-10-15 05:12:35 +02:00
Matthias Krüger
fb691b470a
Rollup merge of #130635 - eholk:pin-reborrow-sugar, r=compiler-errors
Add `&pin (mut|const) T` type position sugar

This adds parser support for `&pin mut T` and `&pin const T` references. These are desugared to `Pin<&mut T>` and `Pin<&T>` in the AST lowering phases.

This PR currently includes #130526 since that one is in the commit queue. Only the most recent commits (bd450027eb4a94b814a7dd9c0fa29102e6361149 and following) are new.

Tracking:

- #130494

r? `@compiler-errors`
2024-10-15 05:12:34 +02:00
Matthias Krüger
c99c4d4057
Rollup merge of #131710 - ShE3py:parse_format_apostrophes, r=compiler-errors
Remove `'apostrophes'` from `rustc_parse_format`

The rest of the compiler uses \`grave accents\`, while `rustc_parse_format` uses \`'apostrophes.'\`

Also makes the crate compile as a stand-alone:
```
~/rust/compiler/rustc_parse_format $ cargo check
   Compiling rustc_index_macros v0.0.0 (/home/lieselotte/rust/compiler/rustc_index_macros)
error[E0277]: `syn::Lit` doesn't implement `Debug`
  --> compiler/rustc_index_macros/src/newtype.rs:52:57
   |
52 |                         panic!("Specified multiple max: {old:?}");
   |                                                         ^^^^^^^ `syn::Lit` cannot be formatted using `{:?}` because it doesn't implement `Debug`
   |
   = help: the trait `Debug` is not implemented for `syn::Lit`
   = note: this error originates in the macro `$crate::const_format_args` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: `syn::Lit` doesn't implement `Debug`
  --> compiler/rustc_index_macros/src/newtype.rs:64:74
   |
64 |                         panic!("Specified multiple debug format options: {old:?}");
   |                                                                          ^^^^^^^ `syn::Lit` cannot be formatted using `{:?}` because it doesn't implement `Debug`
   |
   = help: the trait `Debug` is not implemented for `syn::Lit`
   = note: this error originates in the macro `$crate::const_format_args` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
error: could not compile `rustc_index_macros` (lib) due to 2 previous errors
```
`@rustbot` label +A-diagnostics
2024-10-15 05:11:40 +02:00
Matthias Krüger
2e2c433be4
Rollup merge of #131702 - compiler-errors:method-lookup-trait-warning, r=jieyouxu
Suppress import errors for traits that couldve applied for method lookup error

Self-explanatory. I hit this quite often when refactoring in rustc, so even though this isn't really showing up as significant in the UI test suite, it probably will matter more for multi-module projects.
2024-10-15 05:11:39 +02:00
Matthias Krüger
258c17741b
Rollup merge of #131681 - Zalathar:fix-run-make-stamp, r=jieyouxu
Fix up-to-date checking for run-make tests

This special case in `output_base_dir` had the unfortunate side-effect of causing all run-make tests to share the same `stamp` file. So as soon as any one of them succeeded, all of the failed tests would be incorrectly considered up-to-date and would no longer run in subsequent test invocations.

Fixes #129971.

r? jieyouxu
2024-10-15 05:11:38 +02:00
Matthias Krüger
bd649b4dd0
Rollup merge of #131675 - tdittr:update-unsupported-abi-message, r=compiler-errors
Update lint message for ABI not supported

Tracking issue: #130260

As requested in https://github.com/rust-lang/rust/pull/128784#pullrequestreview-2364026550 I updated the error message.

I could also change it to be the same message as if it was a hard error on a normal function:

> "`{abi}` is not a supported ABI for the current target"

Or would that get confusing when people try to google the error message?

r? compiler-errors
2024-10-15 05:11:38 +02:00
Matthias Krüger
6d9999662c
Rollup merge of #122670 - beetrees:non-unicode-option-env-error, r=compiler-errors
Fix bug where `option_env!` would return `None` when env var is present but not valid Unicode

Fixes #122669 by making `option_env!` emit an error when the value of the environment variable is not valid Unicode.
2024-10-15 05:11:36 +02:00
bors
785c83015c Auto merge of #129458 - EnzymeAD:enzyme-frontend, r=jieyouxu
Autodiff Upstreaming - enzyme frontend

This is an upstream PR for the `autodiff` rustc_builtin_macro that is part of the autodiff feature.

For the full implementation, see: https://github.com/rust-lang/rust/pull/129175

**Content:**
It contains a new `#[autodiff(<args>)]` rustc_builtin_macro, as well as a `#[rustc_autodiff]` builtin attribute.
The autodiff macro is applied on function `f` and will expand to a second function `df` (name given by user).
It will add a dummy body to `df` to make sure it type-checks. The body will later be replaced by enzyme on llvm-ir level,
we therefore don't really care about the content. Most of the changes (700 from 1.2k) are in `compiler/rustc_builtin_macros/src/autodiff.rs`, which expand the macro. Nothing except expansion is implemented for now.
I have a fallback implementation for relevant functions in case that rustc should be build without autodiff support. The default for now will be off, although we want to flip it later (once everything landed) to on for nightly. For the sake of CI, I have flipped the defaults, I'll revert this before merging.

**Dummy function Body:**
The first line is an `inline_asm` nop to make inlining less likely (I have additional checks to prevent this in the middle end of rustc. If `f` gets inlined too early, we can't pass it to enzyme and thus can't differentiate it.
If `df` gets inlined too early, the call site will just compute this dummy code instead of the derivatives, a correctness issue. The following black_box lines make sure that none of the input arguments is getting optimized away before we replace the body.

**Motivation:**
The user facing autodiff macro can verify the user input. Then I write it as args to the rustc_attribute, so from here on I can know that these values should be sensible. A rustc_attribute also turned out to be quite nice to attach this information to the corresponding function and carry it till the backend.
This is also just an experiment, I expect to adjust the user facing autodiff macro based on user feedback, to improve usability.

As a simple example of what this will do, we can see this expansion:
From:
```
#[autodiff(df, Reverse, Duplicated, Const, Active)]
pub fn f1(x: &[f64], y: f64) -> f64 {
    unimplemented!()
}
```
to
```
#[rustc_autodiff]
#[inline(never)]
pub fn f1(x: &[f64], y: f64) -> f64 {
    ::core::panicking::panic("not implemented")
}
#[rustc_autodiff(Reverse, Duplicated, Const, Active,)]
#[inline(never)]
pub fn df(x: &[f64], dx: &mut [f64], y: f64, dret: f64) -> f64 {
    unsafe { asm!("NOP"); };
    ::core::hint::black_box(f1(x, y));
    ::core::hint::black_box((dx, dret));
    ::core::hint::black_box(f1(x, y))
}
```
I will add a few more tests once I figured out why rustc rebuilds every time I touch a test.

Tracking:

- https://github.com/rust-lang/rust/issues/124509

try-job: dist-x86_64-msvc
2024-10-15 01:30:01 +00:00
Lieselotte
dda3066805
Remove 'apostrophes' from rustc_parse_format 2024-10-14 23:22:51 +02:00
Folkert de Vries
10aa255541 improve error messages for C-cmse-nonsecure-entry functions 2024-10-14 22:32:32 +02:00
Michael Goulet
c3b696dec9 Suppress import errors for traits that couldve applied in method lookup on error 2024-10-14 14:40:11 -04:00
Lieselotte
1364631584
rt::Argument: elide lifetimes 2024-10-14 20:24:30 +02:00
Michael Goulet
5a8405a5fa Don't report on_unimplemented for negative traits 2024-10-14 14:18:25 -04:00
Guillaume Gomez
d540e7285c Add regression tests for #130233 2024-10-14 17:51:37 +02:00
Matthias Krüger
b8cdca8cce
Rollup merge of #131550 - compiler-errors:extern-diags, r=spastorino
Make some tweaks to extern block diagnostics

Self-explanatory. See the diagnostic changes; I hope they make them a bit more descriptive.

r? spastorino
2024-10-14 17:06:38 +02:00
Matthias Krüger
75231f8764
Rollup merge of #131430 - surechen:fix_130495, r=jieyouxu
Special treatment empty tuple when suggest adding a string literal in format macro.

For example:
```rust
let s = "123";
println!({}, "sss", s);
```
Suggest:
`println!("{:?} {} {}", {}, "sss", s);`

fixes #130170
2024-10-14 17:06:37 +02:00
Matthias Krüger
32062b4b8e
Rollup merge of #131384 - saethlin:precondition-tests, r=ibraheemdev
Update precondition tests (especially for zero-size access to null)

I don't much like the current way I've updated the precondition check helpers, but I couldn't come up with anything better. Ideas welcome.

I've organized `tests/ui/precondition-checks` mostly with one file per function that has `assert_unsafe_precondition` in it, with revisions that check each precondition. The important new test is `tests/ui/precondition-checks/zero-size-null.rs`.
2024-10-14 17:06:36 +02:00
Matthias Krüger
43bf4f1fd3
Rollup merge of #131332 - taiki-e:arm64ec-clobber-abi, r=Amanieu
Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly

Currently `clobber_abi` in Arm64EC inline assembly is implemented using `InlineAsmClobberAbi::AArch64NoX18`, but broken since it attempts to clobber registers that cannot be used in Arm64EC: https://godbolt.org/z/r3PTrGz5r

```
error: cannot use register `x13`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
 --> <source>:6:14
  |
6 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
  |              ^^^^^^^^^^^^^^^^

error: cannot use register `x14`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
 --> <source>:6:14
  |
6 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
  |              ^^^^^^^^^^^^^^^^

<omitted the same errors for v16-v31>
```

Additionally, this disallows SVE-related registers per https://github.com/rust-lang/rust/pull/131332#issuecomment-2401189142.

cc ``@dpaoliello``

r? ``@Amanieu``

``@rustbot`` label O-windows O-AArch64 +A-inline-assembly
2024-10-14 17:06:35 +02:00
bors
17a19e684c Auto merge of #131672 - matthiaskrgr:rollup-gyzysj4, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #128967 (std::fs::get_path freebsd update.)
 - #130629 (core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments.)
 - #131274 (library: Const-stabilize `MaybeUninit::assume_init_mut`)
 - #131473 (compiler: `{TyAnd,}Layout` comes home)
 - #131533 (emscripten: Use the latest emsdk 3.1.68)
 - #131593 (miri: avoid cloning AllocExtra)
 - #131616 (merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate)
 - #131660 (Also use outermost const-anon for impl items in `non_local_defs` lint)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-14 12:20:35 +00:00
Zalathar
c6e1fbf8eb Fix up-to-date checking for run-make tests
This special case in `output_base_dir` had the unfortunate side-effect of
causing all run-make tests to share the same `stamp` file. So as soon as any
one of them succeeded, all of the failed tests would be considered up-to-date
and would no longer run in subsequent test invocations.
2024-10-14 22:55:51 +11:00
Tamme Dittrich
b6b6c12819 Update lint message for ABI not supported 2024-10-14 10:02:33 +02:00
bors
f6648f252a 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
surechen
ceced5322c Special treatment empty tuple when suggest adding a string literal in format macro.
For example:
```rust
let s = "123";
println!({}, "sss", s);
```
Suggest:
`println!("{:?} {} {}", {}, "sss", s);`

fixes #130170
2024-10-14 10:07:57 +08:00
Taiki Endo
d858dfedbb Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly 2024-10-14 05:30:45 +09:00
Urgau
b5e91a00c8 Also use outermost const-anon for impl items in non_local_defs lint 2024-10-13 18:14:29 +02:00
Trevor Gross
ae8342aa90
Rollup merge of #131591 - matthiaskrgr:crashtests, r=jieyouxu
add latest crash tests
2024-10-12 21:38:37 -05:00
Trevor Gross
507dd637a3
Rollup merge of #131579 - jieyouxu:ui-panic-username, r=compiler-errors
Remap path prefix in the panic message of `tests/ui/meta/revision-bad.rs`

Otherwise `error-pattern` on the test run stderr can incorrectly match if the paths in panic backtrace has a matching substring (like if we look for `bar` in the error pattern, but the username is `baron`).

Tested locally by checking run output `./x test .\tests\ui\meta\revision-bad.rs -- -- --nocapture`:

```
--- stderr -------------------------------
thread 'main' panicked at remapped\meta\revision-bad.rs:14:5:
foo
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
------------------------------------------
```

Fixes #130996.
2024-10-12 21:38:37 -05:00
Trevor Gross
c8b2f7e458
Rollup merge of #131120 - tgross35:stabilize-const_option, r=RalfJung
Stabilize `const_option`

This makes the following API stable in const contexts:

```rust
impl<T> Option<T> {
    pub const fn as_mut(&mut self) -> Option<&mut T>;
    pub const fn expect(self, msg: &str) -> T;
    pub const fn unwrap(self) -> T;
    pub const unsafe fn unwrap_unchecked(self) -> T;
    pub const fn take(&mut self) -> Option<T>;
    pub const fn replace(&mut self, value: T) -> Option<T>;
}

impl<T> Option<&T> {
    pub const fn copied(self) -> Option<T>
    where T: Copy;
}

impl<T> Option<&mut T> {
    pub const fn copied(self) -> Option<T>
    where T: Copy;
}

impl<T, E> Option<Result<T, E>> {
    pub const fn transpose(self) -> Result<Option<T>, E>
}

impl<T> Option<Option<T>> {
    pub const fn flatten(self) -> Option<T>;
}
```

The following functions make use of the unstable `const_precise_live_drops` feature:

- `expect`
- `unwrap`
- `unwrap_unchecked`
- `transpose`
- `flatten`

Fixes: <https://github.com/rust-lang/rust/issues/67441>
2024-10-12 21:38:35 -05:00
beetrees
feecfaa18d
Fix bug where option_env! would return None when env var is present but not valid Unicode 2024-10-13 02:10:19 +01:00
Trevor Gross
19f6c17df4 Stabilize const_option
This makes the following API stable in const contexts:

    impl<T> Option<T> {
        pub const fn as_mut(&mut self) -> Option<&mut T>;
        pub const fn expect(self, msg: &str) -> T;
        pub const fn unwrap(self) -> T;
        pub const unsafe fn unwrap_unchecked(self) -> T;
        pub const fn take(&mut self) -> Option<T>;
        pub const fn replace(&mut self, value: T) -> Option<T>;
    }

    impl<T> Option<&T> {
        pub const fn copied(self) -> Option<T>
        where T: Copy;
    }

    impl<T> Option<&mut T> {
        pub const fn copied(self) -> Option<T>
        where T: Copy;
    }

    impl<T, E> Option<Result<T, E>> {
        pub const fn transpose(self) -> Result<Option<T>, E>
    }

    impl<T> Option<Option<T>> {
        pub const fn flatten(self) -> Option<T>;
    }

The following functions make use of the unstable
`const_precise_live_drops` feature:

- `expect`
- `unwrap`
- `unwrap_unchecked`
- `transpose`
- `flatten`

Fixes: <https://github.com/rust-lang/rust/issues/67441>
2024-10-12 17:07:13 -04:00
Matthias Krüger
b9e083f86b
Rollup merge of #131567 - CastilloDel:reject-unstable-with-accepted-features, r=jieyouxu
Emit an error for unstable attributes that reference already stable features

Closes https://github.com/rust-lang/rust/issues/129814
2024-10-12 23:00:58 +02:00
Matthias Krüger
663da00876
Rollup merge of #131239 - VulnBandit:trait-vulnerability, r=lcnr
Don't assume traits used as type are trait objs in 2021 edition

Fixes #127548

When you use a trait as a type, the compiler automatically assumes you meant to use a trait object, which is not always the case.
This PR fixes the bug where you don't need a trait object, so the error message was changed to:
```
error[E0782]: expected a type, found a trait
```
Also fixes some ICEs:
Fixes https://github.com/rust-lang/rust/issues/120241
Fixes https://github.com/rust-lang/rust/issues/120482
Fixes https://github.com/rust-lang/rust/issues/125512
2024-10-12 23:00:56 +02:00
Matthias Krüger
57be141f8a
Rollup merge of #128784 - tdittr:check-abi-on-fn-ptr, r=compiler-errors
Check ABI target compatibility for function pointers

Tracking issue: https://github.com/rust-lang/rust/issues/130260
Related tracking issue: #87678

Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent.

This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea.

Also this might break existing code, because we now emit extra errors. Does this require a crater run?

# Example
```rust
// build with: --target=x86_64-unknown-linux-gnu

// These raise E0570
extern "thiscall" fn foo() {}
extern "thiscall" { fn bar() }

// This did not raise any error
fn baz(f: extern "thiscall" fn()) { f() }
```

# Open Questions
* [x] Should this report a future incompatibility warning like #87678 ?
* [ ] Is this the best place to perform the check?
2024-10-12 23:00:55 +02:00
bjorn3
8ed77fd29e Update tests for 32bit targets 2024-10-12 16:17:34 +00:00
Trevor Gross
ca3c822068
Rollup merge of #131233 - joboet:stdout-before-main, r=tgross35
std: fix stdout-before-main

Fixes #130210.

Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.

This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
2024-10-12 11:08:43 -05:00
Trevor Gross
8a86f1dd8c
Rollup merge of #130954 - workingjubilee:stabilize-const-mut-fn, r=RalfJung
Stabilize const `ptr::write*` and `mem::replace`

Since `const_mut_refs` and `const_refs_to_cell` have been stabilized, we may now also stabilize the ability to write to places during const evaluation inside our library API. So, we now propose the `const fn` version of `ptr::write` and its variants. This allows us to also stabilize `mem::replace` and `ptr::replace`.
- const `mem::replace`: https://github.com/rust-lang/rust/issues/83164#issuecomment-2338660862
- const `ptr::write{,_bytes,_unaligned}`: https://github.com/rust-lang/rust/issues/86302#issuecomment-2330275266

Their implementation requires an additional internal stabilization of `const_intrinsic_forget`, which is required for `*::write*` and thus `*::replace`. Thus we const-stabilize the internal intrinsics `forget`, `write_bytes`, and `write_via_move`.
2024-10-12 11:08:42 -05:00
Trevor Gross
63a91db022
Rollup merge of #130870 - surechen:fix_130791, r=compiler-errors
Add suggestion for removing invalid path sep `::` in fn def

Add suggestion for removing invalid path separator `::` in function definition.

for example: `fn invalid_path_separator::<T>() {}`

fixes #130791
2024-10-12 11:08:42 -05:00
joboet
9f91c5099f
std: fix stdout-before-main
Fixes #130210.

Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.

This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
2024-10-12 13:01:36 +02:00
Michael Goulet
c8b71ef3dd Also note for fields 2024-10-12 06:14:46 -04:00
Michael Goulet
5e8820caaa Add a note for ? on future in sync function 2024-10-12 06:14:45 -04:00
Matthias Krüger
bcd71624d5 add latest crash tests 2024-10-12 11:29:38 +02:00
CastilloDel
497100a13c Emit an error for unstable attributes that reference already stable features
Add missing error annotations and .stderr file

Acknowledge comments
2024-10-12 10:19:24 +02:00
Jubilee Young
ddc367ded7 library: Stabilize const_ptr_write
Const-stabilizes:
- `write`
- `write_bytes`
- `write_unaligned`

In the following paths:
- `core::ptr`
- `core::ptr::NonNull`
- pointer `<*mut T>`

Const-stabilizes the internal `core::intrinsics`:
- `write_bytes`
- `write_via_move`
2024-10-12 00:02:36 -07:00
Trevor Gross
1f31925345
Rollup merge of #131565 - Urgau:non_local_def-rm-deprecate, r=compiler-errors
Remove deprecation note in the `non_local_definitions` lint

This PR removes the edition deprecation note emitted by the `non_local_definitions` lint.

Specifically this part:

```
= note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
```

because it [didn't make the cut](https://github.com/rust-lang/rust/issues/120363#issuecomment-2407833300) for the 2024 edition.

`@rustbot` label +L-non_local_definitions
2024-10-11 23:57:47 -04:00
Trevor Gross
fcbf4ac6f9
Rollup merge of #131546 - surechen:fix_129833, r=jieyouxu
Make unused_parens's suggestion considering expr's attributes.

For the expr with attributes,
like `let _ = (#[inline] || println!("Hello!"));`,
the suggestion's span should contains the attributes, or the suggestion will remove them.

fixes #129833
2024-10-11 23:57:46 -04:00
Trevor Gross
9e72070f77
Rollup merge of #131310 - taiki-e:msp430-clobber-abi, r=Amanieu
Support clobber_abi in MSP430 inline assembly

This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.

Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf)

cc ``@cr1901``

r? ``@Amanieu``

``@rustbot`` label +O-msp430
2024-10-11 23:57:46 -04:00
许杰友 Jieyou Xu (Joe)
1fe079bd62 Remap path refix in the panic message
Otherwise `error-pattern` on the test run stderr can incorrectly match
if e.g. the paths in panic backtrace has a matching substring (like if
we look for `bar` in the error pattern but username is `baron`).
2024-10-12 09:41:42 +08:00
surechen
1e8d6d1ec3 Make unused_parens's suggestion considering expr's attributes
For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, the suggestion's span should contains the attributes, or the suggestion will remove them.

fixes #129833
2024-10-12 09:32:25 +08:00
Josh Stone
5365b3f7be 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-11 16:22:43 -07:00
Jed Brown
0d8a978e8a intrinsics.fmuladdf{16,32,64,128}: expose llvm.fmuladd.* semantics
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.

https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic

MIRI support is included for f32 and f64.

The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.

I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
2024-10-11 15:32:56 -06:00
Urgau
77b3065ed2 Remove deprecation note in the non_local_definitions warning 2024-10-11 21:21:32 +02:00
Manuel Drehwald
7c37d2db98 Add pretty, ui, and feature-gate tests for the enzyme/autodiff frontend 2024-10-11 20:38:43 +02:00
bors
01e2fff90c Auto merge of #131547 - matthiaskrgr:rollup-ui4p744, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #129079 (Create `_imp__` symbols also when doing ThinLTO)
 - #131208 (ABI: Pass aggregates by value on AIX)
 - #131394 (fix(rustdoc): add space between struct fields and their descriptions)
 - #131519 (Use Default visibility for rustc-generated C symbol declarations)
 - #131541 (compiletest: Extract auxiliary-crate properties to their own module/struct)
 - #131542 (next-solver: remove outdated FIXMEs)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-11 16:27:23 +00:00
VulnBandit
9a2772e1c2 Don't assume traits used as type are trait objs 2024-10-11 17:36:04 +02:00
Michael Goulet
d6391d5d4d Note what qualifier 2024-10-11 11:30:08 -04:00
Michael Goulet
c085071631 Remove unadorned 2024-10-11 11:30:08 -04:00
Matthias Krüger
33b1264540
Rollup merge of #131519 - davidlattimore:intrinsics-default-vis, r=Urgau
Use Default visibility for rustc-generated C symbol declarations

Non-default visibilities should only be used for definitions, not declarations, otherwise linking can fail.

This is based on https://github.com/rust-lang/rust/pull/123994.

Issue https://github.com/rust-lang/rust/issues/123427

When I changed `default-hidden-visibility` to `default-visibility` in https://github.com/rust-lang/rust/pull/130005, I updated all places in the code that used `default-hidden-visibility`, replicating the hidden-visibility bug to also happen for protected visibility.

Without this change, trying to build rustc with `-Z default-visibility=protected` fails with a link error.
2024-10-11 15:36:52 +02:00
Matthias Krüger
fc81a7c1d5
Rollup merge of #131208 - mustartt:aix-call-abi, r=davidtwco
ABI: Pass aggregates by value on AIX

On AIX we pass aggregates byval. Adds new ABI for AIX for powerpc64.

313ad85dfa/clang/lib/CodeGen/Targets/PPC.cpp (L216)

Fixes the following 2 testcases on AIX:
```
tests/ui/abi/extern/extern-pass-TwoU16s.rs
tests/ui/abi/extern/extern-pass-TwoU8s.rs
```
2024-10-11 15:36:51 +02:00
Matthias Krüger
7c79621462
Rollup merge of #129079 - Zoxc:thinlto_imp_symbols, r=wesleywiser
Create `_imp__` symbols also when doing ThinLTO

When generating a rlib crate on Windows we create `dllimport` / `_imp__` symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft's `link` can fix these up (and emits warnings), but `lld` seems to currently be unable to.

This PR also does this generation for ThinLTO avoiding those issues with `lld` and also avoids the warnings on `link`.

This is an workaround for https://github.com/rust-lang/rust/issues/81408.

cc `@lqd`
2024-10-11 15:36:51 +02:00
bors
f4966590d8 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
Matthias Krüger
e00f49db17
Rollup merge of #131498 - Urgau:transparent-const-anons, r=lcnr
Consider outermost const-anon in `non_local_def` lint

This PR change the logic for finding the parent of the `impl` definition in the `non_local_definitions` lint to consider multiple level of const-anon items, instead of only one currently.

I also took the opportunity to cleanup the related code.

cc ``@traviscross``
Fixes https://github.com/rust-lang/rust/issues/131474
2024-10-11 12:21:07 +02:00
Zalathar
599f95ecc2 coverage: Include the highest counter ID seen in .cov-map dumps
When making changes that have a large impact on coverage counter creation, this
makes it easier to see whether the number of physical counters has changed.

(The highest counter ID seen in coverage maps is not necessarily the same as
the number of physical counters actually used by the instrumented code, but
it's the best approximation we can get from looking only at the coverage maps,
and it should be reasonably accurate in most cases.)
2024-10-11 21:04:37 +11:00
Jonathan Dönszelmann
0a9c87b1f5
rename RcBox in other places too 2024-10-11 10:04:22 +02:00
Urgau
7e05da8d42 Consider outermost const-anon in non_local_def lint 2024-10-11 09:39:53 +02:00
Stuart Cook
f6bdf711cf
Rollup merge of #131524 - Zalathar:less-thinlto-magic, r=jieyouxu
compiletest: Remove the magic hacks for finding output with `lto=thin`

This hack was intended to handle the case where `-Clto=thin` causes the compiler to emit multiple output files (when producing LLVM-IR or assembly).

The hack only affects 4 tests, of which 3 are just meta-tests for the hack itself. The one remaining test that motivated the hack currently doesn't even need it!

(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
2024-10-11 17:46:12 +11:00
bors
0321e73d1c Auto merge of #131517 - aDotInTheVoid:rdj-safe-extern-test, r=GuillaumeGomez
rustdoc-json: Add tests for unsafe/safe extern blocks (RFC 3484)

Closes https://github.com/rust-lang/rust/issues/126786, turns out this all Just Works (TM)

Tracking issue: #123743

r? `@GuillaumeGomez`
2024-10-11 03:23:45 +00:00
Zalathar
96224d80ce compiletest: Remove the magic hacks for finding output with lto=thin
This hack was intended to handle the case where `-Clto=thin` causes the
compiler to emit multiple output files (when producing LLVM-IR or assembly).

The hack only affects 4 tests, of which 3 are just meta-tests for the hack
itself. The one remaining test that motivated the hack currently doesn't even
need it!

(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
2024-10-11 11:28:42 +11:00
David Lattimore
42c0494499 Use Default visibility for rustc-generated C symbol declarations
Non-default visibilities should only be used for definitions, not
declarations, otherwise linking can fail.

Co-authored-by: Collin Baker <collinbaker@chromium.org>
2024-10-11 08:43:27 +11:00
Alona Enraght-Moony
8a9b67028c rustdoc-json: Add tests for unsafe/safe extern blocks (RFC 3484) 2024-10-10 20:53:57 +00:00
Matthias Krüger
fa3dff3e24
Rollup merge of #131475 - fmease:compiler-mv-obj-safe-dyn-compat-2, r=jieyouxu
Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible"

Follow-up to #130826.
Part of #130852.

1. 1st commit: Fix stupid oversights. Should've been part of #130826.
2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide.
3. 3rd commit: Apply the renaming to all UI tests (contents and paths).
2024-10-10 22:00:50 +02:00
Matthias Krüger
4f2af123eb
Rollup merge of #131033 - compiler-errors:precise-capturing-in-traits, r=spastorino
Precise capturing in traits

This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work.

Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though.

I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs.

r? types

Tracking issue:
* #130044
2024-10-10 22:00:48 +02:00
Matthias Krüger
edb669350a
Rollup merge of #130741 - mrkajetanp:detect-b16b16, r=Amanieu
rustc_target: Add sme-b16b16 as an explicit aarch64 target feature

LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.

Resolves https://github.com/rust-lang/rust/pull/129894.
2024-10-10 22:00:48 +02:00
Matthias Krüger
13976f1f25
Rollup merge of #130308 - davidtwco:tied-target-consolidation, r=wesleywiser
codegen_ssa: consolidate tied target checks

Fixes #105110.
Fixes #105111.

`rustc_codegen_llvm` and `rustc_codegen_gcc` duplicated logic for checking if tied target features were partially enabled. This PR consolidates these checks into `rustc_codegen_ssa` in the `codegen_fn_attrs` query, which also is run pre-monomorphisation for each function, which ensures that this check is run for unused functions, as would be expected.

Also adds a test confirming that enabling one tied feature doesn't imply another - the appropriate error for this was already being emitted. I did a bisect and narrowed it down to two patches it was likely to be - something in #128796, probably #128221 or #128679.
2024-10-10 22:00:45 +02:00
Michael Goulet
36076ecdc7 Clarify implicit captures for RPITIT 2024-10-10 11:46:51 -07:00
Michael Goulet
a7dc98733d Add variances to RPITITs 2024-10-10 11:46:48 -07:00
Michael Goulet
b7297ac440 Add gate for precise capturing in traits 2024-10-10 11:44:11 -07:00
bors
8d94e06ec9 Auto merge of #131263 - compiler-errors:solver-relating, r=lcnr
Introduce SolverRelating type relation to the new solver

Redux of #128744.

Splits out relate for the new solver so that implementors don't need to implement it themselves.

r? lcnr
2024-10-10 14:59:40 +00:00
bjorn3
ccd1bc2ad1 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.
2024-10-10 14:24:43 +00:00
Gary Guo
bb531083cc Fix longjmp-across-rust test
Destructor are removed from stack because it's considered UB.
2024-10-10 15:02:47 +01:00
Joshua Wong
5e474f7d83 allocate before calling T::default in <Arc<T>>::default()
Same rationale as in the previous commit.
2024-10-10 09:50:35 -04:00
Joshua Wong
dd0620b867 allocate before calling T::default in <Box<T>>::default()
The `Box<T: Default>` impl currently calls `T::default()` before allocating
the `Box`.

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.

Create an uninit `Box` first, and then write `T::default` into it, so that LLVM now only needs to prove
that the `T::default` can't panic, which should be trivial for most `Default` impls.
2024-10-10 09:49:24 -04:00
Joshua Wong
8a1462265f add initial tests for placement new changes 2024-10-10 09:47:26 -04:00
Matthias Krüger
1c62cff897
Rollup merge of #131491 - lcnr:nalgebra-perrrrf, r=compiler-errors
impossible obligations fast path

fixes the remaining performance regression in nalgebra for #130654

r? `@compiler-errors`

Fixes #124894
2024-10-10 12:49:22 +02:00
Matthias Krüger
02930953d8
Rollup merge of #131482 - compiler-errors:struct-res, r=lcnr
structurally resolve adts and tuples expectations too

r? lcnr
2024-10-10 12:49:21 +02:00
Matthias Krüger
a2c43eb806
Rollup merge of #131397 - RalfJung:const-escaping-ref-teach, r=chenyukang
fix/update teach_note from 'escaping mutable ref/ptr' const-check

The old note was quite confusing since it talked about statics, but the message is also shown for consts. So let's reword to something that is true for both of them.
2024-10-10 12:49:19 +02:00
Kajetan Puchalski
335f67b652 rustc_target: Add sme-b16b16 as an explicit aarch64 target feature
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
2024-10-10 10:24:57 +00:00
lcnr
d6fd45c2e3 impossible obligations check fast path 2024-10-10 06:09:50 -04:00
Michael Goulet
09da2ebd63 Move ty::Error branch into super_combine_tys 2024-10-10 06:07:51 -04:00