-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE: stack overflow in self-referential struct in clippy_utils::ty::is_normalizable_helper
#10508
Comments
matthiaskrgr
added
C-bug
Category: Clippy is not doing the correct thing
I-ICE
Issue: Clippy panicked, giving an Internal Compilation Error (ICE) ❄️
labels
Mar 15, 2023
matthiaskrgr
changed the title
ICE: stack overflow
ICE: stack overflow in clippy_utils::ty::is_normalizable_helper ()
Mar 15, 2023
Was this used in real code? |
No this was fuzzed |
another variant use std::marker::PhantomData;
struct Digit<T> {
elem: T
}
struct Node<T:'static> { m: PhantomData<&'static T> }
enum FingerTree<T:'static> {
Single(T),
Deep(
Digit<T>,
Node<FingerTree<Node<T>>>,
)
}
enum Wrapper<T:'static> {
Simple,
Other(FingerTree<T>),
}
fn main() {
let w =
Some(Wrapper::Simple::<u32>);
} |
matthiaskrgr
changed the title
ICE: stack overflow in clippy_utils::ty::is_normalizable_helper ()
ICE: stack overflow in self-referential struct in Dec 16, 2023
clippy_utils::ty::is_normalizable_helper
Another one I think, this compiles fine as is with rustc but clippy stack overflows #[derive(Debug)]
struct S<T> {
t: T,
s: Box<S<fn(u: T)>>,
}
fn main() {} |
bors
added a commit
that referenced
this issue
Aug 14, 2024
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`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
clippy-driver file.rs
is enough.Version
Error output
Backtrace
The text was updated successfully, but these errors were encountered: