frost-rerandomized: warnings when building documentation

[StackOverflowExcept1on]

I use the main branch of frost as dependency and get this kind of warning because of some things being under feature flags.

frost/frost-rerandomized/src/lib.rs

Lines 264 to 271 in 061d1cb

	impl<C> RandomizedParams<C>
	where
	C: RandomizedCiphersuite,
	{
	/// Create a new [`RandomizedParams`] for the given [`VerifyingKey`] and
	/// the given `participants`.
	#[cfg(feature = "serialization")]
	pub fn new<R: RngCore + CryptoRng>(

$ cargo doc -p frost-rerandomized --no-default-features --release

warning: unresolved link to `RandomizedParams::new`
 --> frost-rerandomized/src/lib.rs:6:37
  |
6 | //! - The Coordinator should call [`RandomizedParams::new()`] and send
  |                                     ^^^^^^^^^^^^^^^^^^^^^^^ the struct `RandomizedParams` has no function named `new`
  |
  = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default

warning: unresolved link to `Randomizer::new`
   --> frost-rerandomized/src/lib.rs:225:11
    |
225 |     /// [`Randomizer::new()`] instead.
    |           ^^^^^^^^^^^^^^^^^ the struct `Randomizer` has no function named `new`

warning: unresolved link to `RandomizedParams::new`
   --> frost-rerandomized/src/lib.rs:289:49
    |
289 |     /// be generated uniformly at random! Use [`RandomizedParams::new()`] which
    |                                                 ^^^^^^^^^^^^^^^^^^^^^^^ the struct `RandomizedParams` has no function named `new`

warning: `frost-rerandomized` (lib doc) generated 3 warnings

[conradoplg]

I'm not sure we want to support --no-default-features for cargo doc. We use doc_cfg to label functions which are available only for some features (though we did forget to do that in frost-rerandomized, but I think there is no point fixing it because it will vanish with #762), and that only works with --all-features.

You can likely get rid of the warning by using --no-deps with cargo doc - usually there is no reason to generate the documentation for the dependencies.

Thanks for reporting this though, it reminded me of creating #809