Skip to content

fix unsoundness when compiling [diverging_const; 0] - #165416

Merged
rust-bors[bot] merged 2 commits into
rust-lang:mainfrom
WaffleLapkin:diverging_const_repeated_zero_times
Nov 3, 2026
Merged

rust-bors[bot] merged 2 commits into
rust-lang:mainfrom
WaffleLapkin:diverging_const_repeated_zero_times

Conversation

@WaffleLapkin

@WaffleLapkin WaffleLapkin commented Nov 3, 2026 •

Copy link
Copy Markdown
Member

View all comments

As I described in #165323 (comment), currently [diverging_const; 0] leads to usoundness because hir type check and mir building disagree on whatever diverging_const is evaluated or not. hir type check assumes that it does (and marks anything after it as unreachable) while mir building sees that the constant is repeated 0 times and decides to skip evaluating the constant, resulting in unsoundness.

This PR fixes this by doing the same kind of special case in hir type check.

Fixes (but does not close as this is a temporary workaround) #165323

Previusly we had a disagreement between hir_typeck (assuming that
anything following the diverging constant is unreachable) and mir_build
(assuming we don't need to evaluate constants in `[...; 0]`).

This (temporarily) fixes this by making hir_typeck aware that such
constants should not affect divergence / reachibility analysis
@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 Nov 3, 2026
@rustbot

rustbot commented Nov 3, 2026

Copy link
Copy Markdown
Collaborator

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 77 candidates
  • Random selection from 22 candidates

@WaffleLapkin WaffleLapkin added A-never-type Area: `!` type. For issues not specific to `!`, use A-uninhabited-types. beta-nominated Nominated for backporting to the compiler in the beta channel. labels Nov 3, 2026
@theemathas

Copy link
Copy Markdown
Contributor

Does this need a crater run, and does this need to be beta-nominated?

@WaffleLapkin

Copy link
Copy Markdown
Member Author

Nominating for a beta backport. This fixes an unsoundness with the never type, that is currently stable in beta (and which will be stable in ~9 days).

@WaffleLapkin

Copy link
Copy Markdown
Member Author

@theemathas I don't think this needs a crater run; this can only move code from being unsound to not compiling (and you can only write the unsound code by mentioning ! that was unstable before).

Comment on lines +1777 to +1781
let count_is_zero = {
if let Ok(count) = tcx.try_normalize_erasing_regions(
self.typing_env(self.param_env),
Unnormalized::new_wip(count),
) {

@WaffleLapkin WaffleLapkin Nov 3, 2026 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unclear to me if this does anything / is needed, given the self.normalize call above. cc @khyperia

View changes since the review

@oli-obk oli-obk Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea I think just running the try_to_value method chan below would suffice, no need to try to reevaluate

@oli-obk

oli-obk commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

isn't this the wrong way around? Shouldn't we instead eval the const (or at least eval it if it's uninhabited)? We put a lot of effort into making sure all runtime-reachable const blocks or uses of const items are evaluated, even if optimized out.

Edit: ah this was discussed on the issue, could have still just done that for constants of type ! without it being a breaking change and then figuring out if we can extend that to arbitrary consts without it being an issue (it shouldn't be)

@oli-obk oli-obk left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I would prefer to ensure the consts aren't dropped on the floor by mir building, this change is ready and can be merged now, and is strictly rejecting more code than fixing the issue properly.

@bors r+ p=1

View changes since this review

@rust-bors

rust-bors Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 23d29d9 has been tentatively approved by oli-obk

It will be put into the queue for this repository once PR CI succeeds.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 3, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Member

@bors r=oli-obk force
I'll add this to the current rollup so this gets merged asap for more testing hours

@rust-bors

rust-bors Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 23d29d9 has been approved by oli-obk

It is now in the queue for this repository.

JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Nov 3, 2026
…ted_zero_times, r=oli-obk

fix unsoundness when compiling `[diverging_const; 0]`

As I described in rust-lang#165323 (comment), currently `[diverging_const; 0]` leads to usoundness because hir type check and mir building disagree on whatever `diverging_const` is evaluated or not. hir type check assumes that it does (and marks anything after it as unreachable) while mir building sees that the constant is repeated 0 times and decides to skip evaluating the constant, resulting in unsoundness.

This PR fixes this by doing the same kind of special case in hir type check.

Fixes rust-lang#165323
@theemathas

Copy link
Copy Markdown
Contributor

Should #165323 be kept open after this PR merges, since it seems like the behavior isn't finalized yet?

rust-bors Bot pushed a commit that referenced this pull request Nov 3, 2026
…uwer

Rollup of 21 pull requests

Successful merges:

 - #165416 (fix unsoundness when compiling `[diverging_const; 0]`)
 - #149245 (Make inline attributes apply to the generated `poll` in async fn)
 - #163495 (Parallelize AST -> HIR lowering)
 - #164304 ([perf] Reuse CanonicalVarKinds if no new variables were added)
 - #165109 (Avoid building a region map when erasing bound regions)
 - #163393 (std: Use getexecpath() for current_exe() on OpenBSD)
 - #163625 (Add a lint helper attribute namespace )
 - #164414 (Add `let_underscore_drop_guard` lint.)
 - #165342 (Avoid unnecessary MIR traversals in CheckPackedRef lint)
 - #165351 (delegation: insert probing adjustments before args check adjustments)
 - #165358 (Reenable some cg_gcc tests that were disabled)
 - #165377 (Make `no_implicit_prelude` not suppress tool attributes)
 - #165397 (Add codegen test for unused match arms removed after inlining)
 - #165398 (Rework parallel reproducibility tests)
 - #162608 (Avoid oscillating line wrapping due to symbol indices)
 - #164241 (make the safety documentation consistent in Ptr module)
 - #165029 (Use `MalformedLintAttributeInput` in more places)
 - #165203 (AIX: Implement TLS destructor guard in std and update dynamic-loading-cdylib test)
 - #165230 (Fix rigidity assertion ICE)
 - #165293 (unstable-book: update default-visibility.md to link to tracking issue)
 - #165374 (Refactorings in preparation for the move trait)
@rust-bors

rust-bors Bot commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

⌛ Testing commit 23d29d9 with merge 69e1d01...

Workflow: https://github.com/rust-lang/rust/actions/runs/41696987455

rust-bors Bot pushed a commit that referenced this pull request Nov 3, 2026
…mes, r=oli-obk

fix unsoundness when compiling `[diverging_const; 0]`

As I described in #165323 (comment), currently `[diverging_const; 0]` leads to usoundness because hir type check and mir building disagree on whatever `diverging_const` is evaluated or not. hir type check assumes that it does (and marks anything after it as unreachable) while mir building sees that the constant is repeated 0 times and decides to skip evaluating the constant, resulting in unsoundness.

This PR fixes this by doing the same kind of special case in hir type check.

Fixes (but does not close as this is a temporary workaround) #165323
@JonathanBrouwer

Copy link
Copy Markdown
Member

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #165418 (comment)

@rust-bors rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 3, 2026
@rust-bors

rust-bors Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

This pull request was unapproved.

This PR was contained in a rollup (#165418), which was unapproved.

Auto build was cancelled due to unapproval. Cancelled workflows:

View changes since this unapproval

@JonathanBrouwer

Copy link
Copy Markdown
Member

Added a commit that should fix the problem
@bors r=oli-obk
@bors try jobs=test-x86_64-gnu-llvm-22-3

@rust-bors

rust-bors Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

📌 Commit b7b37d2 has been tentatively approved by oli-obk

It will be put into the queue for this repository once PR CI succeeds.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 3, 2026
@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Nov 3, 2026
…mes, r=<try>

fix unsoundness when compiling `[diverging_const; 0]`


try-job: test-x86_64-gnu-llvm-22-3
@JonathanBrouwer

Copy link
Copy Markdown
Member

@bors r=oli-obk force

@rust-bors

rust-bors Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

📌 Commit b7b37d2 has been approved by oli-obk

It is now in the queue for this repository.

rust-bors Bot pushed a commit that referenced this pull request Nov 3, 2026
…uwer

Rollup of 7 pull requests

Successful merges:

 - #165416 (fix unsoundness when compiling `[diverging_const; 0]`)
 - #163217 ([perf] rustdoc: Avoid re-HIR-ty-lowering tys & const args where possible)
 - #165371 (Don't use `llvm_type` as the type of `static`s.)
 - #165354 (Remove `AbiAlign`)
 - #165357 (rustdoc: Fix invalid clean of paths when they end with `self`)
 - #165401 (Add codegen test for step_by(1) loop vectorization)
 - #165408 (LLVMRustWriteOutputFile: Check the result of runCodeGenPipeline)
@rust-bors

rust-bors Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

☀️ Try build successful (CI)
Build commit: 105361a (105361a1d48f09da1413502159a3c5a18f512c87)
Base parent: a94dce0 (a94dce0bbb3aab81bfdcc30e8a55d7dc95bc644d)

rust-bors Bot pushed a commit that referenced this pull request Nov 3, 2026
Rollup merge of #165416 - WaffleLapkin:diverging_const_repeated_zero_times, r=oli-obk

fix unsoundness when compiling `[diverging_const; 0]`

As I described in #165323 (comment), currently `[diverging_const; 0]` leads to usoundness because hir type check and mir building disagree on whatever `diverging_const` is evaluated or not. hir type check assumes that it does (and marks anything after it as unreachable) while mir building sees that the constant is repeated 0 times and decides to skip evaluating the constant, resulting in unsoundness.

This PR fixes this by doing the same kind of special case in hir type check.

Fixes (but does not close as this is a temporary workaround) #165323
@rust-bors
rust-bors Bot merged commit dc62573 into rust-lang:main Nov 3, 2026
15 checks passed
@rustbot rustbot added this to the 1.101.0 milestone Nov 3, 2026
@rustbot

rustbot commented Nov 4, 2026

Copy link
Copy Markdown
Collaborator

beta backport approved as per compiler team on Zulip. A backport PR will be authored by the release team at the end of the current development cycle. Backport labels are handled by them.

@rustbot rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Nov 4, 2026
@JonathanBrouwer JonathanBrouwer modified the milestones: 1.101.0, 1.100.0 Nov 4, 2026
@JonathanBrouwer JonathanBrouwer removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Nov 4, 2026
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Nov 4, 2026
…uwer

Rollup of 7 pull requests

Successful merges:

 - rust-lang/rust#165416 (fix unsoundness when compiling `[diverging_const; 0]`)
 - rust-lang/rust#163217 ([perf] rustdoc: Avoid re-HIR-ty-lowering tys & const args where possible)
 - rust-lang/rust#165371 (Don't use `llvm_type` as the type of `static`s.)
 - rust-lang/rust#165354 (Remove `AbiAlign`)
 - rust-lang/rust#165357 (rustdoc: Fix invalid clean of paths when they end with `self`)
 - rust-lang/rust#165401 (Add codegen test for step_by(1) loop vectorization)
 - rust-lang/rust#165408 (LLVMRustWriteOutputFile: Check the result of runCodeGenPipeline)
@WaffleLapkin
WaffleLapkin deleted the diverging_const_repeated_zero_times branch November 4, 2026 12:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-never-type Area: `!` type. For issues not specific to `!`, use A-uninhabited-types. beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

6 participants