summaryrefslogtreecommitdiff
path: root/cppu
AgeCommit message (Collapse)AuthorFilesLines
2020-03-06Make TYPELIB_TYPEDESCRIPTIONREFERENCE_ISREALLYWEAK constexprStephan Bergmann2-11/+10
...and make dynamic verifications static where applicable Change-Id: I3fb7ebe6885ee70e493ec1365601a1177d181347 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90002 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-04Remove redundant local reallyWeak functionStephan Bergmann1-17/+12
Change-Id: Ica26c0b5a839ebb2ca8ed1e2fa61b70cd08a9278 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89974 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-24Fix typoAndrea Gelmini1-2/+2
to complete: https://gerrit.libreoffice.org/c/core/+/89082 Change-Id: I8363f05f15c8d4ef032ccc8d469dc29231d74ca7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89360 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-01-15clang-tidy modernize-concat-nested-namespace in cppcanvas..cppuhelperNoel Grandin5-11/+11
Change-Id: I0bb4ea91288a15fb590d077fb390c53be8b50400 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86801 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-07Replace a CPPUNIT_ASSERT_EQUAL with a static_assertStephan Bergmann1-4/+5
Change-Id: I8382aa13eb9c65ae61fc0dbfe440df6718133c18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86352 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18sal_Char->char in cppcanvas..cuiNoel Grandin4-13/+13
Change-Id: I7e9fa7011f1e0bf143f86055718c772caebf8ee6 Reviewed-on: https://gerrit.libreoffice.org/85397 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-03Adapt CPPUNIT_ASSERT to C++20 deleted ostream << for sal_Unicode (aka char16_t)Stephan Bergmann2-0/+2
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t backward compatibility remediation", as implemented now by <https://gcc.gnu.org/ git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++: P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads that would print an integer rather than a (presumably expected) character. But for simplicity (and to avoid issues with non-printing characters), keep printing an integer here. Change-Id: I751b99ee32d418eb488131ffa130d6f7d6d38dc7 Reviewed-on: https://gerrit.libreoffice.org/84348 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-23cppcheck: performing init in init list (comphelper/connectivity/cppu/cui)Julien Nabet1-2/+3
Change-Id: I786c2c10e8b37b48adf6d619c0fa6a905de1bf7f Reviewed-on: https://gerrit.libreoffice.org/83584 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann12-0/+72
...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>
2019-11-08Avoid repeated calls cppu::detail::loadModule -> osl_getModuleURLFromAddressStephan Bergmann1-2/+27
...where the latter are reportedly expensive. Both <https://gerrit.libreoffice.org/#/c/75162/> "tdf#121740 related, cache external mapping in cppu::loadExternal" and <https://gerrit.libreoffice.org/#/c/82261/> "tdf#121740 add cache to win osl_getModuleURLFromAddress" attempted to reduce the costs observed when loading one specific document by introducing caches below cppu::detail::loadModule's call to osl::Module::loadRelative. On the other hand, this change reduces the number of calls to osl_getModuleURLFromAddress by computing the base URI in cppu::detail::loadModule only once. For my local Linux --enable-dbgutil build, for `instdir/program/soffice '109340 class14.ppt'` and then exiting LO again (with the document attached at <https://bugs.documentfoundation.org/show_bug.cgi?id=121740#c0>), this reduces the number of calls to osl_getModuleURLFromAddress from 3775 to 22. (Many of those calls originated from cppu::getCaughtException or cppu::throwException, as in osl_getModuleURLFromAddress osl_getModuleURLFromFunctionAddress osl::Module::getUrlFromAddress osl_loadModuleRelative osl::Module::loadRelative cppu::detail::loadModule cppu::loadModule cppu::loadExternalMapping uno_getMapping com::sun::star::uno::Mapping::Mapping cppu::throwException .) Unfortunately, this needs to duplicate functionality from osl_loadModuleRelative (sal/osl/all/loadmodulerelative.cxx) somewhat, as the stable SAL interface only offers functionality to load relative to a given function, not relative to a given base URI. (And extending the stable SAL interface for this one use is not worth the maintenance costs.) Change-Id: Ib58814136d11c67d1419b0224d12e30bb710e613 Reviewed-on: https://gerrit.libreoffice.org/82290 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-28loplugin:stringadd improve detectionNoel Grandin1-2/+1
if one side of the expression is a compile-time-constant, we don't need to worry about side-effects on the other side Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b Reviewed-on: https://gerrit.libreoffice.org/81589 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-17Remaining loplugin:bufferaddStephan Bergmann3-21/+9
...that had been missing because the plugin didn't implement postRun, so it didn't report anything when run as part of the shared plugin. (But did report the expected warnings when run as a standalone plugin during CompilerTest_compilerplugins_clang.) Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old preallocation of a 20 character OStringBuffer might have prevented buf.append( reinterpret_cast<char *>(escapedString), len -1 ); from potentially throwing std::bad_alloc, which would have caused escapedString to be leaked. Even though that 20-character preallocation was likely just random junk and not meant to address the potential leak, lets address it now. Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900 Reviewed-on: https://gerrit.libreoffice.org/80925 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-15new loplugin:bufferaddNoel Grandin3-20/+17
look for OUStringBuffer append sequences that can be turned into creating an OUString with + operations Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6 Reviewed-on: https://gerrit.libreoffice.org/80809 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin2-2/+2
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-01loplugin:stringadd in basctl..cuiNoel Grandin3-18/+9
Change-Id: I2fdeb7eb3ead3512ad6d3fe793305038ab3aa7ae Reviewed-on: https://gerrit.libreoffice.org/79886 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-03Silence -fsanitize=object-size in --enable-optimized buildsStephan Bergmann1-3/+23
<http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks> (as of recent LLVM trunk towards LLVM 10) states: "-fsanitize=object-size: An attempt to potentially use bytes which the optimizer can determine are not part of the object being accessed. This will also detect some types of undefined behavior that may not directly access memory, but are provably incorrect given the size of the objects involved, such as invalid downcasts and calling methods on invalid pointers. These checks are made in terms of __builtin_object_size, and consequently may be able to detect more problems at higher optimization levels." A `make check screenshot` with --enabled-optimized runs into two such issues that were not diagnosed with --disable-optimized, in both cases because a struct with an "idiomatic trailing dynamic array member" (statically declared to be an array of size 1) is allocated without any space for that array member, as the dynamic array size is 0 in the specific case: * For > [CUT] sc_ucalc > cppu/source/uno/copy.hxx:46:19: runtime error: member access within address 0x6020001aaa70 with insufficient space for an object of type 'uno_Sequence' (aka '_sal_Sequence') > 0x6020001aaa70: note: pointer points here > 2b 00 80 6a be be be be be be be be 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ^ > #0 in cppu::allocSeq(int, int) at cppu/source/uno/copy.hxx:46:19 (instdir/program/libuno_cppu.so.3 +0x41f03f) > #1 in uno_type_sequence_reference2One at cppu/source/uno/sequence.cxx:813:20 (instdir/program/libuno_cppu.so.3 +0x41f03f) [...] the call to pNew = allocSeq( 0, 0 ); in uno_type_sequence_reference2One is inlined, so sal_uInt32 nSize = calcSeqMemSize( nElementSize, nElements ); in allocSeq is known to be too small. * For > testSignatureLineODF::TestBody finished in: 2044ms > engine-gpg.c:302:6: runtime error: member access within address 0x604001f24f10 with insufficient space for an object of type 'struct arg_and_data_s' > 0x604001f24f10: note: pointer points here > 6e 01 00 26 be be be be be be be be be be be be be be be be be be be be be be be be be be be be > ^ > #0 in add_data at workdir/UnpackedTarball/gpgmepp/src/engine-gpg.c:302:6 (instdir/program/libgpgme.so.11 +0x120c2b) [...] > make[1]: *** [solenv/gbuild/CppunitTest.mk:114: workdir/CppunitTest/xmlsecurity_signing.test] Error 1 the a = malloc (sizeof *a - 1); is apparently detected to be too small only with optimization enabled. In both cases, the solution is to operate on the too-small dynamically allocated object via a reinterpret_cast'ed pointer to some newly introduced "struct prefix" type. Change-Id: Ie814db1d00a439bb9189474b91d729e538e81984 Reviewed-on: https://gerrit.libreoffice.org/78548 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-30new loplugin:noexceptmoveNoel Grandin1-2/+2
idea from mike kaganski look for places where we can mark move operators as noexcept, which makes some STL operations more efficient Change-Id: Id732b89d1fcadd5ceb0ea2b9d159fed06136330f Reviewed-on: https://gerrit.libreoffice.org/78251 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-26cid#1448407 silence Resource leakCaolán McNamara1-0/+1
Change-Id: Ida523859077abe5904212db44108fa580bb6c60d Reviewed-on: https://gerrit.libreoffice.org/76355 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-05-22New loplugin:dataStephan Bergmann1-1/+1
...following up on 1453c2c8f13bac64ecd1981af7cebf1c421808ac "prefer vector::data to &vector[0]" Change-Id: I7c113747d92d144a521d49b89384dd8bf1215c01 Reviewed-on: https://gerrit.libreoffice.org/72765 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-04-27tdf#120703 PVS: V581 ifs with identical conditionsMike Kaganski1-11/+8
V581 The conditional expressions of the 'if' statements situated alongside each other are identical. Change-Id: I79c655a072faff0bdb2af031ed1328e684b83aac Reviewed-on: https://gerrit.libreoffice.org/71430 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-04-22Fix typoAndrea Gelmini1-1/+1
Change-Id: I9c69c6e92f04970eada7309969c3016feffcc6e0 Reviewed-on: https://gerrit.libreoffice.org/71056 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-04-15improve loplugin simplifyconstructNoel Grandin1-1/+1
to find stuff like OUString s = OUString("xxx") Change-Id: Ie7ed074c1ae012734c67a2a89c564c1900a4ab04 Reviewed-on: https://gerrit.libreoffice.org/70697 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-01tdf#120703 PVS: Silence V522 warningsMike Kaganski1-0/+7
V522 There might be dereferencing of a potential null pointer. Change-Id: Ie617b41a8f8d334022cf5313b242a236baedba48 Reviewed-on: https://gerrit.libreoffice.org/70017 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-03-03Simplify containers iterations in cppcanvas, cppu, cppuhelperArkadiy Illarionov4-62/+30
Use range-based loop or replace with STL functions Change-Id: I72bf7cdb632c04e2fc8d4f7ab85cb6571222aa07 Reviewed-on: https://gerrit.libreoffice.org/68636 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-03-02Fix typoAndrea Gelmini1-1/+1
Change-Id: Ib5409a3c9b22bf0caf950905a75559bdef8b057f Reviewed-on: https://gerrit.libreoffice.org/68612 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-02-20More loplugin:simplifyboolStephan Bergmann1-1/+1
...found with (trunk) libc++ on macOS, where the standard library iterator implementations are apparently sufficiently different to libstdc++ to find more cases of !(... == ...) vs. ... != ... Change-Id: Ia3861406aa584c7b1d33f47448190b5cf2e770f7 Reviewed-on: https://gerrit.libreoffice.org/68089 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-19Some uses of C++17 class template argument deductionStephan Bergmann1-1/+1
Change-Id: I47c469c0fcdff41d83729be9489c946e81ef3686 Reviewed-on: https://gerrit.libreoffice.org/68020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-19More loplugin:simplifyboolStephan Bergmann1-1/+1
...found with GCC 9, where the standard library iterator implementations are apparently sufficiently different to older versions of GCC to find more cases of !(... == ...) vs. ... != ... Change-Id: Ibe7c5140049a69d2c5318b4b2371f2e66bd05028 Reviewed-on: https://gerrit.libreoffice.org/68012 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-08loplugin:indentation in cppu..cuiNoel Grandin3-8/+8
Change-Id: If625e5bf38ca8e1f12686038c7c9be8d0303b6f6 Reviewed-on: https://gerrit.libreoffice.org/67536 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-29cppu: fix Android buildMiklos Vajna2-0/+8
By restoring includes which are still needed, conditionally. Change-Id: Icc331c7d6a084af7d93b941ea879f0c60b9ca9f3
2019-01-29tdf#42949 Fix IWYU warnings in cppu/Gabor Kelemen26-59/+42
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ia1b2f0a9c99acc7ac538f3b41c1b6757d414db35 Reviewed-on: https://gerrit.libreoffice.org/66970 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-01-19Fix typoAndrea Gelmini1-1/+1
Change-Id: I0ec220642295bd5a855ac38d8e5f721a20351836 Reviewed-on: https://gerrit.libreoffice.org/66633 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-12-29typelib: Fix incorrect parameter type to std::min() on m68kJohn Paul Adrian Glaubitz1-1/+1
Change-Id: Id674d19d38ebe634707f5a480e596efe8c83cc6a Reviewed-on: https://gerrit.libreoffice.org/65684 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-08Remove obsolete SAL_FALLTHROUGH completelyStephan Bergmann1-1/+1
...after 7ffdd830d5fb52f2ca25aa80277d22ea6d89970b "HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true now" Change-Id: I54e5ff4e036a6bb3e5774d1c0524158aae18e937 Reviewed-on: https://gerrit.libreoffice.org/64800 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07loplugin:singlevalfields extend to all static varsNoel Grandin2-2/+2
Change-Id: Ic238bb5291539fd1b7e98cb4afc9b25f37e7d528 Reviewed-on: https://gerrit.libreoffice.org/64710 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-06Remove obsolete GCC version checksStephan Bergmann1-1/+1
...after <https://gerrit.libreoffice.org/63951> "Bump (Linux) GCC baseline to 7.0.0". (In some cases, those checks now need to check for __clang__, which was implicitly covered in the past by Clang consistently reporting to be GCC 4.2.1.) Change-Id: I860fef8c4ca41c22a7541f0fb2d34b37d1d69bed Reviewed-on: https://gerrit.libreoffice.org/63952 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-16loplugin:buriedassign in avmedia..cuiNoel Grandin1-3/+12
Change-Id: Id44f1e98a3aac2c417f8030de603175bf68f0dfe Reviewed-on: https://gerrit.libreoffice.org/63467 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-07coverity#1441100 silence Out-of-bounds accessCaolán McNamara1-0/+1
Change-Id: I8d8f93262481c35968cdfff49eddd7a20cf84c1f Reviewed-on: https://gerrit.libreoffice.org/63022 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-11-04replace double-checked locking patterns with thread safe local staticsMike Kaganski1-16/+13
Change-Id: I1bf67196e97411aeecc13ed4f91d1088a315e323 Reviewed-on: https://gerrit.libreoffice.org/62839 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-11-04replace double-checked locking patterns with thread safe local staticsMike Kaganski1-51/+37
Change-Id: Ie1aae7ecbd065a88b371d8c0deb586f54f7eff65 Reviewed-on: https://gerrit.libreoffice.org/62835 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-10-24remove more rtl::OUString and OString prefixesNoel Grandin19-208/+197
which seem to have snuck back in since the great rounds of removals. Change-Id: I85f7f5f4801c0b48dae8b50f51f83595b286d6a1 Reviewed-on: https://gerrit.libreoffice.org/62229 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-09Extend loplugin:redundantinline to catch inline functions w/o external linkageStephan Bergmann6-36/+36
...where "inline" (in its meaning of "this function can be defined in multiple translation units") thus doesn't make much sense. (As discussed in compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions in include files for now.) All the rewriting has been done automatically by the plugin, except for one instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus some subsequent solenv/clang-format/reformat-formatted-files. Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224 Reviewed-on: https://gerrit.libreoffice.org/61573 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-22tweak markupCaolán McNamara1-2/+2
Change-Id: I5d7171045a9c271e2ef5f456411fa4d3eb5f1571 Reviewed-on: https://gerrit.libreoffice.org/60895 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-09-17New loplugin:externalStephan Bergmann3-3/+7
...warning about (for now only) functions and variables with external linkage that likely don't need it. The problems with moving entities into unnamed namespacs and breaking ADL (as alluded to in comments in compilerplugins/clang/external.cxx) are illustrated by the fact that while struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } returns 1, both moving just the struct S2 into an nunnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { namespace { struct S2: S1 { int f() { return 1; } }; } int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } as well as moving just the function f overload into an unnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; namespace { int f(S2 s) { return s.f(); } } } int main() { return f(N::S2()); } would each change the program to return 0 instead. Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c Reviewed-on: https://gerrit.libreoffice.org/60539 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-10Fix for --enable-debug --disable-assert-always-abortStephan Bergmann1-1/+1
...found by <https://ci.libreoffice.org/job/lo_tb_random_config_linux/1465/> Change-Id: Ia38fe5cac9fa187535599d313a3422c34458bcd9 Reviewed-on: https://gerrit.libreoffice.org/60242 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-06loplugin:simplifyconstruct in canvas..cuiNoel Grandin2-6/+3
Change-Id: I02eba1df117a9d0df42bcac13c3251cb4fa6da14 Reviewed-on: https://gerrit.libreoffice.org/60074 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-29fix android buildNoel Grandin1-1/+1
after commit 37f9fdc11c4e95d6a34cb515a454503256a82c63 replace rtl_allocateMemory with std::malloc Change-Id: Ib565eeb5277a9184f875e67b55040bedbbbdb952
2018-08-29replace rtl_allocateMemory with std::mallocNoel Grandin3-22/+22
where used directly, since rtl_allocateMemory now just calls into std::malloc Change-Id: I59f85bdb7efdf6baa30e8fcd2370c0f8e9c999ad Reviewed-on: https://gerrit.libreoffice.org/59685 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-29loplugin:constantparam (1)Noel Grandin1-39/+39
Change-Id: I25077e391ecca1b678062d261a83d88daadf0a58 Reviewed-on: https://gerrit.libreoffice.org/59701 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-07-29replace double checked locking patternsJochen Nitschke1-11/+4
with thread safe static initialization Change-Id: I4c751a47e3bdf52bbfb67d4f3aabd6f442e30118 Reviewed-on: https://gerrit.libreoffice.org/58287 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>