Age | Commit message (Collapse) | Author |
|
Change-Id: I39ed2485a67ec7a8b24ab90ea0d69a5982374334
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122860
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I47ac4ff7d82eb5732ad54e3b42c18c3665c83b82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122845
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
> sal/cppunittester/cppunittester.cxx(553,115): error: format specifies type 'unsigned int' but the argument has type 'ULONG64' (aka 'unsigned long long') [-Werror,-Wformat]
> printf("\tat %s in %s: line: %lu: address: 0x%0X\n", pSymbol->Name, line->FileName, line->LineNumber, pSymbol->Address);
> ~~~ ^~~~~~~~~~~~~~~~
> %0llX
> sal/cppunittester/cppunittester.cxx(558,64): error: format specifies type 'unsigned int' but the argument has type 'ULONG64' (aka 'unsigned long long') [-Werror,-Wformat]
> printf("\tat %s, address 0x%0X.\n", pSymbol->Name, pSymbol->Address);
> ~~~ ^~~~~~~~~~~~~~~~
> %0llX
> sal/cppunittester/cppunittester.cxx(576,50): error: format specifies type 'unsigned int' but the argument has type 'DWORD' (aka 'unsigned long') [-Werror,-Wformat]
> printf("*** Exception 0x%x occurred ***\n\n",ex->ExceptionRecord->ExceptionCode);
> ~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> %lx
...but where SYMBOL_INFO::Address is documented to be of type ULONG64, which in
turn is documented to be a typedef for unsigned __int64, for which there
is the MSVC-extension I64 format specifier
Change-Id: Ibed1d3fa49ac6fd988174c6041071292fc66dd3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122872
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6a529d2eb737d284bf1e9c1857680c33581f5e0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122846
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I71be097d5051d39295f9f85d3e2329564388b4c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122851
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2c68832a23d80dbe208212ce36b14b21b5312f5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122850
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib7b3bfb7a3162e032cf6c9bf7f19576434592a00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122849
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia374fe0a7a0392e91821fecd1e6ee5917864d59c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122848
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I48ee1c1906ab06a487059128eb1eba0d6adb068f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122847
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9963a527d2323f4df8c3b46c13f5b7993e22f163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122855
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I368123ce4ffdfb0e5c47e80cf4fece0c6ddc5f9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122854
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Fill it in the correct order, starting from the middle
Change-Id: Id35475e391d771d6c23252124a92825b24b55e0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122853
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iee8966eeeaea461e34b5d22b80cb612dfaa57fe4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122750
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I09ab406a8b7279801ce79b2f9c0a0011f6db05be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122749
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This is clang-cl's equivalent of -fvisibility-inlines-hidden,
and it seems to be also sort of the equivalent of MSVC's
-Zc:inline. So it saves build time and disk space.
Clang docs say that this is binary compatible in only one
direction, so our public C++ code shouldn't be using this,
as external C++ code could try to use exported inlines
that are no longer there.
Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I6b40642c7574a1863658854d206ed849517dbd0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122130
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I0186e8f1566ec2e4cec768cc18bdeba0bae182b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122033
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
warning: Excessive padding in 'struct ImplTextEncodingData' (8 padding
bytes, where 0 is optimal).
warning: Excessive padding in 'struct ImplByteConvertData' (10 padding
bytes, where 2 is optimal).
warning: Excessive padding in 'struct ImplDBCSConvertData' (10 padding
bytes, where 2 is optimal).
warning: Excessive padding in 'struct DirectoryItem_Impl' (11 padding
bytes, where 3 is optimal).
Change-Id: Ia19f192099c305734256103c7cdc0f64e398b6af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121902
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To make complex backtraces readable.
Change-Id: I3a95d03d97c8e6d1aa7aeab37957d3b8441c3c90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121724
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ib4351ba7a585ada3887f1cbeb5d676733250598b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121585
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ifc655e4d5e2f3eb934b407e146ee564e3db0146b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121584
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The backtrace_symbols() function provides backtraces that often
miss many function names, try harder to resolve them, using addr2line
is the best (only?) working solution I've found.
Change-Id: Ieda06fc52735596e499fb7f9443cae13d134da5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121539
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I54495044f2bd487eb9315c7a974b9859b26235a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121588
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
so the multiple unit tests don't stomp on each other.
This fixes a couple of things in my earlier attempt
(*) actually set the env variable on Windows
(*) don't use a global variable to test the env var, because that
variable might be initialised BEFORE the env var is actually set
Change-Id: Id43a1dd2fbd324691e0b6578c9026b8a523012e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121436
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4449d3c87adbcb94c721799aa6de1d615eb7041f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121070
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Dynamically trying to obtain the two PSAPI functions was apparently originally
done because "This version can fail because PSAPI.DLL is not always part of
NT 4 despite MSDN Libary 6.0a say so", according to the comment added with
961512bd9ae008fdd8ab5cdf1ba6b5d25ffb0429 "#94875# Added additional method (for
NT4) to determine the module containing an address". (That comment was removed
again in 515d2579d305a6127c6c194319a58eac62437e33 "Replace legacy dynamically-
loaded functions with statically linked ones", which curiously left the dynamic
loading of PSAPI.DLL in place there, though.)
<https://docs.microsoft.com/en-us/windows/win32/api/psapi/nf-psapi-enumprocessmodules>
states that the PSAPI functionality is available in "Kernel32.dll on Windows 7
and Windows Server 2008 R2; Psapi.dll (if PSAPI_VERSION=1) on Windows 7 and
Windows Server 2008 R2; Psapi.dll on Windows Server 2008, Windows Vista, Windows
Server 2003 and Windows XP". I do not find any mention of PSAPI_VERSION across
our code base, so assume that PSAPI_VERSION=1 would be some legacy mode that we
do not use, so with our baseline of Windows 7 (cf. README.md), relying on the
PSAPI functionality being available without adding anything specific to
gb_Library_use_system_win32_libs,sal should presumably be OK.
Change-Id: I55ab29be2a3ee3984c6987e953819cb2e92e4aa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121136
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the
lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building
without --with-latest-c++) requires ROW_RANGE (a local const int variable from
the enclosing TestFormula::testTdf97369) to be captured, even though all uses of
that variable within the lambda body are constant expressions. That is still
true at least for the latest Visual Studio 2019 version 16.11.1. (This is not
an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down,
as they, in addition to using that ROW_RANGE, also use the local const double
variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so
they are implicitly captured and loplugin:unusedcapturedefault does not suggest
dropping those lambdas' capture-defaults in the first place.)
Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
However, restricting the workaround to GCC <= 11 then revealed that some old
versions of Clang apparently had a similar issue, causing "error: use of class
template 'OStringLiteral' requires template arguments; argument deduction not
allowed here", and thus also need the workaround. I saw the non-workaround code
fail with a build of Clang 6.0.0 and succeed with a build of Clang 7.0.0.
Change-Id: I6e4cf6c8c3a11618a578401574e5679e6b65d7f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120657
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1c23fda56c013eeeaf4ad1099c164d6d1146f68b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119851
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
in a handful cases, like a map or a vector, we don't need init on demand
at all, the default constructor can be laid out at compile time
Change-Id: Ifa3188af7a65cd475ce0f603d15a8c26bcda7e6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119710
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0430fe4bc3107b321e7b7ab84cbc3e6afff97372
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119647
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
where we currently have no good feedback when something
goes wrong.
Credit: Exception printing code written by
msdn-whiteknight
as seen at
https://stackoverflow.com/questions/22467604/how-can-you-use-capturestackbacktrace-to-capture-the-exception-stack-not-the-ca
Change-Id: I44c65b10c0b0151c3236521d62a824570d4cdccf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119561
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which were deprecated in 0a126b4c661d65860fd2de92f8cc49bdb65a957c "Deprecate
osl_demultiplexSocketEvents et al" towards LO 7.2 (and leave aborting stubs in
place for backwards compatibility)
Change-Id: Ice6032eb2f351af87dd56eecb002aa2a91e79373
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119560
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
the constructor can be laid out at compile/link time
Change-Id: I377a537e15199ae81394d76ac662576280a25c25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119362
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...like it is also already done in LineParser::readDouble in
sdext/source/pdfimport/wrapper/wrapper.cxx (esp. since the code should be
changed to use C++17 std::from_chars once that is available in all our
baselines), reverting again the introduction of rtl_str_toDouble_WithLength in
b1df9c67349cf4cc5be4128d797aefb87f50e38f "[API CHANGE] reduce cost of numeric
conversion"
Change-Id: If7e3a15649f80093d3407157412fd3deb3a38b12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119318
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
...like it is also already done in LineParser::readInt32 in
sdext/source/pdfimport/wrapper/wrapper.cxx (esp. since the code should be
changed to use C++17 std::from_chars once that is available in all our
baselines), reverting again the introduction of rtl_str_toInt32_WithLength in
b1df9c67349cf4cc5be4128d797aefb87f50e38f "[API CHANGE] reduce cost of numeric
conversion"
Change-Id: I2789f8ec55c8d89150d1c68e6b353a1d2e1d1703
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119301
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
on a hot path, since we already know the length of these strings.
Which requires adding some new variants of our string conversion
functions
Change-Id: I1877f8f3c72934c07f14eec7e73bbe8d7b0f1808
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119065
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The code accepting "NaN" had been introduced with
92dafe9862d693ce9d79269627c3e6832422874e "dba33h: #i112652#: rtl/math.h:
string<->double conversion and XMLSchema-2: [...] rtl_math_stringToDouble and
rtl_math_uStringToDouble support XMLSchema-2 values in addition to deprecated
previously supported values." The "XMLSchema-2" mentioned in that commit and in
the corresponding <https://bz.apache.org/ooo/show_bug.cgi?id=112652> "ORB:
report builder not handle correctly NULL values" presumably references
<https://www.w3.org/TR/xmlschema-2/> "XML Schema Part 2: Datatypes Second
Edition", where section "3.2.5 double" only supports "NaN" without a "+" or a
"-" sign in the lexical representation. So stop accepting those.
(I came across this in the context of 2b2b6405161025678f91a5625e50d0b414597368
"Reliably generate positive or negative NaN again", wondering whether this code
should be updated too. But then decided that it is probably best not to allow
that non-standard signed NaN notation for this case, and just keep producing for
the "NaN" representation whatever std::numeric_limits<double>::quiet_NaN
produces.)
Change-Id: I035e78ca36240317f72f117d2b456fc474d8c08a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118647
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Iae559ca8bee9650c01167a4d1b918e18cbf03c28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118660
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after e5c80bb69a30dfb0a3daf6061ab127d92f8142d6 "Purge out setNan from
math.cxx" had dropped the use of rtl::math::setNan and sign bit fiddling, and
relied on the implicit assumption that std::numeric_limits<double>::quiet_NaN
would produce a positive NaN (but which does not seem to be guaranteed by the
C++ standard) and on the expressed hope that multiplying such a positive NaN by
-1 would generate a negative NaN (but which does not seem to be guaranteed by
IEEE 754: while it mandates that a NaN's payload is preserved across such an
operation, the result's sign bit appears to be unspecified)
Change-Id: I12215c888a1cb8de6b3f046a836c550cb21b5a85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118604
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I243d2998725f09ef533bd06865081d5c415f0d18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118282
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I95f9b37b564bb733f44899a8c6c1ea3c36e35694
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118196
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Reduce operation count by space / speed tradeoff.
This expression is widely used in LO.
Then needs to be fast.
Change-Id: Ic88cf15d451ec95a8ad6da88cd9f601cf2876871
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117954
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Filesystem access is quite expensive on Windows, so add a small
cache for the filepath/name normalisation.
This takes my load time from 19s to 18s
Change-Id: I4410d066b8a4d2fd2eb746a5dd8f4ee763a8aa3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117549
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0297f299c42a5ce5485cdcdebfbd1597969c907c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117573
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
No need for this indirection
Change-Id: I87c90c9f1a7904f5a506acac631fe5a1f52f9190
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117521
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
C++ floating-point environment has thread storage duration, so
std::fesetround call is thread-safe.
std::nearbyint uses half-to-even rounding with FE_TONEAREST,
as specified in ISO/IEC 9899:1999 F.3, and in Appendix to
ANSI/IEEE 854.
Change-Id: I26995842c30e2663b40af5b5314791c1328037d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117307
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
With the recent implementation of
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" in Clang 13 trunk as
<https://github.com/llvm/llvm-project/commit/bf20631782183cd19e0bb7219e908c2bbb01a75f>
"[clang] Implement P2266 Simpler implicit move", a --with-latest-c++ build
started to fail with
> comphelper/source/xml/xmltools.cxx:103:20: error: no viable conversion from returned value of type 'char [39]' to function return type 'rtl::OString'
> return str;
> ^~~
[...]
> include/rtl/string.hxx:277:5: note: candidate constructor [with T = char [39]] not viable: expects an lvalue for 1st argument
> OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() )
> ^
[...]
etc.
Change-Id: If34f143a1855fdd7cd22ea3d7594f9381d50a7ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117336
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... so that thread name could appear in crash dumps, and be
potentially available for logging on Windows 10 version 1607
and later.
Change-Id: I176ca1fce57e0532a226f85836b3889a8ffb2984
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116462
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|