56e6d683db
...so recent LLVM 19 trunk libc++ in debug mode complained during CppunitTest_chart2_export2 about > ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering at > 5 libsystem_c.dylib 0x0000000183279a40 abort + 180 > 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0 > 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960 > 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268 > 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68 > 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508 > 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528 > 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440 > 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728 > 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692 > 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288 But the introduced use of `std::strong_order(first[0], second[0]) < 0` then triggered a false > lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] > 105 | return std::strong_order(first[0], second[0]) < 0; > | ^ so needed some hack in loplugin:nullptr. And old versions of libc++, still used at least on Android, do not have any implementations of std::strong_order. So detect those cases in configure.ac (checking for std::strong_order for double, which is what is actually being used in the code) and fall back to operator <=> for now, even if that will not provide a strict weak ordering and will thus continue to violate the requirements of std::sort. And then our venerable clang-format 5.0.0 would have broken the token `<=>` into `<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment. Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
53 lines
2.4 KiB
C
53 lines
2.4 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
|
|
|
|
// Compiler supports C++20 <compare> std::strong_order:
|
|
#define HAVE_CPP_STRONG_ORDER 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 choose 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
|
|
|
|
// Whether the OS provides a usable dynamic loading API
|
|
#define HAVE_DLAPI 0
|
|
|
|
// Whether the OS uses the common UNIX dynamic loading API calls, like dlopen, dlsym, dladdr etc.
|
|
// Use HAVE_DLAPI instead. Should not be used outside of sal/osl/unx/module.cxx!
|
|
#define HAVE_UNIX_DLAPI 0
|
|
|
|
#endif
|