Tracking issue for nested_impl_trait compatibility lint

[pnkfelix]

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

• Warning period for detecting nested impl trait #58608 introduces the nested_impl_trait lint as warn-by-default
• PR ? makes the nested_impl_trait lint deny-by-default
• PR ? makes the nested_impl_trait lint a hard error