Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No documentation on docs.rs for multicast_all_v4 and set_multicast_all_v4 #551

Closed
proski opened this issue Feb 14, 2025 · 5 comments
Closed

Comments

@proski
Copy link
Contributor

proski commented Feb 14, 2025

Functions multicast_all_v4 and set_multicast_all_v4 are missing from the Socket documentation: https://docs.rs/socket2/0.5.8/socket2/struct.Socket.html

Those functions are documented in the source code for version 0.5.8 (commit 60d118f) but that documentation is missing from the docs.rs site.

I don't know why the documentation is missing. For comparison, the documentation for set_reuse_port is on the site.

@Thomasdezeeuw
Copy link
Collaborator

Might be something wrong with the cfg attribute:

#[cfg_attr(docsrs, doc(cfg(all(feature = "all", target_os = "linux"))))]

@proski
Copy link
Contributor Author

proski commented Feb 15, 2025

It looks like all functions that depend on the all feature are undocumented.
I suspect that docs.rs fails to build the documentation using the package.metadata.docs.rs section in Cargo.toml and falls back to the default build without using that section. As a result, --all-features is not passed to the build.
Most likely, passing --cfg docsrs conflicts with the docs.rs invocation that passes docsrs already: https://docs.rs/about/builds
It's also possible that one of the targets is unavailable.

Another issue with the documentation is the lack of annotations that some functions are only available for specific platforms. I would consider adding a new (crate) feature that would enable the doc_auto_cfg (unstable Rust) feature and make the docsrs use unnecessary - it's a lot of duplicate code. And having a feature would make it easier to test the documentation generation locally.

@Darksonn
Copy link
Collaborator

Most likely, passing --cfg docsrs conflicts with the docs.rs invocation that passes docsrs already

We pass that in Tokio in the same way, and it works fine there, so that can't be the problem.

@proski
Copy link
Contributor Author

proski commented Feb 15, 2025

There are actually docs.rs logs available.
https://docs.rs/crate/socket2/0.5.8/builds

Indeed, --cfg docsrs is passed twice on the same command line. However, it doesn't trigger any warnings.

--all-features is passed to cargo, there are no warnings about it.

There is a warnings about the target for all targets (even for x86_64-unknown-linux-gnu), so it's probably not a real issue we should be worrying about.

[INFO] [stderr] warning: target filter specified, but no targets matched; this is a no-op

But the logs made me realize that there are separate sets of documentation for every platform, and I was looking at the documentation for the default target, aarch64-apple-ios.

I can switch "Platform" on the toolbar on top of the site to x86_64-unknown-linux-gnu and I get the expected documentation. multicast_all_v4 is documented, there is even a notice that it requires the all feature and Linux. https://docs.rs/socket2/0.5.8/x86_64-unknown-linux-gnu/socket2/struct.Socket.html#method.multicast_all_v4

Oh well, it must be a "user issue". Learning something every day.

But let's consider what could have been done better. Perhaps x86_64-unknown-linux-gnu should be the default target, and it's more feature rich.

I also assumed that something was wrong in the cfg_attr directives. I believe they are unnecessary if feature(doc_auto_cfg) is used.

I wish rustdoc would produce a single set of documentation (I assumed that was the case), but it must be a major task and it cannot be fixed in socket2.

Please feel free to close this issue after reading this.

@proski
Copy link
Contributor Author

proski commented Feb 28, 2025

Now I now that the documentation is platform specific. #554 will make x86_64-unknown-linux-gnu the default once a new release is made. Closing this issue as "user error".

@proski proski closed this as completed Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants