What is this lint about
Some occurrences of impl Trait that appear nested at certain points within the type structure of a larger impl Trait type are meant to be rejected by the compiler, because (at least in part) the assignment of concrete types to those nested impl Trait is fragile and fails to provide a path for the user to be more explicit should inference fail.
Due to implementation oversights, some occurrences were erroneously skipped by the nested impl Trait detection, and then those occurrences were sometimes successfully assigned to a type based on Rust type inference implementation details. These implementation oversights were long overlooked and thus became part of the stable Rust compiler.
PR #57730 fixed those aforementioned implementation details, and thus some instances of impl Trait are rejected as erroneous when they were previously accepted by the stable compiler. Since our policy is to provide a smooth transition when such errors are introduced (see RFC 1589), PR #58608 adapted those fixes to the implementation to downgrade those particular rejections of nested impl Trait to be linted as warnings rather than errors.
How to fix this warning/error
All cases where this code was known to successfully compile are instances of impl Trait in argument position (#44721). All such cases can be rewritten to instead use explicit generic type parameters. For example, this signature from #57979
pub fn collect(_: impl IntoIterator<Item = impl Borrow<Data<impl AsRef<[u8]>>>>)
can be rewritten as follows:
pub fn collect<T>(_: impl IntoIterator<Item = impl Borrow<Data<T>>>) where T: AsRef<[u8]>
Current status
What is this lint about
Some occurrences of
impl Traitthat appear nested at certain points within the type structure of a largerimpl Traittype are meant to be rejected by the compiler, because (at least in part) the assignment of concrete types to those nestedimpl Traitis fragile and fails to provide a path for the user to be more explicit should inference fail.Due to implementation oversights, some occurrences were erroneously skipped by the nested
impl Traitdetection, and then those occurrences were sometimes successfully assigned to a type based on Rust type inference implementation details. These implementation oversights were long overlooked and thus became part of the stable Rust compiler.PR #57730 fixed those aforementioned implementation details, and thus some instances of
impl Traitare rejected as erroneous when they were previously accepted by the stable compiler. Since our policy is to provide a smooth transition when such errors are introduced (see RFC 1589), PR #58608 adapted those fixes to the implementation to downgrade those particular rejections of nestedimpl Traitto be linted as warnings rather than errors.How to fix this warning/error
All cases where this code was known to successfully compile are instances of
impl Traitin argument position (#44721). All such cases can be rewritten to instead use explicit generic type parameters. For example, this signature from #57979can be rewritten as follows:
Current status
nested_impl_traitlint as warn-by-defaultnested_impl_traitlint deny-by-defaultnested_impl_traitlint a hard error