Skip to content

Conversation

@workflows-miri
Copy link

Merge ref '6244effd0372' from rust-lang/rust

Pull recent changes from https://github.com/rust-lang/rust via Josh.

Upstream ref: 6244effd0372d5d88fc859d3bf17ce1efcc2c9ec
Filtered ref: 2b788f9
Upstream diff: rust-lang/rust@96fe3c3...6244eff

This merge was created using https://github.com/rust-lang/josh-sync.

oli-obk and others added 15 commits October 21, 2025 11:22
… r=the8472,joshtriplett

Add `FromIterator` impls for `ascii::Char`s to `String`s

Wanted to `collect` ascii chars into a `String` while working on #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 #110998
Add NonNull pattern types

These are the final piece missing for

* rust-lang/rust#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`
…ror, r=nnethercote

Code refactoring on hir report_no_match_method_error

While working on rust-lang/rust#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`
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/rust#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/rust#147930 merges.

cc `@tgross35` (for earlier review)
cc `@alexcrichton,` `@rylev,` `@loganek` (for WASI)
cc `@lasiotus` (for Motor OS)
cc `@jackpot51` (for Redox OS)
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
Rollup of 7 pull requests

Successful merges:

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

r? `@ghost`
`@rustbot` modify labels: rollup
Forbid ShallowInitBox after box deref elaboration.

MIR currently contains a `ShallowInitBox` rvalue. Its principal usage is to allow for in-place initialization of boxes. Having it is necessary for drop elaboration to be correct with that in-place initialization.

As part of analysis->runtime MIR lowering, we canonicalize deref of boxes to use the stored raw pointer. But we did not perform the same change to the construction of the box.

This PR replaces `ShallowInitBox` by the pointer manipulation it represents.

Alternatives:
- fully remove `ShallowInitBox` and implement `Box` in-place initialization differently;
- remove the `ElaborateBoxDeref` pass and keep dereferencing `Box` in runtime MIR.
Update typos

I saw that `typos` was a few versions out of date and figured it would be a good idea to update it. Upgrading to `1.38.1` adds the [July](crate-ci/typos#1331), [August](crate-ci/typos#1345), and [September](crate-ci/typos#1370) dictionary updates. As part of this change, I also sorted the configuration file.
refactor: Move to anstream + anstyle for styling

`rustc` uses [`termcolor`](https://crates.io/crates/termcolor) for styling and writing, while `annotate-snippets` uses [`anstyle`](https://crates.io/crates/anstyle) for styling and currently writes directly to a `String`. When rendering directly to a terminal, there isn't/shouldn't be any differences. Still, there are differences in the escape sequences, which leads to slightly different output in JSON and SVG tests. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I switched `rustc` to use `anstlye` and [`anstream`](https://crates.io/crates/anstream) for styling and writing.

The first commit migrates to `anstyle` and `anstream` and notably does not change the output. This is because it includes extra formatting to ensure that `anstyle` + `anstream` match the current output exactly. Most of this code is unnecessary, as it adds redundant resets or uses 256-color (8-bit) when it could be using 4-bit color. The subsequent commits remove this extra formatting while maintaining the correct output when rendered.

[Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
Split LTO out of the main codegen coordinator event loop into a separate event loop on the same thread

This will make it easier to in the future move all this code to link_binary.

Follow up to rust-lang/rust#146209
Part of rust-lang/compiler-team#908
This updates the rust-version file to 6244effd0372d5d88fc859d3bf17ce1efcc2c9ec.
Pull recent changes from https://github.com/rust-lang/rust via Josh.

Upstream ref: 6244effd0372d5d88fc859d3bf17ce1efcc2c9ec
Filtered ref: 2b788f9
Upstream diff: rust-lang/rust@96fe3c3...6244eff

This merge was created using https://github.com/rust-lang/josh-sync.
@rustbot
Copy link
Collaborator

rustbot commented Oct 23, 2025

Thank you for contributing to Miri!
Please remember to not force-push to the PR branch except when you need to rebase due to a conflict or when the reviewer asks you for it.

@rustbot rustbot added the S-waiting-on-review Status: Waiting for a review to complete label Oct 23, 2025
@oli-obk oli-obk enabled auto-merge October 23, 2025 05:07
@oli-obk oli-obk added this pull request to the merge queue Oct 23, 2025
Merged via the queue into master with commit 93e37ea Oct 23, 2025
13 checks passed
@oli-obk oli-obk deleted the rustup-2025-10-23 branch October 23, 2025 05:52
@rustbot rustbot removed the S-waiting-on-review Status: Waiting for a review to complete label Oct 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants