Skip to content

Wildcard import fails to resolve if a derive is present #56593

New issue

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

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

Already on GitHub? # to your account

Closed
ennis opened this issue Dec 7, 2018 · 6 comments · Fixed by #113099
Closed

Wildcard import fails to resolve if a derive is present #56593

ennis opened this issue Dec 7, 2018 · 6 comments · Fixed by #113099
Assignees
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-bug Category: This is a bug. D-confusing Diagnostics: Confusing error or lint that should be reworked. P-medium Medium priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ennis
Copy link

ennis commented Dec 7, 2018

The following snippet fails to compile with the error [E0412]: cannot find type Foo in this scope

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d954ef6f84f0d1df4e5c4791c7716da9

struct Foo;          // line 1

mod foo {
    use super::*;    // line 4
    
    // Commenting out the Debug derive makes it work
    #[derive(Debug)] // line 7
    pub struct Foo;
}

mod bar {
    use super::foo::*;
    
    fn bar(_: Foo) {}
}

Expected result: code compiles without issues

I can get it to compile by doing one of those:

  • by removing use super::* on line 4
  • by commenting #[derive(Debug)] at line 7
  • by renaming struct Foo on line 1 to Foo2
  • and curiously, by copy-pasting the generated Debug impl obtained with --pretty=expanded instead of using #[derive(Debug)]

The same issue happens with other derives (Clone,Eq,etc.). Seems like #[derive()] is confused when an item with the same name is visible?

@petrochenkov petrochenkov added A-resolve Area: Name/path resolution done by `rustc_resolve` specifically A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. labels Dec 7, 2018
@petrochenkov
Copy link
Contributor

Looks like a legitimate bug.
It's also a regression from Rust 1.15 released almost 2 years ago :)

@petrochenkov petrochenkov self-assigned this Dec 7, 2018
@jonas-schievink jonas-schievink added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 8, 2019
@spastorino spastorino added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Jun 3, 2020
@spastorino
Copy link
Member

spastorino commented Jun 10, 2020

Assigning P-medium as discussed as part of the Prioritization Working Group process and removing I-prioritize.

@spastorino spastorino added P-medium Medium priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Jun 10, 2020
@dtolnay dtolnay changed the title Code fails to compile with #[derive(Debug)] Code fails to compile with derive Dec 29, 2020
@dtolnay dtolnay changed the title Code fails to compile with derive Wildcard import fails to resolve if a derive is present Dec 29, 2020
@estebank
Copy link
Contributor

From #81887:

Hello. I've noticed a strange behaviour where rust-analyzer and rustc would disagree what was wrong with my code. Turns out neither of them were right, I've had an "ambiguous name" problem however both rustc and rust-analyzer resolved the type anyway and they chose a different type to disambiguate into.

I've managed to make this minimal reproduction.
I can either remove the derives or remove the indirection through the c module and the problem will go away.

I expected to get a "Foo is ambiguous" error, instead i get an error for one of the usages of Foo which doesn't match the resolved type of Foo.

As a side-note, at least for rustc the resolved type seems to be dependent on the lexical order of the module/type definitions (not reexports), if that helps at all.

I get the same result on both nightly and stable, locally and on the playground. I found these issues #56593 and #62769 which sound similar but the problem there seems to be the opposite - "type doesn't resolve when it should" (in the presence of derive) instead of here "type resolves when it shouldn't".

@estebank estebank added the D-confusing Diagnostics: Confusing error or lint that should be reworked. label Feb 11, 2021
@rich-g
Copy link

rich-g commented May 20, 2022

Bumping this, as it still seems to be an issue. Minimal example:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=02595dc261355bf662c11cc605d20e55

@wusticality
Copy link

I filed an issue as well and then someone referred me to this issue, I guess it's a dupe. I'm running into this issue as well, any movement on this? Seems like a bug to me, no?

#105235

@cybersoulK
Copy link

having the same issue, it's a major bug, 5 years without fix?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Name/path resolution done by `rustc_resolve` specifically C-bug Category: This is a bug. D-confusing Diagnostics: Confusing error or lint that should be reworked. P-medium Medium priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants