[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.2' - sc/source

Stephan Bergmann (via logerrit) logerrit at kemper.freedesktop.org
Fri May 1 21:34:24 UTC 2020


 sc/source/core/opencl/formulagroupcl.cxx |   19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

New commits:
commit b8c1399761f80708062a492248692514616c6a58
Author:     Stephan Bergmann <sbergman at redhat.com>
AuthorDate: Tue Nov 19 16:32:49 2019 +0100
Commit:     Tor Lillqvist <tml at collabora.com>
CommitDate: Fri May 1 23:33:51 2020 +0200

    Extend loplugin:external to warn about classes
    
    (Just for one source file, unlike the original commit.)
    
    ...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.
    
    Original Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
    
    Change-Id: Idbb47dac7dfa1029da603c716ccc3a1d35687ea6
    Reviewed-on: https://gerrit.libreoffice.org/83239
    Tested-by: Jenkins
    Reviewed-by: Stephan Bergmann <sbergman at redhat.com>
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93247
    Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice at gmail.com>
    Reviewed-by: Tor Lillqvist <tml at collabora.com>

diff --git a/sc/source/core/opencl/formulagroupcl.cxx b/sc/source/core/opencl/formulagroupcl.cxx
index 6ba5ba23d6e9..14feb0d0a7a2 100644
--- a/sc/source/core/opencl/formulagroupcl.cxx
+++ b/sc/source/core/opencl/formulagroupcl.cxx
@@ -267,6 +267,8 @@ size_t VectorRef::Marshal( cl_kernel k, int argno, int, cl_program )
 /// automatically disables use of OpenCL for a formula group. If at some point there are resources
 /// to drain the OpenCL swamp, this should go away.
 
+namespace {
+
 class ConstStringArgument : public DynamicKernelArgument
 {
 public:
@@ -797,6 +799,8 @@ public:
     virtual size_t Marshal( cl_kernel, int, int, cl_program ) override;
 };
 
+}
+
 /// Marshal a string vector reference
 size_t DynamicKernelStringArgument::Marshal( cl_kernel k, int argno, int, cl_program )
 {
@@ -886,6 +890,8 @@ size_t DynamicKernelStringArgument::Marshal( cl_kernel k, int argno, int, cl_pro
     return 1;
 }
 
+namespace {
+
 /// A mixed string/numberic vector
 class DynamicKernelMixedArgument : public VectorRef
 {
@@ -1230,6 +1236,8 @@ private:
     std::vector<DynamicKernelArgumentRef> mParams;
 };
 
+}
+
 void SymbolTable::Marshal( cl_kernel k, int nVectorWidth, cl_program pProgram )
 {
     int i = 1; //The first argument is reserved for results
@@ -1239,6 +1247,8 @@ void SymbolTable::Marshal( cl_kernel k, int nVectorWidth, cl_program pProgram )
     }
 }
 
+namespace {
+
 /// Handling a Double Vector that is used as a sliding window input
 /// Performs parallel reduction based on given operator
 template<class Base>
@@ -2234,7 +2244,7 @@ public:
     }
     virtual std::string BinFuncName() const override { return "fsop"; }
 };
-namespace {
+
 struct SumIfsArgs
 {
     explicit SumIfsArgs(cl_mem x) : mCLMem(x), mConst(0.0) { }
@@ -2242,7 +2252,6 @@ struct SumIfsArgs
     cl_mem mCLMem;
     double mConst;
 };
-}
 
 /// Helper functions that have multiple buffers
 class DynamicKernelSoPArguments : public DynamicKernelArgument
@@ -2533,6 +2542,8 @@ private:
     cl_mem mpClmem2;
 };
 
+}
+
 static DynamicKernelArgumentRef SoPHelper( const ScCalcConfig& config,
     const std::string& ts, const FormulaTreeNodeRef& ft, SlidingFunctionBase* pCodeGen,
     int nResultSize )
@@ -3667,6 +3678,8 @@ DynamicKernelSoPArguments::DynamicKernelSoPArguments(const ScCalcConfig& config,
     }
 }
 
+namespace {
+
 class DynamicKernel : public CompiledFormula
 {
 public:
@@ -3707,6 +3720,8 @@ private:
     int const mnResultSize;
 };
 
+}
+
 DynamicKernel::DynamicKernel( const ScCalcConfig& config, const FormulaTreeNodeRef& r, int nResultSize ) :
     mCalcConfig(config),
     mpRoot(r),


More information about the Libreoffice-commits mailing list