Skip to content

unexpected behavior of pub(in other_module) #109657

Closed

Description

@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.

Activity

  1. mu001999 commented on Mar 27, 2023

    @mu001999
    Member

    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.

  2. lcnr commented on Mar 27, 2023

    @lcnr
    ContributorAuthor

    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
  3. lcnr commented on Mar 27, 2023

    @lcnr
    Author
  4. nandesu-utils commented on Mar 27, 2023

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

  5. petrochenkov commented on Mar 27, 2023

    @petrochenkov
    Contributor

    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.

  6. petrochenkov commented on Mar 27, 2023

    @petrochenkov
    Contributor

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

  7. petrochenkov commented on Mar 27, 2023

    @petrochenkov
    Contributor

    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.

  8. added
    A-diagnosticsArea: Messages for errors, warnings, and lints
    D-confusingDiagnostics: Confusing error or lint that should be reworked.
    and removed
    C-bugCategory: This is a bug.
    on Mar 29, 2023
  9. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Apr 5, 2023
  10. added a commit that references this issue on May 1, 2026
  11. added a commit that references this issue on May 1, 2026
  12. added a commit that references this issue on May 1, 2026
  13. added a commit that references this issue on May 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsD-confusingDiagnostics: Confusing error or lint that should be reworked.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions