Although its such a minor thing, the stabilization of Ipv4Addr::from_octets and Ipv6Addr::from_segments arrived just in time for one of my no_std Rust networking projects. These methods were introduced some time last year but were marked unstable until recently.
The `--target host-tuple` feature being stabilized is also a nice quality-of-life change.
Since I do not have a test harness for some platforms (like aarch64-unknown-uefi or thumbv7em-none-eabihf), I typically compile unit tests against my host platform and run them there. Previously, one would have to write the host tuple explicitly, like so.
cargo test --target aarch64-apple-darwin
The `target` value needs to be substituted for each target if you e.g. orchestrate builds with Nix or other tooling. Now it is sufficient to just run
cargo test --target host-tuple
Similarly, if you use cfg_attrs to partition platform-specific code, the .cargo/config.toml can be configured like so, to conveniently build and test platform-independent code.
Although its such a minor thing, the stabilization of Ipv4Addr::from_octets and Ipv6Addr::from_segments arrived just in time for one of my no_std Rust networking projects. These methods were introduced some time last year but were marked unstable until recently.
The `--target host-tuple` feature being stabilized is also a nice quality-of-life change.
Since I do not have a test harness for some platforms (like aarch64-unknown-uefi or thumbv7em-none-eabihf), I typically compile unit tests against my host platform and run them there. Previously, one would have to write the host tuple explicitly, like so.
The `target` value needs to be substituted for each target if you e.g. orchestrate builds with Nix or other tooling. Now it is sufficient to just run Similarly, if you use cfg_attrs to partition platform-specific code, the .cargo/config.toml can be configured like so, to conveniently build and test platform-independent code.