go/packages.Load() 返回多种类型

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《go/packages.Load() 返回多种类型》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

我试图确定两种类型是否与 go/types.identical 相同，令人惊讶的是，不同 packages 返回的同一代码段的类型总是不同的。load 调用总是不同的。

我对这些 api 做出了错误的假设吗？

package main

import (
    "fmt"
    "go/types"

    "golang.org/x/tools/go/packages"
)

func getTimeTime() *types.Named {
    pkgs, err := packages.Load(&packages.Config{
        Mode: packages.NeedImports | packages.NeedSyntax | packages.NeedTypes | packages.NeedDeps | packages.NeedTypesInfo,
        Overlay: map[string][]byte{
            "/t1.go": []byte(`package t
            import "time"
            var x time.Time`),
        },
    }, "file=/t1.go")
    if err != nil {
        panic(err)
    }
    for _, v := range pkgs[0].TypesInfo.Types {
        return v.Type.(*types.Named) // named type of time.Time
    }
    panic("unreachable")
}

func main() {
    t1, t2 := getTimeTime(), getTimeTime()
    if !types.Identical(t1, t2) {
        fmt.Println(t1, t2, "are different")
    }
}

正确答案

显然，有一个隐藏文档解释了所有这些（它不附加任何内容，因此不在 godoc 上）：https://cs.opensource.google/go/x/tools/+/master:go/packages/doc.go;l=75

动机和设计考虑因素

新包装的设计解决了两个现有的问题 packages：go/build，它定位并描述包，以及 golang.org/x/tools/go/loader，加载、解析和类型检查 他们。 go/build.Package 结构编码了太多的 'go build' 组织项目的方式，让我们需要一种数据类型 描述了独立于 Go 源代码的包 底层构建系统。我们想要同样有效的东西 使用 go build 和 vgo，以及其他构建系统，例如 Bazel 和 Blaze，使得构建适用于所有环境的分析工具成为可能 这些环境。 errcheck 和 staticcheck 等工具 Google 的 Go 社区基本上无法使用，并且某些 Google 的 Go 内部工具无法在外部使用。这个新的 package提供了统一的方式通过查询获取包元数据 这些构建系统中的每一个都可以选择支持它们的首选 包的命令行符号，以便工具可以整齐地集成 与用户的构建环境。元数据查询函数执行 适合当前工作区的外部查询工具。

加载包总是返回完整的导入图“一路 down”，即使您想要的只是有关单个包裹的信息， 因为我们目前所有构建系统的查询机制 支持（{go,vgo} 列表和 blaze/bazel 基于方面的查询）不能 提供有关一个包的详细信息，而无需访问所有包 它也有依赖性，因此没有额外的渐近成本 提供传递信息。 （此属性可能不正确 假设的第五构建系统。）

在对 TypeCheck 的调用中，所有初始包以及任何 传递依赖于其中之一，必须从源加载。 考虑 A->B->C->D->E：如果 A，C 是初始的，则 A，B，C 必须从加载 来源; D 可以从导出数据加载，E 可以不加载 全部（尽管 D 的导出数据可能提到了它，所以 types.Package 可以为其创建并公开。）

旧的加载程序具有抑制函数类型检查的功能 基于每个包的主体，主要是为了减少工作量 获取导入包的类型信息。现在进口 导出数据满意，优化似乎不再 必要的。

尽管进行了一些早期尝试，旧的加载程序并未利用导出 数据，而不是始终使用相当于 WholeProgram 模式。这 是由于混合源数据包和导出数据包的复杂性造成的 （现在通过上面提到的向上遍历来解决），并且因为 导出数据文件几乎总是丢失或过时。现在就去吧 build'支持缓存，所有底层构建系统都可以 保证在合理（摊销）时间内生成出口数据。

现在报告由构建系统合成的测试“主”包 作为一流的套餐，避免了客户的需要（例如 go/ssa）来重新发明这个生成逻辑。

go/packages 比旧的加载器更简单的一种方式是它的 包装内测试的处理。包内测试是那些 包含被测库的所有文件以及测试 文件。旧的加载程序通过两阶段构建包内测试 突变的过程称为“增强”：首先它会构建 并类型检查所有普通库包并类型检查 依赖于它们的包；然后它会添加更多（测试）文件到 再次对包装进行类型检查。这种两阶段方法有四个 主要问题：1）在处理测试时，加载器修改了 库包，客户端应用程序无法看到 测试包和库包；一个会变异 进入另一个。 2）因为测试文件可以声明额外的方法 对于包的库部分中定义的类型， 库部分中方法调用的调度受到 测试文件的存在。这应该是一个线索 包在逻辑上是不同的。 3）这种“增强”模型 假设每个库包最多有一个包内测试，即 对于使用“go build”的项目来说是这样，但其他构建系统则不然。 4） 由于测试处理的两阶段性质，所有包 导入库包必须在扩充之前进行处理，
强制使用“一次性”API 并阻止客户端调用 Load
现在在 WholeProgram 模式下可以按顺序进行多次。 （TypeCheck 模式对于不同的情况具有类似的一次性限制 原因。）

该软件包的早期草案支持“多重拍摄”操作。 尽管它允许客户端进行一系列调用（或并发调用） 调用）到 Load，逐步构建包图，它 具有边际价值：它使 API 变得复杂（因为它允许一些 选项会因调用而变化，但不会因其他调用而变化），这使 实现，它不能在类型模式下工作，如所解释的 如上所述，它的效率低于进行一次组合调用（当 这个有可能）。在我们考察过的客户中，没有一个 多次调用加载但不能轻松且令人满意 修改为仅进行一次调用。但是，应用程序可能会发生变化 需要。例如，ssadump 命令加载用户指定的 包以及运行时包。这是很诱人的 只需将“运行时”附加到用户提供的列表中，但这并不 如果用户指定了一个临时包，例如 [a.go b.go]，则可以工作。 相反，ssadump 不再请求运行时包，而是寻找它 在用户指定的包的依赖项之间，并发出一个 如果没有找到则出错。

好了，本文到此结束，带大家了解了《go/packages.Load() 返回多种类型》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！