-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Stabilize the "IP" feature (continued from #76098) #85585
Conversation
Feature tracking issue: rust-lang#27709 - Stabilize the following methods: - `IpAddr::is_global` - `IpAddr::is_documentation` - `Ipv4Addr::is_global` - `Ipv4addr::is_shared` - `Ipv4Addr::is_ietf_protocol_assignment` - `Ipv4addr::is_benchmarking` - `Ipv4Addr::is_reserved` - `Ipv6Addr::is_global` - `Ipv6Addr::is_unique_local` - `Ipv6Addr::is_unicast_link_local_strict` - `Ipv6Addr::is_unicast_link_local` - `Ipv6Addr::is_unicast_site_local` - `Ipv6Addr::is_documentation` - `Ipv6Addr::is_unicast_global` - `Ipv6Addr::multicast_scope` - Stabilize the following enum: `Ipv6MulticastScope` - Document IP helpers stability guarantees (fixes rust-lang#60239)
Add variants for the currently reserved and un-assigned scopes. Since variants may be added in the future as new RFCs get published, we also make this enum #[non_exhaustive]. Ref: rust-lang#66584 (comment)
Thanks again for the help with understanding the attributes! Co-authored-by: Ashley Mannix <[email protected]>
Remove the looser `is_unicast_link_local` and rename `is_unicast_link_local_strict` as i suggested 😊 See rust-lang#76098 (comment)
Getting kind of extremely out of my comfort zone here and modifying quite a few different files...i hope this is all ok...
I really...i'm terrified i'm breaking something here
Because of the changes made due to the discussion [here](rust-lang#76098 (comment)), the checks for the more relaxed behavior of the old `is_unicast_link_local` method failed when they were tuned to the new, stricter checking behavior. These test cases have been modified to check that a given IPv6 address *is not* unicast link local, using a bitwise or'ing strategy that was already present in other test cases. Further discussion [here](https://rust-lang.zulipchat.com/#narrow/stream/212497-t-compiler.2Fhelp-wanted/topic/fix.20tests.20for.20.2376098).
This brings the behavior more in line with Go, Python, Linux, and C. I know, this should have been a `git revert` but honestly I don't trust myself with that and I just had a big mishap trying to merge upstream Rust anyway so forgive me :crying:
This reverts commit e0f66e43da61d8fe8aadc6bcdc2545de51607332.
Per [RFC 4291](https://tools.ietf.org/html/rfc4291#section-2.5.5.1), IPv6-Compatible IPv4 Addresses are deprecated and may be ignored, so let's ignore them! Also add some tests indicating that IPv6-Mapped addresses are treated specially, but IPv6-Compatible addresses are not.
…ses" This reverts commit 63329f9eadbba6da75a04cbf613f5701b06f71e5. Also, change the behavior of `to_ipv4` to ignore Ipv4-compatible addresses instead of adding another method `to_ipv4_mapped` and never ever using `to_ipv4` instead. Since this method is in stable.
- Use new intra-doc linking - Clarify that the RFC's are IETF RFC's
just did a really big rebase and i'm slightly concerned that i somehow tanked this whole branch but i guess we'll see
(rust-highfive has picked a reviewer for you, use r? to override) |
@saethlin this is the latest update I know of: #76098 (comment). I don't know the status other than that. |
I think the best way forward for this PR is to split it up into several smaller pieces:
Edit: updated to reflect the current state of things |
I split everything up into several issues:
|
Directly actionable for anyone right now:
I think anything else will require addressing the open problems listed in the issues I opened, which will require gathering evidence for the best approach and reaching a consensus. So I don't see stabilization of the entire |
r? @joshtriplett as T-libs member, not sure what the state here is but I likely don't have the expertise on various IP stuff to say anyway. |
☔ The latest upstream changes (presumably #85711) made this pull request unmergeable. Please resolve the merge conflicts. |
@saethlin Ping from triage! There's merge conflict now. Would you mind rebasing this pr? |
@crlf0710 I appreciate the attention. I'll get to this soon. |
Triage: Marking as |
Closing this because I have precious little expertise to offer here. It looks like there are much more capable contributors about, and I have other priorities. |
I noticed the work in #76098 seemed abandoned, so I'm reviving it here. I'm not particularly familiar with RFC 4291 but I'm no stranger to reading IETF RFCs.
I'm not totally clear on what still needs to be done. There's a fair bit of discussion in the preceding PR, but some if it seems outdated. Over the next few days I'll try to piece together what still needs to be done, but if anyone (@KodrAus, @CDirkx, @jyn514) knows better than I please point me in the right direction.