You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
unexpected behavior of pub(in other_module) #109657
mod parent {mod this {pub(insuper::sibling)fnfoo(){}}mod sibling {fnbar(){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
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?
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.
Activity
mu001999 commentedon Mar 27, 2023
The Rust Reference says:
lcnr commentedon Mar 27, 2023
so I guess the fix is
lcnr commentedon Mar 27, 2023
nandesu-utils commentedon Mar 27, 2023
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 commentedon Mar 27, 2023
Resolution for paths inside
pub(...)happens very early (similarly to macro and import paths) andmod siblingis just not yet put into the name resolution structures whenpub(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
crateorsuperpaths are rare there anyway.So the diagnostics are suboptimal.
petrochenkov commentedon Mar 27, 2023
I remember that there's an older duplicate for this issue, but can't find it right now.
UPD: It's #40066.
petrochenkov commentedon Mar 27, 2023
You could notice the difference in diagnostics if you swap the order between
mod thisandmod sibling.Rollup merge of rust-lang#155948 - SynapLink:fix/pub-visibility-order…
Rollup merge of rust-lang#155948 - SynapLink:fix/pub-visibility-order…
Rollup merge of rust-lang#155948 - SynapLink:fix/pub-visibility-order…
Unrolled build for #155948
Rollup merge of #155948 - SynapLink:fix/pub-visibility-order, r=petro…
Rollup merge of #155948 - SynapLink:fix/pub-visibility-order, r=petro…