4b9e440c51
...from which an OString can cheaply be instantiated. The one downside is that OStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a containers that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::string_view, without loss of efficiency compared to the original OStringLiteral, and without loss of expressivity (esp. with the newly introduced OString(std::string_view) ctor). The new OStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OStringLiteral is in all cases where an object that shall itself not be an OString (e.g., because it shall be a global static variable for which the OString ctor/dtor would be detrimental at library load/unload) must be converted to an OString instance in at least one place. Other string literal abstractions could use std::string_view (or just plain char const[N]), but interestingly OStringLiteral might be more efficient than constexpr std::string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". Those places, as well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been replaced with OString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). This change also revealed a bug in at least recent Clang 12 trunk CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least in some calls from loplugin code (for which it can be fixed for now in the existing compat::getSubStringAsWritten). A similar commit for OUStringLiteral is planned, too. Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
46 lines
2.1 KiB
C
46 lines
2.1 KiB
C
/*
|
|
Global configuration file.
|
|
|
|
Only for settings that apply to every source file and are unlikely to change often,
|
|
such as whether a certain C++11 feature is available.
|
|
|
|
Do NOT use for settings local to some code or for settings that can change often.
|
|
Any change in this header will cause a rebuild of almost everything.
|
|
|
|
*/
|
|
|
|
#ifndef CONFIG_GLOBAL_H
|
|
#define CONFIG_GLOBAL_H
|
|
|
|
#define HAVE_GCC_BUILTIN_ATOMIC 0
|
|
#define HAVE_SYSLOG_H 0
|
|
|
|
// Compiler supports C++20 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html>
|
|
// "Immediate functions":
|
|
#define HAVE_CPP_CONSTEVAL 0
|
|
|
|
// Compiler supports all of C++2a <https://wg21.link/P0202R3> "Add Constexpr Modifiers to Functions
|
|
// in <algorithm> and <utility> Headers", <https://wg21.link/P1004R2> "Making std::vector
|
|
// constexpr", and <https://wg21.link/P1143R2> "Adding the constinit keyword":
|
|
#define HAVE_CPP_CONSTINIT_SORTED_VECTOR 0
|
|
|
|
// Useable C++2a <span>:
|
|
#define HAVE_CPP_SPAN 0
|
|
|
|
/* "CWG motion 23: P1825R0 'Merged wording for P0527R1 and P1155R3' (DR)" in
|
|
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4829.html> "N4829 Editors' Report --
|
|
Programming Languages -- C++" marks
|
|
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1155r3.html> "More implicit moves" as a
|
|
DR. Some versions of GCC already implemented it prior to the fix for
|
|
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150> "move ctor wrongly chosen in return stmt
|
|
(derived vs. base)"; MSVC++ 14.24 started to implement it, see <https://
|
|
developercommunity.visualstudio.com/content/problem/852827/
|
|
msvc-1424-started-to-chose-move-ctor-in-return-der.html> "MSVC++ 14.24 started to chose move ctor
|
|
in return derived vs. base". At least Clang 9, which does not implement it, emits
|
|
-Werror,-Wreturn-std-move when it therefore considers a std::move to be missing. On the other
|
|
hand, at least some versions of GCC would emit -Werror=redundant-move in places where such a
|
|
std::move would be added unconditionally, see c00948d9bd35dfb15a331c2163f32e9ee24644fd "Silence
|
|
bogus -Werror=redundant-move (GCC 9)". */
|
|
#define HAVE_P1155R3 0
|
|
|
|
#endif
|