Quarkdown 原生库处理器架构解析KSP 构建期代码生成如何取代渲染期反射调用【免费下载链接】quarkdown Markdown with superpowers: from ideas to papers, presentations, websites, books, and knowledge bases.项目地址: https://gitcode.com/GitHub_Trending/qu/quarkdown本文围绕 ARCHITECTURE.md 展开讲解 Quarkdown 项目中quarkdown-native-library-processor模块的完整架构一个被QFunction标注的 Kotlin 函数是如何在构建期被 KSPKotlin Symbol Processing处理器发现、校验、规划参数转换并生成普通 Kotlin 源代码最终变成 Quarkdown 文档里可以用点号调用的原生函数的。读完后你将理解它的构建期流水线scan → validate → describe → plan → generate、以ValueFactory为单一事实来源的转换规划策略、生成物的四种组成部件以及渲染期调用链如何穿过 binder、binder 生成的包装器抵达原生函数。为什么需要这个模块按名字调用一个原生函数需要做三件事知道它的参数、把每个实参转换成声明的类型、然后调用它。在 Quarkdown 早期这些全部发生在渲染期靠反射完成——每次函数调用都要重新扫描参数、解析类型、反射查找转换函数。问题在于这些输入在 Quarkdown 构建时其实全都是已知的。于是处理器把这些工作前移到构建期一次做完直接吐出普通 Kotlin 代码。带来的收益是明确的渲染期不再做任何反射式的参数扫描与类型查找无法转换的参数类型会在构建时报错而不是在某个文档渲染时才失败见 CoercionPlanner.kt 的注释“an unmappable type fails the build instead of the render”枚举条目被直接“烘焙”成源码里的字面量数组替代运行时的values()反射查找。构建期流水线处理器入口是 NativeLibrarySymbolProcessor.process()每个 KSP round 构建一个全新的DiscoveryContextround 作用域状态然后委托给ModuleDiscovery做发现、ModuleCodeGenerator做发射最后为每个模块打一条Generated Quarkdown module ... with N function(s)的 info 日志。流水线如下与原文档中的架构图一致各阶段职责单一且生成器只读 descriptor这使 KSP 符号完全不泄漏到代码发射层scanModuleDiscovery.scanModuleFiles() 遍历resolver.getNewFiles()并过滤出带file:QModule的源文件。这里有个刻意的实现选择对 FILE 级标注Resolver.getSymbolsWithAnnotation在各 KSP 后端上支持不均所以改用逐文件读自身标注同时用getNewFiles()而非getAllFiles()避免后续 round 重复拾取源文件、产生重复 wrapper。validateModuleValidator 按顺序执行一组ValidationRule任何一条失败即通过KSPLogger.error令当前 round 失败阻止生成器输出畸形输入的代码。默认规则表DEFAULT_RULES包含六条顺序有讲究——结构规则最先因为它违反时会连带使文件级假设失效规则约束TopLevelOrObjectRuleQFunction必须是顶层函数或 object 内的成员InModuleFileRule函数必须位于file:QModule文件内防止孤儿函数NoTypeParametersRule函数不允许带泛型类型参数ExplicitReturnTypeRule必须显式声明返回类型NamedParametersRule参数必须具名NoDoubleUnderscoreNameRule名称中不得出现双下划线保留给生成的__raw/__dynamic后缀防撞名describeModuleDescriber 把 KSP 符号投影为 ModuleDescriptor模块名取去掉.kt的文件名包名、import 原文、按源顺序排列的函数列表。对每个函数再投影出FunctionDescriptor原名、导出名应用Name后、限定名、返回类型、参数列表、KDoc 原文、以及由文档类型标注派生的 validator 表达式。空模块没有任何QFunction会以logger.warn报出但仍返回让调用方可以观察到它。plan conversions为每个参数规划填充方式详见下一节。generateModuleCodeGenerator.generate() 以aggregating false的依赖关系创建文件每个模块一个 Kotlin 文件写入build/generated/ksp下。贯穿所有阶段的共享状态集中在 DiscoveryContextKSPResolver、KSPLogger、反射式 PSI 门面、NameMappingsround 内累积的Name导出注册表、已发现的模块文件集合、以及每 round 只读一次的ValueFactory候选列表。注释里提到这种“单一对象、各阶段协作式修改”的用法与quarkdown-core中Context的模式一致。转换规划替代运行时查找的那一步这是取代运行时反射查找的核心步骤。可用转换不是硬编码在处理器里的表而是从编译类路径上com.quarkdown.core.function.value.factory.ValueFactory的标注上读出来的由 ValueFactoryCatalog.read() 完成逐个读取ValueFactory声明函数上的FromDynamicType标注提取unwrappedType目标静态类型与requiresContext候选函数必须具备可调用形态——只接受 raw value以及可选的 context两个参数否则被logger.warn拒绝因为其它形态会生成编译不过的代码若ValueFactory根本不在类路径上则直接抛错——否则处理器会“静默地生成一批毫无转换能力的 wrapper”。错误信息明确提示运行处理器的模块必须依赖quarkdown-core。对每个参数CoercionPlanner.plan() 按如下决策树规划与原文档流程图一致结合源码各分支的具体产物是注入参数Injected只接受三种可注入类型直接从调用上读取无需转换——Context/MutableContext→call.requireContext() as 类型FunctionCall→callFunctionCallNode→call.sourceNode。其它类型返回Unsupported报错信息会列出合法的三种类型。特殊类型直通DynamicValue参数直接包成DynamicValue(it)并按ParameterType.Dynamic标记Lambda走ValueFactory.lambda(it, call.requireContext())已经是Value体系子类型如OutputValue*的参数原样透传it as? Value*失败时以普通类型不匹配而非 cast 错误报出。枚举生成ValueFactory.enum(it, 枚举FQN.entries.toTypedArray())把枚举条目烘焙进源码替代反射values()查找。工厂匹配先找精确类型匹配的候选没有精确匹配时在参数的超类型里找。恰好一个超类型匹配才通过零个或多个都返回Unsupported并使构建失败。原文明确解释了“宁缺毋滥”的原因旧的运行时转换器靠声明顺序消歧而反射与 KSP 对编译类都不保证声明顺序所以有歧义就失败而不是悄悄挑一个。生成什么ModuleCodeGenerator 为每个file:QModule源文件发射一个object ModuleName模块名即去掉扩展名的文件名文件头写着// Generated by quarkdown-native-library-processor. Do not edit.并带上覆盖 ktlint 与冗余可见性修饰符等的file:Suppress列表同时把源文件的 import 原文照抄进生成文件保证默认值表达式能引用到源文件导入过的符号。对每个导出函数生成物由四件东西组成参数元数据每个展平后的参数一条private val P_函数名_参数名: FunctionParameter携带导出名、ParameterType由转换规划写入、序号、isOptional有没有默认值、isExplicitlyBody、isInjected、isNullable以及一个convertlambda——转换挂在参数上而非写死在函数体里这样当一次调用把参数转交给另一次调用如.super时转换随绑定一起生效。模块导出的可调用private val F_函数名: Function返回类型 SimpleFunction(name, parameters, validators, invoke)其中 validators 来自源函数上的OnlyForDocumentType/NotForDocumentType标注在构建期就渲染成DocumentTypeFunctionCallValidator(...)的构造调用运行期不再读标注。带文档的类型化包装器public fun 导出名(...): 返回类型签名即对外发布的契约KDoc 由源函数文档改写生成参数名已替换为导出名函数级标注原样传播。body 是一行对源函数限定名的委托调用。松类型的动态对应物internal fun 导出名__dynamic(每个参数名__raw: Any Unbound, call: FunctionCall*)。它是调用路径的入口按声明顺序为每个参数发一个局部变量注入参数直接取call.requireContext()等其余参数在__raw Unbound时落回默认值表达式、否则经构建期选定的工厂转换coerce(raw, descriptor, call) { ... }最后委托给第 3 点的类型化包装器。局部变量按声明顺序发射正是这一点让某个参数的默认值表达式可以引用前面的参数包括注入参数。原文档特别强调生成代码是自身形态的权威——要看真实产物去读build/generated/ksp下的文件而不是读任何散文里的拷贝。渲染期流程构建期把所有信息固化之后渲染期的一次调用变成一条无反射的直线与原文档时序图一致对照生成代码即可逐项印证validate对应SimpleFunction携带的 validatorsbind arguments把文档实参按参数元数据配对convert via the parameter就是参数上挂的convertlambdainvoke, guarded对应生成代码里的invokeGuarded(call) { ... }defaults and injected values对应动态 wrapper 里的局部变量填充最后的delegate才是真正执行原生 Kotlin 函数。唯一的反射角落PSI 读取与quarkdown.psi.debug有四项输入不属于 KSP 公共 API默认值表达式、KDoc 文档注释、import 列表、标注的源码原文。它们只能通过 KSP 内部持有的 PSI 读取这是该模块唯一的反射角落。设计上它安静地失败——所有反射访问都被 try/catch 包裹失败后经 PsiDiagnostics 上报然后返回nullextractor 拿不到某段源级信息就只让 wrapper 少一块信息比如丢掉一条 KDoc而不是打断构建默认实现是NoOp保持生产环境安静。需要看到这些失败时典型场景是 KSP 升级后 shaded PSI API 改名/移位在处理器选项里设置quarkdown.psi.debugtrue即可——NativeLibrarySymbolProcessorProvider 读取该选项并换装LoggingPsiDiagnostics每次反射失败都会通过KSPLogger.warn打印PSI reflection failed: 类#方法: 原因。实战写出一个原生库模块把上面的架构串起来一个最小可用的原生库长这样参考测试 fixture NamedFunction.kt 与真实 stdlib 源码// 每个 file:QModule 源文件变成一个 QuarkdownModule file:QModule package com.quarkdown.processor.fixtures import com.quarkdown.core.function.value.VoidValue import com.quarkdown.processor.annotation.Name import com.quarkdown.processor.annotation.QFunction import com.quarkdown.processor.annotation.QModule QFunction Name(renamedLog) fun logInternal(message: String) VoidValue四个标注的职责均定义在 annotation/ 目录SOURCE保留期保证不进入运行时类元数据标注目标作用QModule文件把整个 Kotlin 源文件标记为原生库模块文件即模块名QFunction函数把顶层函数标记为可导出的 Quarkdown 函数Name(x)函数/参数覆盖导出名fun someFunction()调用作.someFunction加Name(somefunction)后调用作.somefunctionSpread参数把类类型参数展开为主构造器参数逐一暴露委托时再用命名参数构造还原实例约束方面除上一节的六条校验规则外参数还支持Body保留 body 参数、Injected注入 context/call/sourceNode、OnlyForDocumentType/NotForDocumentType限制可用文档类型——这些都由描述器识别并固化进生成物见 ModuleDescriber.kt 中的 FQN 常量表。模块接入构建只需两个依赖quarkdown-stdlib的真实配置见 quarkdown-stdlib/build.gradle.ktsplugins { kotlin(jvm) id(com.google.devtools.ksp) version 2.3.12 } dependencies { // 标注与处理器仅构建期需要 compileOnly(project(:quarkdown-native-library-processor)) ksp(project(:quarkdown-native-library-processor)) }处理器模块自身的 build.gradle.kts 声明了extra[noRuntime] true随 JAR 分发但不进入运行时分布、KSP 版本2.3.12并implementation依赖symbol-processing-api运行处理器的模块则必须依赖quarkdown-coreValueFactoryCatalog解析不到ValueFactory时会直接构建失败。一个真实用法示例来自 quarkdown-stdlib/src/main/kotlin/com/quarkdown/stdlib/Collection.ktName(getat)把 Kotlin 函数重命名为文档端更好读的点号名参数上的Name(from)/Name(orelse)同理改写导出参数名——这些名字在 KSP round 内被NameMappings记录最终烘焙进生成 wrapper 的签名。行为的回归由 KSP 集成测试守住src/test/kotlin/com/quarkdown/processor/integration/下有 NameMappingTest.kt、WrapperGenerationTest.kt、OutputLayoutTest.kt、KDocEmissionTest.kt、ImportCopyingTest.kt、SpreadParameterTest.kt、TypeRenderingTest.kt 等直接对build/generated/ksp的真实产物断言CoercionPlanner另有独立单测 CoercionPlannerTest.kt。小结与关键文件索引quarkdown-native-library-processor的设计可以浓缩为三句话把渲染期反射的所有输入参数、类型、默认值、转换函数前移到构建期固化为普通 Kotlin用 descriptor 作为阶段间唯一接口让生成器彻底与 KSP 隔离把不确定性收敛到一个安静的反射角落PSI 读取并给出一条随时可打开的调试通道quarkdown.psi.debugtrue。关注点文件流水线入口NativeLibrarySymbolProcessor.kt选项处理与 PSI 调试开关NativeLibrarySymbolProcessorProvider.kt扫描/校验/描述编排ModuleDiscovery.kt、ModuleValidator.kt、ModuleDescriber.kt转换规划ValueFactoryCatalog.kt、CoercionPlanner.kt生成物模型与代码发射ModuleDescriptor.kt、ModuleCodeGenerator.kt标注定义QModule.kt、QFunction.kt、Name.kt、Spread.kt真实消费方示例quarkdown-stdlib/build.gradle.kts、Collection.kt【免费下载链接】quarkdown Markdown with superpowers: from ideas to papers, presentations, websites, books, and knowledge bases.项目地址: https://gitcode.com/GitHub_Trending/qu/quarkdown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Quarkdown 原生库处理器架构解析：KSP 构建期代码生成如何取代渲染期反射调用
Quarkdown 原生库处理器架构解析KSP 构建期代码生成如何取代渲染期反射调用【免费下载链接】quarkdown Markdown with superpowers: from ideas to papers, presentations, websites, books, and knowledge bases.项目地址: https://gitcode.com/GitHub_Trending/qu/quarkdown本文围绕 ARCHITECTURE.md 展开讲解 Quarkdown 项目中quarkdown-native-library-processor模块的完整架构一个被QFunction标注的 Kotlin 函数是如何在构建期被 KSPKotlin Symbol Processing处理器发现、校验、规划参数转换并生成普通 Kotlin 源代码最终变成 Quarkdown 文档里可以用点号调用的原生函数的。读完后你将理解它的构建期流水线scan → validate → describe → plan → generate、以ValueFactory为单一事实来源的转换规划策略、生成物的四种组成部件以及渲染期调用链如何穿过 binder、binder 生成的包装器抵达原生函数。为什么需要这个模块按名字调用一个原生函数需要做三件事知道它的参数、把每个实参转换成声明的类型、然后调用它。在 Quarkdown 早期这些全部发生在渲染期靠反射完成——每次函数调用都要重新扫描参数、解析类型、反射查找转换函数。问题在于这些输入在 Quarkdown 构建时其实全都是已知的。于是处理器把这些工作前移到构建期一次做完直接吐出普通 Kotlin 代码。带来的收益是明确的渲染期不再做任何反射式的参数扫描与类型查找无法转换的参数类型会在构建时报错而不是在某个文档渲染时才失败见 CoercionPlanner.kt 的注释“an unmappable type fails the build instead of the render”枚举条目被直接“烘焙”成源码里的字面量数组替代运行时的values()反射查找。构建期流水线处理器入口是 NativeLibrarySymbolProcessor.process()每个 KSP round 构建一个全新的DiscoveryContextround 作用域状态然后委托给ModuleDiscovery做发现、ModuleCodeGenerator做发射最后为每个模块打一条Generated Quarkdown module ... with N function(s)的 info 日志。流水线如下与原文档中的架构图一致各阶段职责单一且生成器只读 descriptor这使 KSP 符号完全不泄漏到代码发射层scanModuleDiscovery.scanModuleFiles() 遍历resolver.getNewFiles()并过滤出带file:QModule的源文件。这里有个刻意的实现选择对 FILE 级标注Resolver.getSymbolsWithAnnotation在各 KSP 后端上支持不均所以改用逐文件读自身标注同时用getNewFiles()而非getAllFiles()避免后续 round 重复拾取源文件、产生重复 wrapper。validateModuleValidator 按顺序执行一组ValidationRule任何一条失败即通过KSPLogger.error令当前 round 失败阻止生成器输出畸形输入的代码。默认规则表DEFAULT_RULES包含六条顺序有讲究——结构规则最先因为它违反时会连带使文件级假设失效规则约束TopLevelOrObjectRuleQFunction必须是顶层函数或 object 内的成员InModuleFileRule函数必须位于file:QModule文件内防止孤儿函数NoTypeParametersRule函数不允许带泛型类型参数ExplicitReturnTypeRule必须显式声明返回类型NamedParametersRule参数必须具名NoDoubleUnderscoreNameRule名称中不得出现双下划线保留给生成的__raw/__dynamic后缀防撞名describeModuleDescriber 把 KSP 符号投影为 ModuleDescriptor模块名取去掉.kt的文件名包名、import 原文、按源顺序排列的函数列表。对每个函数再投影出FunctionDescriptor原名、导出名应用Name后、限定名、返回类型、参数列表、KDoc 原文、以及由文档类型标注派生的 validator 表达式。空模块没有任何QFunction会以logger.warn报出但仍返回让调用方可以观察到它。plan conversions为每个参数规划填充方式详见下一节。generateModuleCodeGenerator.generate() 以aggregating false的依赖关系创建文件每个模块一个 Kotlin 文件写入build/generated/ksp下。贯穿所有阶段的共享状态集中在 DiscoveryContextKSPResolver、KSPLogger、反射式 PSI 门面、NameMappingsround 内累积的Name导出注册表、已发现的模块文件集合、以及每 round 只读一次的ValueFactory候选列表。注释里提到这种“单一对象、各阶段协作式修改”的用法与quarkdown-core中Context的模式一致。转换规划替代运行时查找的那一步这是取代运行时反射查找的核心步骤。可用转换不是硬编码在处理器里的表而是从编译类路径上com.quarkdown.core.function.value.factory.ValueFactory的标注上读出来的由 ValueFactoryCatalog.read() 完成逐个读取ValueFactory声明函数上的FromDynamicType标注提取unwrappedType目标静态类型与requiresContext候选函数必须具备可调用形态——只接受 raw value以及可选的 context两个参数否则被logger.warn拒绝因为其它形态会生成编译不过的代码若ValueFactory根本不在类路径上则直接抛错——否则处理器会“静默地生成一批毫无转换能力的 wrapper”。错误信息明确提示运行处理器的模块必须依赖quarkdown-core。对每个参数CoercionPlanner.plan() 按如下决策树规划与原文档流程图一致结合源码各分支的具体产物是注入参数Injected只接受三种可注入类型直接从调用上读取无需转换——Context/MutableContext→call.requireContext() as 类型FunctionCall→callFunctionCallNode→call.sourceNode。其它类型返回Unsupported报错信息会列出合法的三种类型。特殊类型直通DynamicValue参数直接包成DynamicValue(it)并按ParameterType.Dynamic标记Lambda走ValueFactory.lambda(it, call.requireContext())已经是Value体系子类型如OutputValue*的参数原样透传it as? Value*失败时以普通类型不匹配而非 cast 错误报出。枚举生成ValueFactory.enum(it, 枚举FQN.entries.toTypedArray())把枚举条目烘焙进源码替代反射values()查找。工厂匹配先找精确类型匹配的候选没有精确匹配时在参数的超类型里找。恰好一个超类型匹配才通过零个或多个都返回Unsupported并使构建失败。原文明确解释了“宁缺毋滥”的原因旧的运行时转换器靠声明顺序消歧而反射与 KSP 对编译类都不保证声明顺序所以有歧义就失败而不是悄悄挑一个。生成什么ModuleCodeGenerator 为每个file:QModule源文件发射一个object ModuleName模块名即去掉扩展名的文件名文件头写着// Generated by quarkdown-native-library-processor. Do not edit.并带上覆盖 ktlint 与冗余可见性修饰符等的file:Suppress列表同时把源文件的 import 原文照抄进生成文件保证默认值表达式能引用到源文件导入过的符号。对每个导出函数生成物由四件东西组成参数元数据每个展平后的参数一条private val P_函数名_参数名: FunctionParameter携带导出名、ParameterType由转换规划写入、序号、isOptional有没有默认值、isExplicitlyBody、isInjected、isNullable以及一个convertlambda——转换挂在参数上而非写死在函数体里这样当一次调用把参数转交给另一次调用如.super时转换随绑定一起生效。模块导出的可调用private val F_函数名: Function返回类型 SimpleFunction(name, parameters, validators, invoke)其中 validators 来自源函数上的OnlyForDocumentType/NotForDocumentType标注在构建期就渲染成DocumentTypeFunctionCallValidator(...)的构造调用运行期不再读标注。带文档的类型化包装器public fun 导出名(...): 返回类型签名即对外发布的契约KDoc 由源函数文档改写生成参数名已替换为导出名函数级标注原样传播。body 是一行对源函数限定名的委托调用。松类型的动态对应物internal fun 导出名__dynamic(每个参数名__raw: Any Unbound, call: FunctionCall*)。它是调用路径的入口按声明顺序为每个参数发一个局部变量注入参数直接取call.requireContext()等其余参数在__raw Unbound时落回默认值表达式、否则经构建期选定的工厂转换coerce(raw, descriptor, call) { ... }最后委托给第 3 点的类型化包装器。局部变量按声明顺序发射正是这一点让某个参数的默认值表达式可以引用前面的参数包括注入参数。原文档特别强调生成代码是自身形态的权威——要看真实产物去读build/generated/ksp下的文件而不是读任何散文里的拷贝。渲染期流程构建期把所有信息固化之后渲染期的一次调用变成一条无反射的直线与原文档时序图一致对照生成代码即可逐项印证validate对应SimpleFunction携带的 validatorsbind arguments把文档实参按参数元数据配对convert via the parameter就是参数上挂的convertlambdainvoke, guarded对应生成代码里的invokeGuarded(call) { ... }defaults and injected values对应动态 wrapper 里的局部变量填充最后的delegate才是真正执行原生 Kotlin 函数。唯一的反射角落PSI 读取与quarkdown.psi.debug有四项输入不属于 KSP 公共 API默认值表达式、KDoc 文档注释、import 列表、标注的源码原文。它们只能通过 KSP 内部持有的 PSI 读取这是该模块唯一的反射角落。设计上它安静地失败——所有反射访问都被 try/catch 包裹失败后经 PsiDiagnostics 上报然后返回nullextractor 拿不到某段源级信息就只让 wrapper 少一块信息比如丢掉一条 KDoc而不是打断构建默认实现是NoOp保持生产环境安静。需要看到这些失败时典型场景是 KSP 升级后 shaded PSI API 改名/移位在处理器选项里设置quarkdown.psi.debugtrue即可——NativeLibrarySymbolProcessorProvider 读取该选项并换装LoggingPsiDiagnostics每次反射失败都会通过KSPLogger.warn打印PSI reflection failed: 类#方法: 原因。实战写出一个原生库模块把上面的架构串起来一个最小可用的原生库长这样参考测试 fixture NamedFunction.kt 与真实 stdlib 源码// 每个 file:QModule 源文件变成一个 QuarkdownModule file:QModule package com.quarkdown.processor.fixtures import com.quarkdown.core.function.value.VoidValue import com.quarkdown.processor.annotation.Name import com.quarkdown.processor.annotation.QFunction import com.quarkdown.processor.annotation.QModule QFunction Name(renamedLog) fun logInternal(message: String) VoidValue四个标注的职责均定义在 annotation/ 目录SOURCE保留期保证不进入运行时类元数据标注目标作用QModule文件把整个 Kotlin 源文件标记为原生库模块文件即模块名QFunction函数把顶层函数标记为可导出的 Quarkdown 函数Name(x)函数/参数覆盖导出名fun someFunction()调用作.someFunction加Name(somefunction)后调用作.somefunctionSpread参数把类类型参数展开为主构造器参数逐一暴露委托时再用命名参数构造还原实例约束方面除上一节的六条校验规则外参数还支持Body保留 body 参数、Injected注入 context/call/sourceNode、OnlyForDocumentType/NotForDocumentType限制可用文档类型——这些都由描述器识别并固化进生成物见 ModuleDescriber.kt 中的 FQN 常量表。模块接入构建只需两个依赖quarkdown-stdlib的真实配置见 quarkdown-stdlib/build.gradle.ktsplugins { kotlin(jvm) id(com.google.devtools.ksp) version 2.3.12 } dependencies { // 标注与处理器仅构建期需要 compileOnly(project(:quarkdown-native-library-processor)) ksp(project(:quarkdown-native-library-processor)) }处理器模块自身的 build.gradle.kts 声明了extra[noRuntime] true随 JAR 分发但不进入运行时分布、KSP 版本2.3.12并implementation依赖symbol-processing-api运行处理器的模块则必须依赖quarkdown-coreValueFactoryCatalog解析不到ValueFactory时会直接构建失败。一个真实用法示例来自 quarkdown-stdlib/src/main/kotlin/com/quarkdown/stdlib/Collection.ktName(getat)把 Kotlin 函数重命名为文档端更好读的点号名参数上的Name(from)/Name(orelse)同理改写导出参数名——这些名字在 KSP round 内被NameMappings记录最终烘焙进生成 wrapper 的签名。行为的回归由 KSP 集成测试守住src/test/kotlin/com/quarkdown/processor/integration/下有 NameMappingTest.kt、WrapperGenerationTest.kt、OutputLayoutTest.kt、KDocEmissionTest.kt、ImportCopyingTest.kt、SpreadParameterTest.kt、TypeRenderingTest.kt 等直接对build/generated/ksp的真实产物断言CoercionPlanner另有独立单测 CoercionPlannerTest.kt。小结与关键文件索引quarkdown-native-library-processor的设计可以浓缩为三句话把渲染期反射的所有输入参数、类型、默认值、转换函数前移到构建期固化为普通 Kotlin用 descriptor 作为阶段间唯一接口让生成器彻底与 KSP 隔离把不确定性收敛到一个安静的反射角落PSI 读取并给出一条随时可打开的调试通道quarkdown.psi.debugtrue。关注点文件流水线入口NativeLibrarySymbolProcessor.kt选项处理与 PSI 调试开关NativeLibrarySymbolProcessorProvider.kt扫描/校验/描述编排ModuleDiscovery.kt、ModuleValidator.kt、ModuleDescriber.kt转换规划ValueFactoryCatalog.kt、CoercionPlanner.kt生成物模型与代码发射ModuleDescriptor.kt、ModuleCodeGenerator.kt标注定义QModule.kt、QFunction.kt、Name.kt、Spread.kt真实消费方示例quarkdown-stdlib/build.gradle.kts、Collection.kt【免费下载链接】quarkdown Markdown with superpowers: from ideas to papers, presentations, websites, books, and knowledge bases.项目地址: https://gitcode.com/GitHub_Trending/qu/quarkdown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考