jiff - cargo Package Compare versions

Comparing version 0.2.27 to 0.2.28

.cargo_vcs_info.json

 {
   "git": {
-    "sha1": "a6870c43a677c478000225f6d2e443e961877063"
+    "sha1": "66f6ec2d0b75112deadf7e067dbf2ef114d41c50"
   },
   "path_in_vcs": ""
 }

Cargo.lock

@@ -301,3 +301,3 @@ # This file is automatically @generated by Cargo.
 name = "jiff"
-version = "0.2.27"
+version = "0.2.28"
 dependencies = [
@@ -333,5 +333,5 @@ "anyhow",
 name = "jiff-static"
-version = "0.2.27"
+version = "0.2.28"
 source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "47b605b0c050d845fc355bb11eb3f9a8deddc218ea60c76e61aa1f2adfb2c96a"
+checksum = "782d32378dddf207193ac91cefb848ad41abb58195c95168e1291227a0832b47"
 dependencies = [
@@ -338,0 +338,0 @@ "jiff-tzdb",

Cargo.toml

@@ -16,3 +16,3 @@ # THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
 name = "jiff"
-version = "0.2.27"
+version = "0.2.28"
 authors = ["Andrew Gallant <[e-mail]>"]
@@ -205,3 +205,3 @@ build = false
 [target."cfg(any())".dependencies.jiff-static]
-version = "=0.2.27"
+version = "=0.2.28"
 
@@ -208,0 +208,0 @@ [target.'cfg(any(windows, target_family = "wasm"))'.dependencies.jiff-tzdb-platform]

CHANGELOG.md

 # CHANGELOG
 
+0.2.28 (2026-05-28)
+===================
+This is a small release with a fix for test failures on 32-bit targets in
+`no-alloc` environments.
+
+Bug fixes:
+
+* [#573](https://github.com/BurntSushi/jiff/issues/573):
+Fix test failure on 32-bit targets in `no-alloc` environments.
+
+
 0.2.27 (2026-05-26)
@@ -4,0 +15,0 @@ ===================

README.md

@@ -120,2 +120,7 @@ Jiff
 
+Once Jiff 1.0 is released, Jiff 0.2 will continue to get critical bug fix
+updates. There won't be any active feature development, but since so many folks
+are already using Jiff 0.2, it makes sense to offer a transition grace period.
+My plan here is to do it for 1 year after Jiff 1.0 is released.
+
 ### Performance
@@ -122,0 +127,0 @@

src/error/mod.rs

@@ -772,35 +772,47 @@ use crate::util::{
     fn error_size() {
-        let mut expected_size = core::mem::size_of::<usize>();
-        if !cfg!(feature = "alloc") {
-            // oooowwwwwwwwwwwch.
-            //
-            // Like, this is horrible, right? core-only environments are
-            // precisely the place where one want to keep things slim. But
-            // in core-only, I don't know of a way to introduce any sort of
-            // indirection in the library level without using a completely
-            // different API.
-            //
-            // This is what makes me doubt that core-only Jiff is actually
-            // useful. In what context are people using a huge library like
-            // Jiff but can't define a small little heap allocator?
-            //
-            // OK, this used to be `expected_size *= 10`, but I slimmed it down
-            // to x3. Still kinda sucks right? If we tried harder, I think we
-            // could probably slim this down more. And if we were willing to
-            // sacrifice error message quality even more (like, all the way),
-            // then we could make `Error` a zero sized type. Which might
-            // actually be the right trade-off for core-only, but I'll hold off
-            // until we have some real world use cases.
-            //
-            // OK... after switching to structured errors, this jumped
-            // back up to `expected_size *= 6`. And that was with me being
-            // conscientious about what data we store inside of error types.
-            // Blech.
-            //
-            // 2026-01-14: A change to the `Offset` type made this move back
-            // down to `expected_size *= 4`.
-            expected_size *= 4;
+        if cfg!(feature = "alloc") {
+            let expected_size = core::mem::size_of::<usize>();
+            assert_eq!(expected_size, core::mem::size_of::<Error>());
+            return;
         }
-        assert_eq!(expected_size, core::mem::size_of::<Error>());
+        // oooowwwwwwwwwwwch.
+        //
+        // Like, this is horrible, right? core-only environments are
+        // precisely the place where one want to keep things slim. But
+        // in core-only, I don't know of a way to introduce any sort of
+        // indirection in the library level without using a completely
+        // different API.
+        //
+        // This is what makes me doubt that core-only Jiff is actually
+        // useful. In what context are people using a huge library like
+        // Jiff but can't define a small little heap allocator?
+        //
+        // OK, this used to be `expected_size *= 10`, but I slimmed it down
+        // to x3. Still kinda sucks right? If we tried harder, I think we
+        // could probably slim this down more. And if we were willing to
+        // sacrifice error message quality even more (like, all the way),
+        // then we could make `Error` a zero sized type. Which might
+        // actually be the right trade-off for core-only, but I'll hold off
+        // until we have some real world use cases.
+        //
+        // OK... after switching to structured errors, this jumped
+        // back up to `expected_size *= 6`. And that was with me being
+        // conscientious about what data we store inside of error types.
+        // Blech.
+        //
+        // 2026-01-14: A change to the `Offset` type made this move back
+        // down to `expected_size *= 4`.
+        //
+        // 2026-05-28: No changes here, but `4 * pointer-size` is not the
+        // right calculation here. This is unfortunately coupled with an
+        // internal representation for the biggest possible error variant.
+        // And also compiler optimizations. But at time of writing, it's
+        // from the `jiff::error::tz::offset::Error` enum. We get 4 32-bit
+        // integers (always 32-bit) plus one pointer sized discriminant.
+        //
+        // 2026-05-28 redux: this now seems coupled with compiler
+        // optimizations. So just give up and check that it's reasonable.
+        let got = core::mem::size_of::<Error>();
+        assert!(got <= 40, "wanted error size to be <= 40, but got {got}");
     }
 }

No alert changes

No metric changes