[all-commits] [llvm/llvm-project] 153211: [clang] Frontend: Destroy compiling compiler insta...

[Anthony Latsis via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1532116a25573bfc12a43894928974cddb8660e1
      https://github.com/llvm/llvm-project/commit/1532116a25573bfc12a43894928974cddb8660e1
  Author: Anthony Latsis <aqamoss3fan2010 at gmail.com>
  Date:   2025-08-29 (Fri, 29 Aug 2025)

  Changed paths:
    M clang/lib/Frontend/CompilerInstance.cpp

  Log Message:
  -----------
  [clang] Frontend: Destroy compiling compiler instance before read (#154455)

Upstreams https://github.com/swiftlang/llvm-project/pull/10943.

https://github.com/llvm/llvm-project/pull/134887 added a clone for the
compiler instance in `compileModuleAndReadASTImpl`, which would then be
destroyed *after* the corresponding read in the importing instance.

Swift has a `SwiftNameLookupExtension` module extension which updates
(effectively) global state - populating the lookup table for a module on
read and removing it when the module is destroyed.

With newly cloned instance, we would then see:
  - Module compiled with cloned instance
  - Module read with importing instance
  - Lookup table for that module added
  - Cloned instance destroyed
  - Module from that cloned instance destroyed
  - Lookup table for that module name removed

Depending on the original semantics is incredibly fragile, but for now
it's good enough to ensure that the read in the importing instance is
after the cloned instanced is destroyed. Ideally we'd only ever add to
the lookup tables in the original importing instance, never its clones.

Co-authored-by: Ben Barham <ben_barham at apple.com>



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