Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[DF] Remove extern template function declarations
Clang 18 changed the name mangling of function templates, see https://releases.llvm.org/18.1.0/tools/clang/docs/ReleaseNotes.html#c-specific-potentially-breaking-changes The first mentioned case is "When a template parameter in a function template depends on a previous template parameter", for example: ``` struct A { template <typename T, std::enable_if_t<std::is_integral_v<T>, int> = 0> void Member(T p) {} }; template void A::Member(int); ``` With Clang < 18 and current versions of GCC, this will mangle to _ZN1A6MemberIiLi0EEEvT_, but Clang 18 and later will mangle it to _ZN1A6MemberIiTnNSt9enable_ifIXsr3stdE13is_integral_vIT_EEiE4typeELi0EEEvS2_ (unless reverted for compatibility with -fclang-abi-compat=17). For ROOT's use of Cling, this poses a bidirectional problem: * If building current master with Clang 18, the compiler will, by default, mangle according to the new rules. At runtime, Cling based on LLVM/Clang 16 will generate the old name, but that symbol cannot be found in the shared library. * Conversely, in the current attempt to upgrade to LLVM/Clang 18, the opposite situation will happen when building with an "older" compiler so the shared library has the old name. In both cases, a failure of tutorial-tmva-tmva103_Application can be observed, when Cling cannot find the symbol. Unfortunately, it is not easily possible to detect which symbol names are in the shared library because it depends on the host compiler and configuration. Furthermore, with the current LLVM/Clang 16, we do not have access to the new mangling. Finally, it is unclear if generating the template instantiations in question actually takes up significant time during compilation. As such, the best approach in the current situation is to remove the "extern template" declarations and let the compiler / Cling re-generate them as needed. Co-authored-by: Devajith Valaparambil Sreeramaswamy <[email protected]>
- Loading branch information