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>
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...implying that pLocalThreadId, nRefCountOfCurrentId, pCurrentId are
initialized, implying that zero-initializing them during construction isn't
necessary.
Change-Id: I98399203694edde14abc664a82861ba50dfb357c
so we can remove unnecessary calls to the OUString(literal) constructor
when calling constructors like this:
Foo(OUString("xxx"), 1)
Change-Id: I1de60ef561437c86b27dc9cb095a5deb2e103b36
Reviewed-on: https://gerrit.libreoffice.org/33698
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...(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>
Despite being a 32-bit architecture, m68k has a basic
alignment of 16-bit for historic reasons. On m68k,
SAL_TYPES_ALIGNMENT8 is therefore equal to 2 and we
need to cover this case in the static asserts as well.
Change-Id: I4c756af25d57e5d49209697f6e678ef71a5845aa
Reviewed-on: https://gerrit.libreoffice.org/31878
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Depending on timing, it can apparently happen at least during
JunitTest_unordf_complex that a cppu_threadpool::ORequestThread having executed
a binaryurp::IncomingRequest holds the last binaryurp::Bridge reference:
> #2 0x00007fac4ad6bf97 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7fac4b4e8c22 "false", file=file@entry=0x7fac4b4eaec7 "sal/osl/unx/thread.cxx", line=line@entry=443, function=function@entry=0x7fac4b4eaefd "void osl_joinWithThread(oslThread)") at assert.c:92
> #3 0x00007fac4ad6c042 in __GI___assert_fail (assertion=0x7fac4b4e8c22 "false", file=0x7fac4b4eaec7 "sal/osl/unx/thread.cxx", line=443, function=0x7fac4b4eaefd "void osl_joinWithThread(oslThread)") at assert.c:101
> #4 0x00007fac4b4d5258 in osl_joinWithThread(oslThread) (Thread=0x7fabfc0011d0) at sal/osl/unx/thread.cxx:443
> #5 0x00007fac47fbdde5 in cppu_threadpool::ThreadAdmin::join() (this=0x7fac1c0069e0) at cppu/source/threadpool/thread.cxx:89
> #6 0x00007fac47fc23af in cppu_threadpool::ThreadPool::joinWorkers() (this=<optimized out>) at cppu/source/threadpool/threadpool.cxx:179
> #7 0x00007fac47fc35b7 in uno_threadpool_destroy(uno_ThreadPool) (hPool=<optimized out>) at cppu/source/threadpool/threadpool.cxx:499
> #8 0x00007fac25b03b5c in binaryurp::Bridge::terminate(bool) (this=0x7fac24117078, final=true) at binaryurp/source/bridge.cxx:277
> #9 0x00007fac25b0794e in binaryurp::Bridge::dispose() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:904
> #10 0x00007fac25b07215 in binaryurp::Bridge::~Bridge() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:847
> #11 0x00007fac25b07409 in binaryurp::Bridge::~Bridge() (this=0x7fac24117078) at binaryurp/source/bridge.cxx:838
> #12 0x00007fac25b39ee1 in std::default_delete<binaryurp::IncomingRequest>::operator()(binaryurp::IncomingRequest*) const (this=<optimized out>, __ptr=0x7fabfc00ba50) at /usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../include/c++/6.2.1/bits/unique_ptr.h:76
> #13 0x00007fac25b38fa8 in std::unique_ptr<binaryurp::IncomingRequest, std::default_delete<binaryurp::IncomingRequest> >::~unique_ptr() (this=0x7fac0bb74ac0) at /usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../include/c++/6.2.1/bits/unique_ptr.h:236
> #14 0x00007fac25b36d71 in request(void*) (pThreadSpecificData=<optimized out>) at binaryurp/source/reader.cxx:83
> #15 0x00007fac47fbaa95 in cppu_threadpool::JobQueue::enter(long, bool) (this=<optimized out>, nDisposeId=<optimized out>, bReturnWhenNoJob=<optimized out>) at cppu/source/threadpool/jobqueue.cxx:107
> #16 0x00007fac47fbe1f9 in cppu_threadpool::ORequestThread::run() (this=0x7fabfc001160) at cppu/source/threadpool/thread.cxx:165
> #17 0x00007fac47fbf9ca in threadFunc(void*) (param=0x7fabfc001170) at include/osl/thread.hxx:185
> #18 0x00007fac4b4d5a3c in osl_thread_start_Impl(void*) (pData=0x7fabfc0011d0) at sal/osl/unx/thread.cxx:240
> #19 0x00007fac4ab2a5ca in start_thread (arg=0x7fac0bb75700) at pthread_create.c:333
> #20 0x00007fac4ae420ed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
while the main thread is already shutting down:
> #19 0x00007fac4b14100f in desktop::Desktop::doShutdown() (this=0x7fff8a6149d0) at desktop/source/app/app.cxx:1783
> #20 0x00007fac4b13f505 in desktop::Desktop::Main() (this=0x7fff8a6149d0) at desktop/source/app/app.cxx:1716
> #21 0x00007fac419a0f79 in ImplSVMain() () at vcl/source/app/svmain.cxx:185
> #22 0x00007fac419a1c14 in SVMain() () at vcl/source/app/svmain.cxx:223
> #23 0x00007fac4b17c773 in soffice_main() () at desktop/source/app/sofficemain.cxx:166
> #24 0x0000000000400916 in sal_main () at desktop/source/app/main.c:48
> #25 0x00000000004008fb in main (argc=<optimized out>, argv=<optimized out>) at desktop/source/app/main.c:47
Change-Id: I34beac40e89f6d522af49f9dcdb3ed2fc1259c4b
i.e., css::uno::Any function template specializations
Any::has<Any>() const
Any::get(Any const &) const
operator >>=(Any const &, Any &)
operator <<=(Any &, Any const &)
that don't make much sense (the first is always true, the rest can be replaced
with operator =, which additionally supports move semantics). For 3rd-party
compatibility, do this only for LIBO_INTERNAL_ONLY, however.
However, some generic template code did benefit from operator >>= working also
for Any, so make up for that with a new (LIBO_INTERNAL_ONLY, given that
operator >>= still covers if fine for !LIBO_INTERNAL_ONLY) fromAny,
complementing the existing toAny.
Change-Id: I8b1b5f803f0b909808159916366d53c948206a88
Reviewed-on: https://gerrit.libreoffice.org/30022
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
... except in include/rtl, include/sal, include/uno, where sal_Size is
retained for compatibility, and where callers of rtl functions pass in
pointers that are incompatible on MSVC.
Change-Id: I8344453780689f5120ba0870e44965b6d292450c
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "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
follow-up to 7fa183cb1a04120b37069c63166182065c3d975c
"loplugin:countusersofdefaultparams in chart2..desktop"
Change-Id: I099229ac4a3670e26570b083e3b0a4a92984f663
uno::Reference is only allowed to used with classes that have a
::static_type member.
So convert all those places to rtl::Reference.
Maybe we need some LIBO_INTERNAL_ONLY constructors on rtl::Reference and
uno::Reference to make this a little smoother?
Change-Id: Icdcb35d71ca40a87b1dc474096776412adbfc7e3
Reviewed-on: https://gerrit.libreoffice.org/25516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
...which (in LIBO_INTERNAL_ONLY) for Clang expands to [[clang::fallthrough]] in
preparation of enabling -Wimplicit-fallthrough. (This is only relevant for
C++11, as neither C nor old C++ has a way to annotate intended fallthroughs.)
Could use BOOST_FALLTHROUGH instead of introducing our own SAL_FALLTHROUGH, but
that would require adding back in dependencies on boost_headers to many
libraries where we carefully removed any remaining Boost dependencies only
recently. (At least make SAL_FALLTHROUGH strictly LIBO_INTERNAL_ONLY, so its
future evolution will not have any impact on the stable URE interface.) C++17
will have a proper [[fallthroug]], eventually removing the need for a macro
altogether.
Change-Id: I342a7610a107db7d7a344ea9cbddfd9714d7e9ca
...which itself only contains a "break" (or nothing at all at the end of the
"switch"), as otherwise Clang -Wimplicit-fallthrough would warn about these.
Change-Id: I25c1cf2ca74dfeba7ca0385ca8f1c1bf30bbf91b
The option /Zc:wchar_t- prevented to use wchar_t as a built-in type
according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t
was not implemented as a built-in type, but was declared in wchar.h as
a typedef for unsigned short. Now, years later after the end of life
this outdated toolchain, there is no reason not to use native type.
The only issue could be the ABI compatibility. But on a quick look at
least, it looks like none of the mangled C++ symbols in the stable URE
interface actually depend on wchar_t.
We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice
5.2, though.
Change-Id: I8d6b380660859efa44c83c830734978d31d756a0
Reviewed-on: https://gerrit.libreoffice.org/22589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
and related modules.
Replace with C++11 delete copy-constructur
and copy-assignment.
Change-Id: I18aa9fe4ff696f9b5472cbe4cd0097cb174618b7
Reviewed-on: https://gerrit.libreoffice.org/23904
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Including no keywords from extern "C" blocks
Change-Id: I18ddafbf3d41f6779fb43e36ba1f1c48b37757a0
Reviewed-on: https://gerrit.libreoffice.org/23671
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and x86 has smaller alignment than arm or a x86_64 host,
so needs the MAX_ALIGNMENT_4 to not trigger the static_asserts
Change-Id: I5643a33e4975e7bad20693f99fb8bbd5248c7c1c
It is to improve the readability of calls to osl::Condition::wait.
Change-Id: I5945343c5a7e4729ab599380414d18280bd176fe
Signed-off-by: Gurkaran <gurkran@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/23417
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
and avoid to retrieve list->begin and loop from the first element
Change-Id: I536b7a03c4033b02a7226d25f64764c10c28bdd0
Reviewed-on: https://gerrit.libreoffice.org/23126
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
