[dependabot]

Bumps packed_struct_codegen from 0.10.1 to 0.12.0.

Release notes

Sourced from packed_struct_codegen's releases.

0.12.0

This is the first release since 0.10.1. The 0.11.0 version number was used on master in the meantime but never published to crates.io, so everything below is relative to 0.10.1.

The release contains several silent wire-format fixes: some struct definitions that compiled under 0.10.1 packed and unpacked their fields at the wrong bits. They still compile, but the bytes they produce and accept are now different (and correct). If you store packed data or exchange it with other systems, read Wire-format fixes before upgrading.

Upgrade checklist

1. Search your code for exclusive byte ranges, bytes="x..y". Every one of them changes its layout, see below.
2. Check for nested structs, reserved fields or other fields of 32 bytes or more that don't start and end on a byte boundary.
3. Fix any new compile errors about field positions and sizes that disagree. Each one points at a field whose layout was previously wrong or ambiguous.
4. Upgrade the toolchain to Rust 1.85 or newer.

Wire-format fixes

These change what pack() produces and what unpack() expects for the affected structs, with no compile error or warning.

Exclusive byte ranges, bytes="x..y", were one byte short (#107)

The byte range was converted to bits as x*8 ..= (y-1)*8 - 1 instead of x*8 ..= y*8 - 1, so bytes="0..2" covered only byte 0, and bytes="1..3" only byte 1. Bit ranges (bits="x..y") and inclusive byte ranges (bytes="x..=y") were not affected.

Whenever the type still fit into the shorter range, this compiled and silently truncated the field:

#[derive(PackedStruct)]
#[packed_struct(endian="msb", bit_numbering="msb0", size_bytes="4")]
pub struct Reg {
    #[packed_field(bytes="0..4")]
    value: u32,
}

	0.10.1	0.12.0
Reg { value: 0x12345678 }.pack()	[0x34, 0x56, 0x78, 0x00], a 24-bit field	[0x12, 0x34, 0x56, 0x78]
Reg::unpack(&[0x12, 0x34, 0x56, 0x78])	value: 0x123456, the last byte ignored	value: 0x12345678

The same happened to a u64 at bytes="0..8" (packed as 56 bits), and to array fields, whose elements shrank to fit: [u8; 4] at bytes="0..4" was packed as four 6-bit elements into the first 3 bytes. Fields that didn't fit into the shorter range, like a u16 at bytes="0..2", failed to

... (truncated)

Changelog

Sourced from packed_struct_codegen's changelog.

[0.12.0] - 2026-10-01

This is the first release since 0.10.1. The 0.11.0 version number was used on master in the meantime but never published to crates.io, so everything below is relative to 0.10.1.

The release contains several silent wire-format fixes: some struct definitions that compiled under 0.10.1 packed and unpacked their fields at the wrong bits. They still compile, but the bytes they produce and accept are now different (and correct). If you store packed data or exchange it with other systems, read Wire-format fixes before upgrading.

Upgrade checklist

1. Search your code for exclusive byte ranges, bytes="x..y". Every one of them changes its layout, see below.
2. Check for nested structs, reserved fields or other fields of 32 bytes or more that don't start and end on a byte boundary.
3. Fix any new compile errors about field positions and sizes that disagree. Each one points at a field whose layout was previously wrong or ambiguous.
4. Upgrade the toolchain to Rust 1.85 or newer.

Wire-format fixes

These change what pack() produces and what unpack() expects for the affected structs, with no compile error or warning.

Exclusive byte ranges, bytes="x..y", were one byte short (#107)

The byte range was converted to bits as x*8 ..= (y-1)*8 - 1 instead of x*8 ..= y*8 - 1, so bytes="0..2" covered only byte 0, and bytes="1..3" only byte 1. Bit ranges (bits="x..y") and inclusive byte ranges (bytes="x..=y") were not affected.

Whenever the type still fit into the shorter range, this compiled and silently truncated the field:

#[derive(PackedStruct)]
#[packed_struct(endian="msb", bit_numbering="msb0", size_bytes="4")]
pub struct Reg {
    #[packed_field(bytes="0..4")]
    value: u32,
}

	0.10.1	0.12.0
Reg { value: 0x12345678 }.pack()	[0x34, 0x56, 0x78, 0x00], a 24-bit field	[0x12, 0x34, 0x56, 0x78]
Reg::unpack(&[0x12, 0x34, 0x56, 0x78])	value: 0x123456, the last byte ignored	value: 0x12345678

The same happened to a u64 at bytes="0..8" (packed as 56 bits), and to array fields, whose elements shrank to fit: [u8; 4] at bytes="0..4" was packed as four 6-bit elements into the first 3 bytes. Fields that didn't fit into the shorter range, like a u16 at bytes="0..2", failed to

... (truncated)

Commits

• 9d05db2 Merge pull request #121 from hashmismatch/byte-order-lsb
• 4e28719 Add byte_order="lsb" for little-endian bitfield structures
• 41b1572 Document the packing table and the runtime display
• b954d76 Merge pull request #120 from hashmismatch/docs-changelog-enum-fixes
• bb533c4 Document how lsb0 bit numbering works (#92)
• 869be84 Generate Bits<N> up to the full byte width
• 9d8bb4a Fix the inferred primitive type of enums
• 77375cf Document the public API and fix outdated docs
• be27832 Add a changelog
• ab8e0fd Merge pull request #119 from hashmismatch/fix-unaligned-int-packing
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)