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

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

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 resolution 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 resolution 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Name resolution 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