开发F# Linter时，SynExpr.Lambda的args/body与parsedData用法咨询

我正在开发一款F#代码分析器（Linter），对FSharp.Compiler.Service中SynExpr.Lambda的args/body与parsedData用法存在困惑。我认为args/body是parsedData的简化版本，可能与源码内容不一致，开发Linter时应优先使用parsedData，但不清楚parsedData何时为None及应对方式，恳请明确两者用法差异。

SynExpr.Lambda定义如下：

/// First bool indicates if lambda originates from a method. Patterns here are always "simple"
/// Second bool indicates if this is a "later" part of an iterated sequence of lambdas
/// parsedData keeps original parsed patterns and expression,
/// prior to transforming to "simple" patterns and iterated lambdas
///
/// F# syntax: fun pat -> expr
| Lambda of
    fromMethod: bool *
    inLambdaSeq: bool *
    args: SynSimplePats *
    body: SynExpr *
    parsedData: (SynPat list * SynExpr) option *
    range: range *
    trivia: SynExprLambdaTrivia

一、args/body与parsedData的核心差异 #

• args/body：编译器标准化后的版本
  这部分是编译器为后续编译流程（类型检查、IL生成等）处理后的简化结果，会对原始代码做标准化转换：

  • 将复杂参数模式拆解为SynSimplePats（比如把fun (a,b) -> ...拆成两个简单参数的lambda序列）；
  • 将链式lambda（比如fun a b -> ...）拆分为多个Lambda节点，每个节点只保留当前层级的简单参数和对应body；
  • 最终结果可能和用户源码的原始写法结构不一致。

• parsedData：源码原始解析结果
  存储的是用户编写的fun pat -> expr中的原始参数模式列表和表达式，完全保留源码的写法结构，没有经过编译器的标准化转换。比如用户写的fun (a,b) -> ...，parsedData里的SynPat list就是包含一个元组模式的列表，而不是拆解后的两个简单参数。

二、parsedData为None的场景 #

parsedData仅在lambda没有对应的原始F#源码写法时为None，常见场景包括：

• lambda从.NET方法转换而来：当fromMethod为true时，这个lambda是把一个.NET方法当作委托使用生成的，不存在用户手写的fun语法，因此parsedData为None；
• 编译器自动生成的lambda：比如序列表达式、计算表达式、某些语法糖展开时自动生成的lambda，这类lambda没有对应的用户源码，因此parsedData为None。

三、Linter开发的应对建议 #

• 优先使用parsedData：Linter的核心是分析用户编写的原始代码，parsedData能准确反映用户的代码结构和写法，适合用于检查代码风格、语法规范等规则；
• parsedData为None时回退到args/body：此时lambda不是用户手写的F# lambda，可根据Linter规则需求选择：
  • 跳过对这类lambda的分析（因为它们不是用户主动编写的）；
  • 基于args/body做基础分析（比如检查参数数量、body复杂度等通用规则）。

内容的提问来源于stack exchange，提问作者cmeeren