Conversation
Pattern.compile/1 returns an {anchored, elements} tuple, but only find/3
used the flag - gsub/4, gsub_stateful/5, and gmatch/2 discarded it.
Because compile strips the leading ^, those entry points matched the
remaining pattern at every position, so string.gsub("xax", "^x", "Y")
returned "YaY", 2 instead of "Yax", 1, silently corrupting the common
leading-trim idiom s:gsub("^%s+", "").
Route gsub and gsub_stateful through an anchored branch that tries the
match only at position 0 and replaces at most once, mirroring PUC-Lua
str_gsub's anchor flag. An n of 0 still suppresses the replacement, and
an empty anchored match (e.g. ^a* on "bbb") replaces once at the start.
gmatch needed the opposite treatment: per Lua 5.3 (and PUC-Lua's
gmatch_aux, which never strips the caret), a leading ^ in gmatch is not
an anchor but an ordinary literal character - so recompile the pattern
keeping the caret literal instead of dropping it.
Expected values in the regression tests are verified against PUC-Lua
5.3.6.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F3LBtzmXgAMHA8QiGPa5Ek
The standard Lua OOP idiom (T.__index = T) creates tables that contain
themselves. Both eval-boundary walks recursed into them forever,
growing memory without bound: Value.decode in decode: true mode and
Display.peek_table in decode: false mode.
The walk now terminates at the point of recurrence: decode leaves the
table's {:tref, id} reference there, mirroring how functions already
pass through as opaque references, and Display renders a :circular
peek. Shared non-cyclic references decode in full.
OTP 28's opacity checker false-positives on the MapSet the walkers capture in their entry closures (call_without_opaque on every MapSet call), failing CI. Specs on the private clauses don't appease it. A plain map with the ids as keys is the same structure MapSet wraps, so behavior is identical and there is no opaque type left to police.
fix(pattern): honour ^ anchor in gsub and literal caret in gmatch
Fix unbounded recursion on cyclic tables at the eval boundary
A valueless `return` followed by a comment before the block terminator (`elseif`/`else`/`end`/`until`) failed to parse with "Expected expression". `parse_return/1` peeked at the raw next token to detect an empty return; a comment token is not a terminator, so it fell through to `parse_expr_list` and choked on the comment. Comments are whitespace in Lua, so peek past them (`skip_comments/1`) when deciding whether the return is bare. The comment tokens are left in the stream so the block parser still collects them as orphaned/trailing comments. Real Lua 5.3 and Luerl both accept this; the idiom shows up in `if ... then return -- note \n elseif ...` style branches. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fix(parser): allow comments between a bare return and its terminator
# Conflicts: # lib/lua/vm/display/table.ex # lib/lua/vm/stdlib/pattern.ex # test/lua/vm/cyclic_table_test.exs # test/lua/vm/stdlib/pattern_anchor_test.exs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hey,
We noticed that some expected lua behaviour regarding dates is not working as expected.
Changes:
os.time normalises out-of-range date-table fields the way C mktime does
(e.g. day = 0 is the last day of the previous month, month = 13 is
January of the next year) instead of raising a MatchError