3 ms·
To clarify this a bit: 1. The widely used Time crate had some code which converted to an unspecified type. The code then converted this again in a following li
by joshka 2y ago
To clarify this a bit:
1. The widely used Time crate had some code which converted to an unspecified type. The code then converted this again in a following line. Because there was only a single possible (identity) conversion, this code was a noop. Regardless this was fixed in time@0.1.35 (released in April 9, 2024). [1]
2. Rust 1.80 (released July 27, 2024) introduced a new trait implementations that made the second conversion now cause the first conversions to have two possible inferences. [2]
3. Rust packages that upgraded the compiler to 1.80.0, but used a version of the time crate prior to 0.1.35 fail to build the time dependency. This is mitigated by the fact that 0.1.35 is a semver compatible update, which just requires running cargo update to use.
[1]: https://github.com/time-rs/time/pull/671 https://github.com/time-rs/time/pull/671
[2]: https://blog.rust-lang.org/2024/07/25/Rust-1.80.0.html#stabilized-apis https://blog.rust-lang.org/2024/07/25/Rust-1.80.0.html#stabi...
Something that would be neat to see from Rust here would be a way to measure the impact of these sorts of compiler and dependency bumps in order to reduce the blast radius of this sort of thing. Ideally being able to say "this change requires X devs to do process which cost Y minutes, so it's worth investing Z minutes to avoid / document it". I often want to make public API changes to a library I maintain, but the best tool I have for understanding who those changes will affect is often a GitHub search for code.
- bbatha 2y ago> Something that would be neat to see from Rust here would be a way to measure the impact of these sorts of compiler and dependency bumps in order to reduce the blast radius of this sort of thing. Ideally being able to say "this change requires X devs to do process which cost Y minutes, so it's worth investing Z minutes to avoid / document it". I often want to make public API changes to a library I maintain, but the best tool I have for understanding who those changes will affect is often a GitHub search for code. They have such a tool, its called crater. It was used used in making the decision to delay merging the new trait impl until the new version of time was published and in wide use. https://rustc-dev-guide.rust-lang.org/tests/crater.html https://rustc-dev-guide.rust-lang.org/tests/crater.html
- shepmaster 2y ago>> I often want to make public API changes to a library I maintain > They have such a tool, its called crater There are tools out in the wild that help crate authors do similar things. For example, I wrote my own[0] to evaluate some breaking changes for SNAFU. There's also crater-at-home[1] which I don't have any direct experience with. [0]: https://github.com/shepmaster/mini-crater https://github.com/shepmaster/mini-crater [1]: https://github.com/saethlin/crater-at-home https://github.com/saethlin/crater-at-home