Conditional visibility: for integration testing purpose.

For integration testing purpose, it might be necessary to expose more API surface than usual. While it might be possible to directly add integration testing related support, it might be easier to add general purpose mechanism for this.

Strawman proposal:

#[cfg_vis(feature = "internals", pub)]
pub(crate) mod internal_api {
     #[cfg_vis(feature = "internals", pub)]
     pub(crate) fn foo() {
          todo!()
     }
}

or

pub (crate if cfg!(not(feature = "internals"))) mod internal_api {
     pub (crate if cfg!(not(feature = "internals"))) fn foo() {
          todo!()
     }
}

or even

#[cfg(feature = "internals")]
vis internals = pub;

#[cfg(not(feature = "internals"))]
vis internals = pub(crate);

pub(internals) mod internal_api {
     pub(internals) fn foo() {
          todo!()
     }
}

Related existing macro-based crates.

• https://docs.rs/visibility
• https://docs.rs/cfg-vis

Start by comparing the proposed mechanisms with the existing visibility and cfg-vis crates linked in the issue. Determine whether conditional visibility belongs in Rust's language or compiler design, and document one agreed direction with its syntax, semantics, and integration-testing use case. Done means the proposal has a settled scope suitable for an RFC or follow-up implementation issue.