Rollup of 7 pull requests #147957

matthiaskrgr · 2025-10-22T05:12:13Z

Successful merges:

Add FromIterator impls for ascii::Chars to Strings #141445 (Add FromIterator impls for ascii::Chars to Strings)
Add NonNull pattern types #142339 (Add NonNull pattern types)
Code refactoring on hir report_no_match_method_error #147768 (Code refactoring on hir report_no_match_method_error)
const Cell methods #147788 (const Cell methods)
Create UTF-8 version of OsStr/OsString #147932 (Create UTF-8 version of OsStr/OsString)
os_str: Make platform docs more consistent #147933 (os_str: Make platform docs more consistent)
PassWrapper: Access GlobalValueSummaryInfo::SummaryList via getter for LLVM 22+ #147948 (PassWrapper: Access GlobalValueSummaryInfo::SummaryList via getter for LLVM 22+)

r? @ghost
@rustbot modify labels: rollup

- Port `Buf::as_slice`/`as_mut_slice` wording from wtf8 to bytes - Make `Buf::extend_from_slice_unchecked` docs more platform-independent - wtf8 `Buf` was missing `#[repr(transparent)]`

@rustbot

…r LLVM 22+ llvm/llvm-project#164355 makes SummaryList private and provides a getter method. @rustbot label llvm-main

…r-string, r=the8472,joshtriplett Add `FromIterator` impls for `ascii::Char`s to `String`s Wanted to `collect` ascii chars into a `String` while working on rust-lang#141369 , and was surprised these impls don't exist. Seems to me to be simply oversight. BTW, I only added `impl FromIterator<ascii::Char> for Cow<'_, str>`, without a corresponding `FromIterator<&Char>` impl, because there's no existing impl for `FromIterator<&char>`, but that might be oversight too. cc rust-lang#110998

…BoxyUwU Add NonNull pattern types These are the final piece missing for * rust-lang#136006 We cannot use the previous scheme of using an integer range for raw pointers, as we're not just changing the layout of raw pointers anymore, but also the type representation. And we can't represent "any provenance or NonZero<usize>" natively as patterns. So I created a new `!null` pattern. Since this is all unstable representation stuff for replacing rustc_layout_scalar_range_start with pattern types, the divergence from normal patterns is fine, especially since T-lang seems interested in exploring general negation patterns r? `@BoxyUwU`

…method-error, r=nnethercote Code refactoring on hir report_no_match_method_error While working on rust-lang#147753, I found `report_no_match_method_error` now is too long for maintain, 1200 lines of code now: https://github.com/rust-lang/rust/blob/57ef8d642d21965304bde849bab4f389b4353e27/compiler/rustc_hir_typeck/src/method/suggest.rs#L589-L1736 this PR try to refactor it. I tried my best to group most related code into same places, but the logic here is still very complex, there are some variables across different functions, maybe we need more work to make it better understand. Maybe we could add a tidy check to avoid long spaghetti code. r? `@nnethercote`

const Cell methods Tracking: rust-lang#147787 r? `@oli-obk`

Create UTF-8 version of `OsStr`/`OsString` Implement a UTF-8 version of `OsStr`/`OsString`, in addition to the existing bytes and WTF-8 platform-dependent encodings. This is applicable for several platforms, but I've currently only implemented it for Motor OS: - WASI uses Unicode paths, but currently reexports the Unix bytes-assuming `OsStrExt`/`OsStringExt` traits. - [wasi:filesystem](https://wa.dev/wasi:filesystem) APIs: > Paths are passed as interface-type `strings`, meaning they must consist of a sequence of Unicode Scalar Values (USVs). Some filesystems may contain paths which are not accessible by this API. - In [wasi-filesystem#17](WebAssembly/wasi-filesystem#17 (comment)), it was decided that applications can use any Unicode transformation format, so we're free to use UTF-8 (and probably already do). This was chosen over specifically UTF-8 or an ad hoc encoding which preserves paths not representable in UTF-8. > The current API uses strings for filesystem paths, which contains sequences of Unicode scalar values (USVs), which applications can work with using strings encoded in UTF-8, UTF-16, or other Unicode encodings. > > This does mean that the API is unable to open files which do not have well-formed Unicode encodings, which may want separate APIs for handling such paths or may want something like the arf-strings proposal, but if we need that we should file a new issue for it. - As of Redox OS [0.7.0](https://www.redox-os.org/news/release-0.7.0/), "All paths are now required to be UTF-8, and the kernel enforces this". This appears to have been implemented in commit [d331f72f](https://gitlab.redox-os.org/redox-os/kernel/-/commit/d331f72f2a51fa577072f24bc2587829fd87368b) (Use UTF-8 for all paths, 2021-02-14). Redox does not have `OsStrExt`/`OsStringExt`. - Motor OS guarantees that its OS strings are UTF-8 in its [current `OsStrExt`/`OsStringExt` traits](https://github.com/moturus/rust/blob/a828ffcf5f04be5cdd91b5fad608102eabc17ec7/library/std/src/os/motor/ffi.rs), but they're still internally bytes like Unix. This is an alternate approach to rust-lang#147797, which reuses the existing bytes `OsString` and relies on the safety properties of `from_encoded_bytes_unchecked`. Compared to that, this also gains efficiency from propagating the UTF-8 invariant to the whole type, as it never needs to test for UTF-8 validity. Note that Motor OS currently does not build until rust-lang#147930 merges. cc `@tgross35` (for earlier review) cc `@alexcrichton,` `@rylev,` `@loganek` (for WASI) cc `@lasiotus` (for Motor OS) cc `@jackpot51` (for Redox OS)

…=tgross35 os_str: Make platform docs more consistent - Port `Buf::as_slice`/`as_mut_slice` wording from wtf8 to bytes - Make `Buf::extend_from_slice_unchecked` docs more platform-independent - wtf8 `Buf` was missing `#[repr(transparent)]`

PassWrapper: Access GlobalValueSummaryInfo::SummaryList via getter for LLVM 22+ llvm/llvm-project#164355 makes SummaryList private and provides a getter method. `@rustbot` label llvm-main

matthiaskrgr · 2025-10-22T05:12:35Z

@bors r+ rollup=never p=5

bors · 2025-10-22T05:12:38Z

📌 Commit e132d2d has been approved by matthiaskrgr

It is now in the queue for this repository.

bors · 2025-10-22T06:43:43Z

⌛ Testing commit e132d2d with merge b2ee1b3...

bors · 2025-10-22T09:52:41Z

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

github-actions · 2025-10-22T09:55:28Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 0d7813d (parent) -> b2ee1b3 (this PR)

Test differences

Show 355 test diffs

Stage 1

[ui] tests/ui/type/pattern_types/non_null.rs: [missing] -> pass (J1)
[ui] tests/ui/type/pattern_types/unsize.rs: [missing] -> pass (J1)
manually_drop::const_drop_in_place: [missing] -> pass (J2)
ptr::test_const_drop_in_place: pass -> [missing] (J2)

Stage 2

[ui] tests/ui/type/pattern_types/non_null.rs: [missing] -> ignore (only executed when the pointer width is 64bit) (J0)
manually_drop::const_drop_in_place: [missing] -> pass (J3)
ptr::test_const_drop_in_place: pass -> [missing] (J3)
[ui] tests/ui/type/pattern_types/unsize.rs: [missing] -> pass (J4)
[ui] tests/ui/type/pattern_types/non_null.rs: [missing] -> pass (J5)

Additionally, 346 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard b2ee1b333aea9951c3eefa4967098cc763de59ca --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

dist-aarch64-apple: 5771.2s -> 7285.9s (26.2%)
pr-check-1: 1474.5s -> 1830.0s (24.1%)
dist-android: 1578.9s -> 1202.1s (-23.9%)
x86_64-gnu-llvm-20: 2410.5s -> 2869.8s (19.1%)
dist-x86_64-apple: 6244.5s -> 7432.0s (19.0%)
x86_64-gnu-gcc: 3021.8s -> 3556.9s (17.7%)
i686-gnu-2: 5434.9s -> 6303.5s (16.0%)
aarch64-apple: 9777.3s -> 8304.2s (-15.1%)
dist-aarch64-msvc: 5423.5s -> 6198.1s (14.3%)
i686-gnu-nopt-1: 7242.9s -> 8164.0s (12.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-10-22T11:03:41Z

Finished benchmarking commit (b2ee1b3): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	2
Regressions ❌ (secondary)	0.2%	[0.0%, 0.7%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	0.1%	[0.1%, 0.1%]	2

Max RSS (memory usage)

Results (primary -2.0%, secondary -2.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.2%	[2.8%, 3.4%]	3
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-3.9%	[-4.6%, -2.4%]	10
All ❌✅ (primary)	-2.0%	[-2.0%, -2.0%]	1

Cycles

Results (secondary 2.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.5%	[1.8%, 13.4%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.2%	[-7.9%, -1.8%]	6
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 473.118s -> 472.274s (-0.18%)
Artifact size: 388.68 MiB -> 390.70 MiB (0.52%)

yotamofek and others added 22 commits May 23, 2025 15:20

Add FromIterator impls for ascii::Chars to Strings

8569bb2

const Cell methods

97b7170

Move const_drop_in_place test from ptr to manually_drop module

31a2c56

os_str: Make platform docs more consistent

563302e

- Port `Buf::as_slice`/`as_mut_slice` wording from wtf8 to bytes - Make `Buf::extend_from_slice_unchecked` docs more platform-independent - wtf8 `Buf` was missing `#[repr(transparent)]`

Pattern types have their base type as a field

d9f22d2

Add not-null pointer patterns to pattern types

ad4bd08

Allow unsizing pattern types with pointer base

375899c

PassWrapper: Access GlobalValueSummaryInfo::SummaryList via getter fo…

fc7c4be

…r LLVM 22+ llvm/llvm-project#164355 makes SummaryList private and provides a getter method. @rustbot label llvm-main

format

f38839a

actually compile

875cc36

os_str: Create UTF-8 platform encoding

206ffcc

format

1e80546

motor: Use UTF-8 guarantee for OS strings

7e2b76e

code refactoring on report_no_match_method_error

92d5196

add UnsatisfiedPredicate type alias

38e8066

Rollup merge of rust-lang#147788 - clarfonthey:const-cell, r=oli-obk

8c40b9c

const Cell methods Tracking: rust-lang#147787 r? `@oli-obk`

Rollup merge of rust-lang#147948 - aeubanks:summarylist, r=durin42

e132d2d

PassWrapper: Access GlobalValueSummaryInfo::SummaryList via getter for LLVM 22+ llvm/llvm-project#164355 makes SummaryList private and provides a getter method. `@rustbot` label llvm-main

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 Oct 22, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 22, 2025

bors merged commit b2ee1b3 into rust-lang:master Oct 22, 2025
12 checks passed

rustbot added this to the 1.92.0 milestone Oct 22, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Rollup of 7 pull requests #147957

Rollup of 7 pull requests #147957

Uh oh!

matthiaskrgr commented Oct 22, 2025 •

edited by rustbot

Loading

Uh oh!

matthiaskrgr commented Oct 22, 2025

Uh oh!

bors commented Oct 22, 2025

Uh oh!

bors commented Oct 22, 2025

Uh oh!

bors commented Oct 22, 2025

Uh oh!

Uh oh!

github-actions bot commented Oct 22, 2025

Stage 1

Stage 2

Uh oh!

rust-timer commented Oct 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Rollup of 7 pull requests #147957

Rollup of 7 pull requests #147957

Uh oh!

Conversation

matthiaskrgr commented Oct 22, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matthiaskrgr commented Oct 22, 2025

Uh oh!

bors commented Oct 22, 2025

Uh oh!

bors commented Oct 22, 2025

Uh oh!

bors commented Oct 22, 2025

Uh oh!

Uh oh!

github-actions bot commented Oct 22, 2025

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Oct 22, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

matthiaskrgr commented Oct 22, 2025 •

edited by rustbot

Loading