Bump rain-lib-memkv 0.1.5 -> 0.2.0 - #239
Conversation
Moves the pin, the lock entry, the remapping and the five versioned imports to 0.2.0. Closes #238 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (7)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. WalkthroughThe project updates Changesrain-lib-memkv upgrade
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Other Suggested reviewers: Merge Risk: ⚪ Minimal · up to The dependency upgrade preserves the existing MemoryKV usage, with no concrete build or runtime regression identified. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
Full details: Linked Issues checkExplanation Issue ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
Moves the
rain-lib-memkvpin from 0.1.5 to 0.2.0.foundry.tomlandsoldeer.lockcome fromforge soldeer update. The versioned prefixrain-lib-memkv-0.1.5/becomesrain-lib-memkv-0.2.0/inremappings.txtandin the five files that import the store:
src/abstract/RainDeployVerifySnapshotBase.soltest/script/Build.t.soltest/script/Deploy.t.soltest/src/lib/GeneratedSnapshotShape.t.soltest/src/lib/LibRainDeploySnapshot.t.solsoldeer updateadds the 0.2.0 remapping but leaves the 0.1.5 line in place.That line is removed here because nothing resolves through it any more.
Closes #238
Why 0.2.0's aliasing change does not reach this repo
In 0.2.0 a
MemoryKVis a handle to memory. Once a store is non-empty, everycopy of its handle refers to the same store, so a write through one copy shows
up in all of them. This repo uses the store only as a string set, and every
site follows one pattern: a fresh
MemoryKV x = MemoryKV.wrap(0), thenx = x.set(key, MemoryKVVal.wrap(0))in a loop, thenx.has(key)reads.Across the five files there are 15 handles and 15
setcalls. Eachsetassigns back to the handle it was called on. No handle is assigned from
another handle, passed to a function, returned, or saved and restored. No two
copies of a handle ever exist, so there is nothing that could alias.
setandhaskeep their signatures, and the build compiles unchanged.QA
and no assertion changes. The set sites above already exercise
setandhasin the existing suite, and CI runs that suite.five imports still on
rain-lib-memkv-0.1.5/,forge buildfails on everyone with
Error (6275): Source "rain-lib-memkv-0.1.5/src/lib/LibMemoryKV.sol" not found. With the rewrite it compiles (126 files, Solc 0.8.25,"Compiler run successful!").
(
api.soldeer.xyz/api/v1/revision?project_name=rain-lib-memkv). 0.2.0 is thenewest revision (published 2026-09-18T21:06:03Z) at
0_2_0_18-09-2026_21:06:03_rain.lib.zip, and that is the URLsoldeer.locknow records.git grep '0\.1\.5'finds no memkv reference. Two hitsremain, and neither is this dependency.
audit/mutation-test-scans.jsonhaspublishedTag: sol-v0.1.5, which is this repo's own release tag.tools/hyperliquid-big-blocks/Cargo.lockhashttp-body-util 0.1.5, a Rustcrate.
🤖 Generated with Claude Code
Summary by CodeRabbit