Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5 |
|
#
cb2289f3 |
| 15-Nov-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++20] [Modules] Attach implicitly declared allocation funcitons to global module fragment
[basic.stc.dynamic.general]p2 says: > The library provides default definitions for the global allocation >
[C++20] [Modules] Attach implicitly declared allocation funcitons to global module fragment
[basic.stc.dynamic.general]p2 says: > The library provides default definitions for the global allocation > and deallocation functions. Some global allocation and > deallocation > functions are replaceable ([new.delete]); these are attached to > the global module ([module.unit]).
But we didn't take this before and the implicitly generated functions will live in the module purview if we're compiling a module unit. This is bad since the owning module will affect the linkage of the declarations. This patch addresses this.
Closes https://github.com/llvm/llvm-project/issues/58560
show more ...
|