Skip to content

Conversation

@matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

compiler-errors and others added 13 commits January 11, 2025 18:44
…=tgross35

Add inherent versions of MaybeUninit methods for slices

This is my attempt to un-stall rust-lang#63569 and rust-lang#79995, by creating methods that mirror the existing `MaybeUninit` API:

```rust
impl<T> MaybeUninit<T> {
    pub fn write(&mut self, value: T) -> &mut T;
    pub fn as_bytes(&self) -> &[MaybeUninit<u8>];
    pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>];
    pub unsafe fn assume_init_drop(&mut self);
    pub unsafe fn assume_init_ref(&self) -> &T;
    pub unsafe fn assume_init_mut(&mut self) -> &mut T;
}
```

Adding these APIs:

```rust
impl<T> [MaybeUninit<T>] {
    // replacing copy_from_slice; renamed to avoid conflict
    pub fn write_copy_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Copy;

    // replacing clone_from_slice; renamed to avoid conflict
    pub fn write_clone_of_slice(&mut self, value: &[T]) -> &mut [T] where T: Clone;

    // identical to non-slice versions; no conflict
    pub fn as_bytes(&self) -> &[MaybeUninit<u8>];
    pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>];
    pub unsafe fn assume_init_drop(&mut self);
    pub unsafe fn assume_init_ref(&self) -> &[T];
    pub unsafe fn assume_init_mut(&mut self) -> &mut [T];
}
```

Since the `assume_init` methods are identical to those on non-slices, they feel pretty natural. The main issue with the write methods is naming, as discussed in rust-lang#79995 among other places. My rationale:

* The term "write" should be in them somewhere, to mirror the other API, and this pretty much automatically makes them not collide with any other inherent slice methods.
* I chose `write_clone_of_slice` and `write_copy_of_slice` since `clone` and `copy` are being used as objects here, whereas they're being used as actions in `clone_from_slice` and `copy_from_slice`.

The final "weird" thing I've done in this PR is remove a link to `Vec<T>` from `assume_init_drop` (both copies, since they're effectively copied docs), since there's no good way to link to `Vec` for something that can occur both on the page for `std/primitive.slice.html` and `std/vec/struct.Vec.html`, since the code here lives in libcore and can't use intra-doc-linking to mention `Vec`. (see: rust-lang#121436)

The reason why this method shows up both on `Vec<T>` and `[T]` is because the `[T]` docs are automatically inlined on `Vec<T>`'s page, since it implements `Deref`. It's unfortunate that rustdoc doesn't have a way of dealing with this at the moment, but it is what it is, and it's a reasonable compromise for now.
… r=fee1-dead

Suggest typo fix when trait path expression is typo'ed

When users write something like `Default::defualt()` (notice the typo), failure to resolve the erroneous `defualt` item will cause resolution + lowering to interpret this as a type-dependent path whose self type is `Default` which is a trait object without `dyn`, rather than a trait function like `<_ as Default>::default()`.

Try to provide a bit of guidance in this situation when we can detect the typo.

Fixes rust-lang#135349
…=oli-obk

Make MIR cleanup for functions with impossible predicates into a real MIR pass

It's a bit jarring to see the body of a function with an impossible-to-satisfy where clause suddenly go to a single `unreachable` terminator when looking at the MIR dump output in order, and I discovered it's because we manually replace the body outside of a MIR pass.

Let's make it into a fully flegded MIR pass so it's more clear what it's doing and when it's being applied.
…ng, r=chenyukang

Remove a bunch of diagnostic stashing that doesn't do anything

rust-lang#121669 removed a bunch of conditional diagnostic stashing/canceling, but left around the `steal` calls which just emitted the error eagerly instead of canceling the diagnostic. I think that these no-op `steal` calls don't do much and are confusing to encounter, so let's remove them.

The net effect is:
1. We emit more duplicated errors, since stashing has the side effect of duplicating diagnostics. This is not a big deal, since outside of `-Zdeduplicate-diagnostics=no`, the errors are already being deduplicated by the compiler.
2. It changes the order of diagnostics, since we're no longer stashing and then later stealing the errors. I don't think this matters much for the changes that the UI test suite manifests, and it makes these errors less order dependent.
compiletest: add erroneous variant to `string_enum`s conversions error

As requested in rust-lang#135392, this adds which variant caused the string conversion failure.

r? jieyouxu
fixes rust-lang#135392
add more crash tests

try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
@rustbot rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jan 12, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jan 12, 2025

📌 Commit 2fd11d0 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 12, 2025
@bors
Copy link
Collaborator

bors commented Jan 12, 2025

⌛ Testing commit 2fd11d0 with merge 7bb9888...

@bors
Copy link
Collaborator

bors commented Jan 12, 2025

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 7bb9888 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 12, 2025
@bors bors merged commit 7bb9888 into rust-lang:master Jan 12, 2025
7 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Jan 12, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#129259 Add inherent versions of MaybeUninit methods for slices 9be56ee861354b6291d6c9cfb2a2d5d34ea45f40 (link)
#135374 Suggest typo fix when trait path expression is typo'ed 54550e9d86b2d6fe88f31295ea976411b1ee79b4 (link)
#135377 Make MIR cleanup for functions with impossible predicates i… ace23307be56fef65f4987b386e4c4d5b155ec49 (link)
#135378 Remove a bunch of diagnostic stashing that doesn't do anyth… 36f8b4598aa82d2af002bbc6c42f5fc1d10681bc (link)
#135397 compiletest: add erroneous variant to string_enums conver… 6b96e4c83f643abe17b4782370a1ef973d099eca (link)
#135398 add more crash tests df18a9fbb016d4ecf1eab68e7c92da0690a775e9 (link)

previous master: c0f6a1ce3f

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7bb9888): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.2% [0.2%, 0.3%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.0% [-3.3%, -0.6%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.0% [-3.3%, -0.6%] 2

Cycles

Results (primary 2.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.5% [2.5%, 2.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.5% [2.5%, 2.5%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 761.573s -> 763.652s (0.27%)
Artifact size: 326.13 MiB -> 326.10 MiB (-0.01%)

@matthiaskrgr matthiaskrgr deleted the rollup-cz7hs13 branch January 25, 2025 09:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. O-windows Operating system: Windows rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants