Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for future-incompatibility lint self_constructor_from_outer_item #124186

Open
3 tasks
compiler-errors opened this issue Apr 20, 2024 · 0 comments
Open
3 tasks
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@compiler-errors
Copy link
Member

compiler-errors commented Apr 20, 2024

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

@compiler-errors compiler-errors added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Apr 20, 2024
@fmease fmease added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Apr 21, 2024
@fmease fmease added T-lang Relevant to the language team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-future-incompatibility Category: Future-incompatibility lints and removed T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Sep 17, 2024
@fmease fmease changed the title Tracking Issue for future-compatibility warning SELF_CONSTRUCTOR_FROM_OUTER_ITEM Tracking issue for future-incompatibility lint self_constructor_from_outer_item Sep 17, 2024
@fmease fmease added the A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. label Sep 17, 2024
@fmease fmease added A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. and removed A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. labels Dec 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants