Let declared names decide dispatch slots, and finish the FastHashMap proof - #1232
Conversation
Exercises type class bounds through the container they were added for. Six of the seven cases pass on both backends with no compiler change: int keys, tuple keys on Jass, a user class key, two specialisations coexisting, and two instances of one specialisation. tupleKeyLua fails and is a real, pre-existing backend bug. Method names become Lua table keys, but luaMethod.initFor passes the name through raw while every sibling (luaVar, luaFunc, luaClassVar) sanitises via uniqueName. Names are valid identifiers in ordinary code, so nothing hit it until a class method was specialised for Lua with more than one type argument: specializeMethod builds name + "_specialized_" + generics.makeName(), and makeName joins arguments with ", ". Two simple arguments give "get_specialized_integer, integer", which emits "Class.get_specialized_integer, integer = impl" -- valid Lua that assigns to two targets and quietly writes a junk global. A tuple argument gives "⦅integer, integer⦆" and fails the syntax check outright.
Method names become Lua table keys, so they must be identifiers. A method specialised with two type arguments was named after them, commas included, and emitted `Class.get_specialized_integer, integer = impl` - valid Lua that quietly assigns to two targets; a tuple argument produced characters luac rejects outright. normalizeMethodNames is the pass that gives one name to a whole dispatch group, so it sanitises before uniquing: two names that differed only in characters Lua has no place for still get a slot each. The backend maps every slot key and every LuaMethod name through the same function, so call sites and class tables keep agreeing. Lua's identifier rule now has one home. The luac check never caught this, because the broken output parses. Assert instead on the names themselves: every emitted function, method, variable, field and call-by-name must be an identifier, checked for every testLua compile.
The execution path read the spawned process's stderr to EOF before touching stdout, and never bounded the wait. A program that fills the stdout pipe blocks writing while the harness blocks reading stderr, and the suite stops with no output, no timeout and no failing test - a stray worker JVM was still sitting on the build directory twenty minutes later. checkLuaSyntax, in the same file, already drained both pipes on their own threads and waited with a timeout. The execution path now uses the same helper, so a program that does not terminate fails its test instead of the run. Also records what building a repro turned up: a bounded generic class cannot be subclassed on either backend, and the div/mod result type asymmetry is reachable through integer literals rather than harmless.
A method claims the slots of every method it might be an override of, and sharesSemanticName accepted a match on either the declared name or the segment after the last underscore of the mangled one. For a specialised method that segment is a fragment of the type argument: get and slotFor of FastHashMap<int, int> both read as 'integer', and since specialisation gave them the same signature too, get claimed slotFor's slot and the class table bound FastHashMap_slotFor_specialized_integer__integer to FastHashMap_get_specialized. Declared names now settle it whenever both methods have one. The segment stays as the fallback for closures and bridges, which have no declaration to ask - that is the case it was there for. The emitted Lua is the only record of which implementation a slot should hold, so the test asserts it there: every slot named after a method must bind an implementation named after the same method.
remove leaves a tombstone rather than an empty slot, because a probe that stopped at one would miss keys put down beyond it. slotFor passes tombstones over when searching and returns the first one when putting, so removing and re-putting a key reuses its slot instead of lengthening the run. The probe is bounded by capacity, so a table full of tombstones cannot spin. The cost claim is asserted on the least optimised configuration, because it has to hold by construction rather than because the inliner removed it: storage is four plain Jass arrays, no hashtable native is reached for, slotFor takes nothing beyond the receiver and the key, and both requirements are direct calls rather than ExecuteFunc or a dispatch wrapper. With optimisation on, hash(key) becomes key and equals(a, key) becomes a != key. The dispatch_ functions in the output are the nullpointer check every class method gets, not type class dispatch, so the test looks at the real function underneath rather than asserting they are absent. Building the fixture also turned up a silent wrong result in the interpreter, recorded as item 16: a never-written array of a type parameter compares unequal to the type argument's default.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5c234916bc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| " let s = slotFor(key)", | ||
| " if not used[s]", |
There was a problem hiding this comment.
When a ninth distinct key is inserted into a map with all eight slots occupied and no tombstones, slotFor now returns -1, but put immediately evaluates used[-1] and then writes the key/value through that invalid slot. On Lua this creates an unreachable entry and increments count to 9; other targets may fail on the negative index. Reject or grow a full map before accessing the arrays.
Useful? React with 👍 / 👎.
Wurst and Lua reserve different words, so a method can be declared repeat or goto and reach the backend under that name. Method names survive it, because the pass that assigns them uniques against the reserved set. A closure does not: it adds the name it implements as a dispatch alias directly, so the alias arrives as a bare keyword and is emitted as a table key. luac rejects that, so it was loud rather than wrong, but the check added alongside it accepted the name - and catching this before the syntax check is the whole point of having it. isValid now rejects keywords and toIdentifier maps them out of the way. Underscores rather than a counter, so a keyword maps to the same name wherever it is derived: call sites and class tables have to agree without consulting each other.
Two tests for the runner itself, both Lua only: run through the Jass configurations the non-terminating one would hang the interpreter instead, which is the same problem somewhere this fix does not reach. - a program that loops forever fails its own test rather than the run - a program that prints twenty thousand lines still finishes The second is the deadlock this change was for: with the streams read one after the other, the program blocks writing stdout while the runner blocks reading stderr. The timeout is overridable so these take seconds rather than a minute. Output kept for the failure message is capped. Draining still never stops, since stopping is what blocks the process, but a program that loops while printing would otherwise exhaust the worker before the timeout fires. Capping meant success could no longer be read back out of the retained text - testSuccess prints last, well past the limit - so the line is recognised while draining. Which is better regardless: whether a program succeeded no longer depends on how much of its output was kept.
slotFor says a key has nowhere to go by returning a slot below the instance's section, and get, has and remove all check for it. put did not, so a ninth distinct key wrote through the sentinel: an entry nothing can reach, a count of nine, and a negative array index on targets less forgiving than Lua. The test fills the map exactly - keys one to eight hash to the eight slots - and puts a ninth. It does not read the absent key back, because reading one of a type parameter returns a stand-in the interpreter cannot compare; that is a separate bug, fixed later in this stack.
|
Fixed — a real defect, and mine:
One thing the test deliberately does not assert: reading the absent key back. Also merged the updated #1231 into this branch so the diff reads against its current base. @codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f16d43c8d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| public void fastHashMapRuntimeLua() throws IOException { | ||
| test().testLua(true).executeProg().lines(program(fastHashMap(), INT_INSTANCE, USE_WITH_COLLISION)); | ||
| assertEachSlotBindsItsOwnMethod(compiledLua("fastHashMapRuntimeLua")); |
There was a problem hiding this comment.
This slot-aliasing change is covered only by a single FastHashMap specialization whose assignments are checked by method-name substrings; it never exercises a root-slot call through State<T>, four or more sibling overrides, early constant instantiation, or compiling twice. Consequently, a regression that binds the invoked root slot to a base implementation—or makes sibling selection nondeterministic—can still pass this test. Add the repository-mandated FSM-style generated-Lua assertions and byte-identical compile-twice check.
AGENTS.md reference: AGENTS.md:L283-L294
Useful? React with 👍 / 👎.
Neither of these belongs in a branch that gets merged. The loop configuration is machine-local state - an active session id, an iteration count, a path and a branch name from one checkout - and another checkout picking it up would inherit an automation session that has nothing to do with it. The brief beside it is one run's instructions, not documentation of anything. Both came in with the branch this work was based on rather than with the work. Ignored as well, so they do not come back the next time either is written.
…inding # Conflicts: # BACKLOG.md # de.peeeq.wurstscript/src/test/java/tests/wurstscript/tests/FastHashMapTests.java # de.peeeq.wurstscript/src/test/java/tests/wurstscript/tests/LuaRunnerTests.java # de.peeeq.wurstscript/src/test/java/tests/wurstscript/tests/WurstScriptTest.java
|
Updated from master (#1230 and #1231 are in). On the P1 — I checked before writing anything, and the mandated regression already exists.
The repro units have Those tests exercise this change directly: So the coverage you are asking for is present and green; adding a second copy alongside @codex review |
|
Codex Review: Didn't find any major issues. Hooray! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
1 participant
Stacked on #1231.
Dispatch slots
A method claims the slots of every method it might be an override of, and
sharesSemanticNameaccepted a match on either the declared name or the segment after the last underscore of the mangled one. For a specialised method that segment is a fragment of the type argument:getandslotForofFastHashMap<int, int>both read asinteger, and since specialisation gave them the same signature too,getclaimedslotFor's slot. The class table boundFastHashMap_slotFor_specialized_integer__integertoFastHashMap_get_specialized.Declared names now settle it whenever both methods have one. The segment stays as the fallback for closures and bridges, which have no declaration to ask — that is the case it was there for.
The emitted Lua is the only record of which implementation a slot should hold, so the test asserts it there: every slot named after a method must bind an implementation named after that same method. It fails on the old code with exactly the binding above.
FastHashMap
removeleaves a tombstone rather than an empty slot, because a probe that stopped at one would miss keys put down beyond it.slotForpasses tombstones over when searching and returns the first one when putting, so removing and re-putting a key reuses its slot. The probe is bounded by capacity, so a table full of tombstones cannot spin.The cost claim is asserted on the least optimised configuration, because it has to hold by construction rather than because the inliner removed it: storage is four plain Jass arrays, no hashtable native is reached for,
slotFortakes nothing beyond the receiver and the key, and both requirements are direct calls rather thanExecuteFuncor a dispatch wrapper. With optimisation on,hash(key)becomeskeyandequals(a, key)becomesa != key.Note the
dispatch_functions in the output are the nullpointer check every class method gets, not type class dispatch, so the test looks at the real function underneath rather than asserting they are absent.Full test suite green.