rust-lang
Remove `is_normalizable`
fixes #11915 fixes #9798 Fixes only the first ICE in #10508
is_normalizable is used in a few places to avoid an ICE due to a delayed bug in normalization which occurs when a projection type is used on a type which doesn't implement the correct trait. The only part of clippy that actually needed this check is zero_sized_map_values due to a quirk of how type aliases work (they don't a real ParamEnv). This fixes the need for the check there by manually walking the type to determine if it's zero sized, rather than attempting to compute the type's layout thereby avoid the normalization that triggers the delayed bug.
For an example of the issue with type aliases:
trait Foo { type Foo; }
struct Bar<T: Foo>(T::Foo);
// The `ParamEnv` here just has `T: Sized`, not `T: Sized + Foo`.
type Baz<T> = &'static Bar<T>;
When trying to compute the layout of &'static Bar<T> we need to determine if what type <Bar<T> as Pointee>::Metadata is. Doing this requires knowing if T::Foo: Sized, but since T doesn't have an associated type Foo in the context of the type alias a delayed bug is issued.
changelog: [large_enum_variant]: correctly get the size of bytes::Bytes.
r? @y21
rustbot has assigned @y21. 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 does layout_of (supposedly?) ice when normalization fails anyway? LayoutError has a NormalizationFailure variant and it seems to be handling the case where normalization fails? Or am I missing something/is this for something else?
:umbrella: The latest upstream changes (presumably #12690) made this pull request unmergeable. Please resolve the merge conflicts.
Hey @Jarcho , this is a ping from triage, since there hasn't been any activity in some time. Are you still planning to continue this implementation?
If you have any questions, you're always welcome to ask them in this PR or on Zulip.
@rustbot author
Hey this is triage, I'm closing this due to inactivity. If you want to continue this implementation, you're welcome to create a new PR. Thank you for the time, you already put into this!
Interested parties are welcome to pick this implementation up as well :)
@rustbot label +S-inactive-closed -S-waiting-on-author -S-waiting-on-review
Why does layout_of (supposedly?) ice when normalization fails anyway? LayoutError has a NormalizationFailure variant and it seems to be handling the case where normalization fails? Or am I missing something/is this for something else?
You're missing the delay_bug in layout_of. Delayed bugs work by causing an ICE if a compiler error does not issue an error. These exist to catch compiler bugs, but they still cause an ICE even in non-compiler code like clippy.
Right, I see now. I think I initially tested it with a slightly different repro type V<T> = HashMap<(), <T as Trait>::Assoc>; which didn't ICE despite a normalization failure and no compile error, but I can see the ICE with your repro now (I guess it's a particular error path in normalization that gets the delayed bug, not every normalization failure).
I do still think a comment on approx_ty_size would be good to have though (also mentioning that the new sizedness_of could be used for cases when you just want to know if a type is zero sized)
Looks good to me! Initially had some concerns with the is_zst recursion possibly running into stack overflows on recursive types, but I convinced myself this is fine since this properly stops recursing on any kind of indirection (and wouldn't be valid without to begin with).
@bors r+
:pushpin: Commit d3ce4dd038b32a11708f38f3373b7d3d6cde8661 has been approved by y21
It is now in the queue for this repository.
:hourglass: Testing commit d3ce4dd038b32a11708f38f3373b7d3d6cde8661 with merge 35d7f45e5f95f0a234d111e9462db1b62d1e28a5...