-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Ignore unknown address types when looking up hosts #34067
Ignore unknown address types when looking up hosts #34067
Conversation
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
} | ||
match result { | ||
Some(r) => Some(r), | ||
None => self.next(), | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change the implementation to an iterative one, please. Its a trivially optimisable tail-call which will not get optimised out in debug builds.
Seems to me like we’re losing on the errors reported by |
@nagisa No, this is only removing the error type when iterating over the |
Why change the iterator? If the real bug here is that unknown addresses cause too many errors then it sounds like we need to explicitly ignore those real addresses. Hiding errors seems... bad? |
We're not hiding an error any function is returning. |
Is... there motivation for this PR? Presumably you ran across this somehow? |
The motivation of this is that I don't know what to do with the The standard library's way to deal with them seems like a bad idea, the |
The libs team discussed this during triage yesterday and the conclusion was that this implementation seems fine for now, but the docs need to be bolstered with respect to the behavior here. Can you be sure to update relevant documentation to indicate that unknown address types are ignored? |
Previously, any function using a `ToSocketAddrs` input would fail if passed a hostname that resolves to an address type different from the ones recognized by Rust. This also changes the `LookupHost` iterator to only include the known address types, as a result, it doesn't have to return `Result`s any more, which are likely misinterpreted as failed name lookups.
e4fc282
to
6aa0182
Compare
@alexcrichton Updated the documentation. |
⌛ Testing commit 6aa0182 with merge fbafb96... |
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
That doesn't look like this PR's fault. |
@bors: retry On Thu, Jun 30, 2016 at 6:30 AM, tbu- notifications@github.com wrote:
|
⌛ Testing commit 6aa0182 with merge bb88a57... |
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
Something is seriously wrong with the bots, but it's not me:
|
⌛ Testing commit 6aa0182 with merge 1b514ac... |
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
@bors: retry On Fri, Jul 1, 2016 at 12:27 PM, bors notifications@github.com wrote:
|
…alexcrichton Ignore unknown address types when looking up hosts Previously, any function using a `ToSocketAddrs` input would fail if passed a hostname that resolves to an address type different from the ones recognized by Rust. This also changes the `LookupHost` iterator to only include the known address types, as a result, it doesn't have to return `Result`s any more, which are likely misinterpreted as failed name lookups.
Previously, any function using a
ToSocketAddrs
input would fail ifpassed a hostname that resolves to an address type different from the
ones recognized by Rust.
This also changes the
LookupHost
iterator to only include the knownaddress types, as a result, it doesn't have to return
Result
s anymore, which are likely misinterpreted as failed name lookups.