解析错误位置

我在给一个 Go 源码检查器补错误提示时，最先踩到的坑不是语法本身，而是“位置”有两种形态：parser.ParseFile 返回的语法错误通常已经带着文件名、行号和列号；AST 节点上的位置却只是 token.Pos，必须交给同一个 token.FileSet 才能还原。实际处理时，先把 scanner.ErrorList 展开，再用 FileSet.Position 或 PositionFor 做坐标转换，输出就不会混乱。

我先把“错误位置”和“节点位置”分开

go/parser 的 ParseFile 负责把源码解析成 ast.File。源码存在语法问题时，它可能返回一个部分 AST 和一个错误；多个语法错误会以按源位置排序的 scanner.ErrorList 返回。这个错误对象适合直接给用户展示。

另一条路径是解析成功后检查声明、调用或表达式。节点的 Pos() 返回 token.Pos，它是当前 FileSet 中的位置标识，不是“第几行”的整数。把这两条路径混在一起，是我第一次实现时把列号打印成大整数的原因。

用 ErrorList 输出每个语法错误的行列

错误处理可以先保留原始 error，再判断它是不是 scanner.ErrorList。下面的写法不依赖字符串切割，文件名、行号、列号和消息都从结构化字段读取：

package main

import (
    "fmt"
    "go/parser"
    "go/scanner"
    "go/token"
)

func printParseErrors(filename string, src []byte) {
    fset := token.NewFileSet() // 让解析器和后续位置转换共享同一坐标表
    _, err := parser.ParseFile(fset, filename, src, parser.SkipObjectResolution)
    if err == nil {
        return
    }

    if list, ok := err.(scanner.ErrorList); ok {
        for _, item := range list {
            // Position 已经拆出文件、行、列；Msg 保留真正的语法原因
            fmt.Printf("%s:%d:%d: %s\n", item.Pos.Filename, item.Pos.Line, item.Pos.Column, item.Msg)
        }
        return
    }

    // 读取源码失败等非语法错误不一定是 ErrorList，不能丢掉原始错误
    fmt.Printf("%s: %v\n", filename, err)
}

这里的判断边界很重要：读取文件失败、输入源不可读等问题不应该被强行包装成语法错误。若只想保留统一日志格式，可以在最后的分支加上错误类型和文件名，但不要通过解析错误字符串猜行号。

用 FileSet 把 token.Pos 映射成源文件坐标

当检查器需要指出“哪个 AST 节点触发了规则”时，位置来自节点本身：

func printDeclPosition(fset *token.FileSet, file *ast.File) {
    if file == nil || len(file.Decls) == 0 {
        return // 没有声明时没有可供报告的节点位置
    }

    pos := file.Decls[0].Pos() // AST 只给出 FileSet 内部的 token.Pos
    adjusted := fset.Position(pos)
    absolute := fset.PositionFor(pos, false)

    // adjusted 遵守 //line 指令；absolute 反映原始源文件位置
    fmt.Printf("显示位置 %s；绝对位置 %s\n", adjusted.String(), absolute.String())
}

示例省略了导入和解析过程，关键只有一件事：fset 必须是解析该 AST 时传入 ParseFile 的那一个。重新创建一个空的 FileSet，即使 token.Pos 数值看起来正常，也无法定位到对应文件。

遇到 //line 和多文件时保留两套坐标

fset.Position(pos) 会考虑源码中的 //line 指令，适合把生成代码或经过映射的内容展示给用户；fset.PositionFor(pos, false) 则给出未调整的源文件坐标。两者不一定相同，日志和编辑器跳转最好明确字段名称，不要把“显示位置”误称为“物理文件位置”。

如果解析一个目录或多个文件，所有文件都应加入同一个 FileSet。表格可以作为排查时的最小检查清单：

常见问题

为什么不能直接把 token.Pos 打印成行号？

token.Pos 只是文件集合中的位置标识，行列信息由 token.FileSet 的文件和行表解释。直接打印它只能得到偏移语义不明确的整数。

ParseFile 失败后还能使用返回的 AST 吗？

语法错误时可能得到部分 AST，但它只适合容错分析。需要完整语法树的工具应先处理错误，再决定是否接受部分节点。

什么时候应该使用 PositionFor(pos, false)？

当日志、诊断或编辑器跳转必须对应原始源码文件，而不希望被 //line 映射改写时使用；面向用户的生成代码诊断则通常还需要保留调整后位置。

我现在的处理顺序是固定的：语法错误先展开 ErrorList，AST 命中再通过原始 FileSet 映射，遇到行指令同时输出两套坐标。这样既能保留 Go 工具链的原始信息，也能让错误提示真正落到读者可以打开的文件和行列上。