Lua hashtables and the interpreter answer as Jass does

[Frotty]

The Lua hashtable emulation answered differently from Jass in four cases, and so did the interpreter in three. Each case was measured on the 3.0.0 client, with one probe built as Jass and as Lua; each now answers as Jass on both.

	Jass	Lua before	interpreter before
a saved timer, loaded through LoadUnitHandle / LoadWidgetHandle / LoadGroupHandle	null	the timer	the timer (only unit, item and destructable loads were typed)
SaveTimerHandle(h, p, c, null) over a saved timer	stores nothing, the timer stays	removes the timer	stores nothing (already right)
a save after FlushParentHashtable(h)	does not stick: the hashtable is destroyed	sticks	sticks
load, save, remove or flush on a null hashtable	defaults, writes ignored	raises "attempt to index a nil value"	crashes the interpreter

What changes

Lua (LuaHashtable, LuaHashtableTranslation, the helpers in LuaNatives). The in-place forms and the helpers stay the same as each other.

• Typed loads. A handle save also writes the type of its native as a tag, into a sixth subtable __wurst_ht_htype under the same keys. A handle load answers the handle only for a tag it accepts: its own type, a widget's subtypes for LoadWidgetHandle, Widget for a widget subtype, and Agent. In place the check is one lookup in a constant main-chunk set (__wurst_htAccepts_Unit = {Unit=true, Widget=true, Agent=true}). Lua cannot tell a handle's type, so a handle saved through a supertype (SaveAgentHandle, SaveWidgetHandle) is answered to a narrower load.
• Null handle. A handle save does nothing for a null handle (if h and v ~= nil then), and a literal null prints nothing.
• FlushParentHashtable points every subtable at one shared table whose __newindex ignores writes. Later saves are lost and every load answers its default.
• Null hashtable. A load reads through (h and h.T[p] or __wurst_htEmpty), and a save, remove or flush runs under if h then.

Interpreter (HashtableProvider).

• It tags handles the same way, and typed loads use the same accepted tags; where the tag is a supertype, it still checks the mock class for units, items and destructables.
• FlushParentHashtable marks the table destroyed, and every native answers its default for a null hashtable.
• A provider method whose first parameter is a String is now passed the name of the native called (NativeJassFunction, ReflectionNativeProvider). That is how one Save / LoadHandle method knows its type.
• A hashtable destroyed by compile-time code is replayed destroyed (CompiletimeFunctionRunner).

docs/WC3_RUNTIME.md records the measurement.

Effect

	castle fight Lua	zombie defense Lua
luac instructions	473,036 → 474,676 (+0.3%)	384,391 → 385,956 (+0.4%)
script	8,544,773 → 8,563,237 bytes	6,677,685 → 6,692,206 bytes

Most of it is the null-hashtable test in each operation. Both scripts pass luac -p. The probe, built as Lua with this branch and run in game, answers every hashtable case as the Jass build does, apart from two kinds of line. Two lines are dividends Jass reads differently (0.1). Two are the Lua null-string convention, which is not touched here: a missing string is nil while the null literal is "".

Tests

• hashtableOperationsBehaveAsTheNatives (Jass, the interpreter and Lua) and its optimised variant: typed loads, a null handle which replaces nothing and is not saved, a flushed hashtable which keeps nothing, and every operation on a null hashtable. anOperandWithAnEffectKeepsTheCallOfTheHelper checks the same through the helpers. flushingTheWholeTableLeavesNothingToReplay checks the compile-time replay of a destroyed table. Each fails on master.
• hashtableOperationsArePrintedWhereTheyAreCalled, hashtableFlushesTestNoSubtable and three Lua translation tests pin the new shapes.
• Passed: LuaHashtableTests, LuaNativesTests, CompiletimeHashtableTests, CompiletimeTests, CompiletimeNativesTest, InterpreterTests, LuaBackendAuditTests, LuaTranslationTests, LuaKeyedMapTests, BugTests, DeterministicChecks, OptimizerTests. The full suite is left to CI.

[Frotty]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-11T11:22:34.333878Z	b2d78b5	Manual request

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 🎉

Reviewed commit: b2d78b543c

ℹ️ 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".