Remove `is_normalizable` #12550

Jarcho · 2024-03-24T22:58:08Z

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.

rustbot · 2024-03-24T22:58:13Z

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

y21 · 2024-03-24T23:40:18Z

clippy_utils/src/ty.rs

@@ -1013,10 +969,6 @@ pub fn adt_and_variant_of_res<'tcx>(cx: &LateContext<'tcx>, res: Res) -> Option<
 /// Comes up with an "at least" guesstimate for the type's size, not taking into
 /// account the layout of type parameters.
 pub fn approx_ty_size<'tcx>(cx: &LateContext<'tcx>, ty: Ty<'tcx>) -> u64 {
-    use rustc_middle::ty::layout::LayoutOf;
-    if !is_normalizable(cx, cx.param_env, ty) {


This also fixes #11915, right? iirc that lint uses approx_ty_size indirectly and that failed because of the check here

Looks like it.

should this also have a test for that then?

y21 · 2024-03-24T23:53:23Z

clippy_utils/src/ty.rs

@@ -1013,10 +969,6 @@ pub fn adt_and_variant_of_res<'tcx>(cx: &LateContext<'tcx>, res: Res) -> Option<
 /// Comes up with an "at least" guesstimate for the type's size, not taking into
 /// account the layout of type parameters.
 pub fn approx_ty_size<'tcx>(cx: &LateContext<'tcx>, ty: Ty<'tcx>) -> u64 {


So if I understand correctly, approx_ty_size shouldn't be called if the Ty might be a type alias because that can have trait projections without having an explicit T: Trait bound and thus would not be in the ParamEnv, which causes layout_of to crash when normalizing it?

Should this be mentioned in the doc comment that it shouldn't be called in those cases?

Only when you would want to resolve things in the context of the type alias item. If you're in some other context and just instantiating the alias then it's fine.

Right. Isn't it still worth documenting though? I feel like it's a subtle detail that could easily be missed or people might not even know about it.

clippy_utils/src/ty.rs

y21 · 2024-03-25T00:24:08Z

clippy_utils/src/ty.rs

+        ty::Coroutine(_, args) => for_list(tcx, param_env, args.as_coroutine().upvar_tys().iter()),
+        ty::CoroutineClosure(_, args) => for_list(tcx, param_env, args.as_coroutine_closure().upvar_tys().iter()),
+        ty::CoroutineWitness(_, args) => for_list(tcx, param_env, args.iter().filter_map(GenericArg::as_type)),


I don't think coroutines are ZSTs if they don't have upvars. At least futures generated by async blocks are always at least of size 1 to tell that they've finished https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=743d622d9887740234d325ae94dbf5f4

Then again, I have no idea if zero_sized_map_values realistically could ever run into this?

That is a good point. Fixed.

The check for an uninhabited coroutine is still conservative, but that should be fine.

y21 · 2024-03-25T09:32:17Z

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?

bors · 2024-04-18T15:56:36Z

☔ The latest upstream changes (presumably #12690) made this pull request unmergeable. Please resolve the merge conflicts.

xFrednet · 2024-06-20T20:39:32Z

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

xFrednet · 2024-07-23T06:33:29Z

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

Jarcho · 2024-07-23T14:22:44Z

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.

y21 · 2024-07-25T21:18:56Z

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)

…ry on type aliases.

y21 · 2024-08-14T21:58:25Z

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+

bors · 2024-08-14T21:58:27Z

📌 Commit d3ce4dd has been approved by y21

It is now in the queue for this repository.

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: ```rust 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`.

bors · 2024-08-14T21:59:35Z

⌛ Testing commit d3ce4dd with merge 35d7f45...

bors · 2024-08-14T22:04:47Z

💔 Test failed - checks-action_test

Arjentix · 2024-10-01T18:52:51Z

Hello! Just found this PR and pinging @Jarcho since there wasn't much acivity there for more than a month

bors · 2024-11-07T18:11:41Z

☔ The latest upstream changes (presumably #13639) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot assigned y21 Mar 24, 2024

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Mar 24, 2024

y21 reviewed Mar 25, 2024

View reviewed changes

Jarcho force-pushed the issue_10508 branch 2 times, most recently from 107e072 to 88aee9e Compare March 25, 2024 02:08

rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Jun 20, 2024

rustbot added S-inactive-closed Status: Closed due to inactivity and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Jul 23, 2024

xFrednet closed this Jul 23, 2024

Jarcho reopened this Jul 23, 2024

Jarcho added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-inactive-closed Status: Closed due to inactivity labels Jul 23, 2024

Jarcho force-pushed the issue_10508 branch from 88aee9e to 375d0f2 Compare August 10, 2024 02:04

Remove is_normalizable. Add sizedness_of to avoid layout_of que…

d3ce4dd

…ry on type aliases.

Jarcho force-pushed the issue_10508 branch from 375d0f2 to d3ce4dd Compare August 10, 2024 02:07

y21 approved these changes Aug 14, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove `is_normalizable` #12550

Remove `is_normalizable` #12550

Jarcho commented Mar 24, 2024 •

edited

Loading

rustbot commented Mar 24, 2024

y21 Mar 24, 2024

Jarcho Mar 25, 2024

y21 Mar 25, 2024

y21 Mar 24, 2024

Jarcho Mar 25, 2024

y21 Mar 25, 2024

y21 Mar 25, 2024

Jarcho Mar 25, 2024

y21 commented Mar 25, 2024

bors commented Apr 18, 2024

xFrednet commented Jun 20, 2024

xFrednet commented Jul 23, 2024

Jarcho commented Jul 23, 2024

y21 commented Jul 25, 2024

y21 commented Aug 14, 2024

bors commented Aug 14, 2024

bors commented Aug 14, 2024

bors commented Aug 14, 2024

Arjentix commented Oct 1, 2024

bors commented Nov 7, 2024

Remove is_normalizable #12550

Are you sure you want to change the base?

Remove is_normalizable #12550

Conversation

Jarcho commented Mar 24, 2024 • edited Loading

rustbot commented Mar 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

y21 commented Mar 25, 2024

bors commented Apr 18, 2024

xFrednet commented Jun 20, 2024

xFrednet commented Jul 23, 2024

Jarcho commented Jul 23, 2024

y21 commented Jul 25, 2024

y21 commented Aug 14, 2024

bors commented Aug 14, 2024

bors commented Aug 14, 2024

bors commented Aug 14, 2024

Arjentix commented Oct 1, 2024

bors commented Nov 7, 2024

Remove `is_normalizable` #12550

Remove `is_normalizable` #12550

Jarcho commented Mar 24, 2024 •

edited

Loading