Golang 编译器代码浅析
  • 0. Golang 编译器代码浅析
  • 1. golang 编译器 - 前言
    • 1.1 编译器简介
    • 1.2 Golang 编译器
    • 1.3 Go 语言版本
    • 1.4 项目设置
    • 1.5 约定
    • 1.6 写作目的
  • 2. golang 编译器 - 词法分析
    • 2.1 简介
    • 2.2 代码结构
    • 2.3 处理字符
    • 2.4 扫描Token
    • 2.5 总结
  • 3.a 语法分析理论知识
    • 3A.1 语法分析简介
    • 3A.2 文法
    • 3A.3 语法解析
    • 3A.3.1 自顶向下(Top-Down)
    • 3A.3.2 自顶向下 - 递归下降
    • 3A.3.3 自顶向下 - LL(1)文法
    • 3A.3.4 自底向上(Bottom-Up)
    • 3A.3.5 自底向上 - LR(0)项集及SLR预测表
    • 3A.3.6 自底向上 - LR(1)、LALR
    • 3A.4 语法分析工具
    • 3A.5 总结
  • 3B. golang 编译器 - 语法分析
    • 3B.1 简介
    • 3B.2 代码结构
    • 3B.3 数据结构
    • 3B.4 构造语法树
    • 3B.5 Unit Test及AST可视化
  • 4. Golang 编译器 - 类型检查
    • 4.1 简介
    • 4.2 代码结构
    • 4.3 符号解析
    • 4.4.1 数据结构 - 作用域
    • 4.4.2 数据结构 - Package
    • 4.4.3 数据结构 - Object 对象
    • 4.4.4-1 类型数据结构 - 简介
    • 4.4.4-2 类型接口
    • 4.4.4-3 基础类型
    • 4.4.4-4 内置复合类型
    • 4.4.4-5 Struct 类型
    • 4.4.4-6 Interface 类型
    • 4.4.4-7 Named 类型
    • 4.4.4-8 Tuple 类型
    • 4.4.4-9 Sum 类型
    • 4.4.4-10 Function & Method 类型
    • 4.4.4-11 泛型类型
    • 4.4.4-12 类型的等价规则
    • 4.4.4-13 类型的比较规则
    • 4.4.4-14 总结
    • 4.4.5 类型检查器
    • 4.4.6 总结
    • 4.5.1 类型检查逻辑 - 包加载器
    • 4.5.2 类型检查逻辑 - 初始化
    • 4.5.2-1 全局作用域
    • 4.5.2-2 类型检查器
    • 4.5.3 类型检查逻辑 - 流程分析
    • 4.5.3-1.1 总体流程
    • 4.5.3-1.2 类型检查准备工作
    • 4.5.3-1.3 类型检查核心逻辑
    • 4.5.3-1.3a 总体介绍
    • 4.5.3-1.3b 类型表达式的类型检查
    • 4.5.3-1.3c 求值表达式的类型检查
    • 4.5.3-1.3d 类型兼容性检查
    • 4.5.3-1.3e 处理delayed队列
    • 4.5.3-1.4 构建初始化顺序
    • 4.5.3-1.5 总结
    • 4.5.3-2 特定问题分析
    • 4.5.3-2a 对象循环依赖检查
    • 4.5.3-2b 方法与属性查找
    • 4.5.3-2c Underlying Type
    • 4.6 如何测试
    • 4.7 总结
  • 5. Golang 编译器 - IR Tree
    • 5.1 简介
    • 5.2 代码结构
    • 5.3 数据结构
    • 5.4 处理逻辑
    • 5.5 编译日志
    • 5.6 Unit Test
    • 5.7 总结
  • 6. golang 编译器 - 初始化任务
    • 6.1 简介
    • 6.2 代码结构
    • 6.3 总体逻辑
    • 6.4 赋值语句
    • 6.5 编译日志
    • 6.6 Unit Test
    • 6.7 总结
  • 7. golang 编译器 - 清除无效代码
    • 7.1 简介
    • 7.2 处理逻辑
    • 7.3 Unit Test
  • 8. golang 编译器 - Inline
    • 8.1 简介
    • 8.2 Inline的问题
    • 8.3 代码结构
    • 8.4 处理逻辑
    • 8.4.1 遍历调用链
    • 8.4.2 内联判断
    • 8.4.3 内联操作
    • 8.4.4 编译日志
    • 8.4.5 Unit Test
    • 8.4.6 总结
  • 9. golang 编译器 - 逃逸分析
    • 9.1 什么是逃逸分析
    • 9.2 Go 的逃逸分析
    • 9.3 算法思路
    • 9.4 代码结构
    • 9.5 处理逻辑
    • 9.5.1总体逻辑
    • 9.5.2 数据结构
    • 9.5.3 构建数据流有向图
    • 9.5.4 逃逸分析
    • 9.6 编译日志
    • 9.7 Unit Test
    • 9.8 总结
  • 10. golang 编译器 - 函数编译及导出
    • 10.1 简介
    • 10.2 编译函数
    • 10.2.1 SSA
    • 10.2.2 ABI
    • 10.2.3 并发控制
    • 10.3 导出对象文件
    • 10.4 总结
  • 11. Golang 编译器 - 写在最后
由 GitBook 提供支持
在本页
  • 内嵌类型属性的二义性检测
  • 方法的等价性校验

这有帮助吗?

  1. 4. Golang 编译器 - 类型检查

4.5.3-2b 方法与属性查找

在两种情况下我们需要对目标类型进行属性、方法查找:

  1. 当编译器遇到形如X.sel的表达式时,其中sel可能是属性名,也可能是方法名

  2. 判断目标类型是否实现了某接口时,需要判断目标类型是否包含对应接口的所有方法

整个查找逻辑定义在文件$GCROOT/compile/internal/types2/lookup.go文件中,入口方法是lookupFieldOrMethod() 。Go 不允许方法重载(Method Overloading),并且属性与方法也能重名,所以对属性、方法查找的基本思路很简单,就是按照名字匹配就可以了。虽然如此,属性查找的逻辑仍然有一些点值得讨论:

内嵌类型属性的二义性检测

如果在类型中有重复的命名,不用等到属性查找阶段,编译器在对类型申明进行类型检查时就会发现错误,例如:

  type A struct {
      name string
      name string // Compile error: name redeclared [DuplicateDecl]
  }

  func (this *A) name() {} // Compile error: Field and method with the same name name [DuplicateFieldAndMethod]

但我们知道对于内嵌类型,Go 会提升(Promote)内嵌类型的属性,例如:

  type A struct {
      Name string
  }
  type B struct {
      A
      Addr string
  }

  func main() {
      var b B
      name := b.Name // 直接访问内嵌类型的字段
      addr := b.Addr
  }

但上述代码中 Go 并不会真的将 A 的属性 Name 抽取出来放入类型 B 中,这种“提升”其实只是一种便捷的访问方式,在对属性的查找过程中实现:如果当前类型的属性没有匹配项,则对下一级的内嵌类型进行查找,并依此逻辑递归直到查找完所有内嵌类型。这时便会面临一个问题:如果同一层级的内嵌类型有相同属性,那么编译器就不知道到底应该使用哪一个。例如代码:

  type A struct {
      Name string
  }
  type B struct {
      Name string
  }
  type C struct {
      A
      B
  }

  func main() {
      var b B
      name := b.Name // Compile error: ambigous selector b.Name [AmbigousSelector]
  }

此时编译器会提示错误,从而引导用户提供更明确的选择,例如:b.A.Name

方法的等价性校验

方法missingMethod(V Type, T Interface, static bool) (method, wrongType Func)用来判断类型V是否实现了接口T,如果返回值为 nil, 则 V 实现了接口 T; 否则返回值表示查找到的第一个 V 没有实现 T 的方法。

  • T1 (T1 匹配 map[int]bool, 或者直接用 T2 也可以)

  • map[T1]bool (T1 匹配 int)

  • map[int]T2 (T2 匹配 bool)

  • map[T1]T2 (T1 匹配 int, T2 匹配 bool)

    反过来,其无法被下述类型表示:

  • []T1

  • struct{}

  • map[T1]string

可见当引入类型参数后,在结构上不同的两个类型也可能是一个类型,所以此时的处理思路不再是一一对比,而是尝试着找到某种方法来将两个类型统一成同一个类型,从代数上理解的话,有点像寻找两个类型的公倍数。所以从实现上来说,该部分的逻辑如下:撇开类型参数,两个类型结构上必须一致,并且类型必须等价;如果有类型参数的话,那么一个类型的类型参数能够匹配另一个类型的类型参数的所有子类型。

上一页4.5.3-2a 对象循环依赖检查下一页4.5.3-2c Underlying Type

最后更新于3年前

这有帮助吗?

这里涉及到的逻辑分为两个部分:一是对于 T 中的每个方法,按照方法名在 V 中进行查找;二是如果在 V 中找到了同名方法的话,判断两个方法是否是同一个类型,即判断是否拥有一致的参数列表与返回值列表。第一部分的思路与属性的查找一致;第二部分为了支持泛型,在此处并没有使用中的等价比较算法,这里叫着类型统一(),当前的实现逻辑在文件$GCROOT/compile/internal/types2/unify.go中,入口方法是func (u *unifier) unify(x, y Type) bool {}为什么叫类型统一呢?如果将类型想象成一个树形结构(或者图)的话,那么类型的等价规则的核心思想就是比较两个类型的结构是否一致,并且各对应结点的类型是否等价。这在没有类型参数的情况下是合理的,但是类型参数的引入使得该逻辑变得不够完善。在对的讨论中我们提到过类型模版的概念,意在说明包含泛型申明的类型可以表示不同的实际类型,例如,假如 T1 与 T2 都是类型参数,那么一个实际类型map[int]bool可以用如下类型来表示:

类型的等价规则
Type unification
泛型数据结构