llvm-project

c3e7624a - [clang] Add implicit std::align_val_t to std namespace DeclContext for module merging (#187347)

[clang] Add implicit std::align_val_t to std namespace DeclContext for module merging (#187347) When a virtual destructor is encountered before any module providing std::align_val_t is loaded, DeclareGlobalNewDelete() implicitly creates a std::align_val_t EnumDecl. However, this EnumDecl was not added to the std namespace's DeclContext -- it was only stored in the Sema::StdAlignValT field. Later, when a module containing an explicit std::align_val_t definition is loaded, ASTReaderDecl::findExisting() attempts to find the implicit decl via DeclContext::noload_lookup() on the std namespace. Since the implicit EnumDecl was never added to that DeclContext, the lookup fails, and the two align_val_t declarations are not merged into a single redeclaration chain. This results in two distinct types both named std::align_val_t. The implicitly declared operator delete overloads (also created by DeclareGlobalNewDelete) use the implicit align_val_t type for their aligned-deallocation parameter. When module code (e.g. std::allocator:: deallocate) calls __builtin_operator_delete with the module's align_val_t, overload resolution fails because the two align_val_t types are not the same, producing: error: no matching function for call to 'operator delete' note: no known conversion from 'std::align_val_t' to 'std::align_val_t' The fix adds the implicit align_val_t EnumDecl to the std namespace DeclContext via getOrCreateStdNamespace()->addDecl(AlignValT), so the module merger can find it via noload_lookup and merge the two declarations. This bug was exposed by a libc++ change (2b01e7cf2b70) that removed the #include <__new/global_new_delete.h> line from allocate.h, which meant modules no longer had explicit operator delete declarations to paper over the type mismatch. Assisted-by: Claude Code