Age | Commit message (Collapse) | Author |
|
Change-Id: I256a807dd2a4c81126b5a76f3d472e31b8224146
Reviewed-on: https://gerrit.libreoffice.org/46652
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
For allowing the client to enable/disable the new range based header
data
Change-Id: I95da8ec3e48137fb75b9b22af3bb1296001ba9ca
Reviewed-on: https://gerrit.libreoffice.org/46095
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 069cf9321be51e7203e336e0e87d8ba7dc9b729e)
Reviewed-on: https://gerrit.libreoffice.org/46570
Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>
Tested-by: Marco Cecchetti <mrcekets@gmail.com>
|
|
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and remove duplicate method
Change-Id: Ic513a780f3b9b526c3abd0f273ad9c230ffbb373
Reviewed-on: https://gerrit.libreoffice.org/46233
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
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>
|
|
and some more in base64.cxx
Change-Id: I31c9f23d3bd11f5482774e976a7c40025ffcfb86
Reviewed-on: https://gerrit.libreoffice.org/46157
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
variableScope reports in comphelper/drawinglayer/editeng
+filter/framework/l10ntools
Change-Id: I4575428773e8b9b3efedabb44fdcd6d8175ac46a
Reviewed-on: https://gerrit.libreoffice.org/46116
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I88647a66a72d092303560a4348ce3dc55ee6c321
Reviewed-on: https://gerrit.libreoffice.org/46055
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I6f085b67c3477f427bd1efd96db93cbb89e20647
Reviewed-on: https://gerrit.libreoffice.org/46050
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I3241426674050c027e1b000b33fb284525a58cbb
|
|
And pass down all necessary parameters everywhere
Change-Id: I152b9d84c0e35be9e5193a9a6f67de9fb86133b0
|
|
OpenPGP encryption needs to pass down slightly different meta data
to package / zip storage.
Change-Id: Idba9ad7a821cb33070cf5e5a0f79ae55db99b276
|
|
first, since those are safer to change than virtual methods
Change-Id: Ie3b624019d75ee2b793cee33b3c5f64e994e8bfe
Reviewed-on: https://gerrit.libreoffice.org/45798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Otherwise browsers don't recognize base64 encoded svg files.
Change-Id: I54d0b87c52a1ca9da1d820751ae32159b88ed28f
Reviewed-on: https://gerrit.libreoffice.org/45528
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Pass down mimetype to SvXMLGraphicHelper
Change-Id: I9c81c06d2a1d6168704440094081e99d0bcbbff9
Reviewed-on: https://gerrit.libreoffice.org/41893
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: Ie56daf560185274754afbc7a09c432b5c2793791
Reviewed-on: https://gerrit.libreoffice.org/45068
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which had been left out because "lots of our code uses this style, which I'm
loathe to bulk-fix as yet", but now in
<https://gerrit.libreoffice.org/#/c/45060/1/> "use std::unique_ptr" would have
caused an otherwise innocent-looking code change to trigger a
loplugin:unnecessaryparen warning for
pFormat = (pGrfObj)
? ...
(barring a change to ignoreAllImplicit in
compilerplugins/clang/unnecessaryparen.cxx similar to that in
<https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in
loplugin:simplifybool consistent", which should also have caused the warning to
disappear for the modified code, IIUC).
Change-Id: I8bff0cc11bbb839ef06d07b8d9237f150804fec2
Reviewed-on: https://gerrit.libreoffice.org/45088
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia544298334364ece3b3963a4adc00c5e01189b91
Reviewed-on: https://gerrit.libreoffice.org/44654
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Page <aptitude@btconnect.com>
|
|
Change-Id: Ib32e3ca6ba55ab99820a54023041247cea96ab0c
Reviewed-on: https://gerrit.libreoffice.org/44652
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
No need to create helper for those methods.
Change-Id: I0505fe8141b1bad852b7f30aeb69628fb6a90071
Reviewed-on: https://gerrit.libreoffice.org/44649
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...a using declaration should fix it just fine
Change-Id: I0279994c155775e9a58e93aef8da4522d4fd93fd
Reviewed-on: https://gerrit.libreoffice.org/44590
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
convert ServiceInfoHelper to a namespace, since the only usage is to
call it's static method
Change-Id: I908bdbc06cbdb6b72ee1ae469ff207b2fca69963
Reviewed-on: https://gerrit.libreoffice.org/44533
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0cc0455a97be2e0cd84ccadba1f3745b584e1f33
Reviewed-on: https://gerrit.libreoffice.org/44461
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
https://msdn.microsoft.com/en-us/library/ms679351 describes that
"it is unsafe to take an arbitrary system error code returned from an API
and use FORMAT_MESSAGE_FROM_SYSTEM without FORMAT_MESSAGE_IGNORE_INSERTS"
Previously in case when an error string would contain inserts, function
returned error, so the error message wasn't shown (at least it didn't
crash, thanks to nullptr as the function's last argument).
As the function may fail, we now pre-nullify the buffer pointer to avoid
dereferencing uninitialized pointer later (though at least for some
Windows versions, the function nullifies the pointer in case of
FORMAT_MESSAGE_ALLOCATE_BUFFER, but there's no explicit guarantee of this).
Also release of allocated buffer is changed to recommended use of
HeapFree.
The code that doesn't make use of OUString is left directly calling
FormatMessage, to avoid introducing new dependencies. Where it makes
sense, we now use WindowsErrorString from <comphelper/windowserrorstring.hxx>
Change-Id: I834c08eb6d92987e7d3d01e2c36ec55e42aea848
Reviewed-on: https://gerrit.libreoffice.org/44206
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I24a3ecd2ea9fe7e08c92b95aac57a58b922616b2
Reviewed-on: https://gerrit.libreoffice.org/44054
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6683ab0d39dbbb5c0ba0958d72f0a1bbfab47164
Reviewed-on: https://gerrit.libreoffice.org/43954
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I27a860fbbedd2174c60c199af18cae76e02abc25
Reviewed-on: https://gerrit.libreoffice.org/43759
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9297bd0449633d1055125e7c2f2f6d215a22ae7d
|
|
no need to explicitly specify it anymore
Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec
Reviewed-on: https://gerrit.libreoffice.org/43567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6f4b891a016c67051efd9033329065d7e3c8a06b
Reviewed-on: https://gerrit.libreoffice.org/43022
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: Ia23dafd07133779144965682df3b7125a3214235
Reviewed-on: https://gerrit.libreoffice.org/43046
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: If81cd3d4508ba3f44304a9ec9b643bf771e8930c
|
|
Change-Id: I4a1f04b9dfe9e3ebbc174380db93c332e958ccfa
Reviewed-on: https://gerrit.libreoffice.org/43060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
For now, just invalidate the whole dialog whenever any of the controls
in the dialog get invalidated.
Since during dialog painting, many such invalidations are triggered,
don't listen to them when we are painting.
Change-Id: Ia8fc12cf9469691d60e91ef770d687e5ff01a7ef
|
|
if we're going to throw the base class of the exception hierarchy,
we can at least put a useful message in there to make the source a little
bit easier to locate.
Change-Id: I2f3106c99ba25125eacef8fa77e2f3a2c89f2566
Reviewed-on: https://gerrit.libreoffice.org/42968
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I5c7d107a05deb06749b4d04246ba183adfafb14d
Reviewed-on: https://gerrit.libreoffice.org/42829
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I879a52820d78d9151ef64dd21612379f617f66e2
Reviewed-on: https://gerrit.libreoffice.org/42726
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Change-Id: Iabab71ee076227bc38447ec109afaea1e53a86a6
Reviewed-on: https://gerrit.libreoffice.org/42643
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I69d4157aaf6570cecd51ea59df20556914942e06
Reviewed-on: https://gerrit.libreoffice.org/42565
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
It uses random-access iterators, so just use O(1) increments
Change-Id: I9f80789d0bc03184d346c6814fd015bc06876acd
Reviewed-on: https://gerrit.libreoffice.org/42606
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I674cad57ce30a885e126d3bcc921f8fcb53dc36d
Reviewed-on: https://gerrit.libreoffice.org/42577
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
All backends implement the SolarMutex in mostly the same way.
So this consolidates this code into a GenericSolarMutex.
We still need the abstract SolarMutex class for the fake AKA
fascade implementation in dbaccess.
The patch also replaces various places of direct mutex usage with
either SolarMutexGuard or SolarMutexReleaser objects.
Change-Id: Ia0146dd6c51a3b9a513cc6af34a66def58aad831
Reviewed-on: https://gerrit.libreoffice.org/42325
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...like 74cd94a17b3922bdcd44ab6460232297fbf665d0 "Put back some #include (needed
for e.g. --disable-pch)" (this one having caused loplugin:unreffun with
clang-cl)
Change-Id: I1a888ca754365232663fed0b99535d91fded040a
|
|
Change-Id: Ie309f907220ffb69585442a1ae456623debf6654
Reviewed-on: https://gerrit.libreoffice.org/42303
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I419d1f67ba301050d05981db2a3d6178878684a9
Reviewed-on: https://gerrit.libreoffice.org/42110
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...at least ever since the "new" configmgr reimplementation,
6b849a6aeeb9ea8b1e25e28d5a8be390e425f84e "#i101955# initial work in progress of
a configmgr reimplementation (for now in an extra module 'configmgr2')" et al
Change-Id: I43430d991647fb2e26762463d51175247db0604b
|
|
(In some DBG_UTIL code.)
Change-Id: I2f09c46186154551bfed5f711bd3b03efbf81053
Reviewed-on: https://gerrit.libreoffice.org/41909
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I699ecff1f62b3dae7ac275823c6721810589c4cf
Reviewed-on: https://gerrit.libreoffice.org/41507
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Idba9ad7a821cb33070cf5e5a0f79ae55db99b276
Reviewed-on: https://gerrit.libreoffice.org/41504
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
Why not let the computer do it, instead of having to do it by eyeball?
It is not fun to look at numbers like 1503910660.06171 and
1503910665.5169 and try to see whether their difference is larger than
that of 1503910824.20391 and 1503910828.43125.
Change-Id: If20882e97959e65b8518b66c4ae965e1b3cc3b51
|