Higher-ranked function pointers implement Fn
traits without enforcing necessary trait bounds to make sure the return type exists
#85455
Labels
A-associated-items
Area: Associated items (types, constants & functions)
A-trait-system
Area: Trait system
A-type-system
Area: Type system
C-bug
Category: This is a bug.
E-needs-test
Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
F-unboxed_closures
`#![feature(unboxed_closures)]`
glacier
ICE tracked in rust-lang/glacier.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
requires-nightly
This issue requires a nightly compiler in some way.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
on the following code produces an ICE (just
cargo check
doesn’t ICE)(playground)
Possibly, this bug can also lead to unsoundness in some way. (I haven’t fully explored that [yet].) Notably,
Box<dyn Fn…>
doesn’t come with the same problem:I would’ve expected a similar error message for the
fn…
case as well.(Further, note that the way things currently stand, the type
Box<dyn Fn(&()) -> <T as SomeTrait<'_>>::Associated>
itself is not leading to any error. It’s only the call tocallee
which has anFn<…>
bound. The error also successfully appears ifcallee
has a higher-rankedFn<…>
bound and/or is not actually called but just instantiated with the type argument, here’s a playground doing both.)@rustbot label requires-nightly, F-unboxed_closures, A-traits, A-typesystem, A-associated-items
The text was updated successfully, but these errors were encountered: