Rollup of 12 pull requests#158858
Closed
JonathanBrouwer wants to merge 36 commits into
Closed
Conversation
Comments and doc links across std, core, and a process test referenced the older issue 7 (2018 edition) of the POSIX spec, with one link still on issue 6. Point them all at the current issue 8 (2024 edition, IEEE Std 1003.1-2024) under onlinepubs/9799919799, and normalize the `9799919799.2024edition` URL variant to the canonical path. Links that carry a section anchor were verified against the 2024 edition, since section numbering shifts between editions: - Pathname Resolution moved from 4.13 (tag_04_13) to 4.16 (tag_04_16) - Field Splitting moved from tag_18_06_05 to tag_19_06_05 - LC_CTYPE (tag_07_03_01) was unchanged CI's linkchecker only validates intra-doc links, not external URLs, so each page and anchor was checked by hand.
With comparing `sub_unification_table_root_var` you can have an arbitraty long chain of subtyping relatinships, i.e. a <: b :> c <: d :> e ..., where all a/b/c/d/e/... get the same sub root var. So it's not necessarily true that there exists a type that is directly sub/super of the types compared via `sub_unification_table_root_var`.
As per rust-lang#155114 (comment), this `From` impl no longer guarantees panicking for exhausted iterators. Instead, it only guarantees that the conversion will either panic or produce an empty range. This is done so that we can optimize the implementation of `legacy::RangeInclusive` in a way such that we cannot check if it has been exhausted in a generic context without a `Step` and/or `PartialOrd` bound.
… fails to satisfy an `impl Trait` bound
the old solver doesn't register `TypeOutlives` and `RegionOutlives` goals if `ignoring_regions` is set. The new solver always registers these requirements, so we instead ignore errors caused by these constraints.
Co-Authored-By: Clar Fon <15850505+clarfonthey@users.noreply.github.com>
* add regression test for deprecated note on inlined reexport chain * resolve deprecated-note links from the owning reexport * add a comment to regression test
…h726 enable eager `param_env` norm in new solver https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/goodbye.20proper.20param_env.20normalization/near/594260464 Slightly unfortunate that this is what we ended up with. but for now, this fixes issues and landing the new solver with this is certainly not worse than keeping the old impl. This PR only eagerly normalizes, it does not *yet* treat aliases in `param_env` candidates as rigid, which is the worse part of this change. fixes rust-lang/trait-system-refactor-initiative#265 fixes rust-lang#136661 r? @BoxyUwU
…fonthey Move `std::io::Seek` to `core::io` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 Split From: rust-lang#156527 Blocked On: rust-lang#158539 ## Description Moves `std::io::Seek` and `SeekFrom` to `core::io`. This is a pretty simple migration, but it is blocked by rust-lang#158539. --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see rust-lang#154046 (comment) for a review order and broader context for this PR.
consider subtyping when checking if an infer var is sized That is, when checking if an inference variable (say `?0`) is sized, with this PR, we now check for obligations like `?1: Sized`, where `?0` and `?1` are transitively related via subtyping (previously we were checking for `?0 = ?1`). This is sound because subtyping cannot change sized-ness. This fixes the 4-th point/issue from rust-lang#155924. Specifically, it makes this code compile: ```rust fn blah(e: !) { let source = Box::new(e); let _: Box<dyn Send> = source; } ``` This also fixes `tests/ui/impl-trait/unsized_coercion.rs` on new solver, see rust-lang#157820 (comment). r? types
…on, r=Darksonn Update POSIX edition links Comments that reference https://pubs.opengroup.org point to issue 7 (the 2018 edition of IEEE Std 1003.1-2017), with one link still on the older issue 6. The latest issue is 8 (the 2024 edition, IEEE Std 1003.1-2024). From https://www.opengroup.org/austin/papers/posix_faq.html: > Q3. What is the latest version of POSIX.1? > > The 1003.1-2024 standard was published in June 2024. The standard is > formally known as: IEEE Std 1003.1-2024 The Open Group Technical > Standard Base Specifications, Issue 8 Issue 8 lives at https://pubs.opengroup.org/onlinepubs/9799919799/. This PR points all older-edition links to issue 8. Most links are a straight edition bump, but links with a section anchor needed their anchor rechecked, because section numbering shifts between editions. Verified against the 2024 edition: - Pathname Resolution moved from 4.13 (`tag_04_13`) to 4.16 (`tag_04_16`) - Field Splitting moved from `tag_18_06_05` to `tag_19_06_05` - LC_CTYPE (`tag_07_03_01`) was unchanged The Miri changes (`src/tools/miri/`) are kept in a separate commit since that's a synced subtree. I'm happy to move them to a `rust-lang/miri` PR if preferred.
…yukang Fix typo for link on nto-qnx.md Just a quick fix for a typo in nto-qnx.md that stopped the link from working.
Library support for aarch64-unknown-linux-pauthtest target This is a follow up to rust-lang#155722, adding library support for the target.
Better error message when bare type in impl parameter list Fixes rust-lang#147889 Marking this PR ready for feedback on this problem. The approach I'm trying is to create a snapshot parser and attempt to re-parse the input in another way. If it succeeds, we successfully predicted the user's intention and emit the related help message. If it fails, we cancel the errors produced during the attempt and report the original error. The problem is that parse functions may internally recover from parse failures and emit errors directly, which means we can't cancel them later. I saw that we have a `recovery` field to control the recovery mechanism, but it seems there are (maybe) a lot of places in the parser that don't check the recovery field before doing their recovery logic. Should we always use `look_ahead` instead of using a snapshot parser and calling another parse function?
…estion-cast-never-type, r=davidtwco Emit a suggestion to cast the never type into a concrete type when it fails to satisfy an `impl Trait` bound Fixes rust-lang#157923
Expose debug scope of statement and terminator in rustc_public Currently, `scope` is exposed for variables, but it is a meaningless number since the boundary of each scope is not available. This PR changes `span` fields of statement and terminator to `source_info` which includes scope as well. Disclaimer: Written by LLM
…avidtwco rustc_target: Add ARMv8-M related target features This adds the following unstable target features to `feature(arm_target_feature)` (tracking issue: rust-lang#150246): - `acquire-release`: Armv8 atomic instructions - `v6m`: Armv6-M instructions (implies `v6`) - `v8m`: Armv8-M baseline instructions (implies `v6m`) - `v8m.main`: Armv8-M mainline instructions (implies `v7`) - `v8.1m.main`: Armv8.1-M mainline instructions (implies `v8m.main`) - `mve`: M-Profile Vector Extension (Helium) for integer ops (implies `v8.1m.main`, `dsp`, and `fpregs`) - `mve.fp`: MVE for integer & float ops (implies `mve`) The target feature names match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-22.1.8/llvm/lib/Target/ARM/ARMFeatures.td#L597-L741). The dependencies should also match those in LLVM, unless there is no corresponding feature in Rust. This also adds `mve` to vector ABI check and resolve this comment. https://github.com/rust-lang/rust/blob/973ad0d0ab149bde2e96422833c1265c7a5be217/compiler/rustc_target/src/target_features.rs#L1076-L1078 One of the motivations for adding this: In LLVM, the `v8` target feature is not enabled for ARMv8-M targets, and `v8m`/`v8m.main` is enabled instead, so currently there is no way to detect ARMv8-M from target features. ```console $ rustc +nightly --print cfg --target thumbv8m.main-none-eabihf | grep target_feature target_feature="fpregs" target_feature="mclass" target_feature="thumb-mode" target_feature="thumb2" target_feature="v5te" target_feature="v6" target_feature="v6k" target_feature="v6t2" target_feature="v7" ``` r? @davidtwco cc @jonathanpallant @rustbot label +O-arm +A-target-feature
…=JohnTitor Weaken guarantee for `From<legacy::RangeInclusive> for RangeInclusive` As per rust-lang#155114 (comment), this `From` impl no longer guarantees panicking for exhausted iterators. Instead, it only guarantees that the conversion will either panic or produce an empty range. This is done so that we can optimize the implementation of `legacy::RangeInclusive` in a way such that we cannot check if it has been exhausted in a generic context without a `Step` and/or `PartialOrd` bound. If this PR and/or rust-lang#155114 merges after the 1.98.0 beta branch promotion from the main branch, then this will need a beta backport, since this PR changes the stable guarantee previously made in rust-lang#155421. This PR conflicts with and/or blocks rust-lang#155114.
…rt-chain, r=GuillaumeGomez Fix rustdoc ICE on deprecated note in inlined re-export chain Fixes rust-lang#158745
rustbot
added
O-unix
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 6, 2026
Rollup of 12 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-2
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
the
S-waiting-on-author
rust-bors
Bot
removed
the
S-waiting-on-bors
Contributor
|
PR #156548, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
rustbot
removed
the
S-waiting-on-author
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
💔 Test for 45ed011 failed: CI. Failed job:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
param_envnorm in new solver #156976 (enable eagerparam_envnorm in new solver)std::io::Seektocore::io#158540 (Movestd::io::Seektocore::io)impl Traitbound #157966 (Emit a suggestion to cast the never type into a concrete type when it fails to satisfy animpl Traitbound)From<legacy::RangeInclusive> for RangeInclusive#158770 (Weaken guarantee forFrom<legacy::RangeInclusive> for RangeInclusive)r? @ghost
Create a similar rollup