Skip to content

Conversation

pvdrz
Copy link
Contributor

@pvdrz pvdrz commented Oct 8, 2025

This PR guarantees that ./x test --test-args="--edition XXXX" ui runs correctly with the 2015, 2018 and 2021 editions.

I don't expect this PR to hold up over time but it helps to submit further updates to the //@ edition directives of tests where we can use the new range syntax to have a more robust testing across different editions

r? @fmease

@rustbot

This comment was marked as resolved.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 8, 2025
@rustbot

This comment was marked as off-topic.

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-20 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
---- [ui] tests/ui/consts/const-eval/ub-upvars.rs stdout ----
Saved the actual 32bit.stderr to `/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/consts/const-eval/ub-upvars/ub-upvars.32bit.stderr`
diff of 32bit.stderr:

1 error[E0080]: constructing invalid value at .<deref>.<dyn-downcast>.<captured-var(bad_ref)>: encountered a null reference
-   --> $DIR/ub-upvars.rs:6:1
+   --> $DIR/ub-upvars.rs:7:1
3    |
4 LL | const BAD_UPVAR: &dyn FnOnce() = &{
5    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ it is undefined behavior to use this value

Note: some mismatched output was normalized before being compared
---
To only update this specific test, also pass `--test-args consts/const-eval/ub-upvars.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/consts/const-eval/ub-upvars.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--target=i686-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/consts/const-eval/ub-upvars" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/i686-unknown-linux-gnu/native/rust-test-helpers" "-Clinker=x86_64-linux-gnu-gcc" "--edition=2015"
stdout: none
--- stderr -------------------------------
error[E0080]: constructing invalid value at .<deref>.<dyn-downcast>.<captured-var(bad_ref)>: encountered a null reference
##[error]  --> /checkout/tests/ui/consts/const-eval/ub-upvars.rs:7:1
   |
LL | const BAD_UPVAR: &dyn FnOnce() = &{ //~ ERROR null reference
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ it is undefined behavior to use this value
   |
   = note: the rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
   = note: the raw bytes of the constant (size: 8, align: 4) {
               ╾─a3<imm>─╼ ╾─alloc4──╼                         │ ╾──╼╾──╼
           }

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0080`.

@jieyouxu jieyouxu self-assigned this Oct 9, 2025
@jieyouxu jieyouxu added the I-compiler-nominated Nominated for discussion during a compiler team meeting. label Oct 9, 2025
@jieyouxu
Copy link
Member

jieyouxu commented Oct 9, 2025

I'll nominate this for compiler team discussion re. "we accepted the MCP for the direction in theory, here's the actual shape of the implementation" for a quick vibecheck. If team is onboard, we'll coordinate to bump the priority of this PR w.r.t. merge conflict potential.

@fmease fmease added the S-waiting-on-t-compiler Status: Awaiting decision from T-compiler label Oct 9, 2025
@fmease
Copy link
Member

fmease commented Oct 9, 2025

If team is onboard, we'll coordinate to bump the priority of this PR w.r.t. merge conflict potential.

We can do so already proactively:

@bors rollup=never p=20 (bitrot-prone, prone to conflicts in the queue; ref)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-compiler-nominated Nominated for discussion during a compiler team meeting. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-t-compiler Status: Awaiting decision from T-compiler T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants