There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that would implicitly be sign extended (for plain char only if it is signed),
so non-ASCII char values would trigger the isUnicodeCodePoint assert.
Change-Id: Iaf8024ad509e64525558e882fe3fd078cfb4ea91
Reviewed-on: https://gerrit.libreoffice.org/35523
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so that later passing the OStringBuffer's aNum[i] to
createSevenSegmentPolyPolygon (taking a first parameter of type char) doesn't
need to implicitly convert from sal_Unicode to char.
Requires addition of some missing OStringBuffer-related function variants in
rtl/math.hxx and rtl/strbuf.hxx.
Change-Id: I79e6b2a791abc62b6556a6668e4411cced490c11
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by:
* making the OUStringLiteral ctor non-explicit (to be exploited in a follow-up
commit)
* adding (LIBO_INTERNAL_ONLY) overloads to OUString/OUStringBuffer functions
that can now take OUStringLiteral in addition to taking "real" string literals
(Keeping the number of overloads smaller by replacing the ConstCharArrayDetector
overloads with ones taking OUStringLiteral (for LIBO_INTERNAL_ONLY, at least)
and relying on the now-implicit conversion from "real" string literals to
OUStringLiteral unfortunately would not work: Both OUString and OUStringLiteral
argubably need implicit conversions from "real" string literals, so any function
overloaded for OUString and OUStringLiteral would be ambinguous when called with
a "real" string literal. And removing the OUString ctor taking a "real" string
literal and relying on an implicit conversion chain from "real" string literal
to OUStringLiteral to OUString doesn't work because it would involve two user-
provided conversions.)
Change-Id: I14433fc1605b048807f60b3a3e14f92221d3a226
Reviewed-on: https://gerrit.libreoffice.org/32097
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit e559c0c9cbfd819f22ef695a9823bb71f4385b58; just turn the
deleted overloads into non-friend functions (and rely on any other overloads to
be still found via ADL).
Change-Id: I2af834162cab2e71ed9e32ae6903bc9f86d77ba2
Reviewed-on: https://gerrit.libreoffice.org/30441
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...now that
1b98f38 css.xml.sax.XAttributeList is broken by design
074defe Strange OUString null check
a24105a Nonsensical OUString null check
9799fe3 Nonsensical OUString null check
d6b9fea Nonsensical OUString null check
f2de7d0 This apparently always wanted to check that _rChars.trim() is non-empty
a8cfc97 SvxBrushItem::GetGraphicLink no longer returns a pointer
are fixed. (OString didn't have this problem with overloaded operator ==/!=,
but had a similar issue with nullptr_t that OUString in turn didn't have,
f20162304d73bc01955e9ef6506c3bd1c7016c48 "Rule out OString(std::nullptr_t)".)
Change-Id: I4ca0e1f5a911448e7bc9b8c5dddff5993d61ef18
...as
OStringBuffer b("foo"); b = "bar" + b;
doesn't work as one might expect (see the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2016-October/075464.html>
"concat of OUStringBuffer". That feature was LIBO_INTERNAL_ONLY, anyway. And
of the affected places, MethodDescriptor::getSignature
(codemaker/source/javamaker/javatype.cxx) was the only one that would actually
have benefitted.
Change-Id: Ib84266f43e40c42c2e428f0c0616db8cfa90adff
follow-up to 2135eae2a97c17d89cb47a2074830fd2d7b2226f "let approxEqual() not
scale too early for large representable integer values"
Change-Id: I628e01297fea08915d0ca1c95f3ba13f7ce15db8
And since this is now too much code for inline move implementation to math.cxx
Which again made it necessary to give libreofficekit lokdocview.cxx its own
implementation that doesn't even claim to build against sal ...
Change-Id: I0f80be9d9172ee20693b9babde715206f2c3d8c1
Reviewed-on: https://gerrit.libreoffice.org/29428
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
...which makes it more flexible, can now also be used on non-const arguments.
The drawback of the argument no longer being a compile-time constant is remedied
by making the ctor constexpr.
Change-Id: Ia4903a2cc86791fece92eac0cb8406b6659dd19d
1. For DEFAULT_CHARSET/OEM_CHARSET, use correct encoding
based on LibreOffice Default Language for Documents setting
(Tools->Options...->Language Settings->Languages).
For that, two functions added to tencinfo.h, that map language
names to corresponding Windows ANSI/OEM encodings.
2. If charset is DEFAULT_CHARSET/OEM_CHARSET for Symbol font,
then always use RTL_TEXTENCODING_SYMBOL.
Unit test is included.
Change-Id: Ibff63e7a03dec42a9d2a74399936d6bc04f2ff1a
Reviewed-on: https://gerrit.libreoffice.org/28322
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The long-term benefit will be support of C++11 char16_t string literals (for
cases of string literals with non-ASCII content) once we drop any compilers that
don't support those yet. The short-term benefit is support for an improved
OUStringLiteral1 that accepts any sal_Unicode value, not just ASCII ones (see
next commit).
Change-Id: I3f8f6697d7eb62b5176b7e812b5a5113c53b83a4
Reviewed-on: https://gerrit.libreoffice.org/28445
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
