[all-commits] [llvm/llvm-project] 10b965: [Clang] ASTUnit should use the CompilerInstance's ...

[Sirraide via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 10b965f0788ac4cf9a2c9ebd6c65d433aad19729
      https://github.com/llvm/llvm-project/commit/10b965f0788ac4cf9a2c9ebd6c65d433aad19729
  Author: Sirraide <aeternalmail at gmail.com>
  Date:   2026-07-10 (Fri, 10 Jul 2026)

  Changed paths:
    M clang/lib/Frontend/ASTUnit.cpp
    M clang/unittests/Frontend/ASTUnitTest.cpp

  Log Message:
  -----------
  [Clang] ASTUnit should use the CompilerInstance's CodeGenOptions (#195338)

Currently, `ASTUnit::LoadFromCompilerInvocation()` just calls the
constructor of `ASTUnit`, which default-constructs a `CodeGenOptions`
instance. The options from the `CompilerInstance` are never actually
saved in the `ASTUnit`. As a result, serialising the `ASTUnit` ends up
serialising the default-constructed `CodeGenOptions` rather than the
_actual_ `CodeGenOptions`.

This is problematic if you attempt to do the following:
1. Call e.g. `buildASTFromCodeWithArgs()` to build an `ASTUnit`
2. Serialise that `ASTUnit`.
3. Call e.g. `buildASTFromCodeWithArgs()` again with the exact same
arguments and add use the first `ASTUnit` as a PCH using `-include-pch`.

This causes Clang to error because the `CodeGenOptions` we deserialised
for the first `ASTUnit` (the default-constructed ones) are incompatible
with the `CodeGenOptions` implicitly created for the second TU (which
were created by the `CompilerInstance` and potentially modified due to
command-line argument parsing)... despite the fact that we basically
just attempted to build two TUs with the same arguments.

To fix this, copy the `CodeGenOptions` from the `CompilerInstance` into
the `ASTUnit`.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications