Tracking issue for future-incompatibility lint `self_constructor_from_outer_item`

This is a tracking issue for the future-incompatibility lint self_constructor_from_outer_item.

The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.

What

Rust doesn't allow referencing generics from outer items in inner nested items:

fn test<T>() {
    fn nested() -> T { todo!() }
    //~^ ERROR can't use generic parameters from outer item
}

This includes, interestingly, the Self type alias, even if it's not generic itself:

struct Hello;

impl Hello {
    fn test() {
        fn nested() -> Self { todo!() }
        //~^ ERROR can't use generic parameters from outer item
    }
}

However, there was an oversight in the implementation of Self constructors in impls, such that this code worked:

struct Hello;

impl Hello {
    fn test() {
        fn nested() -> Hello { Self }
        // Allowed, for now... ^^^^
    }
}

This lint is implemented for the case where the Self constructor doesn't reference any generic parameters. If it does, then a hard error is given instead (since the code will typically ICE or at least almost always fail to compile).

How to fix

Replace the Self with the relevant type in the impl header.

Tracking

• Initial implementation: #124187
• Bump lint to deny
• Make it a hard error

Start by reading the lint description and the initial implementation issue, #124187, then review the remaining tracking checklist. Done means completing the outstanding lint-policy steps, including the transition from warning to deny and finally to a hard error.