Rollup of 11 pull requests - #162101
Closed
jhpratt wants to merge 35 commits into
Closed
Conversation
The existing name doesn't give a good intuition for what's actually happening, which is that we lower a (possibly complex) boolean condition and then proceed if it's true or break if it's false. This commit also directly exposes the arguments struct to callers, since it makes the call sites more self-documenting.
This convention is a little less intuitive for simple if-expressions, but is easier to follow when dealing with complex nested conditions or with other if-like constructs.
Also contains a formatting change due to rustfmt bump
Rename it `BUILTIN_ATTRIBUTE_SET` because it's a set, and use `contains` instead of `get` where appropriate.
Also fix a typo and wrap some overlong comment lines.
It's more idiomatic.
Fix typos, wrap overlong lines, add missing comments, etc.
Avoid mixing it with `NonZeroU32`.
Every caller passes a predicate that just does a name comparison.
For dist-aarch64-linux (full): * GHA 8c takes 2h25m ($2.03/build) * c8g.8xl takes 1h20m ($1.69/build) * c9g.8xl takes 1h ($1.38/build) * c9g.4xl takes 1h10m ($0.81/build) * m9g.2xl takes 1h30m ($0.59/build) - selected And adds a dist-aarch64-linux-quick: * c8g.8xl takes 50m ($1.059/build) * c9g.8xl takes 40m ($0.924/build) * c9g.4xl takes 47m ($0.543/build) - selected * m9g.2xl takes 64m ($0.417/build) For now I've chosen a balance between cost and speed (c9g.4xl). Once we decide where to enable this (e.g., in try builds by default) we can consider aligning with other tasks and saving $/build if we're not able to benefit from increased speed (e.g., because perf won't run until the try build as a whole finishes). For dist-x86_64-linux-full we have this breakdown: * c8a.8xl takes 1h34m ($2.64/build) - current * c8a.4xl takes 1h45m ($1.51/build) - selected * m8a.2xl takes 2h10m ($1.05/build) I'll re-benchmark dist-x86_64-linux-quick in a future PR, for now it will stay on c8a.8xl. This drops codebuild configuration (but not yet cleaning up various related pieces that are more tied into our CI) since it doesn't seem relevant anymore.
…eature, r=Amanieu support `#[target_feature(enable = ...)]` on `#[naked]` functions fixes rust-lang#136280 Instructions that are part of a target feature require a special directive on some targets. This PR adds those for the most common targets. This is very WIP, but I'm hoping to collect some feedback on what is (not) supported and how to report that to users. r? @ghost cc @taiki-e @Amanieu
…ap, r=nia-e stabilize smart pointer map functions Tracking issue: rust-lang#144419 @rustbot modify labels: +T-libs-api
mir_build: Clearly distinguish or/refutable/irrefutable patterns during match lowering This PR has two related parts. - The first commit divides the various fields of InterPat into three different `InterPatKind` variants, which clearly distinguish between or-pattern nodes, refutable pattern nodes, and irrefutable pattern nodes. Such a split was suggested during review of rust-lang#155144, but at the time I wasn't sure if it was the right direction. Now that I've thought more about how to make it work nicely with InterPat node building, I'm more comfortable with the explicit split. - As a follow-on, the second commit then splits MatchPairTree into two different `MatchPairKind` variants: one for or-pattern nodes, and one for “testable” nodes. In both cases, dividing the outer struct into multiple kinds makes it easier to understand and uphold field invariants, since previously-optional fields can be made mandatory or absent. There should be no change to compiler output. --- - The changes to MatchPairTree can be seen as an alternative to rust-lang#158551. Instead of splitting or-patterns and testable-patterns into separate lists, they still occupy the same list but are distinguished by kind. --- r? Nadrieril
mir_build: Clarify parts of if-condition lowering I've been looking at this condition-lowering code a lot, and I noticed that some parts are hard to follow due to how functions and variables are named. In particular, the function name `then_else_break` doesn't give much useful intuition for the fact that it lowers an `if` condition (or similar), and then proceeds if the condition was true or breaks if the condition was false. Similarly, I was finding it hard to keep track of the two destinations selected after evaluating a condition, especially when dealing with complex subconditions like `||` or `!`, or looking at different callers. So this PR tries to establish a convention of always using `(true_block, false_block)` to refer to the condition's outcome paths, which can then be manipulated as appropriate by calling code. There should be no observable change to compiler behaviour.
…-args, r=BoxyUwU explicitly track inherent const generic args kind in doing so, and as an exercise of this new code, implement regular (non-type-const) inherent consts in the type system under `feature(generic_const_args)` see the new big doc comment in `compiler/rustc_type_ir/src/const_kind.rs` if you dunno what the heck I'm on about with "self args" vs "impl args" ✨ on a small note, the FIXME on `alias_term_kind_from_def_id` becomes even more relevant with this PR, `ty::AliasConstInherentArgsKind` is kinda gross tbh. explicitly not refactoring that in this PR though, to keep scope/the diff manageable. also, `check_args_compatible` is very spooky scary in that if you have a `ty::Alias`, you ought to use `check_term_args_compatible`, but nothing's stopping you from calling `check_args_compatible` with the term's DefId. I was unable to think up a clever API that would prevent this misuse. and finally, I think some of these match statements could theoretically `bug!` on one form or the other of InherentSelf/InherentImpl, but for now I'm intentionally being a bit conservative here, we can tighten up later. --- relevant tracking issue: rust-lang/project-const-generics#98 also very related to `feature(inherent_associated_types)`: rust-lang#8995 rust-lang/project-const-generics#71 relevant PR that intentionally failed to implement inherent consts in the type system due to not tracking this: rust-lang#155341 implementing support for a trait with a regular const being refined with an impl that has a directly represented RHS is extremely annoying and difficult without this, the lack of support of which causes rust-lang#161264 (was working on adding support when I got sidetracked with this PR), see also this zulip thread: [#project-const-generics > implementing assoc consts as direct args](https://rust-lang.zulipchat.com/#narrow/channel/260443-project-const-generics/topic/implementing.20assoc.20consts.20as.20direct.20args/with/618953051) (is there an issue for this?) r? @BoxyUwU
bootstrap: stage0 to cbae9b4 This also contains a formatting change due to rustfmt bump. Need this in order to test <rust-lang#161049>. See also [#t-cargo > ✔ 1.99 beta backport](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/.E2.9C.94.201.2E99.20beta.20backport/with/619824670) r? cuviper
…, r=JonathanBrouwer `rustc_feature` cleanups Various cleanups. Details in individual commits. r? @JonathanBrouwer
remove `_{style}` recovery for diagnostic structs
Followup to rust-lang#103575
Also documents the `style = "..."` option.
… r=JonathanBrouwer Move track_caller on closures gating to attribute parsing I noticed this while reviewing rust-lang#161958
rustbot
added
A-attributes
Member
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
Sep 1, 2026
Rollup of 11 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-*
Contributor
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
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
12 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:
#[target_feature(enable = ...)]on#[naked]functions #137720 (support#[target_feature(enable = ...)]on#[naked]functions)rustc_featurecleanups #162051 (rustc_featurecleanups)_{style}recovery for diagnostic structs #162055 (remove_{style}recovery for diagnostic structs)r? @ghost
Create a similar rollup