我已经为一个学校项目涉足 Go 大约一个月了，我注意到 src/pkg/go 文件夹中的 go/ast、go/token、go/parser 等包。但是，gc 编译器基于位于 src/cmd/gc 中的 C 文件。
我的问题是关于 Go1 中构建和运行程序的新 go 命令：这个工具是否依赖于我上面引用的包？即，如果我向 /go/token/token.go 添加了一个新令牌，新的 go 编译器会识别它吗？
问问题
368 次
3 回答
5
Go 编译器是用纯 C 编写的，不使用go/. 在 Go 源代码树中，其词法分析器位于 src/cmd/gc/lex.c 中，其 Bison 语法为 src/cmd/gc/go.y。
这些go/包用于 godoc、gofmt 等工具和各种 go 工具子命令。也许有一天它们也可以用来在 Go 中编写 Go 编译器，但还没有人在这条路上走得很远。
于 2012-04-21T22:00:30.563 回答
2
注意（2013 年 12 月 18 日），有计划将编译器从 C 移动到 Go 本身：
“ Go 1.3+ 编译器大修”（Russ Cox）
在这种情况下，将涉及像 go/parser 这样的包，并且“第 5 阶段”提到：
go/parser用最新的（也许是新的）版本和替换前端go/types。
Robert Griesemer 讨论了在某个时候设计新的APIgo/parser和go/typesAPI 的可能性，基于对当前 API 的经验（并使用新名称，以保持 Go 1 的兼容性）。
将它们连接到编译器后端的工作可能有助于指导新 API 的设计。
这可能是语言变得多么稳定的一个证明，因为之前提到的旧“ A Tour of Go ”（2012 年 6 月）明确指出：
Go 本身不是编写的这一事实也使得进行重大语言更改变得更加容易。
在最初的发布之前，我们经历了一些大规模的语法剧变，我很高兴我们不必担心我们将如何重新启动编译器或确保在这些更改期间某种向后兼容性。
当时（再次，2012 年 6 月）提到的问题“有没有计划在 Go 中引导 Go，在 Go 中编写 Go 编译器？ ”：
没有立即的计划。Go 确实附带了一个用 Go 编写的 Go 程序解析器，所以第一个部分已经完成，并且有一个实验性的类型检查器正在开发中，但主要用于编写程序分析工具。
我过去曾研究过自举语言，我发现自举不一定适合经常变化的语言。它让我想起了攀登悬崖并偶尔将钩子拧入悬崖以在你跌倒时抓住你。
于 2013-12-19T14:00:44.633 回答
1
这个工具是否依赖于我上面引用的包？
'go' 工具确实依赖于这些包
如果我在 /go/token/token.go 中添加了一个新的令牌，它会被新的 go 编译器识别吗？
不。
于 2012-04-21T18:29:06.833 回答