添加可选链操作符支持 (?. ?: ?[ ?()：支持多返回值，新增 OP_SETTOP 指令，由 BEE_OPTCHAIN 宏启用 by sumneko · Pull Request #67 · actboy168/bee.lua

sumneko · 2026-08-13T22:19:23Z

概述

为 Lua 添加可选链操作符（optional chaining）支持，语法与语义对齐 ES2020 的 ?.，包含四种形式：

x?.y — 字段访问
x?:f() — 方法调用
f?() — 函数调用
t?[1] — 索引访问

支持任意链式组合，如 a?.b.c、a?.b?.c、obj?:get()?.x。

设计思路

解析器补丁 + 一个新增指令，默认构建零影响

实现直接修改 3rd/lua{54,55} 的官方源码，所有改动都由 #if defined(BEE_OPTCHAIN) 宏门控：

解析器（lparser.c）：?. 在编译期展开为标准的 LOADNIL / EQ / JMP + 字段访问/调用指令组合；
新增指令 OP_SETTOP：链末调用（f?()、obj?:m()）的短路路径使用 CALL(k) / JMP / OP_SETTOP 固定布局，OP_SETTOP 将结果寄存器填为 nil 并精确设置栈顶（L->top），使开放指令（OP_RETURN / OP_CALL / OP_SETLIST）读到恰好数量的 nil；
OP_SETTOP 追加在 OP_EXTRAARG 之后（同样由 BEE_OPTCHAIN 门控），普通代码的指令编号完全不变，补丁版与标准版对普通代码的字节码双向兼容；
默认构建不定义 BEE_OPTCHAIN：所有补丁块被预处理剔除，与官方源码字节级一致、行为零影响；启用时仅需 luamake -optchain。

为什么需要新增指令（及备选方案）

Lua 的 LOADNIL 只把寄存器填为 nil，不会调整栈顶 L->top，因此链末调用在多值上下文（return f?()、g(f?())、{f?()}）短路时，开放指令会读到栈上残留的旧值，产生"nil 数量偏多"。此前考虑过不加指令的绕过方案：短路路径改为调用一个预先准备的、返回 1 个 nil 的函数——OP_CALL 会按实际结果数设置 L->top，且在固定结果数时自动补足 nil（如 a, b, c = nilfn() 得 3 个 nil），可精确覆盖所有短路场景，语义上可行。但该方案：

依赖运行时辅助函数：需要一个全局/内部注册的"nil 函数"，既污染命名空间，又可能被用户重定义而破坏短路语义；
真实调用开销：每次短路都走一次完整函数调用（栈帧/参数调整），远慢于一条简单指令，短路路径也需"加载函数 + 调用"两条指令；
语义隐晦：依赖"辅助函数返回 1 个 nil"与"CALL 自动补 nil"的间接行为。

因此最终新增 OP_SETTOP：一条指令同时完成"寄存器填 nil"与"精确设置栈顶"，语义直接、零运行时依赖与调用开销，且位于 OP_EXTRAARG 之后不影响普通代码的指令编号。

语义（对齐 ES2020）

仅 nil 短路：false?.a 仍会报错（与 JS 的 undefined / null 语义对齐）；
短路即整链：一旦中间某节为 nil，整条链立即得到 nil，后续 key / 实参不再求值（无副作用）；
receiver 只求值一次：recv()?.a?.b 中 recv() 只调用一次；
结果不可赋值：obj?.a = 1 为语法错误；
支持多返回值：链末调用保留 open call，可产生多个值；短路路径精确产生对应数量的 nil：
- return f?() 短路 → 恰好 1 个 nil
- g(f?()) 短路 → 恰好 1 个参数
- {f?()} 短路 → 恰好 1 个 nil 元素
- a, b, c = f?() 短路 → 3 个 nil
- 非短路时正常返回被调用函数的全部值

构建与测试

通过 luamake -optchain 启用；
新增 test/test_optional_chain.lua，覆盖字段 / 索引 / 方法 / 调用（含带参）/ 链式组合 / 短路副作用 / 单次求值 / 不可赋值 / 非法语法 / 多返回值（含短路精确性）等用例；
测试文件在默认构建下自动跳过（编译期探测），不影响现有测试。

改动范围

文件	说明
`3rd/lua{54,55}/lparser.c`	可选链解析与代码生成（`BEE_OPTCHAIN` 门控）
`3rd/lua{54,55}/lopcodes.{h,c}`	新增 `OP_SETTOP` 指令（枚举 / 模式表，门控）
`3rd/lua{54,55}/lopnames.h`	指令反汇编名称（门控）
`3rd/lua{54,55}/lvm.c`	`vmcase(OP_SETTOP)`（填 nil + 设置栈顶，门控）
`compile/common.lua`、`compile/lua.lua`	`-optchain` 时定义 `BEE_OPTCHAIN` 宏
`test/test_optional_chain.lua`、`test/test.lua`	测试用例与自动跳过逻辑
`.luarc.json`	诊断配置忽略测试文件中的自定义语法

Copilot

Pull request overview

This PR adds an optional-chaining syntax extension to the vendored Lua 5.4/5.5 parser copies, gated behind a BEE_OPTCHAIN build macro and wired into the build/test flow so it only runs when the feature is enabled.

Changes:

Add ?. / ?: / ?[ / ?() optional-chaining support in patched lparser.c copies for Lua 5.4 and 5.5 (macro-gated).
Update build scripts to switch to the patched onelua.c and define BEE_OPTCHAIN when -optchain is enabled.
Add optional-chaining test coverage and a loader that auto-skips these tests on builds without the syntax.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
`test/test.lua`	Conditionally loads the optional-chaining test module only when the syntax is accepted by the interpreter.
`test/test_optional_chain.lua`	New test suite covering field/index/method/call chaining semantics and short-circuit behavior.
`compile/lua.lua`	Enables selecting patched `onelua.c` and defining `BEE_OPTCHAIN` for relevant targets when `lm.optchain` is on.
`compile/common.lua`	Switches the Lua source set to the patched `onelua.c` and defines `BEE_OPTCHAIN` when enabled.
`3rd/lua-patch/optchain/lua55/onelua.c`	Patched Lua 5.5 single-file build entry to include patched parser sources.
`3rd/lua-patch/optchain/lua55/lparser.c`	Patched Lua 5.5 parser copy with optional-chaining parsing/codegen (macro-gated).
`3rd/lua-patch/optchain/lua54/onelua.c`	Patched Lua 5.4 single-file build entry to include patched parser sources.
`3rd/lua-patch/optchain/lua54/lparser.c`	Patched Lua 5.4 parser copy with optional-chaining parsing/codegen (macro-gated).
`.luarc.json`	Adjusts LuaLS workspace settings to reduce diagnostics noise from the custom syntax in tests.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

+      case '?': {  /* optional chain: '?.' '?:' '?[' '?(' */
+        int reg, nilreg;
+        luaX_next(ls);  /* consume '?' */
+        if (ls->t.token != '.' && ls->t.token != ':' &&
+            ls->t.token != '[' && ls->t.token != '(')
+          luaX_syntaxerror(ls, "unexpected symbol near '?'");
+        reg = luaK_exp2anyreg(fs, v);  /* evaluate receiver only once */
+        nilreg = fs->freereg;
+        luaK_nil(fs, nilreg, 1);  /* ensure it is nil at runtime */
+        fs->freereg++;
+        luaK_codeABCk(fs, OP_EQ, reg, nilreg, 0, 1);  /* jump when nil */
+        luaK_concat(fs, &niljumps, luaK_jump(fs));
+        break;  /* next iteration handles '.' ':' '[' '(' */
+      }


+      case '?': {  /* optional chain: '?.' '?:' '?[' '?(' */
+        int reg, nilreg;
+        luaX_next(ls);  /* consume '?' */
+        if (ls->t.token != '.' && ls->t.token != ':' &&
+            ls->t.token != '[' && ls->t.token != '(')
+          luaX_syntaxerror(ls, "unexpected symbol near '?'");
+        reg = luaK_exp2anyreg(fs, v);  /* evaluate receiver only once */
+        nilreg = fs->freereg;
+        luaK_nil(fs, nilreg, 1);  /* ensure it is nil at runtime */
+        fs->freereg++;
+        luaK_codeABCk(fs, OP_EQ, reg, nilreg, 0, 1);  /* jump when nil */
+        luaK_concat(fs, &niljumps, luaK_jump(fs));
+        break;  /* next iteration handles '.' ':' '[' '(' */
+      }


actboy168 · 2026-08-15T01:22:54Z

这种补丁方式在版本升级时非常难维护

sumneko · 2026-08-17T09:48:28Z

改成在源码里插桩了，但感觉改的有点多。要不这个功能就留在分支里吧，之后master更新后让AI合到分支里

actboy168 · 2026-08-18T11:18:43Z

把它变成git diff提交到仓库，构建的时候apply？

sumneko · 2026-09-02T03:13:31Z

看看？

actboy168 · 2026-09-02T06:56:31Z

这个patch的构建脚本不太好，应该用luamake的依赖规则来实现，否则无法支持增量编译。另外patch构建脚本可以让它更通用一点吗，目前硬编码太多

actboy168 · 2026-09-02T13:04:16Z

+--     避免下游以为产物变化而重新编译。
+local src, dst, patch = ...
+
+local fs_ok, fs = pcall(require, "bee.filesystem")


为什么会有pcall

actboy168 · 2026-09-02T13:04:26Z

-else
-    os.execute(('rm -rf "%s"'):format(dst))
-    os.execute(('mkdir -p "%s"'):format(dst))
+local function ensure_dir(dir)


用filesystem

actboy168 · 2026-09-02T13:04:45Z

+local ok = os.execute(('git apply --directory="%s" "%s"'):format(dst, patch))
+assert(ok, "git apply failed: " .. patch)
+
+-- 补丁后内容没变的文件恢复修改时间


多此一举

actboy168 · 2026-09-02T13:09:30Z

            lm.luadir / "linit.c",
        },
-        defines = {
+        defines = lm.optchain and {


Suggested change

defines = lm.optchain and {

defines = {

"MAKE_LIB",

"LUA_BUILD_AS_DLL",

lm.optchain and "BEE_OPTCHAIN",

},

其他类似的代码，不再赘诉

- 补丁位于 3rd/lua-patch/optchain/{lua54,lua55}/，不改动 vendored 源码 - 构建时 luamake -optchain 开启并定义 BEE_OPTCHAIN，默认关闭行为不变 - 新增 test/test_optional_chain.lua（test.lua 探测到可用时才加载） - 语义对齐 ES2020：整链短路、false 不短路、不可作赋值目标

可选链调用（f?()）短路路径改为固定布局：CALL(k 标志标记可选链) / JMP / OP_SETTOP。 OP_SETTOP 填 R[A..A+B] 为 nil 并精确设置 L->top，使开放指令（OP_RETURN/OP_CALL/OP_SETLIST）读到恰好数量的 nil： - return f?() 短路 -> 恰好 1 个 nil - g(f?()) 短路 -> 恰好 1 个参数 - {f?()} 短路 -> 恰好 1 个 nil 元素 - a,b,c = f?() 短路 -> 3 个 nil 不再把短路指令位置 hack 进 expdesc->t（修复了 dischargevars/goiftrue 将 e->t 当作跳转列表 patch 导致的编译期崩溃）；e->t/f 保持官方语义，单值消费（print(f?())、if f?() then、f?()+1）天然安全。 OP_SETTOP 追加在 OP_EXTRAARG 之后，普通代码指令编号不变；默认构建（无 BEE_OPTCHAIN）零影响。

将 case '?' 中裸的 fs->freereg++ 改为 luaK_reserveregs(fs, 1)（同时正确更新 maxstacksize，避免绕过 luaK_checkstack），使用后立即释放。曾尝试按 review 建议将 nil 寄存器一次性 reserve 到链末复用，但这会破坏 Lua 编译器的线性 freereg 不变量：链中间的 freeexp/exp2nextreg 假设待释放表达式是最后分配的寄存器，reserve 保持会使链末 CALL 基址偏移、结果寄存器与局部变量错位（CALL 0 变 CALL 1 + 多余 MOVE，返回错误值）。

验证 f?(1,2,3) 等带参数场景：非短路正常传参调用、短路时参数不求值（无副作用）、多值短路精确、表构造/参数位置正确。

将可选链补丁从 3rd/lua-patch/optchain/ 的整文件复制改为直接写入 3rd/lua{54,55} 官方源码，全部由 #if defined(BEE_OPTCHAIN) 门控： - lparser.c / lvm.c / lopcodes.{h,c} / lopnames.h：每文件仅增几行门控补丁（lparser.c ~110 行、lvm.c 15 行、指令表各 3-7 行） - OP_SETTOP 枚举/模式表/反汇编名均以 BEE_OPTCHAIN 门控，默认构建预处理后与官方源码字节级一致，零影响 - compile 不再切换 onelua.c 来源，仅保留 -optchain 时定义宏分支相对 master 的 diff 从 ~10100 行降至 ~500 行。默认 + optchain（lua54/lua55）全部测试通过。

按 actboy168 建议，将可选链补丁从" 官方源码插桩\改为\git diff 补丁 +

source_set 的 deps 只作用于 target 组合，不保证 obj 编译顺序；改用 objdeps（ninja implicit inputs / order-only），让所有依赖 patched 源码的 obj 在编译前先运行 apply_optchain_patch，消除并行构建时 lua.hpp 缺失的竞态。 runlua 的 args/inputs/outputs 改用 lm:path 对象，自动加当前项目前缀，保证 bee.lua 作为 submodule 被引用时路径正确。

actboy168 · 2026-09-03T10:09:45Z

在已经使用git patch的情况下#if BEE_OPTCHAIN还有必要吗，如果是为了外部代码的可观测性，可以添加#define BEE_OPTCHAIN 1

actboy168 · 2026-09-03T10:39:33Z

@sumneko 看下这个 test

actboy168 · 2026-09-03T11:25:36Z

+ static void lastlistfield (FuncState *fs, ConsControl *cc) {
+   if (cc->tostore == 0) return;
+   if (hasmultret(cc->v.k)) {
+    luaK_setreturns_optchain(fs, &cc->v, LUA_MULTRET);


如果nresults等于LUA_MULTRET，这个函数就变成空函数，可以直接删了。

actboy168 · 2026-09-03T12:02:45Z

findsetreg需要支持新的字节码

actboy168 · 2026-09-04T05:02:46Z

ljumptab.h也需要patch。另外看看CI的错误

actboy168 · 2026-09-04T09:56:40Z

只改了lua55，没改lua54?

sumneko · 2026-09-04T10:23:10Z

只改了lua55，没改lua54?

5.4 的 luaK_finish 无 luaP_isOT/isIT 断言、lvm.c 无 top 失效断言（均为 5.5 特有），故无需改 lcode.c

actboy168 · 2026-09-04T11:22:51Z

这不是吗

bee.lua/3rd/lua54/lcode.c

Line 1852 in 676d850

lua_assert(i == 0 || isOT(*(pc - 1)) == isIT(*pc));

actboy168 · 2026-09-04T13:47:50Z

@sumneko 看下CI的错误

Copilot AI lite review requested due to automatic review settings August 13, 2026 22:19

Copilot started reviewing on behalf of sumneko August 13, 2026 22:19 View session

Copilot AI reviewed Aug 13, 2026

View reviewed changes

sumneko marked this pull request as draft August 13, 2026 22:32

sumneko changed the title ~~添加可选链操作符支持 (?. ?: ?[ ?()，由 BEE_OPTCHAIN 宏启用~~ 添加可选链操作符支持 (?. ?: ?[ ?()：支持多返回值，新增 OP_SETTOP 指令，由 BEE_OPTCHAIN 宏启用 Aug 14, 2026

sumneko marked this pull request as ready for review August 14, 2026 00:20

actboy168 requested changes Sep 2, 2026

View reviewed changes

sumneko added 13 commits September 3, 2026 17:51

fix: 修正 optchain 补丁源路径（目录为 lua55/lua54，而非 55/54）

6d439db

诊断完全忽略新的测试文件

03cca5d

跳过诊断使用完整路径

081f0dd

test(optchain): 补充带参数的可选调用测试用例

d4d7b5b

验证 f?(1,2,3) 等带参数场景：非短路正常传参调用、短路时参数不求值（无副作用）、多值短路精确、表构造/参数位置正确。

refactor(optchain): 改为 git diff 补丁 + 构建时 apply

7041f7e

按 actboy168 建议，将可选链补丁从" 官方源码插桩\改为\git diff 补丁 +

refactor(optchain): 用 luamake 依赖规则重写补丁构建，消除硬编码

0a49f07

refactor(optchain): 按 review 意见简化补丁脚本与构建配置

5e85bdf

refactor(optchain): 自查清理：精确依赖、去死代码

61c5007

actboy168 force-pushed the feature/optional-chaining branch from 4969fcb to 61c5007 Compare September 3, 2026 09:53

sumneko and others added 2 commits September 3, 2026 18:29

refactor(optchain): 删除补丁内冗余的 BEE_OPTCHAIN 门控

70c2484

增加一个test

03f5850

fix(optchain): OP_SETTOP 的 B 字段在 nresults==0 时越界写入 255

96d55a6

actboy168 requested changes Sep 3, 2026

View reviewed changes

refactor(optchain): 删除 LUA_MULTRET 的空操作调用点

de81fa0

sumneko and others added 5 commits September 3, 2026 20:11

fix(optchain): findsetreg 支持 OP_SETTOP

983c92b

style(optchain): 自查清理注释与格式

4d5365c

git补丁通用化

f9affa6

为补丁添加文档

d9e44a3

增加CI测试

6b01b44

sumneko added 2 commits September 4, 2026 15:00

fix(optchain): ljumptab 补丁与 debug 构建的 top 断言冲突

2f2cca0

docs(optchain): README 同步补丁文件清单与配套说明

13f764a

sumneko and others added 2 commits September 4, 2026 19:40

fix(optchain): lua54 补丁补充缺失的 debug 断言豁免

cf7df87

增加几个测试

45d54e3

sumneko and others added 4 commits September 4, 2026 23:25

fix(optchain): luaG_traceexec hook 下重置 top 破坏 open call 结果数

b5b06a3

增加lua54的测试

39483d4

使用subprocess代替os.execute

7f75478

简化代码

af4b723

-        defines = lm.optchain and {
+        defines = {
+            "MAKE_LIB",
+            "LUA_BUILD_AS_DLL",
+            lm.optchain and "BEE_OPTCHAIN",
+        },

Conversation

sumneko commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

概述

设计思路

解析器补丁 + 一个新增指令，默认构建零影响

为什么需要新增指令（及备选方案）

语义（对齐 ES2020）

构建与测试

改动范围

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

actboy168 commented Aug 15, 2026

Uh oh!

sumneko commented Aug 17, 2026

Uh oh!

actboy168 commented Aug 18, 2026

Uh oh!

sumneko commented Sep 2, 2026

Uh oh!

actboy168 commented Sep 2, 2026

Uh oh!

actboy168 Sep 2, 2026

Choose a reason for hiding this comment

Uh oh!

actboy168 Sep 2, 2026

Choose a reason for hiding this comment

Uh oh!

actboy168 Sep 2, 2026

Choose a reason for hiding this comment

Uh oh!

actboy168 Sep 2, 2026

Choose a reason for hiding this comment

Uh oh!

actboy168 commented Sep 3, 2026

Uh oh!

actboy168 commented Sep 3, 2026

Uh oh!

actboy168 Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

actboy168 commented Sep 3, 2026

Uh oh!

actboy168 commented Sep 4, 2026

Uh oh!

actboy168 commented Sep 4, 2026

Uh oh!

sumneko commented Sep 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

actboy168 commented Sep 4, 2026

Uh oh!

actboy168 commented Sep 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sumneko commented Aug 13, 2026 •

edited

Loading

sumneko commented Sep 4, 2026 •

edited

Loading