so it can code following the CPPUNIT_ASSERT doesn't need
to check what condition might have failed in the assert
Change-Id: Ife7e5e54b17a8316425222d2a0efd694c9467089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167480
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
...to avoid
> workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:115:8: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
> sprintf(buffer, "%.*g", precision, x);
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/stdio.h:188:1: note: 'sprintf' has been explicitly marked deprecated here
> __deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/sys/cdefs.h:215:48: note: expanded from macro '__deprecated_msg'
> #define __deprecated_msg(_msg) __attribute__((__deprecated__(_msg)))
> ^
on macOS after the upcoming <https://gerrit.libreoffice.org/c/core/+/147257>
"Don't mis-apply GCC < 4.6 workaround for Clang"
Change-Id: I213de1d112cb56fba220006842e611c56ccc7331
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147333
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Often a developer debugging a failing CppUnit test wants a core dump with the
place where an uncaught exception is thrown. So if the newly introduced
CPPUNIT_PROPAGATE_EXCEPTIONS environment variable is set (to any value), disable
all the protectors that would otherwise catch such exceptions (and just report
some limited information about them).
Change-Id: I3052f71c0787583c496279a6f5b35a0299c357b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143882
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
What prompted me to make this change is that when I tried an --enable-lto build,
CppunitTest_xmlsecurity_signing failed in a non-obvious way, and I noticed that
it ran the individual tests in a different order than a --disable-lto build.
With this change, CppunitTest_xmlsecurity_signing also started to fail in the
--disable-lto build, which has meanwhile been fixed with
800eebfa82 "Database document apparently needs to
be closed before it is disposed". No other tests started to fail in my
Linux --disable-lto-build with this change, and my Linux --enable-lto build
(using recent Fedora 32 GCC 10.2 and the default linker) also succeeds `make
check` after 800eebfa82, both with and without
this cppunit change.
(<https://bugs.documentfoundation.org/show_bug.cgi?id=126442> "LTO build
segfaults in sw_apitests" and <https://src.fedoraproject.org/rpms/libreoffice/c/
5d644f1606b76ffa4a102433849a824d7293a404> "%check fails with lto enabled"
indicate that older branches also fail CppunitTest_sw_apitests with
--enable-lto, but I could not reproduce that on current master.)
What happens in cppunit is that every CPPUNIT_TEST_SUITE_REGISTRATION (or other
macro like CPPUNIT_TEST_FIXTURE internally calling
CPPUNIT_TEST_SUITE_REGISTRATION) creates a global static variable whose ctor
inserts the address of a sub-object of that global static variable into the
TestFactoryRegistry::m_factories set. Even if the order of invocation of those
ctors from one .cxx is deterministic, the relative order or the addresses of
those sub-objects inserted into the TestFactoryRegistry::m_factories set need
not be (though they probably typically are). Another source of nondeterminism
is that the order of ctors from different .cxx is not specified (which might
have caused the CppunitTest_xmlsecurity_signing failures, given that test
includes suites from two different .cxx).
So to make test execution more reproducible, make the order in which the tests
are run deterministic, sorting them by name. (When
TestFactoryRegistry::addTestToSuite the adds the sorted tests to
TestSuite::addTest, they are inserted into a TestSuite::m_tests vector, from
which point on things appear to already happen in a deterministic order.)
Change-Id: I40741f397a96772974fd41bacdb3dd763c885417
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100384
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This includes a revert of commit 9808486a89 "Avoid
-Werror,-Wimplicit-fallthrough with clang-cl", and also undoes older MSVC
workarounds (that would start to cause "warning C4702: unreachable code" now).
Change-Id: If72bf336e12e0a2db589857e8875003dae861977
Reviewed-on: https://gerrit.libreoffice.org/67248
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I am writing a separate unit test app that will include selected
existing unit tests that make sense and are important to run on iOS.
Change-Id: I4722f1ed872ba21e181eeba5ed3b58e82d8fed72
Reviewed-on: https://gerrit.libreoffice.org/61049
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
...which mentions extern "C", so CppUnit's TestPlugInSignature must reflect
that. It is a bit odd how CPPUNIT_PLUGIN_EXPORT needs to be passed into
CppUnit, so probably best to keep this as a local patch for now. (Clang's
-fsanitize=undefined complained about the mismatch.)
Change-Id: Ied179a1afe82ceb04de4739c14cf8fadff31b80f
coverity seems to think that code execution can continue
after a coverity test fails, but it will effectively halt
and not trundle into the dereference of the tested-for-NULL
pointer, try a [+kill] on the fail method
Change-Id: I07c9a074b5681c367a31637c8af78d52a9c88d59
Caolán McNamara