.. to more explicit SvStream::Write* calls
This was done using another run of the clang rewriter, and then
a lot of hand tweaking to fix all the places where the rewriter
did not play nice with various macros.
Change-Id: I7bcab93851c8dfb59cde6bc76290c6484d88fb18
Reviewed-on: https://gerrit.libreoffice.org/7494
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
...is lost to history, but they are effectively equivalent to pssing default
SorageMode nStorageMode = 0 today, as the only thing that is done with that
nStorageMode value (in SotStorage::CreateStorage, sot/source/sdstor/storage.cxx)
is to compare it against STORAGE_TRANSACTED (0x04) STORAGE_CREATE_UNPACKED
(0x44).
Change-Id: I6ce79c03aff941b5abb5370e52a30b2294690b3a
This is in preparation for more conversion of SvStream::operator<< calls
to use more explicit method names.
This converts the subclasses that have their own convenience overloads
of operator<< to use normal methods.
Change-Id: I5efd5d9a24c264cb86d2471303dd5849bf91ba80
This is the actual re-write.
Use a clang rewriter to rewrite SvStream::operator<< to methods
like WriteuInt32.
Note that the rewriter is not perfect, and I hand-tweaked the output.
In particular, I had to adjust places doing things like
(*this) << 1;
Change-Id: I5923eda3f4ebaa8b452b6ef109e726e116235a2a
Reviewed-on: https://gerrit.libreoffice.org/7342
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
- this renames the 'almost' module target to non-l10n
- and adds a l10n target which is intended to only build l10n parts of
the product
- packagers should then be able to build l10n and non-l10n parts of the
product independently, thus:
- enable quicker rebuilds
- distribution of load
- updates to l10n without a full rebuild
- security fixes to binaries without rebuilding all l10n
- the new targets are called build-l10n-only and build-non-l10n-only
- note this is not intended to move a concept of split packages
upstream -- while this exsists in distros, the number of test
scenarios for this would explode upstream
Change-Id: Ib8ccc9bc52718d9b0ebbfee76ad93dc29c260863
Conflicts:
filter/Module_filter.mk
Convert code like
aStr.compareToAscii("XXX") == 0
to
aStr.equalsAscii("XXX")
which is both easier to read and faster.
Change-Id: I448abf58f2fa0e7715dba53f8e8825ca0587c83f
This is both an optimisation and a cleanup.
This converts code like
aStr.indexOf("XX") == 0
to
aStr.startsWith("XX")
and converts code like
aStr.lastIndexOf("XXX") == aStr.getLength() - 3
to
aStr.endsWith("XXX")
Note that in general
aStr.lastIndexOf("X") == aStr.getLength() - 1
converts to
aStr.isEmpty() || aStr.endsWith("X")
so I used the surrounding context to determine if aStr could be empty
when modifying the code.
Change-Id: I22cb8ca7c2a4d0288b001f72adb27fd63af87669
There were only a couple of real bugs fixed, but we're a little
bit safer now.
This also fixes the assert and the comment in OUString::operator[]
about this.
Change-Id: Ibe16b5794e0ba7ecd345fa0801586d25b015974c
