Extend loplugin:external to warn about classes

...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".

Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:

filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx

All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage.  (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)

For friend declarations using elaborate type specifiers, like

class C1 {};
class C2 { friend class C1; };

* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")

* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".

Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace.  But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".

Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.

And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.

And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is.  GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>)  The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.

Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

1 files changed, 24 insertions, 0 deletions

diff --git a/sal/rtl/digest.cxx b/sal/rtl/digest.cxx
index 1000fc0aed02..55af5ad7c3b2 100644
--- a/sal/rtl/digest.cxx
+++ b/sal/rtl/digest.cxx
@@ -52,6 +52,8 @@ typedef rtlDigestError (Digest_update_t) (
 typedef rtlDigestError (Digest_get_t) (
     void *ctx, sal_uInt8 *Buffer, sal_uInt32 BufLen);
 
+namespace {
+
 struct Digest_Impl
 {
     rtlDigestAlgorithm  m_algorithm;
@@ -63,6 +65,8 @@ struct Digest_Impl
     Digest_get_t       *m_get;
 };
 
+}
+
 static void swapLong(sal_uInt32 *pData, sal_uInt32 nDatLen)
 {
     sal_uInt32 *X;
@@ -175,6 +179,8 @@ void SAL_CALL rtl_digest_destroy(rtlDigest Digest) SAL_THROW_EXTERN_C()
 #define DIGEST_CBLOCK_MD2 16
 #define DIGEST_LBLOCK_MD2 16
 
+namespace {
+
 struct DigestContextMD2
 {
     sal_uInt32 m_nDatLen;
@@ -189,6 +195,8 @@ struct DigestMD2_Impl
     DigestContextMD2 m_context;
 };
 
+}
+
 static void initMD2   (DigestContextMD2 *ctx);
 static void updateMD2 (DigestContextMD2 *ctx);
 static void endMD2    (DigestContextMD2 *ctx);
@@ -437,6 +445,8 @@ void SAL_CALL rtl_digest_destroyMD2(rtlDigest Digest) SAL_THROW_EXTERN_C()
 #define DIGEST_CBLOCK_MD5 64
 #define DIGEST_LBLOCK_MD5 16
 
+namespace {
+
 struct DigestContextMD5
 {
     sal_uInt32 m_nDatLen;
@@ -451,6 +461,8 @@ struct DigestMD5_Impl
     DigestContextMD5 m_context;
 };
 
+}
+
 static void initMD5 (DigestContextMD5 *ctx);
 static void updateMD5 (DigestContextMD5 *ctx);
 static void endMD5 (DigestContextMD5 *ctx);
@@ -824,6 +836,8 @@ typedef sal_uInt32 DigestSHA_update_t(sal_uInt32 x);
 static sal_uInt32 updateSHA_0(sal_uInt32 x);
 static sal_uInt32 updateSHA_1(sal_uInt32 x);
 
+namespace {
+
 struct DigestContextSHA
 {
     DigestSHA_update_t *m_update;
@@ -839,6 +853,8 @@ struct DigestSHA_Impl
     DigestContextSHA m_context;
 };
 
+}
+
 static void initSHA(
     DigestContextSHA *ctx, DigestSHA_update_t *fct);
 
@@ -1390,6 +1406,8 @@ void SAL_CALL rtl_digest_destroySHA1(rtlDigest Digest) SAL_THROW_EXTERN_C()
 
 #define DIGEST_CBLOCK_HMAC_MD5 64
 
+namespace {
+
 struct ContextHMAC_MD5
 {
     DigestMD5_Impl m_hash;
@@ -1402,6 +1420,8 @@ struct DigestHMAC_MD5_Impl
     ContextHMAC_MD5 m_context;
 };
 
+}
+
 static void initHMAC_MD5(ContextHMAC_MD5 * ctx);
 static void ipadHMAC_MD5(ContextHMAC_MD5 * ctx);
 static void opadHMAC_MD5(ContextHMAC_MD5 * ctx);
@@ -1586,6 +1606,8 @@ void SAL_CALL rtl_digest_destroyHMAC_MD5(rtlDigest Digest) SAL_THROW_EXTERN_C()
 
 #define DIGEST_CBLOCK_HMAC_SHA1 64
 
+namespace {
+
 struct ContextHMAC_SHA1
 {
     DigestSHA_Impl m_hash;
@@ -1598,6 +1620,8 @@ struct DigestHMAC_SHA1_Impl
     ContextHMAC_SHA1 m_context;
 };
 
+}
+
 static void initHMAC_SHA1(ContextHMAC_SHA1 * ctx);
 static void ipadHMAC_SHA1(ContextHMAC_SHA1 * ctx);
 static void opadHMAC_SHA1(ContextHMAC_SHA1 * ctx);