Wildcard imports do not seem to propagate as expected for tuple-like struct types having at least one non-pub field

[yvt]

In the following code, ::mod1::Item is expected to be imported as ::mod1::mod2::Item via the following route:

1. ::mod1::Item (the original definition)
2. ::Item (by use self::mod1::* in the crate root)
3. ::mod1::mod2::Item (by use Item in ::mod1::mod2)

However, an “unresolved import” error is reported for the last use as shown below:

#![allow(unused_imports)]

mod mod1 {
    mod mod2 {
        use Item;            // <--- Causes an "unresolved import" error
        // use ::Item;       // <--- So does this too
        // use super::super::Item;  // <--- This, three
        
        // use super::Item;  // <--- But not this one
    }
    
    pub struct Item(usize);
    
    // The "unresolved import" error no longer occurs if the above definition
    // was replaced with any one of the following:
    
    // pub struct Item(pub usize);
    // pub struct Item();
    // pub struct Item { x: usize }
}

use self::mod1::*; // `Item` is supposed to re-exported here

// Replacing the above `use` with the following one makes the error disappear
// use self::mod1::Item;

fn main() {
    let _: Option<Item> = None;
}

(Playground)

Errors:

   Compiling playground v0.0.1 (file:///playground)
error[E0432]: unresolved import
 --> src/main.rs:5:13
  |
5 |         use Item;            // <--- Causes an "unresolved import" error
  |             ^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.

This issue can be reproduced in:

• 1.30.0-nightly (73c7873 2018-08-05).
• 1.29.0-beta.2 (ea82e08 2018-08-05).

But not in:

• 1.28.0.

[petrochenkov]

Very interesting.
Tuple struct constructors do have unusual properties - they are as public as the most private field, so use self::mod1::*; should import only the type Item, but not constructor.
However, it still shouldn't make use Item; an error, the type can still be imported.

It's interesting that the error happens only if use Item; is located inside of mod1:

mod mod1 {
    pub struct Item(usize);
    
    use Item as Something; // ERROR
}

use mod1::*;

mod mod2 {
    use Item; // OK
}

Perhaps bisection can find what commit caused the regression?

[petrochenkov]

Applying bisect-rust would be of great help here.
I won't be able to look at this issue in the next few weeks, but at least this part of the work can be delegated and when the reason is found I could probably mentor for the fix as well.

[Mark-Simulacrum]

ef97813 is where the regression occurs with the minimized example; this is #52555. I've not bisected within the PR itself.

[nikomatsakis]

Visiting for triage. Marking as P-high as this is a regression. @petrochenkov has already assigned themselves.

[Mark-Simulacrum]

https://crater-reports.s3.amazonaws.com/beta-1.29-1/beta-2018-08-01/reg/cubeb-core-0.5.1/log.txt
https://crater-reports.s3.amazonaws.com/beta-1.29-1/beta-2018-08-01/reg/bitintr-0.1.18/log.txt
https://crater-reports.s3.amazonaws.com/beta-1.29-1/beta-2018-08-01/reg/diesel_geometry-1.2.2/log.txt
https://crater-reports.s3.amazonaws.com/beta-1.29-1/beta-2018-08-01/reg/screeps-game-api-0.0.10/log.txt

All of these look like they are probably caused by this as well.

[petrochenkov]

Fixed in #53509