Rollup of 11 pull requests #137001
Merged
Rollup of 11 pull requests #137001
Conversation
This file contains 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
Previously, we unconditionally set the bitwidth to 128-bits, the largest an discrimnator would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit descriminators, so this would also have occasionally resulted in truncated data (or an assert) if more than 64-bits were used. LLVM added support for 128-bit enumerators in llvm/llvm-project#125578 That patchset also trusts the constant to describe how wide the variant tag is. As a result, we went from emitting tags that looked like: DW_AT_discr_value (0xfe) (`form1`) to emitting tags that looked like: DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ) This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which: 1. Is probably closer to our intentions in terms of describing the data. 2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools. 3. Will result in smaller debug information.
(S)ccache can be useful for more things that just LLVM. For example, we will soon want to use it also for GCC, and theoretically also for building stage0 Rust tools.
This continues two ongoing projects: - Replacing ascii art with real icons that don't look like syntax, are understandable to people who're familiar with desktop computers and smart devices, and aren't ugly. - Using labels and tooltips to clarify these icons, when the limits of popular iconography hit us. In this case, I've added tooltips, because, unfortunately, there's not room for always-visible labels.
When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
I told rhelmot to do this in rust-lang#134913. But it's not correct; compiletest shouldn't inherit RUSTFLAGS at all. Pass a single new --host-rustcflags to compiletest instead, without overwriting any existing arguments. Fixes the following failure, which only happens when building llvm from source and then running `x test --stage 1 ui-fulldeps`: ``` diff --git a/tests/ui-fulldeps/fluent-messages/test.stderr b/tests/ui-fulldeps/fluent-messages/test.stderr index 0b3bb14ce51..978ac46c5a2 100644 --- a/tests/ui-fulldeps/fluent-messages/test.stderr +++ b/tests/ui-fulldeps/fluent-messages/test.stderr @@ -1,3 +1,8 @@ +warning[E0602]: unknown lint: `linker_messages` + | + = note: requested on the command line with `-A linker_messages` + = note: `#[warn(unknown_lints)]` on by default ```
Signed-off-by: onur-ozkan <work@onurozkan.dev>
"stage 1" for fulldeps means "compile with stage 0, link against stage 1". But this code wanted to switch on the compiler that's building, not the compiler that's being tested. Fix the check. Previously, it would fail with a warning about linker-messages: ``` --- stderr ------------------------------- warning[E0602]: unknown lint: `linker_messages` | = note: requested on the command line with `-A linker_messages` = note: `#[warn(unknown_lints)]` on by default ```
…rors rework rigid alias handling Necessary for rust-lang#136824 if we treat coinductive cycles as errors as we otherwise don't emit an error for ```rust trait Overflow { type Assoc; } impl<T> Overflow for T { type Assoc = <T as Overflow>::Assoc; } ``` The important part is that we only add a `RigidAlias` candidate in cases where the alias is actually supposed to be rigid: - its trait bound has been proven via a `ParamEnv` or `ItemBound` candidate - it's one of the special builtin traits which have a blanket impl with a `default` assoc type This means that we now more explicitly control which aliases should rigid to avoid accidentally accepting cyclic aliases. This requires changes to diagnostics as we no longer enter an explicit `RigidAlias` candidate for `NormalizesTo` goals whose trait bound doesn't hold. To fix this I've modified the `BestObligation` visitor always ignore `RigidAlias` candidates and to instead manually check these requirements if there are no applicable candidates. I also removed the hack for handling `structurally_normalize_ty` failures. This fixes rust-lang#134905 as we no longer continue to use the `EvalCtxt` even though a nested goal failed. r? ``@compiler-errors``
…inding, r=estebank Fix diagnostic when using = instead of : in let binding Fixes rust-lang#133713 r? ``@estebank``
debuginfo: Set bitwidth appropriately in enum variant tags Previously, we unconditionally set the bitwidth to 128-bits, the largest an enum would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit enumerators, so this would also have occasionally resulted in truncated data. LLVM added support for 128-bit enumerators in llvm/llvm-project#125578 That patchset trusts the constant to describe how wide the variant tag is, so the high 64-bits of zeros are considered potentially load-bearing. As a result, we went from emitting tags that looked like: DW_AT_discr_value (0xfe) (because `dwarf::BestForm` selected `data1`) to emitting tags that looked like: DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ) This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which: 1. Is probably closer to our intentions in terms of describing the data. 2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools. 3. Will result in smaller debug information.
…piler-errors eagerly prove WF when resolving fully qualified paths fixes rust-lang/trait-system-refactor-initiative#161. This hopefully shouldn't impact perf. I do think we need to deal with at least part of the fallout here, opening for vibes. r? ``@compiler-errors``
Move `llvm.ccache` to `build.ccache` (S)ccache can be useful for more things that just LLVM. For example, we will soon want to use it also for GCC, and theoretically also for building stage0 Rust tools (rust-lang#136921, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Using.20sccache.20for.20Rust). r? ``@onur-ozkan``
…ttons, r=GuillaumeGomez rustdoc: use better, consistent SVG icons for scraped examples ## Screenshots     ## Description This continues two ongoing projects - Replacing ascii art with real icons that don't look like syntax, are understandable to people who're familiar with desktop computers and smart devices, and aren't ugly. - Using labels and tooltips to clarify these icons, when the limits of popular iconography hit us. In this case, I've added tooltips, because, unfortunately, there's not room for always-visible labels. r? ``@GuillaumeGomez``
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
Compiletest should not inherit all host RUSTFLAGS I told ``@rhelmot`` to do this in rust-lang#134913. But it's not correct; compiletest shouldn't inherit RUSTFLAGS at all. Pass a single new --host-rustcflags to compiletest instead, without overwriting any existing arguments. Fixes the following failure, which only happens when building llvm from source and then running `x test --stage 1 ui-fulldeps`: ``` diff --git a/tests/ui-fulldeps/fluent-messages/test.stderr b/tests/ui-fulldeps/fluent-messages/test.stderr index 0b3bb14ce51..978ac46c5a2 100644 --- a/tests/ui-fulldeps/fluent-messages/test.stderr +++ b/tests/ui-fulldeps/fluent-messages/test.stderr ``@@`` -1,3 +1,8 ``@@`` +warning[E0602]: unknown lint: `linker_messages` + | + = note: requested on the command line with `-A linker_messages` + = note: `#[warn(unknown_lints)]` on by default ``` See https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20unknown.20lint.3A.20.60linker_messages.60.20when.20blessing.20tests.20on.20.2E.2E.2E for more context.
…ouxu unify LLVM version finding logic kind a self-explanatory
ci: move `x86_64-gnu-debug` job to the free runner try-job: x86_64-gnu-debug
Fix `x test --stage 1 ui-fulldeps` on macOS (until the next beta bump) "stage 1" for fulldeps means "compile with stage 0, link against stage 1". But this code wanted to switch on the compiler that's building, not the compiler that's being tested. Fix the check. Previously, it would fail with a warning about linker-messages: ``` --- stderr ------------------------------- warning[E0602]: unknown lint: `linker_messages` | = note: requested on the command line with `-A linker_messages` = note: `#[warn(unknown_lints)]` on by default ``` cc https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/unknown.20lint.3A.20.60linker_messages.60.20when.20blessing.20tests.20on.20.2E.2E.2E, rust-lang#136960
rustbot
added
A-testsuite
rustbot
added
T-compiler
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: a567209daa In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Feb 14, 2025
|
Finished benchmarking commit (6dfeab5): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 0.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 789.427s -> 789.679s (0.03%) |
rustbot
added
the
perf-regression-triaged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
llvm.ccachetobuild.ccache#136941 (Movellvm.ccachetobuild.ccache)x86_64-gnu-debugjob to the free runner #136970 (ci: movex86_64-gnu-debugjob to the free runner)x test --stage 1 ui-fulldepson macOS (until the next beta bump) #136973 (Fixx test --stage 1 ui-fulldepson macOS (until the next beta bump))r? @ghost
@rustbot modify labels: rollup
Create a similar rollup