Rollup of 12 pull requests - #162100
Closed
jhpratt wants to merge 38 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.
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 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-*
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #162014, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
Contributor
|
💔 Test for 273328f failed: CI. Failed jobs:
|
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
13 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)rustdoc-htmltests using--testinto the right folder #162014 (Move morerustdoc-htmltests using--testinto the right folder)rustc_featurecleanups #162051 (rustc_featurecleanups)_{style}recovery for diagnostic structs #162055 (remove_{style}recovery for diagnostic structs)r? @ghost
Create a similar rollup