unexpected behavior of `pub(in other_module)`

[lcnr]

mod parent {
    mod this {
        pub(in super::sibling) fn foo() {}
    }
    
    mod sibling {
        fn bar() {
            super::this::foo();
        }
    }
}

results in

error[E0433]: failed to resolve: could not find `sibling` in `super`
 --> src/lib.rs:3:23
  |
3 |         pub(in super::sibling) fn foo() {}
  |                       ^^^^^^^ could not find `sibling` in `super`

this error feels very weird 🤔

I see the following possible fixes here:

• this is a bug with name resolution and should compile
• the in super::sibling error should be changed to explain what's going on here and why that doesn't work

found via #109511 (comment)

cc @petrochenkov in case you know more about what's going on here.

[mu001999]

The Rust Reference says:

pub(in path) makes an item visible within the provided path. path must be an ancestor module of the item whose visibility is being declared.

[lcnr]

so I guess the fix is

• the in super::sibling error should be changed to explain what's going on here and why that doesn't work

[lcnr]

so I guess the fix is

• the in super::sibling error should be changed to explain what's going on here and why that doesn't work

[nandesu-utils]

so I guess the fix is

• the in super::sibling error should be changed to explain what's going on here and why that doesn't work

Shouldn't it change to error of declaring an item with pub(in super::sibling) where the path is surely not an ancestor? Otherwise it doesn't really make sense to delay the error until trying to use the item?

[petrochenkov]

Resolution for paths inside pub(...) happens very early (similarly to macro and import paths) and mod sibling is just not yet put into the name resolution structures when pub(in super::sibling) is resolved.

For paths in macro calls and reexports we would put such unresolved path into a queue to try resolving it later, because for macros and imports it's important for correctness.

For paths in visibilities nobody cared to organize such a queue with retries, because it would complicate things and would only affect diagnostics but not correctness, and non crate or super paths are rare there anyway.
So the diagnostics are suboptimal.

[petrochenkov]

I remember that there's an older duplicate for this issue, but can't find it right now.

[petrochenkov]

mod sibling is just not yet put into the name resolution structures when pub(in super::sibling) is resolved

You could notice the difference in diagnostics if you swap the order between mod this and mod sibling.