[miaobyte]

⚠ 行为变更

变的是

uint64(5) + 1、uint8(5) + 1 这类「无符号变量或 cast + 未定型整数字面量」，
从 init 失败变为正常计算。

不变的是

两侧都是确定类型且符号冲突的（如 uint64_var + int64_var）仍然报错，行为不变。

为什么值得单独一个 PR

u + 1 是最常见的写法之一，以前会在布局期就失败——这不是边缘情况，而是
无符号类型日常不可用的主因。

读者看到「⚠ 行为变更」时容易以为又是一次破坏性改动；这里恰恰相反：它修的是
「本来就不该失败的东西」。

规范依据

落地的条款是：

• 03-类型系统/01-种类与定宽类型 第 10 条（未定型整数字面量例外）；
• 05-runtime语义/11-指令派发与特化 的补充条款「未定型整数字面量不计入 int × uint
  混合符号判定」。

两条已在 #625 / #626 合入，本 PR 是执行侧实现，PR 与规范可互相追溯。

证据分工（重要：两类证据不是同一件事）

证据	说明什么	不说明什么
全量 261 例值级 diff=0	既有程序的行为没有改变	不说明新行为正确
7 例新用例（uint_literal_adapt.rs）	新行为本身正确	—

diff=0 不能被当成「已验证」。新行为正确性只由那 7 例支撑，其中两条正好覆盖边界：

• confirmed_mixed_signs_stay_untyped —— 两侧确定类型仍不特化（行为不变的那条）
• uint8_literal_boundary_fits_and_overflows —— 越界字面量按自然类型处理，随后落入混合符号报错

验证（git archive 干净副本，layout + runtimec2 + byteseek 三重建）

项	结果
7 例新测试	7/7 通过
layout 全量	91 通过 / 0 失败
error_cases	44/44 PASSED
tutorial	242/1，失败集合同（唯一 09-debugger/pauses.kv）
benchmark	采信 coding1 的 30 valid（未独立跑）

文件（3 个）

M  layout/src/code.rs
M  layout/src/lower.rs
A  layout/tests/uint_literal_adapt.rs

关联 #622，不关闭该 issue。

🤖 Generated with Claude Code