...and remove some unncessary using directives/declarations, in preparation of
removing now-unnecessary #includes from cppumaker-generated files, post
e57ca02849c3d87142ff5ff9099a212e72b8139c "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>
During the conversion of uno services a few lines where removed that
probably should not have been removed. This caused the dialog editor
to crash if you tried to add a new language resource to a document
fdo#93077. The fix for that bug fixed the crash but also made it
imposible to add a language resource to a dialog that isn't previously
translated.
With this patch the functionality should be back on track, adding/removing
language resources without problems at least as far as my testing goes.
Change-Id: Ie6e083837894a219bf8e9c75dec6bf7652d51615
Reviewed-on: https://gerrit.libreoffice.org/30462
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
... 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
... so that the library is stored (and encrypted), and not copied
unencrypted from source storage.
Change-Id: I9546087ec6f07007aa1ec377d2e959f2bae99a38
If the Basic library is newly created it may not have been stored to the
document storage yet.
(regression from 5246fa262450f686674850c53df666422f441c86)
Change-Id: I9c2fc1d7446795b9c1c2224671118b2a671dcad8
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>
no version bump but B_USERTYPE defined
fix test from commit de26ef85 that should be nMaxRecords
tested full round trip on password protected document (ie. use binary storage)
master --(0)--> master --(1)--> libreoffice 4.4 --(2)--> master --(3)--> master
(0) in master, User type supported, big module supported
(1) in libreoffice 4.4, user type not supported, big module supported, no loss of code
(2) in master, user type not supported, big module not found, no loss of code
it is OK as libreoffice 4.4 saves to LegacyVersion
(3) in master, User type supported, big module supported (all is restored)
it is OK as module was saved with CURRENT_VERSION (see sbxmod.cxx)
Change-Id: I237cf7de70adf1a755be1bc30987b21c43b6ab35
Reviewed-on: https://gerrit.libreoffice.org/17871
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
This was a feature requested by mmeeks, as a result of
tdf#92611.
It validates that things that extend XInterface are not
directly heap/stack-allocated, but have their lifecycle managed
via css::uno::Reference or rtl::Reference.
Change-Id: I28e3b8b236f6a4a56d0a6d6f26ad54e44b36e692
Reviewed-on: https://gerrit.libreoffice.org/16924
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
