Don't look for non-type-level assoc consts when checking trait object types#153738
Open
fmease wants to merge 1 commit intorust-lang:mainfrom
Open
Don't look for non-type-level assoc consts when checking trait object types#153738fmease wants to merge 1 commit intorust-lang:mainfrom
fmease wants to merge 1 commit intorust-lang:mainfrom
Conversation
rustbot
added
PG-exploit-mitigations
This comment has been minimized.
This comment has been minimized.
fmease
force-pushed
the
dyn-ace-gingerly-care
branch
from
414fbd9 to
c8f02eb
Compare
fmease
commented
Mar 11, 2026
Member
Author
fmease
commented
Mar 11, 2026
Member
Author
There was a problem hiding this comment.
I've manually looked through a bunch of test directories (like type-alias/) and I've made rustc wfcheck the defsite of eager type aliases and run the test suite just to figure out if we already have a test demonstrating the lack of def-site wfcking for (eager) type aliases. It's possible that I've simply missed them since it was only a semi-rigorous approach.
rustbot
added
the
S-waiting-on-review
Collaborator
|
Some changes occurred in compiler/rustc_sanitizers cc @rcvalle |
rustbot
removed
the
S-waiting-on-author
fmease
added
the
beta-nominated
fmease
commented
Mar 12, 2026
fmease
force-pushed
the
dyn-ace-gingerly-care
branch
from
c8f02eb to
f9251e9
Compare
ViewWay
added a commit
to ViewWay/rust
that referenced
this pull request
Mar 14, 2026
… checking trait object types This is a cherry-pick of PR rust-lang#153738 Problem: - PR rust-lang#150843 introduced a regression where eager type aliases containing dyn Trait (with associated consts) would incorrectly report 'trait is not dyn compatible' errors - This affected 254 crates depending on old bitvec versions Root cause: - When checking for unspecified assoc items in trait object types, we were filtering for all associated consts (is_const()) - But eager type aliases don't get wfchecked at definition site - This broke the assumption that dyn-incompatible traits would be rejected early Fix: - Changed is_const() to is_type_const() to only check type-level associated consts, not regular associated consts - Regular associated consts cannot be bound in trait object types anyway, so checking them was unnecessary Modified files: - compiler/rustc_hir_analysis/src/hir_ty_lowering/dyn_trait.rs - compiler/rustc_middle/src/ty/assoc.rs - compiler/rustc_middle/src/ty/sty.rs - compiler/rustc_sanitizers/src/cfi/typeid/itanium_cxx_abi/transform.rs - tests/ui/type-alias/lack-of-wf.rs (new test) Fixes: rust-lang#153731
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
On main, when looking for assoc items that weren't specified in a given trait object type (via binding), we comb through all (eligible) assoc consts whether type-level or not even though you're not allowed to bind non-type-level assoc consts.
That's usually fine because traits containing (eligible) non-type-level assoc consts are dyn incompatible, so the trait object type is ~already considered ill-formed. Therefore, in PR #150843, I saved myself the extra effort, esp. since back then it was more annoying to check if the const item was declared type-level.
(More concretely: In bodies, we check for all dyn compatibility violations when lowering the trait object type, so we will bail out early with an error; in contrast, item signatures / non-bodies get wfchecked (
WellFormedobligation) after lowering which includes dyn compatiblity checking (DynCompatibleobligation); however to reduce the amount of diags, during lowering if there are any unspecified assoc items, we'll check them for dyn compatibility and bail out early if any of them tests negative.)Now, we obviously don't wfcheck the defsite of (eager) type aliases which breaks the assumption that such trait object types get rejected. This led to the regression found in #153731: The ill-formed trait object type doesn't get rejected (as is expected) but we now require the single (non-type-level) assoc const to be bound in the dyn-Trait which we didn't do before. The actual error talks about dyn incompatibility due to the aforementioned extra check that's usually there to contain the number of diags.
Fixes [after beta backport] #153731.