C++ LLVM中编译单元的正确抽象是什么？

在LLVM中，我们有

LLVMContext

，它是存储单元，我们有

LLVM:：Module

，它是构建新符号（函数和类型）的地方

我的问题是,；编译单元使用的正确llvm抽象是什么？

模块是否为

？或者这实际上意味着更大的范围，即：共享库目标

在我看来，编译单元必须满足要么全有要么全无的结果；它编译所有内容时没有错误，或者存在错误，需要修复并重新构建，然后CU中的任何符号才可用。在我看来，这就是编译单元应该代表什么的定义

如果模块是CU的正确抽象，我如何将其他（正确编译的）

module

对象中的符号呈现给即将构建的新模块，以便它能够找到这些符号？我是否需要添加声明，或者是否有其他加速方法

---

在

clang

中指向相关行的一点将非常有帮助

模块是编译单元的正确抽象。您可以将模块链接在一起，从那里进行整个程序分析。

这是一个正在进行的尝试，旨在回答我自己的问题：

该类能够获取多个模块并返回包含现有模块中所有符号的单个复合模块。在完成链接并创建复合模块之后，我仍然不清楚关于输入模块所有权的规则是什么

在任何情况下，该类都应该允许您采用增量路径来增长模块。假设您正在尝试实现REPL，这意味着您将向全局命名空间添加新符号：

REPL的大纲如下所示：

• 在REPL中编写一些函数
• 将函数编译为单个模块，称之为“base”
• 在REPL中编写更多函数
• 在新模块中编译新函数
• 如果新函数模块编译成功，请将“base”链接到新模块中的新模块，并将其称为“base.2”
• 冲洗并重复
  如果按名称替换符号或函数，则希望旧符号可以看到符号的替代版本。因此，在定义新函数时，您需要确保在现有的“基本”模块和新模块中都调用了

  getOrInsertFunction

---

您描述的是链接器问题，而不是编译器问题。

clang

本身与此无关。您需要查看LLVM中的链接位。并非所有符号解析都可以延迟到链接阶段，特别是在类型的情况下。在任何情况下，我关心llvm——我只提到clang，因为它是规范化的客户机示例理想情况下，您永远不会将编译单元作为任何编译器的一部分。因此，我认为它们没有正确的抽象。@DeadMG，你能详细说明你的断言吗？“CU不应该是任何编译器的一部分”是什么意思？我在另一个问题中添加了更多的上下文：