Age | Commit message (Collapse) | Author | Files | Lines |
|
...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>
|
|
Change-Id: I65ab9176b39a436afce23e6bd4423ebf76219166
|
|
nullptr_t""
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>
|
|
This reverts commit 2e3f5c8dd3b21efe83269f603e26ac20f3adde64, some GCC
have trouble with deleted friend functions; need to fix that properly.
|
|
...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
|
|
Change-Id: Ic96b64244f817196ccdfe06b97f7f31291adf372
|
|
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>
|
|
...by adding more assign op overloads instead
Change-Id: I3686d6c29adc47b1a8c48be4260614fd53589c8b
|
|
...by adding more assign op overloads instead
Change-Id: I2d2e1b7f19d1b57528707ed5a5cce94b5fa5c2d0
|
|
...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>
|
|
...not merely an ASCII character
Change-Id: Id2b381b35fe3a15574728ed973d60263dfef7249
Reviewed-on: https://gerrit.libreoffice.org/28446
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>
|
|
...Except[Const]CharArrayDetector, under RTL_STRING_UNITTEST
Change-Id: Ib185fb8406c4afcff1c854a2b74dae02a0ee2b3f
Reviewed-on: https://gerrit.libreoffice.org/28444
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Callgrind tinderbox complains that "string" shadows some global, so
let's try "rString" instead.
Change-Id: I3973f23ef6e8ebf861d66012fede84cb8a685be8
|
|
These aren't used any more, and the C++11 std equivalents don't use
get_pointer() overloads.
Change-Id: Ib97a6a595863e21a1621c63709ea2b28f6550fde
Reviewed-on: https://gerrit.libreoffice.org/24982
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I1f127d56e40b04f2b4df85c0afbcfd424d68a8cc
|
|
Change-Id: Ic7c14c2e39a5ade1f5622a8350f9197d84cf9cc8
|
|
...and fix its documentation, and use it throughout the code base.
Change-Id: I349bc2009b1b0aa7115ea90bc6ecd0a812f63698
|
|
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>
|
|
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86
Reviewed-on: https://gerrit.libreoffice.org/21209
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@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>
|
|
Change-Id: Icdc5f7137cca8360f116d5d4c7b0bf4a4c526e1d
Reviewed-on: https://gerrit.libreoffice.org/20712
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I9bc06cfb5eeb38fd7ae7fb25f876ea9f96e4a65a
|
|
Change-Id: I14c2dc0be12151b5d4ea2ba3b65030f6f4494905
|
|
...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>
|
|
Change-Id: I2f79e52da2aa0ad3a37aac07a36dbe14dfe401a9
|
|
Change-Id: Iafd6e5f899835303e421be923f70d1e3f42bf65e
|
|
Change-Id: Id2359f6ff4bddb2afbc0b346e17cd858f00179e3
|
|
Change-Id: I1bc6c87fcd6e5e96362623be94c59be216a3b2b8
|
|
...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
|
|
Change-Id: Ifeaddeac673366b4eacc55ce6f2a74a2553ac927
|
|
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>
|
|
Change-Id: Id66432ef80fc2963fd2cbc6fad5d8e135e8975b0
Reviewed-on: https://gerrit.libreoffice.org/18956
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
Tested-by: Oliver Specht <oliver.specht@cib.de>
|
|
...analogous to the existing OUString::startsWihtIgnoreAsciiCase, to be used in
the next commit
Change-Id: Iad6989c16e1bda6b2b0a58e6c768f7852560bb00
|
|
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
|
|
Change-Id: Ifabb905819e32cf4db603f3f7bb18e6cc8fdfdcf
|
|
Change-Id: I56e69fbdb555bb30cd88d75717d6f716c81ae237
Reviewed-on: https://gerrit.libreoffice.org/16804
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
(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
|
|
Change-Id: I70b03c152f63e48341dc5629a99b0eeab7b497c0
Reviewed-on: https://gerrit.libreoffice.org/16834
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ie2bbe020fc6e3a4a4f913208c245f395849bb9ee
Reviewed-on: https://gerrit.libreoffice.org/16708
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
...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
|
|
Change-Id: Ib34196185f90204a71598f2c659c3fddce7a0e4d
|
|
Change-Id: I70acf02c36ced3ff19f424768f293f2221ef7af5
|
|
Change-Id: I889aa10e0cb7b5779527e5ef2be5d707dd493e90
|
|
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."
|