...by adding some further SAL_DLLPUBLIC_RTTI type annotations (cf.
b4f6b26b5a "SAL_DLLPUBLIC_RTTI for proper RTTI
visibility for LLVM") and by making sure relevant function types do not use
incomplete types in their parameter and return types (which would make the RTTI
hidden).
Change-Id: Id7aadcbc0704b9759968ae36266fc9ce11a2e340
Sadly cannot forward declare "struct {...} TimeValue;".
rtl/(u)?string.hxx still include sal/log.hxx but removing osl/diagnose.h
was painful enough for now...
Change-Id: Id41e17f3870c4f24c53ce7b11f2c40a3d14d1f05
Using it as a namespace in our rtl string headers breaks compilation
of cli_ure/source/climaker/climaker_emit.cxx (and other C++/CLI
sources we might have that include rtl string headers). Rename it to
'libreoffice_internal'.
Change-Id: Ieae68bd612b05d326d570945c1d08a54bf011852
8f8bc0dcf3 "Move string hash function into String
class" had introduced a new getHash64 that, besides returning sal_uInt64 instead
of just sal_Int32, didn't do sampling of only a handful of characters, but
always computed the hash over all characters (as the usage in SfxItemSet and
SdPage appears to require for either performance or approximated correctness).
However, it would be advantageous to keep the stable URE interface as small as
possible. Now, O(1) sampling was apparently considered state of the art when
the rtl string classes were first created, closely copying java.lang.String,
which at that time demanded sampling for hashCode(), too---but never sampling
more than 15 characters, with the obvious (in hindsight, at least) performance
catastrophes, so they changed it to O(n) somewhere along the way.
Based on that, this commit changes the existing hash functions to not do
sampling any more, and removes the newly introduced -64 variants again. (Where
the extended value range of sal_uInt64 compared to sal_Int32 was hopefully not
vital to the existing uses.)
The old implementation used sampling only for strings of length >= 256, so I did
a "make check" build with an instrumented hash function that flagged all uses
with inputs of length >= 256, and grepped workdir/{Cppunit,Junit,Python}Test for
hits. Of the 2849 hits encountered, 2845 where in the range from 256 to 295
characters, and only the remaining four where of 2472 characters. Those four
were from CppunitTest_sc_subsequent_filters_test, importing long text into a
cell, causing ScDocumentImport::setStringCell to call
svl::SharedStringPool::intern, which internally uses an unordered_set. These
results appear to justify the change.
Change-Id: I78fcc3b0f07389bdf36a21701b95a1ff0a0d970f
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
Updated the documentation for the new optional second parameter in the
O(U)String startsWith* and endsWith* methods so it is explicitly said
that it is only available since LibreOffice 4.2
Change-Id: I58758e4bae85eef07c578dd50d6e0279b49deaf5
Reviewed-on: https://gerrit.libreoffice.org/6649
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
GCC 4.8.2 warns when index is a subtraction expression; the real
problems in that case will be found by the "index >= 0" check.
Change-Id: Iac2796badf88b7bdf6c273ddb800a8af0d3eaa6a
...as there are many cases where the code later wants to obtain this part, and
esp. for the string literal variants it is awkward to calculate the length of
the literal again if this is coded with a following copy() call. Adapt some
code to use this new feature.
(Strictly speaking, the @since tags for the---backwards-compatibly---modified
functions are no longer accurate of course. Also, clean up some sal_Bool and
SAL_THROWS(()) that are unnecesssary cargo-cult here, and where the clean-up
should have no practical compatibility consequences.)
Change-Id: I43e5c578c8c4b44cb47fd08f170b5c69322ad641
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
...since gb_LinkTarget_NOEXCEPTIONFLAGS became unused with
e81b1f23c4 "remove
gb_LinkTarget_add_noexception_object."
Change-Id: I4a7275b5b26a9d4b6ded66efb52e6866e6e09cc3
...which has become necessary since bd60d41176
"Handle oveflow in O(U)String::toInt() functions" reduces values in the range
(SAL_MAX_INT32 .. SAL_MAX_UINT32] to zero, but some calls of toInt32(16) relied
on getting a correct (unsigned) value for the whole input range ["0" ..
"FFFFFFFF"] (see libreoffice-4-1 commit 9bf6c83367cedb7be81bf67f30d2147d26c7a8c3
"Revert overflow checks in O[U]String::toInt{32,64} again").
Audited all uses of toInt32/64 with non-decimal radix. (There is still a TODO
comment in oox/source/helper/attributelist.cxx, and
stoc/source/typeconv/convert.cxx will still need some love and test code.)
Change-Id: Iadaca1c0e41dab553687d0ce41c20c10cd657a95
(Preventing documentation of macros via @cond ... @endcond is apparently at
least broken in Doxygen 1.8.3 and working in Doxygen 1.8.4.)
Change-Id: I2ee582119dba2c3d27db5298786d3076921af46d
