You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 4ae45cc
Browse filesBrowse the repository at this point in the historyBrowse files
fix(hermes-base): stop rejecting a base over a printed property name
hermesc's BytecodeList.def annotates the string operand of
DefineOwnByIdLong but not of DefineOwnById, so one instruction has two
pretty renderings. A plain compile keeps small string ids and prints the
bare id, which normalization resolved to the full name; a base compile
inherits the base's string table, spills past 16 bits, takes the Long
form and prints the text -- cut to hermesc's display budget, so
`promotionRequestItemId` arrives as `"promotionRequestI"...`. Every
property name longer than that budget therefore read as a difference and
threw away a perfectly good base. Production has one such rejection
(`Function<h> +72: DefineOwnById r3, r6, 1, "promotionRequestI"... vs
"promotionRequestItemId"`), and the remaining eleven are the SwitchImm
jump-table case already fixed in 12aba20 -- no rejection so far was real.
The two renderings cannot be converted into each other: the display
budget also truncates non-ASCII silently and without a marker (`ab中`
prints as `"ab"`). So the operand is folded to `<str>` and the property
name is compared by the raw audit, which decodes it from the binary
string table in full -- STRING_OPERANDS already supplies the annotation
hermesc is missing. An id that does not resolve still throws: that means
the string table was not read at all.
Tests use a real compiler: a base large enough to push the id past 16
bits reproduces the two renderings and must now compare equivalent, and
two property names past the budget must still differ (caught by the raw
pass). 40 fuzz rounds on seed 7: 40 equivalent, 4/4 planted differences
caught.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments