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.
Uh oh!
There was an error while loading. Please reload this page.
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: