| Age | Commit message (Collapse) | Author |
|---|
|
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t
backward compatibility remediation", as implemented now by <https://gcc.gnu.org/
git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++:
P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads
that would print an integer rather than a (presumably expected) character.
But for simplicity (and to avoid issues with non-printing characters), keep
printing an integer here.
Change-Id: I751b99ee32d418eb488131ffa130d6f7d6d38dc7
Reviewed-on: https://gerrit.libreoffice.org/84348
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 5d8f0fad50f90195a11873c70ddab4644f5839ea)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87760
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which had accidentally been broken with
87707670c993794ab12b0fad0f048f11429269c2 "Make OUStringLiteral more useful".
(std::strlen unfortunately isn't constexpr, so need to use an explicit loop
instead.)
Change-Id: I9a820e2940b99a0c37124477810ef879d82c8325
Reviewed-on: https://gerrit.libreoffice.org/59344
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I539ca8b9dee5edc5fc2282a2b9b0ffd78bad8b11
|
|
Change-Id: I1b7c3f8de5b09c96e27aa9124096b00638afb3f3
|
|
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>
|
|
...after 84b36c704d73362d4d86dc9e9c0efa0625958347 "Drop support for MSVC 2013".
Make this a fatal configuration error for now. The check should be removed
completely after LO 5.4 branch-off.
Change-Id: If2f196abb93607dde9ba5c4f04d219679585e633
Reviewed-on: https://gerrit.libreoffice.org/34822
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>
|
|
Change-Id: Iefc33784f21e7a0b88c8d6308618926e38ab8554
|
|
...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
|
|
Change-Id: I2692ba63f010b61e7b4c1fe54368f4dac9c42d60
|
|
And also address a few new warnings in sal, plus silence such warnings
in salhelper till we can't print typeids out of the box.
Change-Id: I38049146710b6885f6a874bf74eedbc38b4d4651
Reviewed-on: https://gerrit.libreoffice.org/29809
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...which has HAVE_CXX11_UTF16_STRING_LITERAL but cannot use chart16_t string
literals with ConstCharArrayDetector (which uses sal_Unicode) as long as
sal_Unicode is still wchar_t instead of char16_t for MSVC.
Change-Id: I7c55e0361d1c8c717467d5ab6c942bce3569f3a7
|
|
...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
|
|
...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>
|
|
Change-Id: I9f9b647ed73e06a5e926eff8f95dda92fec134c0
Reviewed-on: https://gerrit.libreoffice.org/27177
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...to avoid bogus -Werror=unused-result from trunk GCC in the macro expansion.
Change-Id: I227a0edfb22255c31d285609761dbefb4e50e09a
Reviewed-on: https://gerrit.libreoffice.org/26004
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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
|
|
Change-Id: Iad01e628b692a6dcf882696908de0ef1f24c04c4
|
|
Change-Id: I9414d9167213c0156fb97559a8af5e55a4e1c1de
|
|
Change-Id: I09049db51668176b90dabe2c82d525b2fab60299
|
|
...for cases where ? "a" : "bb" does not work, as well as to work around the
MSVC bug for cases like ? "a" : "b".
Change-Id: Id404716047aca5cc81440f291616d92365379b8f
|
|
...to use single ASCII character literals "more directly" in the OUString API
(instead of having to go via an intermediary OUString ctor call). Especially
useful for character literals that are defined as const variables or via macros
("direct" uses of character literals in the OUString API can often simply be
replaced with single-character string literals, for improved readability).
(The functions overloaded for OUStringLiteral1 are those that are actually used
by the existing LO code; more could potentially be added. The asymmetry in the
operator ==/!= parameter types is by design, though---writing code like
'x' == s
is an abomination that shall not be abetted.)
Change-Id: Ic5264714be7439eed56b5dfca6ccaee277306f1f
|