Constify std::net::IpAddr, Ipv4Addr, and Ipv6Addr
#76205
Labels
A-const-fn
Area: const fn foo(..) {..}. Pure functions which can be applied at compile time.
C-feature-request
Category: A feature request, i.e: not implemented / a PR.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
jonas-schievink
added
A-const-fn
CDirkx
pushed a commit
to CDirkx/rust
that referenced
this issue
Sep 1, 2020
Make the following methods of `std::net::Ipv6Addr` unstable const under the `const_ipv6` feature: - `segments` - `is_unspecified` - `is_loopback` - `is_global` (unstable) - `is_unique_local` - `is_unicast_link_local_strict` - `is_documentation` - `multicast_scope` - `is_multicast` - `to_ipv4_mapped` - `to_ipv4` Changed the implementation of `is_unspecified` and `is_loopback` to use a `match` instead of `==`. Part of rust-lang#76205
This was referenced Sep 1, 2020
tmandry
added a commit
to tmandry/rust
that referenced
this issue
Sep 2, 2020
Make all methods of `std::net::Ipv6Addr` const Make the following methods of `std::net::Ipv6Addr` unstable const under the `const_ipv6` feature: - `segments` - `is_unspecified` - `is_loopback` - `is_global` (unstable) - `is_unique_local` - `is_unicast_link_local_strict` - `is_documentation` - `multicast_scope` - `is_multicast` - `to_ipv4_mapped` - `to_ipv4` This would make all methods of `Ipv6Addr` const. Changed the implementation of `is_unspecified` and `is_loopback` to use a `match` instead of `==`, all other methods did not require a change. All these methods are dependent on `segments`, the current implementation of which requires unstable `const_fn_transmute` ([PR#75085](rust-lang#75085)). Part of rust-lang#76205
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Sep 3, 2020
Make all methods of `std::net::Ipv4Addr` const Make the following methods of `std::net::Ipv4Addr` unstable const under the `const_ipv4` feature: - `octets` - `is_loopback` - `is_private` - `is_link_local` - `is_global` (unstable) - `is_shared` (unstable) - `is_ietf_protocol_assignment` (unstable) - `is_benchmarking` (unstable) - `is_reserved` (unstable) - `is_multicast` - `is_broadcast` - `is_documentation` - `to_ipv6_compatible` - `to_ipv6_mapped` This would make all methods of `Ipv6Addr` const. Of these methods, `is_global`, `is_broadcast`, `to_ipv6_compatible`, and `to_ipv6_mapped` require a change in implementation. Part of rust-lang#76205
CDirkx
added a commit
to CDirkx/rust
that referenced
this issue
Sep 23, 2020
Make the following methods of `std::net::IpAddr` unstable const under the `const_ip` feature: - `is_unspecified` - `is_loopback` - `is_global` - `is_multicast` Also adds a test for these methods in a const context. Possible because these methods delegate to the inner `Ipv4Addr` or `Ipv6Addr`, which were made const, and the recent stabilization of const control flow. Part of rust-lang#76205
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Sep 24, 2020
Make delegation methods of `std::net::IpAddr` unstably const Make the following methods of `std::net::IpAddr` unstable const under the `const_ip` feature: - `is_unspecified` - `is_loopback` - `is_global` - `is_multicast` Also adds a test for these methods in a const context. Possible because these methods delegate to the inner `Ipv4Addr` or `Ipv6Addr`, which were made const ([PR#76205](rust-lang#76142) and [PR#76206](rust-lang#76206)), and the recent stabilization of const control flow. Part of rust-lang#76205 r? @ecstatic-morse
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Nov 23, 2020
Stabilize `IpAddr::is_ipv4` and `is_ipv6` as const Insta-stabilize the methods `is_ipv4` and `is_ipv6` of `std::net::IpAddr` as const, in the same way as [PR#76198](rust-lang#76198). Possible because of the recent stabilization of const control flow. Part of rust-lang#76225 and rust-lang#76205.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 19, 2020
Stabilize all stable methods of `Ipv4Addr`, `Ipv6Addr` and `IpAddr` as const This PR stabilizes all currently stable methods of `Ipv4Addr`, `Ipv6Addr` and `IpAddr` as const. Tracking issue: rust-lang#76205 `Ipv4Addr` (`const_ipv4`): - `octets` - `is_loopback` - `is_private` - `is_link_local` - `is_multicast` - `is_broadcast` - `is_docmentation` - `to_ipv6_compatible` - `to_ipv6_mapped` `Ipv6Addr` (`const_ipv6`): - `segments` - `is_unspecified` - `is_loopback` - `is_multicast` - `to_ipv4` `IpAddr` (`const_ip`): - `is_unspecified` - `is_loopback` - `is_multicast` ## Motivation The ip methods seem like prime candidates to be made const: their behavior is defined by an external spec, and based solely on the byte contents of an address. These methods have been made unstable const in the beginning of September, after the necessary const integer arithmetic was stabilized. There is currently a PR open (rust-lang#78802) to change the internal representation of `IpAddr{4,6}` from `libc` types to a byte array. This does not have any impact on the constness of the methods. ## Implementation Most of the stabilizations are straightforward, with the exception of `Ipv6Addr::segments`, which uses the unstable feature `const_fn_transmute`. The code could be rewritten to equivalent stable code, but this leads to worse code generation (rust-lang#75085). This is why `segments` gets marked with `#[rustc_allow_const_fn_unstable(const_fn_transmute)]`, like the already const-stable `Ipv6Addr::new`, the justification being that a const-stable alternative implementation exists rust-lang#76206 (comment). ## Future posibilities This PR const-stabilizes all currently stable ip methods, however there are also a number of unstable methods under the `ip` feature (rust-lang#27709). These methods are already unstable const. There is a PR open (rust-lang#76098) to stabilize those methods, which could include const-stabilization. However, stabilizing those methods as const is dependent on `Ipv4Addr::octets` and `Ipv6Addr::segments` (covered by this PR).
|
has there been any updates on this? |
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Sep 19, 2023
Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable, as well as
const stabilize `Ipv6Addr::to_ipv4_mapped`.
Newly stable API:
impl IpAddr {
// Now stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
}
impl Ipv6Addr {
// Now stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
// Already stable, this makes it const stable under
// `const_ipv6_to_ipv4_mapped
const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
These stabilize a subset of the following tracking issues:
- rust-lang#27709
- rust-lang#76205
tgross35
added a commit
to tgross35/rust
that referenced
this issue
Sep 19, 2023
Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable, as well as
const stabilize `Ipv6Addr::to_ipv4_mapped`.
Newly stable API:
impl IpAddr {
// Now stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
}
impl Ipv6Addr {
// Now stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
// Already stable, this makes it const stable under
// `const_ipv6_to_ipv4_mapped`
const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
These stabilize a subset of the following tracking issues:
- rust-lang#27709
- rust-lang#76205
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 15, 2023
Stabilize `{IpAddr, Ipv6Addr}::to_canonical`
Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`.
Newly stable API:
```rust
impl IpAddr {
// Newly stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
}
impl Ipv6Addr {
// Newly stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
// Already stable, this makes it const stable under
// `const_ipv6_to_ipv4_mapped`
const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
```
These stabilize a subset of the following tracking issues:
- rust-lang#27709
- rust-lang#76205
Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward.
I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708
cc implementor `@the8472`
r? libs-api
`@rustbot` label +T-libs-api +needs-fcp
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 16, 2023
Stabilize `{IpAddr, Ipv6Addr}::to_canonical`
Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`.
Newly stable API:
```rust
impl IpAddr {
// Newly stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
}
impl Ipv6Addr {
// Newly stable under `ip_to_canonical`
const fn to_canonical(&self) -> IpAddr;
// Already stable, this makes it const stable under
// `const_ipv6_to_ipv4_mapped`
const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
```
These stabilize a subset of the following tracking issues:
- rust-lang#27709
- rust-lang#76205
Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward.
I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708
cc implementor ``@the8472``
r? libs-api
``@rustbot`` label +T-libs-api +needs-fcp
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 16, 2023
Rollup merge of rust-lang#115955 - tgross35:ip-to-canonical, r=dtolnay Stabilize `{IpAddr, Ipv6Addr}::to_canonical` Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`. Newly stable API: ```rust impl IpAddr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; } impl Ipv6Addr { // Newly stable under `ip_to_canonical` const fn to_canonical(&self) -> IpAddr; // Already stable, this makes it const stable under // `const_ipv6_to_ipv4_mapped` const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> } ``` These stabilize a subset of the following tracking issues: - rust-lang#27709 - rust-lang#76205 Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward. I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708 cc implementor ``@the8472`` r? libs-api ``@rustbot`` label +T-libs-api +needs-fcp
|
Closing this as it these have been stabilised by #79342. If any are missing it is better to add them in a new tracking issue for visibility sake. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Due to recent stabilizations of const integer arithmetic and const control flow, all methods of types
std::net::IpAddr,Ipv4Addr, andIpv6Addrcan be made const. This issue provides an overview of all methods and steps that need to be taken:Ipv4AddrMethods already stable const:
newis_unspecifiedMethods unstable const by PR#76142 (
const_ipv4):octetsis_loopbackis_privateis_link_localis_shared(unstable)is_ietf_protocol_assignment(unstable)is_benchmarking(unstable)is_multicastis_documentationis_global(unstable)is_reserved(unstable)is_broadcastto_ipv6_compatible(deprecated?)to_ipv6_mappedNone of these methods depends on an unstable feature, and could all thus be made stable const.
Ipv6AddrMethods already stable const:
new(uses#[allow_internal_unstable(const_fn_transmute)])octetsIpv6Addr::segmentshas been made unstable const in PR#76206 (const_ipv6), together with all dependent methods:segmentsis_unspecifiedis_loopbackis_global(unstable)is_unique_local(unstable)is_unicast_link_local_strict(unstable)is_documentation(unstable)multicast_scope(unstable)is_multicastto_ipv4_mapped(unstable)to_ipv4All of these methods depend on
segments, and thus upon the unstable featureconst_fn_transmute, however the transmute is only used for better code generation, the operations could be rewritten equivalently using stable const code.IpAddrThe following methods are stable const:
is_ip4is_ipv6Implemented in PR#76226.
With the relevant methods of
Ipv4AddrandIpv6Addrmade const, the following were also made unstable const in PR#76304:is_documentation(unstable)is_global(unstable)is_loopbackis_multicastis_unspecifiedThe text was updated successfully, but these errors were encountered: