| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I6c52316e46117aacb22a2adcb75841aed834041f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134705
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This commit was carried out by a Python script, source of which
is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97.
Change-Id: Icadf43a74e4ba99e587a1e6287adf8d65f819ca1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100144
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iba1282caadab91a0c6e1c044dbab5e6e15f3707b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93705
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...redux, after 8473ac2e27efff3ec902a358896a669ce05f047a "Elide use of
rtl_Instance (which is obsoleted by C++11 thread-safe statics)" had done the
same in parallel but forgot to remove some now-unnecessary parts:
There appears to be no good reason to control the lifecycle of the VtableFactory
instance via dso_init/exit, instead of via a plain static local variable.
This removes the need for the Windows DllMain functions. They also called
DisableThreadLibraryCalls, which disables the DLL_THREAD_ATTACH and
DLL_THREAD_DETACH notifications for the respective DllMain. Lets assume that
this was only done (as an optimization) because there had to be a user-provided
DllMain, and that it was not in itself a reason to have a user-provided DllMain.
(Most other DllMain across the code base that call DisableThreadLibraryCalls
also do something else. The only DllMain that only calls
DisableThreadLibraryCalls is the one in
shell/source/win32/shlxthandler/ooofilt/ooofilt.cxx, introduced with
3fbfb21e298ba506c50733d4aaefc7550bca2fe4 "INTEGRATION: CWS desktintgr02".)
Change-Id: I696e1c8d49060853c1a2c24f67469f6adfea6801
Reviewed-on: https://gerrit.libreoffice.org/85367
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Replace them with default initialization or calloc
Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1
Reviewed-on: https://gerrit.libreoffice.org/80805
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id1a0749b78a7021be3564487fb974d7084705129
Reviewed-on: https://gerrit.libreoffice.org/62718
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since cdecl is the default calling convention on Windows for
such functions, the annotation is redundant.
Change-Id: I1a85fa27e5ac65ce0e04a19bde74c90800ffaa2d
Reviewed-on: https://gerrit.libreoffice.org/46164
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
In this first commit, I use the plugin to verify the consistency of our
SAL_CALL annotations.
The point being to make the next commit more mechanical in nature,
purely using the rewriter.
There are various chunks of unix-only code that have never had to be
compiled by MSVC, hence the inconsistencies.
In bridges, I had to inline some typedefs to make the verification code
happy, since it cannot see into typedefs.
Change-Id: Iec6e274bed857febf7295cfcf5e9f21fe4a34da0
Reviewed-on: https://gerrit.libreoffice.org/45502
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I13df4e184a826682f34a1d9e974b601397ba4a3d
Reviewed-on: https://gerrit.libreoffice.org/43865
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icad98d3153a5b1710c8c2a2d338ba0129e9ff208
|
|
Change-Id: I8fb8e4fad4d6bfb4e24648833826f1a7e211b062
Reviewed-on: https://gerrit.libreoffice.org/43320
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iad47a01fd283345a2461eaaea50633bf840e5201
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I46bcc6eb1f34184626d2f584d7164d84f54c2cf8
Reviewed-on: https://gerrit.libreoffice.org/29879
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ibf313b8948a493043006ebf3a8281487c1f67b48
Reviewed-on: https://gerrit.libreoffice.org/25532
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
