Ensure tcp test case passes when disconnected from network

[tmerr]

net::tcp::tests::connect_timeout_unroutable fails when the network
is unreachable, like on a laptop disconnected from wifi. Check for
this error and allow the test to pass.

Closes #44645

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @dtolnay (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.

[dtolnay]

Thanks! Is there any way to tell that the Other case corresponds to the network being unreachable? Is there a consistent error message across platforms or anything else we could check here?

[tmerr]

A few ideas

• Make the test include a platform-dependent comparison against error.raw_os_error(). Check for libc::ENETUNREACH on POSIX and I guess a hard coded 10051 representing WSAENETUNREACH on Windows.
• Compare error.description() == "Network is unreachable". But can this be relied on?
• Add an ErrorKind::NetworkUnreachable for this error

The first 2 ideas seem a little sketchy to me, and I am guessing the 3rd would need an RFC, but I am out of my depth here so any advice is appreciated!

[dtolnay]

Let's go ahead with your fix -- requiring network access for the test suite to succeed seems like an oversight.

The risk here is that at some point we mess up connect_timeout so that it always returns some wrong Other error code instead of timing out, and we fail to notice. That seems unlikely and minor enough that merging your fix is more important.

If you do want to follow up with another PR to improve the test, any of your 3 ideas sounds good to me. I believe we could do the 3rd one without a formal RFC. The variant would have an #[unstable] attribute when it is added, be unstable for a couple releases, and the libs team would discuss before eventually stabilizing it. The first 2 ideas are fine too and it wouldn't need to be super thorough. Just two different asserts for #[cfg(unix)] and #[cfg(not(unix))] would be decent, where unix looks for ENETUNREACH and not-unix just accepts any Other error like in the current code.

@bors r+ rollup

[bors]

📌 Commit fcdd46e has been approved by dtolnay