This is type-safe, and allows to catch cases where a source type
is changed for some reason, but reinterpret_cast masks that
Change-Id: Ib64b6fa2e22d94a6bba890f0ccc3e20325c6f0a1
Reviewed-on: https://gerrit.libreoffice.org/42961
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
this modifies codemaker so that, for an UNO enum, we generate code
that effectively looks like:
#ifdef LIBO_INTERNAL_ONLY && HAVE_CX11_CONSTEXPR
enum class XXX {
ONE = 1
};
constexpr auto ONE = XXX_ONE;
#else
...the old normal way..
#endif
which means that for LO internal code, the enums are scoped.
The "constexpr auto" trick acts like an alias so we don't have to
use scoped naming everywhere.
Change-Id: I3054ecb230e8666ce98b4a9cb87b384df5f64fb4
Reviewed-on: https://gerrit.libreoffice.org/34546
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
As it causes "unopkg.bin:
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/comphelper/source/misc/threadpool.cxx:96:
comphelper::ThreadPool::~ThreadPool(): Assertion `mbTerminate' failed."
in
<https://ci.libreoffice.org/job/lo_gerrit/8283/Config=linux_clang_dbgutil_64/console>
and also locally. Revert till it's clear if that assert() should be a
SAL_WARN() or unopkg has to be fixed.
This reverts commit 9899ffd244.
Change-Id: I72902f7da410012340aa8231d84c6871a3f7b976
Commit aa68c99d88 added some code using
std::condition_variable to comphelper.
Built with MSVC 2017, this causes many cppunittester.exe processes to
deadlock in ThreadPool::shutdown():
maTasksChanged.notify_all();
This ultimately calls NtReleaseKeyedEvent(), which never returns.
The reason appears to be a bug in Windows 7, for which a "hotfix"[1] is
avaiable here, but it's apparently not distributed via Windows Update
so we likely can't rely on users or even developers having this installed.
However, the documentation of DllMain[2] and ExitProcess[3] indicates
that during shutdown, by the time global destructors are invoked
all threads other than the one that called ExitProcess have already
been terminated.
Returning from main() implicitly calls ExitProcess [4].
As it turns out the problem only happens for some CppUnitTests because
soffice.bin will call ThreadPool::shutdown() from Desktop::doShutdown()
while it is still safe.
[1] http://support.microsoft.com/kb/2582203
[2] https://msdn.microsoft.com/en-US/library/windows/desktop/ms682583(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx
[4] https://blogs.msdn.microsoft.com/oldnewthing/20100827-00/?p=13023
Change-Id: I6137461ca7efe9a5fbe4f8f8478fb96de3570469
Reviewed-on: https://gerrit.libreoffice.org/35066
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
...and remove some unncessary using directives/declarations, in preparation of
removing now-unnecessary #includes from cppumaker-generated files, post
e57ca02849 "Remove dynamic exception
specifications".
Change-Id: Iaf1f268871e2ee1d1c76cf90f03557527ebc9067
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
On a fresh installed Sierra pyuno fails to build due to a py_UNICODE
conversion problem.
Py_UNICODE expand to "unsigned short", and OUString expect a form of sal_UNICODE
The hack was done locally and not generally expand OUString functionality.
Change-Id: Ib7834c423c1c5cd9cd1e8d1ed8393e80bf8a5e5d
Bunch of these were setting C++ or Make modes and icky tabs...
Also, reportedly Emacs can figure out to enable python-mode
automatically.
Change-Id: I50072488fb92cb4d27aa3f74f717a28ae3967543
The issue of 362d4f0cd4 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
to static members (data, in addition to function) via class member access
syntax. Also covers the (somewhat obscure) access to enumerator members.
Change-Id: Iec54b8df2fdb423c0caf21a0dd0f9fe8fdf33897
* Fixing pep8 violations
* Improving comments, docstrings, and unifying coding style
* Using functionality copied from six library for Python 2/3 compatibility
* Using standard traceback formatting
Change-Id: I62bd0e8513ffc59202163002fa4adea3d92572c3
Reviewed-on: https://gerrit.libreoffice.org/22848
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
...now that sal_Unicode no longer clashes with sal_uInt16 on any platform (in
LIBO_INTERNAL_ONLY code), after e16fa715c4 "Handle
wchar_t as native C++11 type on windows"
Change-Id: Id423dd6235bf14823fa5611b804c0974edbe64b3
A recent commit 6e70103d deleted some Any constructors and methods, and
updated all the places where these had been called - except it looks
like one call was missed, active only when building against Python 2.
Adjust this call following what was done for the Python 3 case.
Change-Id: I0f92b7476b617d9fdf0e5f698e363360497d115e
Reviewed-on: https://gerrit.libreoffice.org/24759
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(at least for LIBO_INTERNAL_ONLY), to help further reduce the occurrences of
sal_Bool across the code base
Change-Id: I70654a0cb56655984c717b7b894f26c9ab47536e
are actually pointer vars.
Also convert from regex to normal code, so we can enable this
plugin all the time.
Change-Id: Ie36a25ecba61c18f99c77c77646d6459a443cbd1
Reviewed-on: https://gerrit.libreoffice.org/24391
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Searched source for using declarations.
Checked if those symbols reappear in the source file,
even in comments or dead code but not in #include statements.
If they don't reappear, remove the declaration.
Remove includes whose symbol got removed.
Change-Id: Ibb77163f63c1120070e9518e3dc0a78c6c59fab0
Reviewed-on: https://gerrit.libreoffice.org/24148
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
