Age | Commit message (Collapse) | Author |
|
This allows to test the actual type, not something unrelated
Change-Id: I82d0714f6355fc5ae7bd3205af3472a43f1f1051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105998
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I890d19f5e2177294dc1175c90c98b964347f9e85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105751
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Protect against callers using for example rtl_math_StringFormat_F
with rtl_math_DecimalPlaces_Max in worst case..
Change-Id: I9f143df6ae67b22e7732547c0f7a53b498caf2b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104472
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I2ce95de07b8e0952a1e778e65940b30597396aa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103949
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
+ remove sal_Char check on compilerplugins
Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9
Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I022f5ed37d25f2c8a8870033bab32ff59d4d8da6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97648
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I76cbd5d3e65f0b392d713a51607f5c88dae79593
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95101
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
GCC appears to support it at least since <https://gcc.gnu.org/git/
?p=gcc.git;a=commit;h=51e2940139d5e3e86590f6e6802ffc3f3010be5b> "Initial
revision" in 1992, and Clang appears to support it since <https://github.com/
llvm/llvm-project/commit/d93abc3bb0acdd430839abdd67bd3920fee87bbc> "Implement
ffs, parity, and popcount builtins" in Clang 2.4. (And if a build used a
compiler that does not support it, there would be no guarantee that it would
support strings.h function ffs from X/Open System Interfaces, either.)
Introducing HAVE_GCC_BUILTIN_FFS in 334a9f16cd1d1f9694f885c759903a41aa3d4833
"tdf#113211: fix calculations with big integers" appears to be due to a
misguided recommendation at <https://gerrit.libreoffice.org/c/core/+/43477/4#
message-899806c724fbdcece0ea9438514a6a5db6a2e645>.
Change-Id: Ib6ee6de548172b3aae25483d03efb86620133933
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92421
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I5a7bc9378ceacb9116c03e3a9fc01c5675c40908
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92243
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icc30c79d599486203c8f763cd5ff43059f0bb910
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91556
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5d53e6369d35093445b2efd8936bbf8c6775ff47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90451
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I91235eee8c6a9d4a59c1933527b49141f64cd91b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90478
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id0f0e07b324230d2d69cbf4ab07b0fff5b24474d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90377
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
- make all calls look like `std::isfinite`.
- change the comments referring `rtl::math::isFinite`.
Change-Id: I0cde9ceb9f20150467b454cddde5e62003cfde1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90234
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit d4d37662b090cb237585156a47cd8e1f1cbe2656.
Now that we know that making fields has negative side effects
like disabling assignment operator generation.
Change-Id: Idef4937b89a83d2efbfaf0ab87d059a0143c0164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90364
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Size of buffer on stack is 256 characters. Logging function usage
in make check, of >1 100 000 invocations, the longest string was
80 characters, average being 4.6 characters. So heap allocation
is unlikely in scenarios with intensive function usage.
Several existing unit tests had to be fixed. Usually, the change
is either minimal or getting closer to what Excel returns (for
Calc tests). But in case of AMORDEGRC, I had to change rate value
passed to the function from 0.3 to 0.31. It's because the closest
double value for 0.3 is 0.29999999999999999, which is a bit less
than 0.3; multiplied by 1.5, this gives 0.44999999999999996, and
then rounding the result of multiplication of the latter by cost
gave the result 1 less than before, when 0.3 was imported as
0.30000000000000004. Now the function returns a value 1 less than
Excel for that set of arguments. I don't see how to fix that.
Having rate slightly different gives consistent result between
Calc and Excel.
Change-Id: Icae5ce374fe0c31a1aa10cee815e65ef0014f382
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89422
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iab5ab11059437a595596e8ba3ec7aa45cec15f0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87617
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...plus loplugin:unnecessaryparen fallout in sw/source/uibase/docvw/edtwin.cxx.
Each of the files contained at least one #define that would have caused warnings
with upcoming loplugin:unsignedcompare. For consistency, I changed all #defines
in those files (using a variable of a specific type if the original #define used
a cast to that type, otherwise using 'auto').
Change-Id: I66f71b2d83394c9dc6952ae19df774cdd4d0b76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87374
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6d32942960a5e997f16eb1301c45495661cd4cea
Reviewed-on: https://gerrit.libreoffice.org/85514
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...that had been added by accident with 55e596956e56b175ab17b682e7c8ac7daeb9289a
"loplugin:external (clang-cl)"
Change-Id: Ieff93c825632d68adb621d8f646ff8abb72b5452
Reviewed-on: https://gerrit.libreoffice.org/84599
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...plus loplugin:consttobool and loplugin:fakebool fallout
Change-Id: Ie3d8121815c080b13bea6d9deca1eb138ca56138
Reviewed-on: https://gerrit.libreoffice.org/84515
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
as found by <https://ci.libreoffice.org/job/lo_tb_random_config_linux/2039/>
Change-Id: Ie698b7905bd2f25e74791f91f586479d1fc473dc
Reviewed-on: https://gerrit.libreoffice.org/82488
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
by 10%, by avoiding an OUString construction in a hot path
through
XMLTextColumnContext_Impl::XMLTextColumnContext_Impl
-> sax::Convert::convertNumber
Also changed XMLTextAnimationStepPropertyHdl::importXML
to take advantage of the modified convertNumber passing
convention.
Change-Id: I4e5503dbb094c88a09af8b6dc8c22b6c53f9eb75
Reviewed-on: https://gerrit.libreoffice.org/81726
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>
|
|
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>
|
|
The idea is to internally in sal/osl/unx/ use OString instead of OUString to
represent pathnames, so that the OString carries the actual bytes that make up
the pathname. At the boundary of translating between pathname OStrings and file
URL OUStrings, translate sequences of bytes that are valid according to
osl_getThreadTextEncoding() into UTF-8 and translate other bytes into individual
(percent-encoded) bytes in the file URL.
This change required duplicating some of the internal functionality in
sal/osl/unx/ for both OString and OUString, and to make part of sal/rtl/uri.cxx
accessible from sal/osl/unx/ via new sal/inc/uri_internal.hxx.
Change-Id: Id1ebaebe9e7f2d21f350f6b1a07849edee54331f
Reviewed-on: https://gerrit.libreoffice.org/78798
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3424e17cfdfb563fdc5882942031deafae8689fe
Reviewed-on: https://gerrit.libreoffice.org/78678
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
doubleToString() is entered with an inaccuracy afflicted
fValue=-9999.9999999999927 for which the rounding into the next
magnitude incremented the '-' character to '.' instead of
appending a '1' (and '0' and then "000") thus yielded ".0000"
instead of "-10000"
This seems to have been always the case.
Change-Id: I66170defa71fec40ca0b85f68affde8eff0d5ccb
Reviewed-on: https://gerrit.libreoffice.org/77208
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: Ie183c445bf8a545f59aac7b0e29f72ab679a6cf3
Reviewed-on: https://gerrit.libreoffice.org/76852
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: Id9d994343d10b5d5e852b10946c036dfbeb66d04
Reviewed-on: https://gerrit.libreoffice.org/76656
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7bd1511a6acc105ab5b42c698c7578cfb9ce06b4
Reviewed-on: https://gerrit.libreoffice.org/70708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use range-based loop or replace with STL functions
Change-Id: If6b734dab12a7298fce16003d3d175305fbe798d
Reviewed-on: https://gerrit.libreoffice.org/67701
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I67462369d93e9d9ff3c056800947c4b75f71ba5f
Reviewed-on: https://gerrit.libreoffice.org/67486
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id6280424627a3bbcb484d61cee2f2003aa1ca9b6
Reviewed-on: https://gerrit.libreoffice.org/67604
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4b877751818febaec8e64018335dca691a476a43
Reviewed-on: https://gerrit.libreoffice.org/67561
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Also a group separator character followed by a non-digit is not.
Change-Id: Id57e43fe7692706c5532fb05ad394224265c2750
Reviewed-on: https://gerrit.libreoffice.org/64358
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95
Reviewed-on: https://gerrit.libreoffice.org/64102
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I0853cf13162bae44cf8a5c44a4546a73f05772d9
Reviewed-on: https://gerrit.libreoffice.org/63780
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I954c12d9e1c493be6ac8c7b15076077b5bff5b74
Reviewed-on: https://gerrit.libreoffice.org/62811
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id2478ac637140b604cb0f7e3aa4267f02aa859c4
Reviewed-on: https://gerrit.libreoffice.org/63255
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I3068b18f5cff024a48a8f8c68d69cadad30fe4d5
Reviewed-on: https://gerrit.libreoffice.org/62953
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1bf67196e97411aeecc13ed4f91d1088a315e323
Reviewed-on: https://gerrit.libreoffice.org/62839
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I9265425a215609ef6bf4298ba39c8399f215ce27
Reviewed-on: https://gerrit.libreoffice.org/62406
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
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>
|
|
Change-Id: I0c3efa394511e479d925f5320977d071e8301f8d
Reviewed-on: https://gerrit.libreoffice.org/62002
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|