No need for pub(crate) in binary crates?

guidelines style
1

In a crate with multiple binaries, I guess the benefits of using pub(crate) over pub are:

  • the binary entrypoint modules cannot use the pub(crate) ones
  • potentially fewer symbols in target/debug/libmycrate.rlib (but I couldn't actually see a difference, so I don't think this is true)

so this doesn't seem worth the extra verbosity of pub(crate) (assuming that the entry points are very small).

Posting this mainly because this was not obvious to me before.

2

pub(crate) can help me check whether all functions are used.

Check the following codes:

pub mod foo1 {
    pub fn bar() {}
    pub(crate) fn baz() {}
}

pub(crate) mod foo2 {
    pub fn bar() {}
    pub(crate) fn baz() {}
}

fn main() {}

foo1::baz, foo2::bar and foo2::baz are reported not used, while foo1::bar is silently ignored.

3 Likes
3

I created a thread here a couple years ago about this. Ultimately it was decided that for diagnostic purposes this is fine, and there's been an open issue for it ever since.

4

For the purposes of a binary crate, since there's no external interface to put pub symbols in, it might make sense for us to warn about unused items even if they're pub.

The one case I can think of where that might cause issues would be sharing source files between a library and binary crate, but that's usually a bad idea anyway.

5 Likes
5

Is that true though? If you have a pub extern ā€œCā€œ item (presumably no_mangle as well), that can be used from dlopened libraries that you load, via dlsym. I assume the same will be true in crabi if that happens.

1 Like
6

I'm distinguishing here between pub and exported symbols (a property that for instance #[no_mangle] implies, and that we've talked about providing orthogonally to #[no_mangle]).

(And that's also orthogonal to ABI, e.g. "C".)