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

Improve std::net docs #40838

Merged
merged 14 commits into from
Mar 29, 2017
Merged

Improve std::net docs #40838

merged 14 commits into from
Mar 29, 2017

Conversation

chordowl
Copy link
Contributor

Fixes #29363

Summary:

  • Added a lot of missing links, both to other types/methods and to IETF RFCs, and changed occurences of just "RFC" to "IETF RFC"
  • Expanded a bunch of top-level docs, specifically the module docs & the docs for TcpListener, TcpStream, UdpSocket, IpAddr, Ipv4Addr, Ipv6Addr, SocketAddr, SocketAddrV4, SocketAddrV6,
  • Expanded method docs for SocketAddrV6, AddrParseError,
  • Various edits for clarity, consistency, and accuracy

See the commit descriptions for more detail.

Things not done quite as laid out in the task list in #29363:

  • AddrParseError still doesn't have examples, but I wasn't quite sure how to do them; other FromStr error types don't have any, either
  • I didn't link to an IETF RFC in IpAddr, but in Ipv4Addr and Ipv6Addr and linked tho those from IpAddr; this seems more appropriate to me
  • Similarly, I didn't really exand SocketAddr's docs, but elaborated on SocketAddrV4 and SocketAddrV6's and linked to them from SocketAddr

Theres definitely still room for improvement, but this should be a good first effort 😄

Part of #29363

In the section about the default implementations of ToSocketAddrs,
I moved the bulletpoint of SocketAddrV4 & SocketAddrV6 to the one
stating that SocketAddr is constructed trivially, as this is what's
actually the case
Additionally changed the summary sentence to be more consistent with most
of the other FromStr implementations' error types.
Part of #29363
Expanded top-level documentation & linked to relevant IETF RFCs.
Added a bunch of links (to true/false/Ipv4Addr/etc.) throughout the docs.
Relative links in trait methods don't resolve in e.g.
std/primitive.tuple.html
:(
…AddrV6} docs

Part of #29363
Changed summary sentences of SocketAddr and IpAddr for consistency
Linked to SocketAddrV4 and SocketAddrV6 from SocketAddr, moving explaination
there
Expanded top-level docs for SocketAddrV4 and SocketAddrV6, linking to some
relevant IETF RFCs, and linking back to SocketAddr
Changed some of the method summaries to third person as per RFC 1574; added
links to IETF RFCs where appropriate
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@chordowl
Copy link
Contributor Author

r? @steveklabnik
(oops)

#[derive(Copy, Clone, PartialEq, Eq, Hash, Debug)]
#[stable(feature = "rust1", since = "1.0.0")]
pub enum SocketAddr {
/// An IPv4 socket address which is a (ip, port) combination.
/// An IPv4 socket address.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For those (like me) who aren't much into network, the original sentence made more sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll probably address this by mentioning this in SocketAddr's top-level docs again, since it's also (mostly) true for the V6 variant (unless someone has a better solution)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think it's fine; it's a summary line, not a full explanation.

#[stable(feature = "rust1", since = "1.0.0")]
V4(#[stable(feature = "rust1", since = "1.0.0")] SocketAddrV4),
/// An IPv6 socket address.
#[stable(feature = "rust1", since = "1.0.0")]
V6(#[stable(feature = "rust1", since = "1.0.0")] SocketAddrV6),
}

/// An IPv4 socket address which is a (ip, port) combination.
/// An IPv4 socket address.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this small introduction better but I think the removed part should be put somewhere under.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It being a combination of IP address and port is already stated in the next sentence. Should I make that more explicit?

/// Returns true if the IP in this `SocketAddr` is a valid IPv4 address,
/// false if it's a valid IPv6 address.
/// Returns [`true`] if the [IP address] in this `SocketAddr` is an
/// [IPv4 address] and [`false`] if it's an [IPv6 address].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if "or false" wouldn't be better than "and false". Anyone has a thought on this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd put a comma before the "and" (but keep the "and")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One formulation I thought about was , `false` otherwise, maybe that's better?

/// Returns true if the IP in this `SocketAddr` is a valid IPv6 address,
/// false if it's a valid IPv4 address.
/// Returns [`true`] if the [IP address] in this `SocketAddr` is an
/// [IPv6 address] and [`false`] if it's an [IPv4 address].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above.

@GuillaumeGomez
Copy link
Member

Except for the few (very) little nits I mentionned, it's awesome!

Copy link
Member

@killercup killercup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice.

/// Returns true if the IP in this `SocketAddr` is a valid IPv4 address,
/// false if it's a valid IPv6 address.
/// Returns [`true`] if the [IP address] in this `SocketAddr` is an
/// [IPv4 address] and [`false`] if it's an [IPv6 address].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd put a comma before the "and" (but keep the "and")

/// corresponding to the `sin6_flowinfo` field in C.
/// Returns the flow information associated with this address.
///
/// This information corresponds to the `sin6_flowinfo` field in C, as specified in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"in C" → "in C's netinet/in.h"

@@ -632,7 +746,9 @@ pub trait ToSocketAddrs {
///
/// # Errors
///
/// Any errors encountered during resolution will be returned as an `Err`.
/// Any errors encountered during resolution will be returned as an [`Err`].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is obvious from the function signature with Result that it returns an Err on error… Or you would have added a "Panics" section instead 😉 Maybe instead mention which Err variants it will return? Apparently one/some of std::io::Error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked around and it seems like the std::io::ErrorKinds that might (commonly) come in the provided implementations are InvalidInput, PermissionDenied, and NotFound.
I will add this instance with this PR, but this is kind of an issue in general throughout the docs (#40322) and out of scope for what I wanted to achieve with this PR. Thanks for the pointer tho, this does sound rather silly!
(Sidenote: I will have to test this myself, but it seems like from Windows' decode_error_kind implementation that this might return an io:Error with ErrorKind::Other more often then it should/could on Windows??)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So yes, agreed with both: this does feel a little redundant right now, but also, we do want to start describing which errors actually can happen.

You could also just remove this section for the purposes of this PR.

Copy link
Contributor Author

@chordowl chordowl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noticed some bona fide errors here and there, will correct them later

//! [`SocketAddrV6`]: ../../std/net/struct.SocketAddrV6.html
//! [`TcpListener`]: ../../std/net/struct.TcpListener.html
//! [`TcpStream`]: ../../std/net/struct.TcpStream.html
//! [`ToSocketAddr`]: ../../std/net/trait.ToSocketAddr.html
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be ../../std/net/trait.ToSocketAddrs.html (cought by linkchecker)

//! [`Ipv6Addr`] are respectively IPv4 and IPv6 addresses
//! * [`SocketAddr`] represents socket addresses of either IPv4 or IPv6; [`SocketAddrV4`]
//! and [`SocketAddrV6`] are respectively IPv4 and IPv6 socket addresses
//! * [`ToSocketAddr`] is a trait that used for generic address resolution interacting
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing a "when" before "interacting"

///
/// # Examples
///
/// ```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This example is missing the closing ```.

Copy link
Member

@steveklabnik steveklabnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonderful PR. Thanks so much!

@@ -632,7 +746,9 @@ pub trait ToSocketAddrs {
///
/// # Errors
///
/// Any errors encountered during resolution will be returned as an `Err`.
/// Any errors encountered during resolution will be returned as an [`Err`].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So yes, agreed with both: this does feel a little redundant right now, but also, we do want to start describing which errors actually can happen.

You could also just remove this section for the purposes of this PR.

* Fixed spelling ToSocketAddr -> ToSocketAddrs in module docs
  (which also fixes a link)
* Added missing "when" before "interacting" in module docs
* Changed SocketAddr's top-level docs to explicitly state what socket
  addresses consist of, making them more consistent with SocketAddrV4's
  and SocketAddrV6's docs
* Changed "in C" -> "in C's `netinet/in.h`"
* Changed wording in is_ipv4/is_ipv6 methods to ", `false` otherwise"
* Add missing closing ` ``` ` in Ipv6Addr's examples
* Removed "Errors" section in ToSocketAddrs' to_socket_addrs method as it
  was rather redundant
@chordowl
Copy link
Contributor Author

Addressed requested changes; see commit description for more details.

@steveklabnik
Copy link
Member

Looks great to me!

@GuillaumeGomez
Copy link
Member

Since everyone approved, I'll start the merge process. Don't hesitate to r- if there is anything wrong.
Thanks again @lukaramu!

@bors: r+ rollup

@bors
Copy link
Contributor

bors commented Mar 28, 2017

📌 Commit b8cbc5d has been approved by GuillaumeGomez

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Mar 29, 2017
…omez

Improve std::net docs

Fixes rust-lang#29363

Summary:
* Added a _lot_ of missing links, both to other types/methods and to IETF RFCs, and changed occurences of just "RFC" to "IETF RFC"
* Expanded a bunch of top-level docs, specifically the module docs & the docs for `TcpListener`, `TcpStream`, `UdpSocket`, `IpAddr`, `Ipv4Addr`, `Ipv6Addr`, `SocketAddr`, `SocketAddrV4`, `SocketAddrV6`,
* Expanded method docs for `SocketAddrV6`, `AddrParseError`,
* Various edits for clarity, consistency, and accuracy

See the commit descriptions for more detail.

Things not done quite as laid out in the task list in rust-lang#29363:
* `AddrParseError` still doesn't have examples, but I wasn't quite sure how to do them; other `FromStr` error types don't have any, either
* I didn't link to an IETF RFC in `IpAddr`, but in `Ipv4Addr` and `Ipv6Addr` and linked tho those from `IpAddr`; this seems more appropriate to me
* Similarly, I didn't really exand `SocketAddr`'s docs, but elaborated on `SocketAddrV4` and `SocketAddrV6`'s and linked to them from `SocketAddr`

Theres definitely still room for improvement, but this should be a good first effort 😄
frewsxcv added a commit to frewsxcv/rust that referenced this pull request Mar 29, 2017
…omez

Improve std::net docs

Fixes rust-lang#29363

Summary:
* Added a _lot_ of missing links, both to other types/methods and to IETF RFCs, and changed occurences of just "RFC" to "IETF RFC"
* Expanded a bunch of top-level docs, specifically the module docs & the docs for `TcpListener`, `TcpStream`, `UdpSocket`, `IpAddr`, `Ipv4Addr`, `Ipv6Addr`, `SocketAddr`, `SocketAddrV4`, `SocketAddrV6`,
* Expanded method docs for `SocketAddrV6`, `AddrParseError`,
* Various edits for clarity, consistency, and accuracy

See the commit descriptions for more detail.

Things not done quite as laid out in the task list in rust-lang#29363:
* `AddrParseError` still doesn't have examples, but I wasn't quite sure how to do them; other `FromStr` error types don't have any, either
* I didn't link to an IETF RFC in `IpAddr`, but in `Ipv4Addr` and `Ipv6Addr` and linked tho those from `IpAddr`; this seems more appropriate to me
* Similarly, I didn't really exand `SocketAddr`'s docs, but elaborated on `SocketAddrV4` and `SocketAddrV6`'s and linked to them from `SocketAddr`

Theres definitely still room for improvement, but this should be a good first effort 😄
bors added a commit that referenced this pull request Mar 29, 2017
Rollup of 5 pull requests

- Successful merges: #40682, #40731, #40783, #40838, #40864
- Failed merges:
@bors bors merged commit b8cbc5d into rust-lang:master Mar 29, 2017
@chordowl chordowl deleted the std-net-docs branch March 29, 2017 10:53
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

Successfully merging this pull request may close these issues.

8 participants