Slang IR 文档修复实战Generics 与 Existentials 指令族的生产者溯源与 no-producer 清单【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang本篇文章围绕 Slang 编译器仓库中一份真实存在的修复报告展开——即docs/generated/design/_meta/remediations/ir-reference/generics-and-existentials.md.remediation.md它记录了对自动生成的 IR 参考文档docs/generated/design/ir-reference/generics-and-existentials.md的一次系统性修订逐条核实 39 行指令记录的 AST origin生产者来源、确认 7 个无人生产的 opcode、并裁剪越界的 pass 行为描述。读完本文你将掌握 Slang IR 中泛型generics、存在类型existentials、witness 查找与 type-flow 特化指令族的整体图谱理解生产者溯源这种文档校验方法以及如何在源码层面核实一个 opcode 究竟由谁、在哪个 pass 中产生。背景从审查到修复的文档流水线Slang 项目维护着一套自动生成的 IR 参考文档位于docs/generated/design/ir-reference/下每个指令族一个页面。由于文档由模型生成、且源码持续演进项目建立了一条审查 → 修复 → 刷新的流水线审查review审查模型对照源码、提示词契约与受监控文件清单manifest产出审查报告如docs/generated/design/_meta/reviews/ir-reference/generics-and-existentials.md.review.md。该报告对generics-and-existentials页面给出了 6 条 findings2 条 major、2 条 minor、2 条 nit核心问题是 40 行指令记录仍保留着已废弃的(synthesized)或裸—作为 AST origin。修复remediation修复模型依据docs/generated/design/_meta/prompts/_remediate.md定义的规则逐条处理 findings产出修复报告即本篇文章的关联文档包含 actions 表、每条的 rationale 与 fix summary。刷新mark-fresh页面被编辑后由操作员运行regenerate.py mark-fresh更新 front matter 中的generated_at、source_commit、watched_paths_digest三个字段这些字段不归修复模型管。本次修复的最终结果5 条 finding 被修复fixed1 条被判定为越界拒绝rejected-out-of-scope。目标文档的 39 行记录被重写——33 个已退役的单元格被替换其中 26 个写明了具体的生产 pass7 个标记为no producer at HEAD另有 6 个单元格被剥离了(synthesized) —前缀。修复后AST origin 列中不再残留任何(synthesized)或裸—。核心契约AST origin 列必须写出生产者本次修复的核心驱动力是一条文档契约。docs/generated/design/_meta/prompts/_common.md:240-241要求AST origin列必须写出实际的生产 pass/函数若某 opcode 根本没有生产者则必须写no producer at HEAD并在 summary 中说明。审查报告 F-001 指出generics-and-existentials页面曾有 40 行指令记录使用已退役的(synthesized)兜底标签或裸—其中包括一些已经写出了生产函数的行以及 4 个未生产的 opcode 行。生产者producer在此处的含义是在 IR 构建过程中负责创建某条 opcode 的具体代码路径——可以是一个 lowering 访问器visit*方法、一个 IR pass、或核心模块中的__intrinsic_op声明。这条契约的意义在于读者拿到任意一条 IR 指令都能从文档反查到它来自哪里从而在阅读-dump-ir输出时快速定位到生成它的编译阶段。F-001 深度修复逐行溯源每一个生产者F-001 是本次修复中工作量最大的一条 major finding。修复原则是每个生产者都必须被追踪核实而不是猜测Every producer was traced, not guessed。修复过程覆盖了以下源码群set 与 set-element 指令族由 type-flow 特化 passsource/slang/slang-ir-typeflow-specialize.cpp构建。四个 set opcode 通过IRBuilder::getSingletonSet/getSet产生七个 set-element opcode如TypeSet、FuncSet、WitnessTableSet、GenericSet以及UnboundedTypeElement、UnboundedWitnessTableElement、UninitializedTypeElement、NoneTypeElement等散布在该 pass 的多处构建点。tagged-union 组MakeTaggedUnion、CastInterfaceToTaggedUnionPtr、GetTagFromTaggedUnion、GetValueFromTaggedUnion等均由 type-flow 特化 pass 产生。tag 转换组GetTagForSubSet、GetTagForMappedSet、GetTagForSpecializedSet、GetTagOfElementInSet等同样来自 type-flow 特化 pass。GetTagForSuperSet与一个GetTypeTagFromTaggedUnion构建点位于source/slang/slang-ir-typeflow-set.cpp159 行与 134 行即 set 转换发射逻辑。GetTagFromSequentialID/GetSequentialIDFromTag除了 type-flow 特化 pass还由动态派发 loweringsource/slang/slang-ir-lower-dynamic-dispatch-insts.cpp构建——这对应全局顺序 ID ↔ set 局部 tag的往返转换。GetElementFromTag与SpecializeExistentialsInType来自特化 passsource/slang/slang-ir-specialize.cpp3721 行与 3061 行。SpecializeExistentialsInFunc与WeakUse前者由 type-flow 特化 pass 产生后者通过IRBuilder::getWeakUse构建。溯源过程中还发现了两个此前被认为有生产者的 opcode 实际上无人调用IRBuilder::emitGetDispatchersource/slang/slang-ir-insts.h:4536与emitGetSpecializedDispatcher同文件 4557 行在整个source/目录中没有任何调用方——唯一的其他引用是slang-ir-lower-dynamic-dispatch-insts.h:34中的消费方声明lowerGetSpecializedDispatcher以及slang-ir.cpp:9668的一个 dump 分支。因此这两个 opcode 被归入无生产者清单。最终结果33 个已退役单元格全部转换完毕26 个写明了生产 pass/函数7 个标记为no producer at HEAD另有 6 个形如(synthesized) — producer的单元格被剥离了死亡前缀。无生产者清单7 个 opcode 的核实修复后generics-and-existentials页面的 ## Source 一节记录了完整的无生产者清单从 4 个增长到 7 个。这 7 个 opcode 的共同特征是存在IRBuilder发射器但没有任何代码调用它。它们分别是OpcodeC 包装器证据rtti_objectIRRTTIObjectLua 条目未声明操作数IRBuilder::emitMakeRTTIObject存在但无调用方C 与 C-like 发射器仍能处理它makeExistentialWithRTTIIRMakeExistentialWithRTTIIRBuilder::emitMakeExistentialWithRTTI无调用方尽管多个 pass 仍能识别该 opcodeextractTaggedUnionTagIRExtractTaggedUnionTagIRBuilder::emitExtractTaggedUnionTag无调用方extractTaggedUnionPayloadIRExtractTaggedUnionPayloadIRBuilder::emitExtractTaggedUnionPayload无调用方Lua 条目只声明unionVal发射器实际构建时带第二个tag操作数UnboundedGenericElementIRUnboundedGenericElementIRBuilder::getUnboundedGenericElement无调用方其余引用仅为分类/消费GetDispatcherIRGetDispatcherIRBuilder::emitGetDispatcher无调用方GetSpecializedDispatcherIRGetSpecializedDispatcherIRBuilder::emitGetSpecializedDispatcher无调用方但lowerGetSpecializedDispatcher仍消费该 opcode这些行的处理方式不是随意归因一个 origin而是如实记录no producer at HEAD并在 summary 中说明发射器存在但无人调用这一事实。例如makeExistentialWithRTTI行会同时说明它与makeExistential语义相同只是把值类型作为显式操作数携带且发射器当前无人调用——这对编译工程师判断这条指令会不会真的出现在 IR 里至关重要。F-002front matter 字段归属与 mark-freshF-002 被判定为rejected-out-of-scope即结论正确但不属于修复模型的编辑范围。理由依据docs/generated/design/_meta/prompts/_remediate.md:97-100generated_at、source_commit、watched_paths_digest三个 front matter 字段被保留给操作员的regenerate.py mark-fresh运行禁止修复模型编辑它们。由于本页面确实被编辑过mark-fresh会记录当前的文件摘要digest所以该 finding 无需修复模型处理。这条规则的意义在于谁改文档、谁刷新元数据职责必须分离否则摘要字段会与页面内容脱节破坏审查流水线的可追溯性。F-003UnboundedGenericElement 的佐证F-003 是 minor 级别确认了UnboundedGenericElement应加入无生产者清单。证据链如下IRBuilder::getUnboundedGenericElementsource/slang/slang-ir-insts.h:4620是唯一的构建路径且没有任何调用方其余引用只是slang-ir-insts.h:2983与:2999的分类 case、source/slang/slang-ir-typeflow-specialize.cpp:4054的消费方检查、以及slang-ir.cpp:9691的一个 dump case。这与页面自身对其他未生产 opcode 的判定标准完全一致有发射器、无调用方因此该行被标记为no producer at HEAD## Source一节的无生产者清单也相应从 4 个扩展到 7 个覆盖 F-001 中发现的另外两个 dispatcher opcode。F-004禁止内容裁剪——pass 行为细节不属于本页F-004 涉及文档边界控制。docs/generated/design/_meta/prompts/ir-reference-generics-and-existentials.md:70-73明确把特化 pass 细节slang-ir-specialize.cpppass列为禁止内容_common.md:269-271进一步强化了该约束。但 AST origin 列契约仍然要求写出生产 pass 的名字——因此修复只裁剪了行为性描述保留了 opcode 级事实lookupWitness的 callout 不再描述特化 pass 何时重写查找而是陈述 opcode 级事实——查找是一个一等公民的未求值值first-class unevaluated value并链接到docs/generated/design/pipeline/05-ir-passes.md让读者自行了解 pass 行为specialize的 callout 中删除了特化会用泛型的return_val结果替换每个应用这句话。这条修复体现了文档工程中的一条通用原则per-opcode 参考页只讲指令是什么、操作数是什么、由谁产生至于pass 何时消化它属于流水线文档的职责。F-005 与 F-006文档契约与文字修正两条小修正如实落地F-005nit_common.md:65-66要求正文第一段同时说明文档覆盖什么与读者是谁。修复将原本单独成段的 intended-reader 句并入开头段末尾仅做句子的拼接内容未变。F-006nitinterface_req_entry行中存在an associated-type bound such as an associated-type bound such as的重复片段删除重复的从句。被修复文档的实质内容Generics 与 Existentials 指令族速览为了让修复报告中的生产者概念有落点这里结合被修复的目标文档docs/generated/design/ir-reference/generics-and-existentials.md梳理该指令族的技术全貌。指令分布与命名约定这些 opcode 在source/slang/slang-ir-insts.lua中并不连续而是散布在多处specialize1047 行、lookupWitness1048、GetSequentialID1055、bind_global_generic_param1057、globalValueRef1062与普通值指令混居rtti_object1149、packAnyValue1155、unpackAnyValue1156也在附近global_generic_param932位于模块作用域簇与 requirement-key 和 witness-table 指令相邻后者由structure.md页面负责存在类型的构造/解构簇从makeExistential2708延伸到extractTaggedUnionPayload2733GetDynamicResourceHeap在 2819 行type-flow 特化指令从抽象的SetBase组3125直到SpecializeExistentialsInType3384。命名约定继承自types.md页面生成的IROp枚举名是kIROp_加条目的struct_name而非 Lua key因此key变成kIROp_StructKey、lookupWitness变成kIROp_LookupWitnessMethod、rtti_object变成kIROp_RTTIObjectLua key 则作为-dump-ir打印的助记符保留。若省略struct_nameLua 文件底部的process会用to_pascal_case从 key 推导。该族每个 opcode 都有 C 包装器。21 个是手写的struct IRFoo声明如IRSpecialize、IRLookupWitnessMethod、IRMakeExistential、IRExtractExistentialValue、抽象的IRSetBase、IRWitnessTableSet、IRTypeSet全部位于source/slang/slang-ir-insts.h其余由slang-ir.h.lua中的 FIDDLE 模板生成——getAllOtherInstStructsData152 行跳过已定义的IRstruct_name为其余条目发射isaImpl、kOp常量以及每个具名 Lua 操作数的访问器。指令族层级SetBase是该族唯一的抽象 Lua 父条目其余分组仅为读者阅读方便不对应 Lua 条目。关键生产路径AST 侧与 pass 侧从 AST 侧lowering来看生产者集中在source/slang/slang-lower-to-ir.cppemitDeclRef15302 行为GenericAppDeclRef发射specialize15351 行为经由LookupDeclRef到达的接口需求发射lookupWitness15425 行visitCastToSuperTypeExpr7312 行产生makeExistentialvisitExtractExistentialValueExpr7716、visitExtractExistentialType2935、visitExtractExistentialSubtypeWitness2944产生三个存在类型投影visitTypeEqualityWitness2411产生TypeEqualityWitnessvisitIsTypeExpr7420产生GetSequentialIDvisitGlobalGenericParamDecl10878产生global_generic_param。其余则由 IR pass 引入slang-ir-specialize.cpp、slang-ir-bind-existentials.cpp、slang-ir-lower-dynamic-dispatch-insts.cpp、slang-ir-typeflow-specialize.cpp、slang-ir-typeflow-set.cpp或由核心模块的__intrinsic_op声明产生。例如createExistentialObject来自source/slang/core.meta.slang中createDynamicObjectT, U(uint typeId, U value)的__intrinsic_op声明且会被slang-ir-lower-dynamic-dispatch-insts.cpp重建GetDynamicResourceHeap来自source/slang/hlsl.meta.slang中__getDynamicResourceHeapT : IOpaqueDescriptor的__intrinsic_op声明随后被lowerDynamicResourceHeapslang-ir-lower-dynamic-resource-heap.cpp:48替换为布局好的global_param。值得注意的指令行为specialize对base应用一个或多个泛型实参base可以是泛型函数、泛型类型或泛型 witness table。它是可提升hoistable的因此对同一泛型、同实参的引用会合并为一条 IR 值。泛型约束类型如struct BoxT : IFoo会把InheritanceDecl置于 generic 之下调用受约束辅助函数时会在实参列表里产生嵌套的specialize。lookupWitness接口派发的 IR 编码第一个操作数是 witness table 值第二个是 requirement key通过getWitnessTable()/getRequirementKey()读回。key 操作数可能是StructKey或可提升的BuiltinRequirementKey所以其静态类型是IRInst当需求本身是泛型时查找产生的是IRGeneric使用点必须用specialize包裹。makeExistential与其三个投影makeExistential(value, witness)把具体类型的值和其符合接口I的 witness 打包成I类型的值是到接口类型的加宽转换的 IR 形式来自CastToSuperTypeExpr。extractExistentialValue/extractExistentialType/extractExistentialWitnessTable是反向的三个投影其中类型与 witness-table 投影可提升值投影不可。wrapExistential处理特化值进入未特化被调方的方向——把BindExistentialsT, ...类型的值还原为T。操作数 0 之后是(具体类型, witness table)槽位对用getSlotOperandCount()/getSlotOperand(i)读取emitWrapExistential在构造期短路两种情形零槽位直接原样返回目标类型是InterfaceType时改为产生makeExistential。GetSequentialID与 RTTI返回操作数的稳定uintID使动态派发 lowering 能用整数做跳表键。尽管 Lua 操作数名为RTTIOperand所有调用方传入的都是 witness table——visitIsTypeExpr用它实现可选约束检查where optional T : IFoo加T is IFoo测试另一个调用方slang-ir-lower-dynamic-dispatch-insts.cpp通过Linkage::mapMangledNameToRTTIObjectIndex分配/读取表 ID。*Setopcodes 与集合论类型四个 set opcode 是四种集合论类型UntaggedUnionType、ElementOfSetType、SetTagType、TaggedUnionType详见docs/generated/design/ir-reference/types.md的操作数。前三者各只接受一个IRSetBase操作数TaggedUnionType接受两个且操作数顺序与其 Lua 注释相反——getTaggedUnionType(IRWitnessTableSet*, IRTypeSet*)把 witness-table set 放在操作数 0、type set 放在操作数 1。packAnyValue/unpackAnyValue跨越AnyValueType边界的类型擦除值搬运被ResultT, E合法化把错误值打包进定长 blob与 type-flow pass把具体值打包进UntaggedUnionType负载两处不相关的 lowering 使用。无生产者之外的边界FuncTypeOf值得注意的反例是FuncTypeOf——它是该族中唯一不由 type-flow 特化 pass 产生的指令。lowerFuncDependentTypeslang-lower-to-ir.cpp:2511是其在整个source/中的唯一构建点因此在 lowering 期就出现且可从普通源码触达对[Differentiable]函数调用fwd_diff会得到FwdDiffFuncTypelowering 该类型时用FuncTypeOf包裹原始可调用对象而非内嵌它。这解释了为什么它的 AST origin 列写的是 lowering 函数而非某个 pass。如何复核阅读源码的路径清单如果你要独立验证本文涉及的结论可沿以下路径核对均为仓库根目录相对路径指令模式定义source/slang/slang-ir-insts.lua、source/slang/slang-ir-insts.h包装器与枚举生成规则source/slang/slang-ir.h.luaAST 侧生产者source/slang/slang-lower-to-ir.cpppass 侧生产者source/slang/slang-ir-specialize.cpp、source/slang/slang-ir-typeflow-specialize.cpp、source/slang/slang-ir-typeflow-set.cpp、source/slang/slang-ir-lower-dynamic-dispatch-insts.cpp读取辅助source/slang/slang-ir-util.hfindWitnessTableEntry、source/slang/slang-ir.cpp核心模块来源source/slang/core.meta.slang、source/slang/hlsl.meta.slang文档流水线契约docs/generated/design/_meta/prompts/_remediate.md、docs/generated/design/_meta/prompts/_common.md、docs/generated/design/_meta/prompts/ir-reference-generics-and-existentials.md延伸阅读docs/generated/design/ir-reference/generics-and-existentials.md——本次修复的目标文档完整的 per-opcode 参考含各指令的操作数、flag、AST origin 与摘要。docs/generated/design/ir-reference/structure.md——generic、witness_table、witness_table_entry、interface_req_entry、key/StructKey、builtinRequirementKey、thisTypeWitness、TypeEqualityWitness的结构定义。docs/generated/design/ir-reference/types.md——BindExistentialsType、AnyValueType、RTTIType等类型 opcode以及接受*Setopcode 作为操作数的集合论类型。docs/generated/design/cross-cutting/ir-instructions.md——op flag、包装器生成与 hoistable/global 约定。docs/generated/design/pipeline/04-ast-to-ir.md 与 docs/generated/design/pipeline/05-ir-passes.md——lowering 路径与消化specialize/lookupWitness、插入wrapExistential、引入*Set机制的各个 pass。docs/design/existential-types.md 与 docs/design/decl-refs.md——存在类型模型与 decl-ref 机制的设计背景。关联的审查报告docs/generated/design/_meta/reviews/ir-reference/generics-and-existentials.md.review.md记录了全部 6 条 finding 的原始证据。【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Slang IR 文档修复实战：Generics 与 Existentials 指令族的生产者溯源与 no-producer 清单
Slang IR 文档修复实战Generics 与 Existentials 指令族的生产者溯源与 no-producer 清单【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang本篇文章围绕 Slang 编译器仓库中一份真实存在的修复报告展开——即docs/generated/design/_meta/remediations/ir-reference/generics-and-existentials.md.remediation.md它记录了对自动生成的 IR 参考文档docs/generated/design/ir-reference/generics-and-existentials.md的一次系统性修订逐条核实 39 行指令记录的 AST origin生产者来源、确认 7 个无人生产的 opcode、并裁剪越界的 pass 行为描述。读完本文你将掌握 Slang IR 中泛型generics、存在类型existentials、witness 查找与 type-flow 特化指令族的整体图谱理解生产者溯源这种文档校验方法以及如何在源码层面核实一个 opcode 究竟由谁、在哪个 pass 中产生。背景从审查到修复的文档流水线Slang 项目维护着一套自动生成的 IR 参考文档位于docs/generated/design/ir-reference/下每个指令族一个页面。由于文档由模型生成、且源码持续演进项目建立了一条审查 → 修复 → 刷新的流水线审查review审查模型对照源码、提示词契约与受监控文件清单manifest产出审查报告如docs/generated/design/_meta/reviews/ir-reference/generics-and-existentials.md.review.md。该报告对generics-and-existentials页面给出了 6 条 findings2 条 major、2 条 minor、2 条 nit核心问题是 40 行指令记录仍保留着已废弃的(synthesized)或裸—作为 AST origin。修复remediation修复模型依据docs/generated/design/_meta/prompts/_remediate.md定义的规则逐条处理 findings产出修复报告即本篇文章的关联文档包含 actions 表、每条的 rationale 与 fix summary。刷新mark-fresh页面被编辑后由操作员运行regenerate.py mark-fresh更新 front matter 中的generated_at、source_commit、watched_paths_digest三个字段这些字段不归修复模型管。本次修复的最终结果5 条 finding 被修复fixed1 条被判定为越界拒绝rejected-out-of-scope。目标文档的 39 行记录被重写——33 个已退役的单元格被替换其中 26 个写明了具体的生产 pass7 个标记为no producer at HEAD另有 6 个单元格被剥离了(synthesized) —前缀。修复后AST origin 列中不再残留任何(synthesized)或裸—。核心契约AST origin 列必须写出生产者本次修复的核心驱动力是一条文档契约。docs/generated/design/_meta/prompts/_common.md:240-241要求AST origin列必须写出实际的生产 pass/函数若某 opcode 根本没有生产者则必须写no producer at HEAD并在 summary 中说明。审查报告 F-001 指出generics-and-existentials页面曾有 40 行指令记录使用已退役的(synthesized)兜底标签或裸—其中包括一些已经写出了生产函数的行以及 4 个未生产的 opcode 行。生产者producer在此处的含义是在 IR 构建过程中负责创建某条 opcode 的具体代码路径——可以是一个 lowering 访问器visit*方法、一个 IR pass、或核心模块中的__intrinsic_op声明。这条契约的意义在于读者拿到任意一条 IR 指令都能从文档反查到它来自哪里从而在阅读-dump-ir输出时快速定位到生成它的编译阶段。F-001 深度修复逐行溯源每一个生产者F-001 是本次修复中工作量最大的一条 major finding。修复原则是每个生产者都必须被追踪核实而不是猜测Every producer was traced, not guessed。修复过程覆盖了以下源码群set 与 set-element 指令族由 type-flow 特化 passsource/slang/slang-ir-typeflow-specialize.cpp构建。四个 set opcode 通过IRBuilder::getSingletonSet/getSet产生七个 set-element opcode如TypeSet、FuncSet、WitnessTableSet、GenericSet以及UnboundedTypeElement、UnboundedWitnessTableElement、UninitializedTypeElement、NoneTypeElement等散布在该 pass 的多处构建点。tagged-union 组MakeTaggedUnion、CastInterfaceToTaggedUnionPtr、GetTagFromTaggedUnion、GetValueFromTaggedUnion等均由 type-flow 特化 pass 产生。tag 转换组GetTagForSubSet、GetTagForMappedSet、GetTagForSpecializedSet、GetTagOfElementInSet等同样来自 type-flow 特化 pass。GetTagForSuperSet与一个GetTypeTagFromTaggedUnion构建点位于source/slang/slang-ir-typeflow-set.cpp159 行与 134 行即 set 转换发射逻辑。GetTagFromSequentialID/GetSequentialIDFromTag除了 type-flow 特化 pass还由动态派发 loweringsource/slang/slang-ir-lower-dynamic-dispatch-insts.cpp构建——这对应全局顺序 ID ↔ set 局部 tag的往返转换。GetElementFromTag与SpecializeExistentialsInType来自特化 passsource/slang/slang-ir-specialize.cpp3721 行与 3061 行。SpecializeExistentialsInFunc与WeakUse前者由 type-flow 特化 pass 产生后者通过IRBuilder::getWeakUse构建。溯源过程中还发现了两个此前被认为有生产者的 opcode 实际上无人调用IRBuilder::emitGetDispatchersource/slang/slang-ir-insts.h:4536与emitGetSpecializedDispatcher同文件 4557 行在整个source/目录中没有任何调用方——唯一的其他引用是slang-ir-lower-dynamic-dispatch-insts.h:34中的消费方声明lowerGetSpecializedDispatcher以及slang-ir.cpp:9668的一个 dump 分支。因此这两个 opcode 被归入无生产者清单。最终结果33 个已退役单元格全部转换完毕26 个写明了生产 pass/函数7 个标记为no producer at HEAD另有 6 个形如(synthesized) — producer的单元格被剥离了死亡前缀。无生产者清单7 个 opcode 的核实修复后generics-and-existentials页面的 ## Source 一节记录了完整的无生产者清单从 4 个增长到 7 个。这 7 个 opcode 的共同特征是存在IRBuilder发射器但没有任何代码调用它。它们分别是OpcodeC 包装器证据rtti_objectIRRTTIObjectLua 条目未声明操作数IRBuilder::emitMakeRTTIObject存在但无调用方C 与 C-like 发射器仍能处理它makeExistentialWithRTTIIRMakeExistentialWithRTTIIRBuilder::emitMakeExistentialWithRTTI无调用方尽管多个 pass 仍能识别该 opcodeextractTaggedUnionTagIRExtractTaggedUnionTagIRBuilder::emitExtractTaggedUnionTag无调用方extractTaggedUnionPayloadIRExtractTaggedUnionPayloadIRBuilder::emitExtractTaggedUnionPayload无调用方Lua 条目只声明unionVal发射器实际构建时带第二个tag操作数UnboundedGenericElementIRUnboundedGenericElementIRBuilder::getUnboundedGenericElement无调用方其余引用仅为分类/消费GetDispatcherIRGetDispatcherIRBuilder::emitGetDispatcher无调用方GetSpecializedDispatcherIRGetSpecializedDispatcherIRBuilder::emitGetSpecializedDispatcher无调用方但lowerGetSpecializedDispatcher仍消费该 opcode这些行的处理方式不是随意归因一个 origin而是如实记录no producer at HEAD并在 summary 中说明发射器存在但无人调用这一事实。例如makeExistentialWithRTTI行会同时说明它与makeExistential语义相同只是把值类型作为显式操作数携带且发射器当前无人调用——这对编译工程师判断这条指令会不会真的出现在 IR 里至关重要。F-002front matter 字段归属与 mark-freshF-002 被判定为rejected-out-of-scope即结论正确但不属于修复模型的编辑范围。理由依据docs/generated/design/_meta/prompts/_remediate.md:97-100generated_at、source_commit、watched_paths_digest三个 front matter 字段被保留给操作员的regenerate.py mark-fresh运行禁止修复模型编辑它们。由于本页面确实被编辑过mark-fresh会记录当前的文件摘要digest所以该 finding 无需修复模型处理。这条规则的意义在于谁改文档、谁刷新元数据职责必须分离否则摘要字段会与页面内容脱节破坏审查流水线的可追溯性。F-003UnboundedGenericElement 的佐证F-003 是 minor 级别确认了UnboundedGenericElement应加入无生产者清单。证据链如下IRBuilder::getUnboundedGenericElementsource/slang/slang-ir-insts.h:4620是唯一的构建路径且没有任何调用方其余引用只是slang-ir-insts.h:2983与:2999的分类 case、source/slang/slang-ir-typeflow-specialize.cpp:4054的消费方检查、以及slang-ir.cpp:9691的一个 dump case。这与页面自身对其他未生产 opcode 的判定标准完全一致有发射器、无调用方因此该行被标记为no producer at HEAD## Source一节的无生产者清单也相应从 4 个扩展到 7 个覆盖 F-001 中发现的另外两个 dispatcher opcode。F-004禁止内容裁剪——pass 行为细节不属于本页F-004 涉及文档边界控制。docs/generated/design/_meta/prompts/ir-reference-generics-and-existentials.md:70-73明确把特化 pass 细节slang-ir-specialize.cpppass列为禁止内容_common.md:269-271进一步强化了该约束。但 AST origin 列契约仍然要求写出生产 pass 的名字——因此修复只裁剪了行为性描述保留了 opcode 级事实lookupWitness的 callout 不再描述特化 pass 何时重写查找而是陈述 opcode 级事实——查找是一个一等公民的未求值值first-class unevaluated value并链接到docs/generated/design/pipeline/05-ir-passes.md让读者自行了解 pass 行为specialize的 callout 中删除了特化会用泛型的return_val结果替换每个应用这句话。这条修复体现了文档工程中的一条通用原则per-opcode 参考页只讲指令是什么、操作数是什么、由谁产生至于pass 何时消化它属于流水线文档的职责。F-005 与 F-006文档契约与文字修正两条小修正如实落地F-005nit_common.md:65-66要求正文第一段同时说明文档覆盖什么与读者是谁。修复将原本单独成段的 intended-reader 句并入开头段末尾仅做句子的拼接内容未变。F-006nitinterface_req_entry行中存在an associated-type bound such as an associated-type bound such as的重复片段删除重复的从句。被修复文档的实质内容Generics 与 Existentials 指令族速览为了让修复报告中的生产者概念有落点这里结合被修复的目标文档docs/generated/design/ir-reference/generics-and-existentials.md梳理该指令族的技术全貌。指令分布与命名约定这些 opcode 在source/slang/slang-ir-insts.lua中并不连续而是散布在多处specialize1047 行、lookupWitness1048、GetSequentialID1055、bind_global_generic_param1057、globalValueRef1062与普通值指令混居rtti_object1149、packAnyValue1155、unpackAnyValue1156也在附近global_generic_param932位于模块作用域簇与 requirement-key 和 witness-table 指令相邻后者由structure.md页面负责存在类型的构造/解构簇从makeExistential2708延伸到extractTaggedUnionPayload2733GetDynamicResourceHeap在 2819 行type-flow 特化指令从抽象的SetBase组3125直到SpecializeExistentialsInType3384。命名约定继承自types.md页面生成的IROp枚举名是kIROp_加条目的struct_name而非 Lua key因此key变成kIROp_StructKey、lookupWitness变成kIROp_LookupWitnessMethod、rtti_object变成kIROp_RTTIObjectLua key 则作为-dump-ir打印的助记符保留。若省略struct_nameLua 文件底部的process会用to_pascal_case从 key 推导。该族每个 opcode 都有 C 包装器。21 个是手写的struct IRFoo声明如IRSpecialize、IRLookupWitnessMethod、IRMakeExistential、IRExtractExistentialValue、抽象的IRSetBase、IRWitnessTableSet、IRTypeSet全部位于source/slang/slang-ir-insts.h其余由slang-ir.h.lua中的 FIDDLE 模板生成——getAllOtherInstStructsData152 行跳过已定义的IRstruct_name为其余条目发射isaImpl、kOp常量以及每个具名 Lua 操作数的访问器。指令族层级SetBase是该族唯一的抽象 Lua 父条目其余分组仅为读者阅读方便不对应 Lua 条目。关键生产路径AST 侧与 pass 侧从 AST 侧lowering来看生产者集中在source/slang/slang-lower-to-ir.cppemitDeclRef15302 行为GenericAppDeclRef发射specialize15351 行为经由LookupDeclRef到达的接口需求发射lookupWitness15425 行visitCastToSuperTypeExpr7312 行产生makeExistentialvisitExtractExistentialValueExpr7716、visitExtractExistentialType2935、visitExtractExistentialSubtypeWitness2944产生三个存在类型投影visitTypeEqualityWitness2411产生TypeEqualityWitnessvisitIsTypeExpr7420产生GetSequentialIDvisitGlobalGenericParamDecl10878产生global_generic_param。其余则由 IR pass 引入slang-ir-specialize.cpp、slang-ir-bind-existentials.cpp、slang-ir-lower-dynamic-dispatch-insts.cpp、slang-ir-typeflow-specialize.cpp、slang-ir-typeflow-set.cpp或由核心模块的__intrinsic_op声明产生。例如createExistentialObject来自source/slang/core.meta.slang中createDynamicObjectT, U(uint typeId, U value)的__intrinsic_op声明且会被slang-ir-lower-dynamic-dispatch-insts.cpp重建GetDynamicResourceHeap来自source/slang/hlsl.meta.slang中__getDynamicResourceHeapT : IOpaqueDescriptor的__intrinsic_op声明随后被lowerDynamicResourceHeapslang-ir-lower-dynamic-resource-heap.cpp:48替换为布局好的global_param。值得注意的指令行为specialize对base应用一个或多个泛型实参base可以是泛型函数、泛型类型或泛型 witness table。它是可提升hoistable的因此对同一泛型、同实参的引用会合并为一条 IR 值。泛型约束类型如struct BoxT : IFoo会把InheritanceDecl置于 generic 之下调用受约束辅助函数时会在实参列表里产生嵌套的specialize。lookupWitness接口派发的 IR 编码第一个操作数是 witness table 值第二个是 requirement key通过getWitnessTable()/getRequirementKey()读回。key 操作数可能是StructKey或可提升的BuiltinRequirementKey所以其静态类型是IRInst当需求本身是泛型时查找产生的是IRGeneric使用点必须用specialize包裹。makeExistential与其三个投影makeExistential(value, witness)把具体类型的值和其符合接口I的 witness 打包成I类型的值是到接口类型的加宽转换的 IR 形式来自CastToSuperTypeExpr。extractExistentialValue/extractExistentialType/extractExistentialWitnessTable是反向的三个投影其中类型与 witness-table 投影可提升值投影不可。wrapExistential处理特化值进入未特化被调方的方向——把BindExistentialsT, ...类型的值还原为T。操作数 0 之后是(具体类型, witness table)槽位对用getSlotOperandCount()/getSlotOperand(i)读取emitWrapExistential在构造期短路两种情形零槽位直接原样返回目标类型是InterfaceType时改为产生makeExistential。GetSequentialID与 RTTI返回操作数的稳定uintID使动态派发 lowering 能用整数做跳表键。尽管 Lua 操作数名为RTTIOperand所有调用方传入的都是 witness table——visitIsTypeExpr用它实现可选约束检查where optional T : IFoo加T is IFoo测试另一个调用方slang-ir-lower-dynamic-dispatch-insts.cpp通过Linkage::mapMangledNameToRTTIObjectIndex分配/读取表 ID。*Setopcodes 与集合论类型四个 set opcode 是四种集合论类型UntaggedUnionType、ElementOfSetType、SetTagType、TaggedUnionType详见docs/generated/design/ir-reference/types.md的操作数。前三者各只接受一个IRSetBase操作数TaggedUnionType接受两个且操作数顺序与其 Lua 注释相反——getTaggedUnionType(IRWitnessTableSet*, IRTypeSet*)把 witness-table set 放在操作数 0、type set 放在操作数 1。packAnyValue/unpackAnyValue跨越AnyValueType边界的类型擦除值搬运被ResultT, E合法化把错误值打包进定长 blob与 type-flow pass把具体值打包进UntaggedUnionType负载两处不相关的 lowering 使用。无生产者之外的边界FuncTypeOf值得注意的反例是FuncTypeOf——它是该族中唯一不由 type-flow 特化 pass 产生的指令。lowerFuncDependentTypeslang-lower-to-ir.cpp:2511是其在整个source/中的唯一构建点因此在 lowering 期就出现且可从普通源码触达对[Differentiable]函数调用fwd_diff会得到FwdDiffFuncTypelowering 该类型时用FuncTypeOf包裹原始可调用对象而非内嵌它。这解释了为什么它的 AST origin 列写的是 lowering 函数而非某个 pass。如何复核阅读源码的路径清单如果你要独立验证本文涉及的结论可沿以下路径核对均为仓库根目录相对路径指令模式定义source/slang/slang-ir-insts.lua、source/slang/slang-ir-insts.h包装器与枚举生成规则source/slang/slang-ir.h.luaAST 侧生产者source/slang/slang-lower-to-ir.cpppass 侧生产者source/slang/slang-ir-specialize.cpp、source/slang/slang-ir-typeflow-specialize.cpp、source/slang/slang-ir-typeflow-set.cpp、source/slang/slang-ir-lower-dynamic-dispatch-insts.cpp读取辅助source/slang/slang-ir-util.hfindWitnessTableEntry、source/slang/slang-ir.cpp核心模块来源source/slang/core.meta.slang、source/slang/hlsl.meta.slang文档流水线契约docs/generated/design/_meta/prompts/_remediate.md、docs/generated/design/_meta/prompts/_common.md、docs/generated/design/_meta/prompts/ir-reference-generics-and-existentials.md延伸阅读docs/generated/design/ir-reference/generics-and-existentials.md——本次修复的目标文档完整的 per-opcode 参考含各指令的操作数、flag、AST origin 与摘要。docs/generated/design/ir-reference/structure.md——generic、witness_table、witness_table_entry、interface_req_entry、key/StructKey、builtinRequirementKey、thisTypeWitness、TypeEqualityWitness的结构定义。docs/generated/design/ir-reference/types.md——BindExistentialsType、AnyValueType、RTTIType等类型 opcode以及接受*Setopcode 作为操作数的集合论类型。docs/generated/design/cross-cutting/ir-instructions.md——op flag、包装器生成与 hoistable/global 约定。docs/generated/design/pipeline/04-ast-to-ir.md 与 docs/generated/design/pipeline/05-ir-passes.md——lowering 路径与消化specialize/lookupWitness、插入wrapExistential、引入*Set机制的各个 pass。docs/design/existential-types.md 与 docs/design/decl-refs.md——存在类型模型与 decl-ref 机制的设计背景。关联的审查报告docs/generated/design/_meta/reviews/ir-reference/generics-and-existentials.md.review.md记录了全部 6 条 finding 的原始证据。【免费下载链接】slangMaking it easier to work with shaders项目地址: https://gitcode.com/GitHub_Trending/sl/slang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考