xuyueandClaude Opus 5
8b4d8899f9
上游 QingdaoU/JudgeServer 停更在 2024-04（registry 上的 latest 和 1.6.1 是同一份 镜像，编译器停在 gcc-13），没有新版可拉，所以自己重编。docker/judge/ 是只改工具链 的 Dockerfile 分叉，server/ 和 Judger/ 从上游固定 commit b28aa56 拉，一行没动。 镜像 oj2-judge-2（不在任何 registry 上：本机 build.sh --save → scp → docker load） - gcc/g++ 13 → 14.2，Python 3.12 → 3.13.5，都是 trixie 默认 - Go / JDK / Node 整套删掉：前端的题目语言复选框从来只给 C / C++ / Python / SQL， 12 万条提交里 Java 44 条、Golang 15、JavaScript 3，全是很早以前的 - 体积 1.1GB → 433MB；默认走清华源，构建 12 分钟 → 40 秒（--no-mirror 换回官方） - deploy.sh 加一道自检：镜像不在本机就中止，并打印该跑的三条命令 C 的编译参数加三个 -Wno-error（implicit-function-declaration / int-conversion / incompatible-pointer-types）：gcc-14 把它们从 warning 提成了 error，而 -w 压不住。 语言值统一成 Python（迁移 0019 / 0020） - 0019：Python3（104527 条提交）与 Python2（3 条）并成 Python，一并改掉 937 道题的 languages、75 个 template 键、15 个 ast_rules 键、257 条 answers、1235 个用户的 成就指标 _languages（languages_used 重算，总和 1928 → 1925，少的 3 个是同时用过 两种 Python 的人） - 0020：把 Java / JavaScript / Golang 从 84 道题的可选语言里摘掉 —— 不摘的话那些题 的语言下拉还能选 Java，提交必 SYSTEM_ERROR - 契约新增 normalizeLanguage() 别名表，判题侧一律走 judgeConfigFor()：旧客户端 localStorage 里的 Python3、迁移前排进队列的任务都还能判；协作的语言归一也走它， 否则上线那一刻学生页面里的 Python3 会静默落到 C - 回滚要连数据一起回，只滚代码会让所有 Python 提交变 SYSTEM_ERROR 实跑 - 判题冒烟 docker/judge/smoke.ts 13 条全过：三种语言、六种状态码、gcc 宽松度 - 拿备份里的真实代码逐文件比对新旧镜像的编译结果，0 差异：C 提交 1951 份 （1725 过 / 226 CE）、C++ 882 份、Python 2000 份、20 篇 C 教程的 93 个代码块。 不加那三个 -Wno-error 的话，C 有 26 份会从能过变成 CE - 迁移在灌了 12.4 万行真实数据的一次性库里跑过：0 残留、没有题目被清空； dev 库用真正的执行器跑通 - check:ast 56 个 target 全过，前后端 typecheck 均 0 顺带记下一个升级之前就有的坑（现在随 Go 一起消失，写在 README 里）：GOCACHE 指向 容器的 tmpfs，判题机重启后第一次 Go 提交是冷构建，Go 1.22 要 5.6 秒 CPU、超过 3 秒 的编译预算，于是重启后第一个交 Go 的学生必吃一次 CE，后面的人缓存热了又都正常。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.9 KiB
AST 代码规则
规矩在 CLAUDE.md「AST 代码规则」一节。这里是加语言、加 target 时要一起看的细节。
为什么会有 check:ast
契约的 AST_NODE_TARGETS_BY_LANGUAGE 是唯一一张表，一个 target 一条
{ label, node }：label 给后台下拉和题目页，node 给判题机比 tree-sitter 节点类型。
运算符表 AST_OPERATOR_TARGETS_BY_LANGUAGE 一份两用（它的值既是文案又是要比的 token）。
判题机侧没有第二张表，解析统一走契约的 astTargetNodeType()，所以加 target 而漏配节点
类型在结构上不可能。
但配错仍然可能，而且完全静默：节点类型对不上就是一个都收不到，于是「必须使用 X」永远 失败、「不能使用 X」永远通过，两头不报错，只有学生受着。
bun run --filter '@oj2/api' check:ast # 每个 target 的 node 在语法里是否真实存在
升级 tree-sitter-* 依赖之后一定要跑一次 —— 语法改节点名是常事，后果全静默。
加这个检查那天，56 个 target 里就抓出一个：f_string 一直配的是 format_string，
而这个版本的 tree-sitter-python 根本没有这种节点（f-string 是 string 里带
interpolation），所以「不能使用 f-string」从上线起就没生效过。
它只验节点类型存在，不验语义对不对（把 while_loop 配成 for_statement 这种两个都
存在，机器看不出来），语义那层还是得实跑。
只有三种语言真的会跑
判题机只认 AST_SUPPORTED_LANGUAGES（C / C++ / Python）。别的语言配了规则一条都不会跑，
所以后台不给它们开 tab，题目页也不把它们的规则展示成「要求」——
看得见却不检查比没有更糟。
C++ 不是「C 加几条」那么简单
C++ 的语法表是「C 的全集 + C++ 独有的几条」，因为 tree-sitter-cpp 继承 tree-sitter-c， C 那 14 个 target 在 C++ 树里逐个实测通用。但调用形态两者不同，加语言时必须一起看：
a.push_back()和p->push_back()在 C++ 都是call_expression+field_expression， 不是 Python 的attribute；std::sort(...)的 function 是qualified_identifier而不是identifier，所以functionCalls对 C++ 额外比一次::末段 —— 否则学生写了using namespace std与否 会得到不同的判定结果。
规则的语义校验为什么不在 zod 上
在 astRulesError()，不在 astRulesSchema 的 refine 上：那个 schema 同时用于读后台
题目详情，在读路径上抛错会让历史脏数据把整个题目详情打不开（同 docs/contract.md 那套教训）。
同理，保存前先 pickAstRules() 剔除够不着的分组再校验，否则早年配过 C++ 规则的题会把老师
锁死 —— tab 里看不到那组规则，保存却被拦下。