<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>
...following up on 314f15bff0 "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>
...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>
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>
...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>
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>
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>
<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>
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>
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>
...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>
...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>
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>
...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>
...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>
...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>
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>
Stephan Bergmann