Skip to content

Bump the pinned standard library, and check its string handling - #1240

Merged
Frotty merged 1 commit into
masterfrom
deps/bump-pinned-stdlib
Aug 16, 2026
Merged

Bump the pinned standard library, and check its string handling#1240
Frotty merged 1 commit into
masterfrom
deps/bump-pinned-stdlib

Conversation

@Frotty

Copy link
Copy Markdown
Member

Moves the pinned standard library from 16729fa to 98b1140, twenty-one commits on.

This is the bump that was blocked until the interpreter agreed with the game on byte semantics. The library enables multibyte support by default over this range and works the engine's behaviour out at runtime rather than being told: String.wurst cuts a character in half to see how a partial slice is represented, and slices a 64 character literal byte by byte to enumerate every continuation byte. All of that rests on a string being a sequence of bytes.

Why there are tests attached to a version bump

Nothing in this repository runs the standard library's own test functions, so a bump has only ever been checked for still compiling. That is a weak signal for a change whose whole point is behaviour: the library's multibyte detection is designed to degrade quietly to an ascii-only path when it cannot find what it probes for, so a version where it silently gave up would look exactly like a version where it worked.

StdLibStringTests checks the part this bump turns on:

  • lengthOfAMultibyteStringIsInBytes"ä".length() is 2 and "aä".length() is 3, so the library counts what the game counts.
  • aPositionInsideACharacterIsNotABoundary — both ends of "ä" are boundaries and the position between its two bytes is not. This is the detection working end to end: it only answers this way if slicing actually produced the partial bytes the library expects, and it is the assertion that would fail on the silent fallback.
  • everyPositionInAnAsciiStringIsABoundary — ascii is unaffected.

Worth noting the library reaches the right answer by a different route than it does in game. The engine collapses every half-character slice to one marker string with a constant hash; byte-accurate, a lead byte hashes as itself and misses PARTIAL_CHAR_HASH, then falls through to the continuation byte table, is not found there, and is correctly reported as a boundary. Both paths agree on the answer, so isCharBoundary is right either way, but PARTIAL_CHAR_DETECTABLE is true at compiletime while matching a narrower set of slices than in game.

Full suite green on the new pin.

Moves the pin from 16729fa to 98b1140. The library turns multibyte support on
by default as of this range, and works the engine's behaviour out at runtime
rather than being told: it cuts a character in half to see how a partial slice
is represented, and slices a literal byte by byte to enumerate every
continuation byte. That rests on a string being a sequence of bytes, which the
interpreter now agrees with.
Nothing runs the library's own tests, so a bump was otherwise only checked for
still compiling. StdLibStringTests covers the part this one turns on: a
multibyte length in bytes, a position inside a character reported as not a
boundary, and ascii unaffected. The middle one is the detection working end to
end, since it only answers that way if slicing produced the partial bytes the
library expects to find.
@Frotty
Frotty merged commit 4950724 into masterAug 16, 2026
9 of 10 checks passed
Sign up for freeto 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

@Frotty