1. Allow character entity ( &#nnnn; ) to exceed 0xffff in HTMLParser::ScanText()
2. Return a character as sal_uInt32 ( utf32 ) instead of sal_Unicode ( utf16 )
from SvParser::GetNextChar().
Conflicts:
sw/qa/extras/htmlexport/htmlexport.cxx
Change-Id: Ida455040970fae800f0f11471b27f53461fb78e4
Reviewed-on: https://gerrit.libreoffice.org/21152
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>
Find a few million mis-predicted branches (according to callgrind)
and annotate them. Mark string acquire/release as hot, and a number of
deprecated methods as cold.
Change-Id: I678b3981794221c97f9ebb70fd0161c0fda5dceb
Odd problem, with MSVC 2013 in CppunitTest_smoketest in
sal/osl/w32/procimpl.cxx the read_environment calls std::stable_sort,
which turns about 89 elements into the empty string since commit
c9f6e12e7eb6a49389360626d206191147a174fb.
No idea what the problem is but let's disable the move for now.
Change-Id: I2912cd54a339bb6ab39922be516ea368a430f7c9
Reviewed-on: https://gerrit.libreoffice.org/20834
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
...in LIBO_INTERNAL_ONLY, __cplusplus, non-MSVC case.
It turns out that sal_Unicode happens to not be mangled into any symbols that
make up the stable URE interface, so (for LIBO_INTERNAL_ONLY, at least) we are
free to replace the typedef to sal_uInt16 with a typedef to any integral type
layout-compatible with that. (sal_Unicode does appear in some symbols in sal's
PRIVATE_textenc.1 section, but that is private between the sal and sal_textenc
libraries, so changing those symbols does not require a change of SONAME.)
C++11 chart16_t is the obvious choice (and will ultimately allow using u"..."
to write literals of type array-of-sal_Unicode). Reportedly, char16_t is
supported since GCC 4.4 and Clang 2.9 but will only be available in MSVC 2015.
For plain C, we continue to use sal_uInt16. We could theoretically use C11
char16_t from <uchar.h>, but at least the Mac OS X 10.11 SDK still does not
offer that C11 header.
For MSVC, we continue to use wchar_t (which is actually unsigned short, due to
/Zc:wchar_t-) for now. Potential options there include dropping /Zc:wchar_t-
and using true wchar_t, or using C++11 char16_t once support for MSVC 2013 is
dropped.
Some code needed to be adapted that was written in a way assuming that
sal_Unicode is unsigned short (which indicates that changing sal_Unicode for
non-LIBO_INTERNAL_ONLY would be an ABI change). OUStringBuffer::append can now
differentiate between being called with sal_Unicode (to append a single
character) and erroneously being called with sal_uInt16 (intending to append a
number's textual representation, for which the sal_Int32 overload must be used
instead). Bugs found are 379fe0409e7973b36210cffa3dd1dfd4032f0ecc "Assume that
this code wants to append a number, not a character" and
dc148335a6a438848325f24c49198fba81043279 "Assume this wants to append the
numerical representation."
The GDB support for pretty-printing of sal_Unicode-related data in
solenv/gdb/libreoffice/sal.py can presumably be simplified now.
Change-Id: I445b3a80e65b7cb004d9e08b38bdc9ee93bc9401
Reviewed-on: https://gerrit.libreoffice.org/20036
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...found regression e31205f3ec1f941ab5a188bfde6329edf2acc55b
"EditUndoRemoveChars::GetStr must return a reference" and dubious code
0e23f7b0839df68d277186b4df54ba391ac3406a "Lets assume this doesn't want to
update m_pForcedPrefix->GetText() anyway" in addition to the apparent sillies
directly fixed in this commit.
Introduces HAVE_CXX11_REF_QUALIFIER.
Change-Id: I564e98254fd53c1dd9b34193d7057c59721ee24c
Add move constructor and appropriately overloaded assignment operator to
rtl::Reference, and add basic unit tests for the reference counting of
rtl::Reference.
Change-Id: Ia7ff5d786bdf3b17709cec06608c91e22379746c
Reviewed-on: https://gerrit.libreoffice.org/19762
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
find places where we do not need to be passing a parameter to a
function, because that function has a default value which matches the
value we are passing.
Change-Id: I04d1fd6275204dd4925e6563282464f461123632
(This is no issue for OUString, as it has two ctors taking a single pointer
argument, so passing a null pointer is ambiguous anyway.)
Change-Id: I36f44b29eb84eb83e284fa080d706eabb4b485d5
...from most rtl/bootstrap.h functions. They are effectively only called from
C++ code (there is no plain C UNO binding), so it should be fine to let std
exceptions (like bad_alloc or length_error) propagate from their implementations
to call sites.
(The exception is rtl_bootstrap_args_close, which is typically called from C++
dtors, so should not throw anyway.)
This would strictly speaking be an [API CHANGE], but it should make no practical
difference whether a process terminates abruptly because an exception cannot
pass through a SAL_THROW_EXTERN_C() nothrow specification or because legacy
client code does not expect exceptions to be thrown from functions from which
SAL_THROW_EXTERN_C() has now been removed.
Change-Id: I08e8479e9c5731e46021aadd6a725c1793024d10
This reverts commit 5cba714b4d03ed54debf71534ad8c8edc383a01e, now including a
workaround for <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53658> "internal
compiler error -- segmentation fault."
Change-Id: I31f6d9ddcb0b884134703df2b9dc1800ba0a84be
This reverts commit 4d4f3512db0cf0bf47c2ba1b39c3813842903ef7, at least "gcc
version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux)" fails with
"include/rtl/stringutils.hxx:175:49: internal compiler error: Segmentation
fault."
...by making all places that accept a string literal via ConstCharArrayDetector
also accept an OUStringLiteral1 via ConstCharArrayDetector (which required some
tweaking of the ConstCharArrayDetector internals). That removes the need for
special-purpose OUStringLiteral1 overloads, and will allow OUStringLiteral1 to
be used in more places.
Change-Id: I370de8480e02f8423cde5677dd38479b81bccdb2
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, modifying the patch to
carefully keep the undefined behavior in the already existing additions that may
potentially overflow, instead of making the static_cast<sal_Int32> introduction
look like end - pData->buffer will be guaranteed to fit into sal_Int32 (which it
is not).
Change-Id: Id2fb64dc4585dae34257be6968a8905254a3b42d
...with numeric values that are not meant to be characters. Inspired by
<https://gerrit.libreoffice.org/#/c/16339/> "OUString: add constructor from
single Unicode code point" and ecaf1cb3861c1b519a1495487fc796884cf37b92 "seems
to be what was meant." Found e46e8d19458fd64ff20b1013e5eeabd07e62379c "Shall
this produce a string representation of a number?" and
f2a0e4032734d6be635f14ade3dea499c29ec6c2 "Don't truncate a UTF-32 code point to
a UTF-16 code unit."
(LIBO_INTERNAL_ONLY mostly because it uses a C++11 delegating ctor for
simplicity, but also because it requires mild modifications to client code, see
additional changes in this commit and some other recent commits.)
Change-Id: I8a156f01d1b772c6052d7afaa088ae13ed234e2b
Document that in README.lifecycle; the problem is that our constructors
currently take and release references left/right on the object being
created, which ... means we need an initial reference.
Change-Id: I5de952b73ac67888c3fbb150d4a7cde2a7bc9abf
Create 4 new formats enums rtl_math_StringFormat:
rtl_math_StringFormat_E1, rtl_math_StringFormat_E2,
rtl_math_StringFormat_G1, rtl_math_StringFormat_G2
to 1 or 2 digits in exponent for scientific notation.
Set General format to use rtl_math_StringFormat_E2.
Set trendline equation in status bar to use rtl_math_StringFormat_E1
Change-Id: I41466a6d4ba808ba5b9b38ba252b37c6b4560f12
Reviewed-on: https://gerrit.libreoffice.org/14562
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
