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

Cannot use use Self::*; inside a method #63720

Open
varkor opened this issue Aug 19, 2019 · 7 comments
Open

Cannot use use Self::*; inside a method #63720

varkor opened this issue Aug 19, 2019 · 7 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@varkor
Copy link
Member

varkor commented Aug 19, 2019

enum A {}

impl A {
    fn foo() {
        use Self::*; // error: unresolved import `Self`
    }
}

It's counterintuitive that this fails. At the very least (if it's not possible to fix this), we should special case the error message to explain the problem.
#49683 (comment) may be related.

@varkor varkor added A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 19, 2019
@Centril
Copy link
Contributor

Centril commented Aug 19, 2019

cc @petrochenkov @estebank

@Centril Centril added the D-confusing Diagnostics: Confusing error or lint that should be reworked. label Nov 18, 2019
@enterprisey
Copy link
Contributor

I would like to try and write a patch for this. @Centril, do you think this would require an RFC first? (Apologies for the ping, you were the last commenter)

@estebank estebank added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Feb 18, 2020
@estebank
Copy link
Contributor

It depends on how we close this ticket: if we extend the language to allow Self, then the lang team should chime in. If we continue to deny it rustc should suggest using A instead of Self here. For the later you can go ahead and implement it directly without much fuzz (and likely it would be 90% of the machinery to implement the actual lang feature). For the former, you could make the argument that this falls under the existing RFC (although there's no direct mention about this, one way or another).

@Centril
Copy link
Contributor

Centril commented Feb 18, 2020

I think we decided to "interpret the RFC" when we actually stabilized the feature as not legitimizing this, or to be more accurate, the language team essentially overrode that section of the RFC. (See #61682 for details.) I think it would be best to focus on the diagnostics work right now as supporting use Alias::Variant; would also need to be supported (and that doesn't seem as likely.)

@varkor
Copy link
Member Author

varkor commented Feb 18, 2020

@Centril: could you point out where in #61682 this is mentioned? I couldn't spot it by glancing through, though the discussion thread is quite long, so I could easily have missed it.

would also need to be supported (and that doesn't seem as likely.)

Is this also mentioned in that pull request? Why is this?

@Centril
Copy link
Contributor

Centril commented Feb 18, 2020

@varkor See the heading "Divergences from RFC". In particular notice how we don't allow pub use Alias::Some; contrary to the RFC. This is then discussed (see in particular comments referenced by @petrochenkov and @eddyb). In particular:

For use E2::*; to work, it would have to be sugar for use <E2>::*;, and involve the typesystem in name resolution (if any generic arguments are involved, you would have to transport them faithfully), which isn't really doable atm.
This is a more general problem, in that use Foo::...; won't import associated consts/types/methods from types/traits.

Is this also mentioned in that pull request? Why is this?

It is not, but it would be ad-hoc, and contrary to the spirit of #61682 (in my view) to support type relative resolution for use Self::*; specifically but not for use Alias::*;. I don't see a strong justification for such a special case.

@petrochenkov
Copy link
Contributor

[triagebot] Yeah, Self::anything is a type-based resolution, so it isn't supposed to work in imports.
Ideally, this fact should be conveyed in the error message reported when someone attempts to use a any path that may use type-based resolution, not only Self::..., in an import.

@crlf0710 crlf0710 added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jun 11, 2020
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue May 20, 2023
… r=compiler-errors

Better diagnostic for `use Self::..`

Fixes rust-lang#111627

cc `@petrochenkov,` you might have thoughts on a better way to handle this (rust-lang#63720 (comment))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-resolve Area: Name resolution C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants