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
...where their use of boost::shared_ptr (instead of std::shared_ptr) matches the
use in libcmis, but makes them unlikely to be useful anywhere else. So move
them into ucb/source/ucb/cmis/.
Change-Id: I68359be6b43d6889af4f241dcdcbdc0d9d70d717
triggered when I noticed a class doing acquire() in the
constructor and then release() in the destructor.
found mostly by
git grep -n -B5 -e '->release()'
Change-Id: I96e43a3d30ffd9ae9a34275f24cd914d8f7b026f
Reviewed-on: https://gerrit.libreoffice.org/25806
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
triggered when I noticed a class doing acquire() in the constructor and
then release() in the destructor.
found mostly by
git grep -n -B5 -e '->release()'
Change-Id: Ie1abeaed75c1f861df185e3bde680272dbadc97f
Reviewed-on: https://gerrit.libreoffice.org/25363
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
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
create an InterfaceContainer2 class to replace InterfaceContainer.
It uses a std::vector instead of a Sequence for the mutable listener
list, which provides far better performance.
Switch all our internal use-sites to the new class.
Change-Id: I6b56cfa511ded2395faa22e68fab3b2f16c3cb88
Changes done to the code in sfx2, ucbhelper, ucb, unotools in no particular order
- add method helpers to call the ucb lock/unlock
- add lock/unlock 'real' management
- make DateChange property retrieval working for WebDAV as well
- add check for changed content of a WebDAV file, in order to reload
it correctly when 'Edit Mode' command is activated from GUI
- Unlock WebDAV file while saving only if explicitly enabled
Needed in order to avoid the small window of file unlocked state that
opens while saving a file.
When saving LO actually does as follows:
- unlock the prevoius version of the file
- prepares operations to save the modified version
- lock the new file
- save the new version
- the lock method is enabled if the DAV resource supports it.
In case the lock is not supported, for example example DAV with lock
disabled, the lock method is disabled.
Exception: when the resource is first created and the lock is not
supported: a lock command is sent anyway, because if the resource is not
yet present, there is no method to detect the lock/unlock availability
in this case.
- cppcheck:noExplicitConstructor
Change-Id: I0aa876c4e3364d86e5740977b97f3db9a01e4491
Reviewed-on: https://gerrit.libreoffice.org/17189
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
