ci: Begin running ui tests with rust.debuginfo-level-tests=1
#144499
Merged
Conversation
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
|
r? @davidtwco rustbot has assigned @davidtwco. Use |
rustbot
added
A-CI
|
This PR modifies |
Enselic
force-pushed
the
ci-debuginfo-level-tests
branch
from
8e58746 to
4996539
Compare
|
Can someone trigger the following try job please? Thanks in advance. @bors2 try jobs=x86_64-gnu-debug |
|
@Enselic: 🔑 Insufficient privileges: not in try users |
|
@bors try jobs=x86_64-gnu-debug |
rust-bors bot
added a commit
that referenced
this pull request
Jul 26, 2025
ci: Begin running ui tests with `rust.debuginfo-level-tests=1` try-job: x86_64-gnu-debug
|
☔ The latest upstream changes (presumably #115746) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I will wait with resolving conflicts until after a first review. |
davidtwco
added
S-waiting-on-author
To reduce risk of regressing on generating debuginfo e.g. in the form of ICE:s. This will also ensure that future ui tests support different debuginfo levels. When I looked at run time for different CI jobs, **x86_64-gnu-debug** was far from the bottle neck, so it should be fine to make it perform more work.
Enselic
force-pushed
the
ci-debuginfo-level-tests
branch
from
4996539 to
9637774
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Rebase was trivial as can be seen in the above range-diff (I love that new feature!). I don't have |
|
@Enselic: 🔑 Insufficient privileges: Not in reviewers |
Enselic
added
S-waiting-on-review
|
@bors delegate+ |
|
✌️ @Enselic, you can now approve this pull request! If @davidtwco told you to " |
|
@bors r+ |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Aug 26, 2025
Rollup of 9 pull requests Successful merges: - #144499 (ci: Begin running ui tests with `rust.debuginfo-level-tests=1`) - #145790 (Improve dist for gnullvm hosts) - #145792 (Use attribute name in message for "outer attr used as inner attr" errors) - #145840 (rustc_codegen_ssa: More comprehensive RISC-V ELF flags) - #145876 (Enable building/disting standard library in stage 0) - #145887 (bootstrap: Don't panic if codegen-backends is set to empty) - #145888 (platform-support: Fix LoongArch32 host column) - #145892 (add a flag to codegen fn attrs for foreign items) - #145901 (Fix typo in comment of library/alloc/src/raw_vec/mod.rs) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Aug 27, 2025
Rollup merge of #144499 - Enselic:ci-debuginfo-level-tests, r=davidtwco ci: Begin running ui tests with `rust.debuginfo-level-tests=1` To reduce risk of regressing on generating debuginfo e.g. in the form of ICE:s. This will also ensure that future ui tests work with different debuginfo levels. See #61117. When I looked at run time for different CI jobs, **x86_64-gnu-debug** was far from the bottleneck, so it should be fine to make it perform more work. A handful of tests are failing so we need to force debuginfo=0 on those for now. We'll start small with debuginfo=1. We'll step up to debuginfo=2 once most (all?) tests can handle debuginfo=1. There are more failures with debuginfo=2 than with debuginfo=1.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Aug 27, 2025
Rollup of 9 pull requests Successful merges: - rust-lang/rust#144499 (ci: Begin running ui tests with `rust.debuginfo-level-tests=1`) - rust-lang/rust#145790 (Improve dist for gnullvm hosts) - rust-lang/rust#145792 (Use attribute name in message for "outer attr used as inner attr" errors) - rust-lang/rust#145840 (rustc_codegen_ssa: More comprehensive RISC-V ELF flags) - rust-lang/rust#145876 (Enable building/disting standard library in stage 0) - rust-lang/rust#145887 (bootstrap: Don't panic if codegen-backends is set to empty) - rust-lang/rust#145888 (platform-support: Fix LoongArch32 host column) - rust-lang/rust#145892 (add a flag to codegen fn attrs for foreign items) - rust-lang/rust#145901 (Fix typo in comment of library/alloc/src/raw_vec/mod.rs) r? `@ghost` `@rustbot` modify labels: rollup
tgross35
added a commit
to tgross35/rust
that referenced
this pull request
Aug 29, 2025
…=wesleywiser compiler: Include span of too huge enum with `-Cdebuginfo=2` We have the ui test `tests/ui/limits/huge-enum.rs` to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level. I'm sure we can propagate spans in more places, but let's start small. ## Test failure without the fix Here is what the failure looks like if you run the test without the fix: ``` [ui] tests/ui/limits/huge-enum.rs#full-debuginfo ... F . failures: ---- [ui] tests/ui/limits/huge-enum.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-enum.full-debuginfo/huge-enum.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `Option<TYPE>` are too big for the target architecture - --> $DIR/huge-enum.rs:17:9 - | - LL | let big: BIG = None; - | ^^^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-enum.rs` ``` as can be seen, the `span` used to be missing with `debuginfo=2`. ## See also This is one small step towards resolving rust-lang#61117. cc rust-lang#144499 which began running UI tests with `rust.debuginfo-level-tests=1`. This PR is part of preparing for increasing that to debuglevel 2.
tgross35
added a commit
to tgross35/rust
that referenced
this pull request
Aug 29, 2025
…=wesleywiser compiler: Include span of too huge enum with `-Cdebuginfo=2` We have the ui test `tests/ui/limits/huge-enum.rs` to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level. I'm sure we can propagate spans in more places, but let's start small. ## Test failure without the fix Here is what the failure looks like if you run the test without the fix: ``` [ui] tests/ui/limits/huge-enum.rs#full-debuginfo ... F . failures: ---- [ui] tests/ui/limits/huge-enum.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-enum.full-debuginfo/huge-enum.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `Option<TYPE>` are too big for the target architecture - --> $DIR/huge-enum.rs:17:9 - | - LL | let big: BIG = None; - | ^^^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-enum.rs` ``` as can be seen, the `span` used to be missing with `debuginfo=2`. ## See also This is one small step towards resolving rust-lang#61117. cc rust-lang#144499 which began running UI tests with `rust.debuginfo-level-tests=1`. This PR is part of preparing for increasing that to debuglevel 2.
tgross35
added a commit
to tgross35/rust
that referenced
this pull request
Aug 30, 2025
…=wesleywiser compiler: Include span of too huge enum with `-Cdebuginfo=2` We have the ui test `tests/ui/limits/huge-enum.rs` to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level. I'm sure we can propagate spans in more places, but let's start small. ## Test failure without the fix Here is what the failure looks like if you run the test without the fix: ``` [ui] tests/ui/limits/huge-enum.rs#full-debuginfo ... F . failures: ---- [ui] tests/ui/limits/huge-enum.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-enum.full-debuginfo/huge-enum.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `Option<TYPE>` are too big for the target architecture - --> $DIR/huge-enum.rs:17:9 - | - LL | let big: BIG = None; - | ^^^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-enum.rs` ``` as can be seen, the `span` used to be missing with `debuginfo=2`. ## See also This is one small step towards resolving rust-lang#61117. cc rust-lang#144499 which began running UI tests with `rust.debuginfo-level-tests=1`. This PR is part of preparing for increasing that to debuglevel 2.
tgross35
added a commit
to tgross35/rust
that referenced
this pull request
Aug 30, 2025
…=wesleywiser compiler: Include span of too huge enum with `-Cdebuginfo=2` We have the ui test `tests/ui/limits/huge-enum.rs` to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level. I'm sure we can propagate spans in more places, but let's start small. ## Test failure without the fix Here is what the failure looks like if you run the test without the fix: ``` [ui] tests/ui/limits/huge-enum.rs#full-debuginfo ... F . failures: ---- [ui] tests/ui/limits/huge-enum.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-enum.full-debuginfo/huge-enum.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `Option<TYPE>` are too big for the target architecture - --> $DIR/huge-enum.rs:17:9 - | - LL | let big: BIG = None; - | ^^^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-enum.rs` ``` as can be seen, the `span` used to be missing with `debuginfo=2`. ## See also This is one small step towards resolving rust-lang#61117. cc rust-lang#144499 which began running UI tests with `rust.debuginfo-level-tests=1`. This PR is part of preparing for increasing that to debuglevel 2.
rust-timer
added a commit
that referenced
this pull request
Aug 30, 2025
Rollup merge of #145967 - Enselic:big-enum-debuginfo-span, r=wesleywiser compiler: Include span of too huge enum with `-Cdebuginfo=2` We have the ui test `tests/ui/limits/huge-enum.rs` to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level. I'm sure we can propagate spans in more places, but let's start small. ## Test failure without the fix Here is what the failure looks like if you run the test without the fix: ``` [ui] tests/ui/limits/huge-enum.rs#full-debuginfo ... F . failures: ---- [ui] tests/ui/limits/huge-enum.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-enum.full-debuginfo/huge-enum.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `Option<TYPE>` are too big for the target architecture - --> $DIR/huge-enum.rs:17:9 - | - LL | let big: BIG = None; - | ^^^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-enum.rs` ``` as can be seen, the `span` used to be missing with `debuginfo=2`. ## See also This is one small step towards resolving #61117. cc #144499 which began running UI tests with `rust.debuginfo-level-tests=1`. This PR is part of preparing for increasing that to debuglevel 2.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Aug 30, 2025
compiler: Include span of too huge enum with `-Cdebuginfo=2` We have the ui test `tests/ui/limits/huge-enum.rs` to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level. I'm sure we can propagate spans in more places, but let's start small. ## Test failure without the fix Here is what the failure looks like if you run the test without the fix: ``` [ui] tests/ui/limits/huge-enum.rs#full-debuginfo ... F . failures: ---- [ui] tests/ui/limits/huge-enum.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-enum.full-debuginfo/huge-enum.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `Option<TYPE>` are too big for the target architecture - --> $DIR/huge-enum.rs:17:9 - | - LL | let big: BIG = None; - | ^^^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-enum.rs` ``` as can be seen, the `span` used to be missing with `debuginfo=2`. ## See also This is one small step towards resolving rust-lang/rust#61117. cc rust-lang/rust#144499 which began running UI tests with `rust.debuginfo-level-tests=1`. This PR is part of preparing for increasing that to debuglevel 2.
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.
To reduce risk of regressing on generating debuginfo e.g. in the form of ICE:s. This will also ensure that future ui tests work with different debuginfo levels. See #61117.
When I looked at run time for different CI jobs, x86_64-gnu-debug was far from the bottleneck, so it should be fine to make it perform more work.
A handful of tests are failing so we need to force debuginfo=0 on those for now.
We'll start small with debuginfo=1. We'll step up to debuginfo=2 once most (all?) tests can handle debuginfo=1. There are more failures with debuginfo=2 than with debuginfo=1.