Work around issue with clang implicit instantiation in C++20 mode.

GaudiHandleBase has a virtual destructor which is declared with `=default'. However. in C++20 mode, clang will then try to instiantiate all the virtual functions for classes derived from this whenever the declarations for those classes are seen. The upshot is that then using Gaudi handles with forward-declared classes doesn't work (even if the handle is only declared in the header but not used in any way).

It turns out that we can avoid this behavior by changing the declaration of the base class destructor to say {}' instead of =default'. (This is perhaps a clang bug, but the standard is not very clear on exactly when virtual members of the templated class are required to be or not to be implicitly instantiated.)

This is needed to fix many errors in the ATLAS C++20 clang build. See also ATLINFR-5113.

changed title from Work around issue with clang implicit instantiation in C++ mode. to Work around issue with clang implicit instantiation in C++20 mode.

added lhcb-gaudi-head label

changed milestone to %v37r1

• [2023-10-28 00:03] Validation started with lhcb-gaudi-head#3728
• [2023-10-28 00:07] Validation started with lhcb-run2-gaudi-head#639
• [2023-10-28 00:12] Validation started with lhcb-sim10-gaudi-head#419

The issue with the website CI job is that this MR is based on an older version of Gaudi. The latest versions of .gilab-ci.yml fix the version of Python, but this does not and (most probably) a change in the default Python docker image (now on Python 3.12) must clash with the job.

I'll rebase the MR and if the CI pipeline passes I'll merge.

added 118 commits

• 18f33007...a69fcfa6 - 117 commits from branch gaudi:master
• 0c541ffa - Work around issue with clang implicit instantiation in C++ mode.

Compare with previous version

approved this merge request

enabled an automatic merge when the pipeline for 0c541ffa succeeds

merged

mentioned in commit 28af5b55