Age | Commit message (Collapse) | Author |
|
Change-Id: I806ffb3ab06731c61fe9c58788aabf00a05e980f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110987
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I569c7f34acbdf8451cd5c9acf1abd334637072d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110051
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I843746f976855168c791c97a56bcce430af1eea5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109046
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I3a1179947704452e3ffec02be59d0f7bf0b75ab0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109017
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit 8c5c6b8993a52c40b9de231e778204bcdca16333.
Reason for revert: "This is broken. For example, "Tools - Macros - Run Macro... - Library - LibreOffice Macros - HelloWorld" under "Macro Name" no longer lists the JVM-based scripts ("helloworld.bsh", "helloworld.js", "org.libreoffice.exmpale.java_scripts.HelloWorld.printHW")."
Change-Id: I6fef6ea80689f036e79816c8d58d2c1f9e64967c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108007
Tested-by: Henry Castro <hcastro@collabora.com>
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
The context data "DontEnableJava" is set when
it is not required to JVM to get involved,
in particular case when the Macro Selector Dialog
tries to fill the macro scripts, but the client side
has disabled the JVM and it produces a lot of checks
to try to get booted the JVM.
Is there any reason why it is not a pre-condition
at the beginning of the function?
Change-Id: I3bd4a22ddef12a130ea5ecd08c67f1db66bbac72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107242
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
Except recently checked sc, sd, svx, sw
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ice1b86628e4f22a39f307b9c5fa567b6ab9d5acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106917
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I401279561e2481a8af7ed600d4133812b08386ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105712
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icc0d2555bb90a5e0bf6ea828d14fb9e836dd7981
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103845
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I57f77f127f7cb45fb181b755b40873d47015e5b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91059
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
...instead of having individual overloads for OUString, OUStringLiteral, and
literal char16_t const[N]. (The variants taking OUString are still needed for
!LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char
const[N] are also left in place.)
This nicely reduces the number of needed overloads. std::u16string_view allows
to pass as arguments:
* OUString
* OUStringLiteral
* OUStringChar (with the necessary conversion added now)
* OUStringNumber
* u"..." char16_t string literals
* u"..."sv std::u16string_view literals
* std::u16string, plain char16_t*, and more
A notable exceptions is OUStringConcat, which now needs to be wrapped in
OUString(...), see the handful of places that needed to be adapted.
One caveat is the treatment of embedded NUL characters, as
std::u16string_view(u"x\0y")
constructs a view of size 1, while only
u"x\0y"sv
constructs a view of size 3 (which matches the old behavior of overloads for
literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16
machinery). See the new checkEmbeddedNul in
sal/qa/rtl/strings/test_oustring_stringliterals.cxx.
The functions that have been changed are generally those that:
* already take a string of determined length, so that using std::u16string_view,
which is always constructed with a determined length, is no pessimization
(e.g., there are operator == overloads taking plain pointers, which do not
need to determine the string length upfront);
* could not benefit from the fact that the passed-in argument is an OUString
(e.g., the corresponding operator = overload can reuse the passed-in
OUString's rtl_uString pData member);
* do not run into overload resolution ambiguity issues, like the comparison
operators would do.
One inconsistency that showed up is that while the original
replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0)
overload takes an optional third fromIndex argument, the existing replaceAll
overloads taking OUStringLiteral and literal char16_t const[N] arguments did
not. Fixing that required a new (LIBO_INTERNAL_ONLY)
rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in
sal/qa/rtl/strings/test_strings_replace.cxx).
Another issue was posed by test code in
sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the
RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that
certain function calls should not compile (and would compile under
RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to
OUString as arguments). Those problematic "should fail to compile" tests have
been converted into a new CompilerTest_sal_rtl_oustring.
Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
O[U]StringView had an odd mixture of uses. For one, it was used like
std::[u16]string_view, for which directly using the latter std types is clearly
the better alternative. For another, it was used in concatenation sequences,
when neither of the two leading terms were of our rtl string-related types.
For that second use case introduce O[U]String::Concat (as std::[u16]string_view
can obviously not be used, those not being one of our rtl string-related types).
Also, O[U]StringLiteral is occasionally used for this, but the planned changes
outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral
from char[] to char16_t[]" commit message will make that no longer work, so
O[U]String::Concat will be the preferred solution in such use cases going
forward, too.
O[U]StringView was also occasionally used to include O[U]StringBuffer values in
concatenation sequences, for which a more obvious alternative is to make
O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat
machinery.
Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8dc0cdcfe6bd90efc596df28e6c6d968b92618b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101098
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: Ib4a812dd115299d4251d863d0ee275d7acba1c5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99443
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
See tdf#74608 for motivation.
Change-Id: I4eb381d19e453ceb2b035462f0f5de923458a03e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99345
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Ic55e4779af26378a41cf31465d4cafd429085596
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98696
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Idf47e3fff2ca0e693834bcdd228159b5725837e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98700
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Ie1c953c58688a0dfbbc8a40385e400b8d0314f3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98699
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Ic1ce8431bfb116c1e64116e2019fa0d3bcf8344c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98698
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Iaa8805141e480e05badd92c61a455e46bd411e87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98697
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I993e4c0aef41b0925678d7744a989ad5539cc80e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
mostly to catch stuff from the flatten work, but I think this looks good
in general
Change-Id: I7be5b7bcf1f3d9f980c748ba20793965cef957e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92493
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7e70614ea5a1cb1a1dc0ef8e9fb6fd48e85c3562
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93904
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I979faf4c476a7de91a0b6e06dd8717cee25525f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92313
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 0ddf3e0a628599d01356cb5262b93faca073ee9f.
Change-Id: I3e476399a465950defc15ac4d6199a638c4a4baf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90452
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
After 424a7f404565e068995e2a9827d5bc6f76920ec8 "add some more libs to libmerged"
had added javaloader to libmerged, destruction of static xStaticRef started to
cause problems at least during CppunitTest_services of --enable-mergedlib
Windows builds (presumably because the relative order of static variable
destruction had changed).
Change-Id: I8307570222cc9a3d9511d090d0dae7f7dfe7a9ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90254
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
("The Java Native Interface" by Sheng Liang, Addison-Wesley 1999, states on
page 211: "This function [ExceptionDescribe] has the side effect of clearing
the pending exception." And since Java 10, the documentation of
ExceptionDescription at <https://docs.oracle.com/javase/10/docs/specs/jni/
functions.html#exceptiondescribe> states that "[t]he pending exception is
cleared as a side-effect of calling this function", even though for Java 8
<https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#
ExceptionDescribe> does not mention that. So assume that calling
ExceptionDescribe always makes calling ExceptionClear superfluous.)
Change-Id: I4f89eb44768d436a224d7027afb5e7a93f092f29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88050
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which is much better for CPU cache, since the representation is more
compact, and since we almost always do insert() in pointer order,
there is surprisingly little sorting
Also add a count() method for compatibility with std::set and the
proposed std::flat_set
Change-Id: I2a3211dc59919cfec5cac1497530a4c3600d50ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87793
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie23019fe0b86f16820dd68c647c4ce15bbbb42dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87575
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ice7c0ecc8ee05a5c3b0af458ceeee8191bdde322
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86752
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I42b59c9d22edb987c55aace700934fdab95f83f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86719
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1c1e7b42211c51f572698efd3135e388f8fb2979
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86648
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia133c1a7549d81f2e88e34ab7e6c9ea578c745ae
Reviewed-on: https://gerrit.libreoffice.org/85702
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8eadedbdf5f4bee218ae2f39c76300fc0624912b
Reviewed-on: https://gerrit.libreoffice.org/84374
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib40fad986f99d02e58f0564fb68608e86989173c
Reviewed-on: https://gerrit.libreoffice.org/84325
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
1) https://cgit.freedesktop.org/libreoffice/core/commit/?id=4e1ae2a9a0d2d9185b49677fa4ea2a2b1fe8bab2
I had let "size" and "fields" initialized twice instead of initializing only
2) https://cgit.freedesktop.org/libreoffice/core/commit/?id=e6ab01ce532d1db01579b70bd476b2f643522bf9
put back original order for NestedKeyImpl and adjust initialization accordingly
Change-Id: I6ca4e6520558011c359f8ea089b6d431ad79edfe
Reviewed-on: https://gerrit.libreoffice.org/83810
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
+ fix:
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/connectivity/source/drivers/mork/MStatement.cxx:64:6: error: no need to explicitly init an instance of 'std::unique_ptr<connectivity::OSQLParseNode>' with nullptr, just use default constructor [loplugin:simplifyconstruct]
,m_pParseTree(nullptr)
^~~~~~~~~~~~~~~~~~~~~
from another patch to calm down clang Jenkins
Change-Id: Ia8304b7baedbce760a6e01ea154c5ff3cd19cbd4
Reviewed-on: https://gerrit.libreoffice.org/83595
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iddbd3256aabe9552472b55d3d9b88a3769698de9
Reviewed-on: https://gerrit.libreoffice.org/83576
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...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>
|
|
I started with 32 and kept doubling the size until the site
did not need re-alloc, but clamped it at 512 (e.g. in emfio/).
Change-Id: Ib7caf35a1b7e42b0e4ed8aa812493449e3eefc8f
Reviewed-on: https://gerrit.libreoffice.org/81540
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by the simple expidient of putting asserts in
the resize routine. Where an explicit const size is used,
I started with 32 and kept doubling until that site
did not need resizing anymore.
Change-Id: I998787edc940d0a3ba23b5ac37131ab9ecd300f4
Reviewed-on: https://gerrit.libreoffice.org/81138
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|