Normalization can skip WF #100041
Description
Activity
cc @rust-lang/types
I think I found the bug(s). This is:
- partly due to Try to normalize associated types before processing obligations #90887, which normalizes
WellFormedpredicates before we can actually walk through the projection type and register a WF obligation for the projection's self ty, - and partly due to us doing a
normalizecall before registering aWellFormedpredicate in wfcheck code.
Let me put up a PR.
Reacted by jyn- partly due to Try to normalize associated types before processing obligations #90887, which normalizes
Just checked out that PR, and it's not fixed by #99217.
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-high
12 remaining items
- added a commit that references this issue
on Feb 18, 2024 This is currently mostly fixable, except for types in impl headers.
As stated by @aliemjay in #100046 (comment), we can check unnormalized types for WF if the type is from an item signature.
We already use their unnormalized type when computing WF in borrowck, so we can first fix #105948 by using the unnormalized types from fn sigs.
We can then check the wf of function signatures without normalizing them.
Reacted by Crystal Durhamlowering this from P-high to P-medium as this cannot directly result in undefined runtime behavior by itself. Fixing this will be straightforward once we've imnplemented the better approach to handling implied bounds on binders, which is still a high priority as it also blocks other issues, such as #25860 and #84591.
Reacted by Crystal Durham and apirainoalso the case for types in associated type constraints of opaques which we could in theory fix separately
trait ToUnit { type Assoc; } impl<T> ToUnit for T { type Assoc = (); } // We ever check that the associated type of the opaque // is well-formed before normalization fn path_ssh_parser() -> impl ToUnit<Assoc = <[str; 2] as ToUnit>::Assoc> {}
I opened #153082 for that but I actually don't think this warrants a separate issue
- marked we don't check associated type bounds of opaques for WF pre normalization #153082 as a duplicate of this issue
on Feb 25, 2026
I tried this code: [playground]
I expected this to error;
[[[[[[u8]]]]]]is clearly not a well-formed type, asVec<str>is perhaps even more cursed.Instead: it compiles.
This is especially relevant for blanket/builtin traits which have associated types, such as
marker::DiscriminantKindandptr::Pointee.Meta
1.64.0-nightly (2022-07-31 f9cba63)
@rustbot label +A-associated-items
cc @eddyb who said this was
@rustbot label +I-unsound