You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tracking issue for release notes of #150557: Don't try to evaluate const blocks during constant promotion #151600
This issue tracks the release notes text for #150557.
cc @dianne, @lcnr -- original issue/PR authors and assignees for drafting text
See the forge.rust-lang.org chapter about release notes for an overview of how the release team makes use of these tracking issues.
Release notes text
This section should be edited to specify the correct category(s) for the change, with succinct description(s) of what changed. Some things worth considering:
Does this need an additional compat notes section?
Was this a libs stabilization that should have additional headers to list new APIs under Stabilized APIs and Const Stabilized APIs?
# Language-[Const blocks are no longer evaluated to determine if expressions involving fallible operations can implicitly be constant-promoted.](https://github.com/rust-lang/rust/pull/150557). Expressions whose ability to implicitly be promoted would depend on the result of a const block are no longer implicitly promoted.
Tip
Use the previous releases for inspiration on how to write the release notes text and which categories to pick.
Release blog section
If this change is notable enough for inclusion in the blog post then this section should be edited to contain a draft for the blog post. Otherwise leave it empty.
Note
If a blog post section is required the release-blog-post label should be added (@rustbot label +release-blog-post) to this issue as otherwise it may be missed by the release team.
It's been a while, but wasn't the breakage already done in a previous release by #138499 creating query cycles? This should only affect code that was hitting those cycles, so it shouldn't cause any less code to compile (though not everything that compiled before #138499 will compile now). I wasn't sure how to capture that in a not-overly-technical way in the relnotes, so I instead described the overall effect of both changes together (which is a breaking change). Not sure what the procedure is for that.
Activity
theemathas commentedon Apr 2, 2026
This is technically a breaking change, so it needs a compatibility notes section, right?
dianne commentedon Apr 2, 2026
It's been a while, but wasn't the breakage already done in a previous release by #138499 creating query cycles? This should only affect code that was hitting those cycles, so it shouldn't cause any less code to compile (though not everything that compiled before #138499 will compile now). I wasn't sure how to capture that in a not-overly-technical way in the relnotes, so I instead described the overall effect of both changes together (which is a breaking change). Not sure what the procedure is for that.