Bug 1941482 - Enable Clang 20 support for Firefox with Windows plugin fixes r=glandium

This change adds support for building Firefox with Clang 20, including
critical fixes for the clang-plugin dynamic linking on Windows.

Clang 20 introduced two breaking changes that prevented the clang-plugin
from loading on Windows:

1. The CLANG_ABI macro was added to Attr classes, causing inline methods
   like classof() and getAnnotation() to generate dllimport references.
   This fails because these methods are defined inline in headers, not
   exported from the DLL.

2. The extract_symbols.py script became more aggressive in filtering
   symbols, blocking Registry<T> static data members (Head/Tail) that
   don't match function signature patterns.

The fix consists of two patches for the Clang 20 build:

- plugin-registry-symbols_clang_20-llvm-pr-163391.patch:

  Make extract_symbols.py recognize and export Registry<T>::Head and
  ::Tail static members for any Registry instantiation.

  References Registry<PluginASTAction>::add_node() and ::begin() to force
  the linker to include these symbols.

  See llvm/llvm-project#163367 and
  llvm/llvm-project#163391.

- remove-clang-abi-from-attrs_clang_20.patch: Removes the CLANG_ABI
  macro from Attr class generation to prevent dllimport issues with
  inline methods in Windows.

  See llvm/llvm-project#163349.

Differential Revision: https://phabricator.services.mozilla.com/D268255

Author: zond

build/build-clang/clang-20.json

@@ -12,6 +12,8 @@
         "llvmorg-22-init-4745-gbe179d069664.patch",
         "android-hardware-buffer-header-workaround.patch",
         "arm64e-hack.patch",
-        "compiler-rt-rss-limit-heap-profile.patch"
+        "compiler-rt-rss-limit-heap-profile.patch",
+        "plugin-registry-symbols-llvm-pr-163391.patch",
+        "remove-clang-abi-from-attrs-clang-20.patch"
     ]
 }

build/build-clang/plugin-registry-symbols-llvm-pr-163391.patch

@@ -0,0 +1,62 @@
+Fix plugin registry symbols not exported/linked with CLANG_LINK_CLANG_DYLIB.
+
+When building LLVM with CLANG_LINK_CLANG_DYLIB=ON on Windows, external plugins
+cannot register through llvm::Registry<clang::PluginASTAction> due to two issues:
+
+1. Static data members (Head, Tail) are filtered out during symbol export by
+   extract_symbols.py because they don't match function signature patterns.
+
+2. Static methods (add_node(), begin()) exist in libraries but aren't linked
+   into clang.exe because they're unreferenced by the driver.
+
+This patch fixes both issues by adding pattern matching to recognize Registry
+symbols for export and by adding C++ code to force linking of Registry methods.
+
+See https://github.com/llvm/llvm-project/issues/163367
+
+diff --git a/clang/tools/driver/driver.cpp b/clang/tools/driver/driver.cpp
+index 00c00cea16f4..d2622e679a47 100644
+--- a/clang/tools/driver/driver.cpp
++++ b/clang/tools/driver/driver.cpp
+@@ -55,6 +55,25 @@
+ #include <set>
+ #include <system_error>
+ 
++#if defined(CLANG_PLUGIN_SUPPORT) && defined(_WIN32)
++#include "clang/Frontend/FrontendPluginRegistry.h"
++
++// Force plugin registry symbols into clang.exe on Windows so plugins can
++// register. These methods exist in libraries but aren't linked by default
++// because they're unreferenced. Taking their addresses forces the linker to
++// include them.
++namespace {
++void ForcePluginRegistrySymbols() {
++  using PluginRegistry = llvm::Registry<clang::PluginASTAction>;
++  // Use volatile to prevent the compiler from optimizing away these references
++  volatile auto add_node_ptr = &PluginRegistry::add_node;
++  volatile auto begin_ptr = &PluginRegistry::begin;
++  (void)add_node_ptr;
++  (void)begin_ptr;
++}
++} // anonymous namespace
++#endif
++
+ using namespace clang;
+ using namespace clang::driver;
+ using namespace llvm::opt;
+diff --git a/llvm/utils/extract_symbols.py b/llvm/utils/extract_symbols.py
+index 388723421d66..72f992f560c7 100755
+--- a/llvm/utils/extract_symbols.py
++++ b/llvm/utils/extract_symbols.py
+@@ -105,6 +105,11 @@ def should_keep_microsoft_symbol(symbol, calling_convention_decoration):
+     # Skip X86GenMnemonicTables functions, they are not exposed from llvm/include/.
+     elif re.match(r"\?is[A-Z0-9]*@X86@llvm", symbol):
+         return None
++    # Keep Registry<T>::Head and Registry<T>::Tail static members for plugin support.
++    # Pattern matches: ?Head@?$Registry@<template_args>@llvm@@ or ?Tail@?$Registry@...
++    elif ("?$Registry@" in symbol and "@llvm@@" in symbol and
++          (symbol.startswith("?Head@") or symbol.startswith("?Tail@"))):
++        return symbol
+     # Keep mangled llvm:: and clang:: function symbols. How we detect these is a
+     # bit of a mess and imprecise, but that avoids having to completely demangle
+     # the symbol name. The outermost namespace is at the end of the identifier

build/build-clang/remove-clang-abi-from-attrs-clang-20.patch

@@ -0,0 +1,31 @@
+Remove CLANG_ABI macro from generated Attr classes on Windows only.
+
+Clang 20 added CLANG_ABI (__declspec(dllimport)) to Attr classes, but on Windows
+this breaks inline methods like classof() and getAnnotation() in plugins because
+they are defined in headers and can't be imported. This change generates code
+that conditionally removes CLANG_ABI on Windows at compile time, keeping it for
+other platforms.
+
+diff --git a/clang/utils/TableGen/ClangAttrEmitter.cpp b/clang/utils/TableGen/ClangAttrEmitter.cpp
+index de12c7062666..53bdf76ca96d 100644
+--- a/clang/utils/TableGen/ClangAttrEmitter.cpp
++++ b/clang/utils/TableGen/ClangAttrEmitter.cpp
+@@ -2722,10 +2722,15 @@ static void emitAttributes(const RecordKeeper &Records, raw_ostream &OS,
+         Inheritable = true;
+     }
+ 
+-    if (Header)
+-      OS << "class CLANG_ABI " << R.getName() << "Attr : public " << SuperName
++    if (Header) {
++      // On Windows, CLANG_ABI causes issues with inline methods in plugins
++      OS << "class "
++         << "#ifndef _WIN32\n"
++         << "CLANG_ABI "
++         << "#endif\n"
++         << R.getName() << "Attr : public " << SuperName
+          << " {\n";
+-    else
++    } else
+       OS << "\n// " << R.getName() << "Attr implementation\n\n";
+ 
+     std::vector<const Record *> ArgRecords = R.getValueAsListOfDefs("Args");