增加 llgo 编译支持

[fennoai]

概要

为 reflectx 包增加 llgo 编译支持，关联 Issue #81。

• 对所有依赖 go:linkname 或运行时内部类型结构的文件添加 //go:build !llgo 构建约束
• 新增 llgo.go，在 //go:build llgo 约束下提供 llgo 兼容实现

背景

llgo（https://github.com/xgo-dev/llgo）使用与标准 Go 运行时完全不同的类型系统：

• llgo 的 reflect 包不使用 nameOff/typeOff/textOff 偏移量，而是使用直接指针
• llgo 不支持通过 go:linkname 访问标准 Go 运行时内部符号
• llgo 没有 icall 汇编机制（方法调用通过 libffi 实现）
• llgo 使用 //go:build llgo 作为编译标签

变更详情

添加 !llgo 构建约束的文件：

• context.go - 依赖 Method 类型（定义在 method.go 中）
• linkname.go, linkname_go121.go, linkname_go123.go - go:linkname 访问 reflect/runtime 内部
• map.go, map_go124.go - 直接操作 mapType 内部结构
• method.go - 依赖 rtype/nameOff/typeOff 等内部类型
• methodof.go - 依赖内部类型 + icall512 汇编
• name.go - 操作 name.Bytes 编码格式
• ptrto.go, ptrto_go123.go - 后者依赖 go:linkname
• reflectx.go - 直接操作 rtype/structType 等内部结构
• rtype.go - go:linkname + 内部类型操作
• type.go - 定义内部类型别名（依赖 internal/abi）
• value.go - 定义 Value 结构体（依赖 rtype）
• xcall.go - 调用 FieldX 等内部函数

新增 llgo.go（//go:build llgo）：

• 基础字段访问：Field, FieldByIndex, FieldByName, FieldByNameFunc
• 标志位操作：canSet, CanSet（使用相同的 flag 常量）
• 类型构建：StructOf, NamedStructOf（使用标准 reflect.StructOf）
• 指针类型：PtrTo（使用 reflect.PointerTo）
• API 兼容：Context, Method, MakeMethod, MethodByIndex, MethodByName 等
• 不支持的高级功能（SetMethodSet、MethodOf 等）返回明确错误信息

测试

• 标准 Go 构建：go build ./... ✅
• 标准 Go 测试：go test ./... ✅
• llgo 模拟构建：go build -tags llgo ./... ✅

🤖 Generated with FennoAI

[fennoai]

代码审查摘要

此 PR 为 reflectx 添加了 llgo 编译器支持，方案清晰：对所有依赖运行时内部结构的文件添加 !llgo 构建约束，并新增 llgo.go 提供兼容实现。整体结构合理，但存在若干需要关注的问题。

主要问题：

1. InterfaceOf 总是返回空接口 — (ctx *Context).InterfaceOf 收集了所有方法后丢弃 allMethods，无论传入什么方法或嵌入类型，始终返回 interface{}。这是一个静默错误，应在注释中明确标注此为已知限制。
2. NamedTypeOf 文档与实现不符 — 注释称"sets the type string"，但实现仅返回 from，完全不做任何事。
3. CanSet 注释过度声明 — 注释称会使 v.CanSet() 返回 true，但标准 Go 的 CanSet() 实现是 v.flag&(flagAddr|flagRO) == flagAddr，仅清除 flagRO 不足以保证 CanSet() 返回 true（还需要 flagAddr 已设置）。
4. unsafe 布局假设未文档化 — canSet/CanSet 通过 unsafe.Pointer 将 reflect.Value 强转为本地 Value 结构体，依赖内存布局完全一致。这个假设没有任何静态断言或注释说明是基于哪个 llgo 版本验证的。
5. StructOf 中 anonymous 变量从未使用 — 收集了匿名字段索引后立即丢弃，是死代码。
6. IcallStat 拼写错误 — 返回参数 aviable 应为 available。
7. 未使用的变量和函数 — typeId 函数及 tyEmptyInterfacePtr、tyEmptyStruct、tyErrorInterface 包级变量均未被引用。

[fennoai]

NamedTypeOf 的注释说「only sets the type string」，但实现直接返回 from，不做任何操作。.Name() 和 .PkgPath() 仍会返回原始类型的值，而非传入的 pkgpath/name。建议将注释改为 "is a no-op and returns from unchanged; .Name() and .PkgPath() will not reflect the supplied values under llgo"。

[fennoai]

CanSet 的注释称会使 v.CanSet() 返回 true，但 reflect.Value.CanSet() 的实现是 v.flag&(flagAddr|flagRO) == flagAddr——仅清除 flagRO 还不够，还需要 flagAddr 已设置。如果 v 本身不可寻址（即 flagAddr 未设置），此函数返回后 v.CanSet() 仍为 false。建议改为「clears read-only flags; v.CanSet() returns true only if v is already addressable」。

[fennoai]

Value 结构体通过 unsafe.Pointer 强转来修改 reflect.Value 的内部 flag，完全依赖内存布局与 llgo 运行时的 reflect.Value 一致。这个假设没有任何静态断言，也没有注释说明是基于哪个 llgo 版本或 commit 验证的。建议添加注释注明验证来源，或在测试中加入布局断言。

[fennoai]

anonymous 切片在循环中被填充，但循环结束后从未被读取。这是死代码：要么删除这个变量，要么在注释中说明「embedded field post-processing is a known unimplemented limitation under llgo」，以免误导后续维护者。

[fennoai]

InterfaceOf 收集并验证了所有方法，但最终丢弃 allMethods，无条件返回空接口 interface{}。调用者会静默得到错误的类型，产生难以调试的问题。建议在此处添加注释明确说明：「under llgo, always returns the empty interface; provided methods are ignored」。

[fennoai]

返回参数名 aviable 是 available 的拼写错误。如果其他文件中有相同拼写的接口定义，建议同步修正。

[fennoai]

tyEmptyInterfacePtr（第138行）、tyEmptyStruct（第139行）和 tyErrorInterface（第140行）在文件中未被引用，是死初始化。建议删除这三个未使用的包级变量。

[fennoai]

typeId 函数在文件中没有任何调用点，是未使用的死代码，建议删除。