Skip to content

Fix the two stdlib breakages blocking every mojo-redis build - #5

Merged
conorbronsdon merged 1 commit into
mainfrom
fix-array-copy-and-ptr-offset
Jul 31, 2026
Merged

Fix the two stdlib breakages blocking every mojo-redis build#5
conorbronsdon merged 1 commit into
mainfrom
fix-array-copy-and-ptr-offset

Conversation

@conorbronsdon

@conorbronsdon conorbronsdon commented Jul 31, 2026

Copy link
Copy Markdown
Owner

Unlike the other mojo repos, mojo-redis is not recent nightly drift — neither workflow has ever been green, going back to the 7/29 publish. Both test and docs fail on the same two errors, so this fixes both.

1. src/redis/connection.mojo:97InlineArray is no longer ImplicitlyCopyable

error: value of type 'Array[UInt8, Int(4)]' cannot be implicitly copied
note: consider transferring the value with '^'

octets is dead after the return, so ^ is the right call — the compiler's other suggestion, .copy(), would add a pointless 4-byte copy.

2. src/redis/connection.mojo:201 — pointer arithmetic now requires an unsafe pointer

UnsafePointer split into safe and unsafe variants, and __add__ gained a where Self._is_unsafe constraint that List.unsafe_ptr()'s return type doesn't satisfy. unsafe_offset is the identical operation without the constraint — __add__ literally forwards to it (unsafe_pointer.mojo:827) — so behaviour is unchanged.

Not addressed here: the init_pointee_copyunsafe_write deprecation warnings. They're warnings, don't fail the build, and are a separate change.

🤖 Generated with Claude Code

Both the test and docs workflows have failed since the repo was published --
neither has ever been green -- and both fail on the same two errors.

InlineArray no longer conforms to ImplicitlyCopyable, so returning the local
`octets` out of _parse_ipv4 needs an explicit transfer. The value is dead after
the return, so `^` is right; `.copy()` would add a needless copy of 4 bytes.

UnsafePointer split safe and unsafe variants, and `__add__` now carries a
`where Self._is_unsafe` constraint that List.unsafe_ptr()'s return type does not
satisfy. `unsafe_offset` is the same operation with no such constraint -- it is
what `__add__` itself forwards to -- so the pointer arithmetic is unchanged in
behaviour.

Leaves the init_pointee_copy deprecation warnings alone; they are warnings, not
errors, and swapping them for unsafe_write is a separate change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@conorbronsdon
conorbronsdon merged commit 598fe7c into main Jul 31, 2026
1 check passed
@conorbronsdon
conorbronsdon deleted the fix-array-copy-and-ptr-offset branch July 31, 2026 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant