summaryrefslogtreecommitdiff
path: root/config_host/config_global.h.in
AgeCommit message (Collapse)Author
2020-09-02Turn OStringLiteral into a consteval'ed, static-refcound rtl_StringStephan Bergmann
...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>
2020-04-17No need for HAVE_GCC_DEPRECATED_MESSAGEStephan Bergmann
GCC appears to support it at least since <https://gcc.gnu.org/git/ ?p=gcc.git;a=commit;h=9b86d6bb25587db93a322bf5778e9892aaa8b776> "re PR c/36892 (Support __attribute__((deprecated("text string"))))" in GCC 4.5, and Clang appears to support it at least since <https://github.com/llvm/llvm-project/ commit/c7890fed01f8c8accba188236d781af26845cb2c> "Add an optional string argument to DeprecatedAttr for Fix-It" in Clang 3.9. Change-Id: If0939c692703522523d1953c3793070e0f808973 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92455 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-17No need for HAVE_GCC_PRAGMA_OPERATORStephan Bergmann
The _Pragma operator is a C99/C++11 feature, and we only need it for GCC and Clang anyway, to inject some #pragma GCC diagnostic ... directives. (MSVC would only support it with the upcoming VS 2019 Version 16.6, see <https://devblogs.microsoft.com/cppblog/ announcing-full-support-for-a-c-c-conformant-preprocessor-in-msvc/>.) Change-Id: I6de3611021a28ba13860f55e7ad005ad3fbbb5e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92452 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-17HAVE_CPP_GUARANTEED_COPY_ELISION should always be true nowStephan Bergmann
...since 24973523ba59087185d434396fd614e73d72107f "Bump Windows build baseline to Visual Studio 2019 16.4", where that version of the compiler appears to no longer have the issue that at least VS 2017 15.8.1 had. And according to <view-source:https://en.cppreference.com/w/cpp/compiler_support>, the other compilers support it since GCC 7 and Clang 4, so we should be OK there. But for safety, leave the configure.ac check in for some longer. Change-Id: I07bfaa554d897613c0887ab70e8df93f6e000410 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92422 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-17Just use __builtin_ffs on GCC and ClangStephan Bergmann
GCC appears to support it at least since <https://gcc.gnu.org/git/ ?p=gcc.git;a=commit;h=51e2940139d5e3e86590f6e6802ffc3f3010be5b> "Initial revision" in 1992, and Clang appears to support it since <https://github.com/ llvm/llvm-project/commit/d93abc3bb0acdd430839abdd67bd3920fee87bbc> "Implement ffs, parity, and popcount builtins" in Clang 2.4. (And if a build used a compiler that does not support it, there would be no guarantee that it would support strings.h function ffs from X/Open System Interfaces, either.) Introducing HAVE_GCC_BUILTIN_FFS in 334a9f16cd1d1f9694f885c759903a41aa3d4833 "tdf#113211: fix calculations with big integers" appears to be due to a misguided recommendation at <https://gerrit.libreoffice.org/c/core/+/43477/4# message-899806c724fbdcece0ea9438514a6a5db6a2e645>. Change-Id: Ib6ee6de548172b3aae25483d03efb86620133933 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92421 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-28HAVE_GCC_ATTRIBUTE_WARN_UNUSED should always be true now for Clang/GCCStephan Bergmann
...but for safety, leave the configure.ac check in for some longer. Change-Id: I90cba5812492ba85d7723ff71aba75b7721b9622 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87621 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-14Rename HAVE_GCC_BUG_87150 to HAVE_P1155R3Stephan Bergmann
...to match the new reality (see comment in config_host/config_global.h.in) Change-Id: I5450e520d8b82584e3fd71d7e42a6840993b5ddb Reviewed-on: https://gerrit.libreoffice.org/85142 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-07Adapt o3tl::span to P1872R0Stephan Bergmann
..."span should have size_type, not index_type" (<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1872r0.pdf>), as implemented by libc++ since <https://github.com/llvm/llvm-project/commit/ 1466335cf4b2854a0be1defcf279fe50772bad6f> "[libc++][P1872] span should have size_type, not index_type." All uses of index_type had been added to mitigate the previous std::span change from signed (ptrdiff_t) to unsigned (size_t) index_type, see 6ef8420fdbf8dff16de13147c5ab833bc5e01121 "Adapt o3tl::span to updated C++2a std::span". There is no easy solution to transparently support all three std::span variants currently out there (signed index_type, unsigned index_type, unsigned size_type), without causing compilation failures due to CPPUNIT_ASSERT_EQUAL with arguments of different types, or compiler warnings about mixed signed/unsigned comparisons. So rule out the oldest std::span variant (signed index_type) in configure.ac (so that o3tl::span will use its own hand-rolled code in that case) and simplify the uses of index_type to std::size_t (as had already been mentioned in 6ef8420fdbf8dff16de13147c5ab833bc5e01121). Change-Id: I6ddf424ffb7941da3f69ad66fd29ecd35f09afae Reviewed-on: https://gerrit.libreoffice.org/84652 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-25constinit, here we comeStephan Bergmann
Following up on b13421011d9377676e1adc282634991d5064a866 "better data structures for some static const vars": * Make the o3tl::sorted_vector ctor taking an initializer_list constexpr. <https://wg21.link/P0202R3> "Add Constexpr Modifiers to Functions in <algorithm> and <utility> Headers", which will be in C++2a and is already implemented by recent libc++ and libstdc++ according to <https://en.cppreference.com/w/cpp/compiler_support #C.2B.2B2a_library_features>, makes std::sort constexpr but explicitly keeps std::stable_sort non-constexpr. ("Algorithms stable_partition, inplace_merge and stable_sort allocate memory, construct variables using placement new, use unique_ptr and do other things not acceptable in constexpr expressions. Making those algorithms constexpr seems to be a hard task that would require a lot of intrinsics. Those algorithms are not marked with constexpr in this wording.") But keep o3tl::sorted_vector::Resort (which was introduced in c59355e936446fe55960209e543b072acb6b2170 "fdo#58793: re-implement SwpHintsArray::Resort()") using std::stable_sort instead of std::sort, in case that is relevant for its pre-exisiting uses. * <https://wg21.link/P1004R2> "Making std::vector constexpr", which was voted into C++2a according to <https://wg21.link/n4829> "Editors' Report -- Programming Languages -- C++", will make the relevant parts of std::vector constexpr. But none of libc++, libstdc++, and MSVC implement that as of now. * Introduce HAVE_CPP_CONSTINIT_SORTED_VECTOR to hide the constinit behind for now for the one case from b13421011d9377676e1adc282634991d5064a866 "better data structures for some static const vars" that can clearly be constinit once constexpr std::vector is supported by compilers. The other three cases (s_aContainerDocumentCommands in chart2/source/controller/main/CommandDispatchContainer.cxx, aMetricCompatibleMap in vcl/source/font/PhysicalFontCollection.cxx, and aBlacklist in writerfilter/source/dmapper/PropertyMap.cxx) would each need a constexpr OUString first. (Technically, the constinit would not even be needed, but it nicely documents our intent that this will actually be initialized at compile-time once compilers support that.) Change-Id: Ibeb138f120528be3a7a09b3912143bf795fbab29 Reviewed-on: https://gerrit.libreoffice.org/79556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-08HAVE_CPP_ATTRIBUTE_NODISCARD is always true nowStephan Bergmann
...but for safety, leave the configure.ac check in for some longer. Also, save removing now-redundant SAL_WARN_UNUSED_RESULT in internal code for a follow-up commit. Change-Id: Ibe30b51c5cc4abc270f955c7c40b59f268986672 Reviewed-on: https://gerrit.libreoffice.org/64771 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CXX_CWG1579_FIX is always true nowStephan Bergmann
...(according to <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> it is fixed in C++14), but for safety, leave the configure.ac check in for some longer. Change-Id: Ibd2f0cac228117e35ac299e2fe74207394c900cd Reviewed-on: https://gerrit.libreoffice.org/64773 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CPP_INLINE_VARIABLES is always true nowStephan Bergmann
...but for safety, leave the configure.ac check in for some longer. Also remove now-redundant SAL_INLINE_VARIABLE again (which was LIBO_INTERNAL_ONLY). Change-Id: Id049e0cb84b4f97f5859f1b16b867b39b448dec0 Reviewed-on: https://gerrit.libreoffice.org/64772 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true nowStephan Bergmann
...but for safety, leave the configure.ac check in for some longer. Also, save removing now-redundant SAL_FALLTHROUGH for a follow-up commit. Change-Id: I9bf42d237aea4c09459f28275568cf340e588607 Reviewed-on: https://gerrit.libreoffice.org/64770 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_CXX14_CONSTEXPR is always true nowStephan Bergmann
...but for safety, leave the configure.ac check in for some longer. o3tl::array_view::max_size (include/o3tl/array_view.hxx) and o3tl::basic_string_view::max_size (include/o3tl/string_view.hxx) started to produce loplugin:staticmethods warnings, which I silenced by /not/ making the functions static. Those classes are meant to be temporary drop-in replacements for standard classes (std::span slated for C++20, prev. std::array_view; and std::basic_string_view, resp.), so should have the same behavior as their standard counterparts (and making the functions static would likely cause loplugin:staticaccess warnings at call sites). Change-Id: If21674dbf02886f453ca447544e37b184df5a25e Reviewed-on: https://gerrit.libreoffice.org/64768 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-07HAVE_BROKEN_CONST_ITERATORS is always false nowStephan Bergmann
...but for safety, leave the configure.ac check in for some longer. Change-Id: Ife94cdfd56696edb113e32d84f563dd805e757e5 Reviewed-on: https://gerrit.libreoffice.org/64769 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-11Use [[fallthrough]] also with MSVCStephan Bergmann
Change-Id: I840de9460c164b86dcbd96b4c0f382e1a1b609a2 Reviewed-on: https://gerrit.libreoffice.org/60330 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-11Use [[nodiscard]] in SAL_WARN_UNUSED_RESULT where availableStephan Bergmann
...which required some lax placements of SAL_WARN_UNUSED_RESULT to be fixed. Also, Clang unfortunately is rather picky about the relative order of SAL_WARN_UNUSED_RESULT expanding to [[nodiscard]] and uses of the DLLPUBLIC macros (expanding to __attribute__(...) resp. __declspec(..) for clang-cl). Change-Id: Iae6ca36bef97f1864873aefdb5f05c7f5e045ad3 Reviewed-on: https://gerrit.libreoffice.org/60274 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-31GCC only supports inline variables since GCC 7Stephan Bergmann
(see also discussion at <https://gerrit.libreoffice.org/#/c/59204/11> "new loplugin:conststringfield" about its changes to registry/source/regimpl.cxx) Change-Id: Id2743adbfeb4d7c42105a65ba8400d7051da2f03 Reviewed-on: https://gerrit.libreoffice.org/59873 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-30Silence bogus -Werror=redundant-move (GCC 9)Stephan Bergmann
Change-Id: Ia078fb8e1e497edfa08e2a61d1659100461fc52e Reviewed-on: https://gerrit.libreoffice.org/59720 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-08-29-Werror=redundant-move (GCC 9), take twoStephan Bergmann
...after 5b62a43349da6fda13fb33e0f1ec477c21daec8f "Revert '-Werror=redundant-move'" to fix the build for GCC 8.1 again. Turns out the std::move can only be dropped if the compiler has a fix for CWG1579. For GCC that's the case starting with GCC 5.1, so the !HAVE_CXX_GWG1579_FIX case can hopefully be removed again soon, see the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2018-July/080588.html> "Compiler baselines (was: [Libreoffice-qa] minutes of ESC call ...)"). Change-Id: I3592cad7fb503db921c37e92831a34785a1054a1 Reviewed-on: https://gerrit.libreoffice.org/59741 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-07-04Make brittle SortedAutoCompleteStrings ownership handling more explicitStephan Bergmann
Change-Id: Ieaf2231a84d97528bb1b9a410c4ee0c38966dd27 Reviewed-on: https://gerrit.libreoffice.org/56950 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-08Drop HAVE_GCC_ATTRIBUTE_WARN_UNUSED_STLStephan Bergmann
For one, loplugin:unusedvariablecheck does not merely check for unused variables with types from the standard library since fe2164949b38a7f73883dbdcb3271b94e5c81744 "teach unusedvariablecheck plugin about SfxPoolItem subclasses", so disabling loplugin:unusedvariablecheck based on HAVE_GCC_ATTRIBUTE_WARN_UNUSED_STL is wrong. For another, I have seen no standard library implementation that decorates its types with such "warn-if-unused" attributes, and <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0600r0.pdf> "[[nodiscard]] in the Library" (which proposes to add the corresponding C++17 attribute to just a few select functions and no types at all) makes it appear unlikely that will happen. Change-Id: I0a7759e1caf3e3137057c9689080948a4d6747e0
2017-10-19tdf#113211: fix calculations with big integersMike Kaganski
... and munbers with few fractional bits Change-Id: I86c3e8021e803fed498fae768ded9c9e5337c8bd Reviewed-on: https://gerrit.libreoffice.org/43477 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com>
2017-06-16Remove HAVE_CXX11_REF_QUALIFIER, always true nowStephan Bergmann
...after 579497164f6bddfeb14bb6b0f4b9cd3322af1803 "Bump GCC baseline to 4.8.1" Make this a fatal configuration error for now. The check should be removed completely after LO 6.0 branch-off. Change-Id: I70cf65d6b0eb7158008f28449794c66c1b775916 Reviewed-on: https://gerrit.libreoffice.org/38869 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-06-01HAVE_THREADSAFE_STATICS sould always be trueStephan Bergmann
...(for LIBO_INTERNAL_ONLY), now that the status of Android has been clarified, see <https://lists.freedesktop.org/archives/libreoffice/2017-June/077827.html> "Re: Some baseline thoughts" Change-Id: Ie9d5444df84c23d48c24b68d9d2ab5322c619858
2017-03-02Remove HAVE_CXX11_UTF16_STRING_LITERAL, always true nowStephan Bergmann
...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>
2017-03-02Remove HAVE_CXX11_CONSTEXPR, always true nowStephan Bergmann
...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: I990fd8fcb4ec1327282df4efe21640c938d3cf06 Reviewed-on: https://gerrit.libreoffice.org/34821 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-12-15Phase out support for HAVE_BROKEN_STATIC_INITIALIZER_LISTStephan Bergmann
...I'm pondering a change that would make that a hard requirement, and from the comment in configure.ac it looks like only old Clang < 3.4 were affected. Change-Id: I8ef64f759fed1a45d88f94d0e8a60839ad10b263 Reviewed-on: https://gerrit.libreoffice.org/32029 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-12-12[API CHANGE] Remove salcpprt static libraryStephan Bergmann
...containing replacements for global operator new/delete (that can be linked into executables), but which is no longer used. The mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2012-March/028690.html> "operator new no longer routes through rtl_AllocMemory in libsalcpprt under gbuild link rules" has the details of how this was used on some platforms (but not on others) before the switch to gbuild, and has been "lost" ever since---but apparently a loss not mourned much over the years. For the SDK, c5f974287fd04bb529de145113133b9e35687702 "INTEGRATION: CWS jsc3: #i62434# copy libsalcpprt.a" added the library (under Linux) and 6db9c5af960f9787e33e4addc56bddbb1695a402 "INTEGRATION: CWS jsc3: #i62434# extend link options for executbales to link libsalcpprt.a, LINUX only" added its use to odk/settings/settings.mk, but fc0ca57f2cd649c6330171445a06b80e2143a0e9 "INTEGRATION: CWS jsc21" removed that use again (for no documented reason). So this is an incompatible change, but unlikely to actually affect any users of the SDK. Change-Id: Ia38b4c439f21fca3f5d9af7d1a34054e992054e9 Reviewed-on: https://gerrit.libreoffice.org/31810 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-08-29Support ConstCharArrayDetector also for UTF-16 arraysStephan Bergmann
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>
2016-03-31Typo in HAVE_BROKEN_STATIC_INITILIZER_LISTStephan Bergmann
Change-Id: Ia29868d1832b529d438a5a5448b751683c226846
2015-11-09Prevent += called on temporary O[U]String instancesStephan Bergmann
...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
2015-10-12HAVE_CXX11_PERFECT_FORWARDING is required on all supported toolchainsStephan Bergmann
Change-Id: I8f4d7f8ebdfa0fb2c5a8efc676d1f66876b6daa9
2015-10-12HAVE_CXX11_FINAL is required on all supported toolchainsStephan Bergmann
Change-Id: I85ed86fdd8b11863c96b7a6c3ba76d77dbecf192
2015-10-12HAVE_CXX11_OVERRIDE is required on all supported toolchainsStephan Bergmann
Change-Id: Ibc5462642d0a3cd0f96668472ddc0ac0ae407132
2015-10-12HAVE_CXX11_DELETE is required on all supported toolchainsStephan Bergmann
Change-Id: I53c746be98972c7024dc2f340738182e46c24241
2015-09-30Avoid unhelpful -Wunused-variableStephan Bergmann
...at least from "g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)" with --disable-debug, when a namespace-scope const variable with a "complex" initializer declared in an include file remains unused. Avoid that warning via SAL_CONSTEXPR, which in turn requires large parts of o3tl::is_typed_flags to be SAL_CONSTEXPR, which in turn requires a new HAVE_CXX14_CONSTEXPR to allow assert in constexpr functions, which in turn requires using -std=c++14 instead of -std=c++11 where available, which in turn (a) requires to /not/ use -std=c++14 if it would run into a bug between Clang and libstdc++ discussed at <https://llvm.org/bugs/show_bug.cgi?id=24115> "llvm-nm fails to build with gcc 5.1's libstdc++" (and which hits us in sfx2/source/control/thumbnailview.cxx), and (b) requires a new HAVE_CXX14_SIZED_DEALLOCATION to work around GCC 5.1 -Werror=sized-deallocation (where Clang >= 3.7 only supports C++14 sized deallocation when explictly enabled via -fsized-deallocation, btw). This effectively reverts ff6462e6307e6924dc6c8178043ae9032f4b4152 "avoid unused variable warning:" again. Change-Id: I424e3561452a3e6d8c8a9604d6c737cab49840c4 Reviewed-on: https://gerrit.libreoffice.org/18918 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2015-06-19Fix check for broken standard libraryStephan Bergmann
The compiler's __GNUC__ etc. need not match the libstdc++ version used (esp. when using Clang as compiler), and libstdc++'s __GLIBCXX__ macro doesn't inrease monotonically with version numbers, so resort to a configure check. Change-Id: I06de6b68324169863f6f5c31ae5d855e8b04cd6b
2015-02-10Properly check for Clang with static initializer_list bugStephan Bergmann
Change-Id: I98060f1adae0ba8ec03b2f0d6b0db6d5a1c0385c
2015-02-06Make OUStringLiteral more usefulStephan Bergmann
...don't dare make it non-explicit, yet. Along the way, introduce SAL_CONSTEXPR. Change-Id: Ia3179d0d5e001fd7aa92237c97437e9b74366ee1
2014-10-02remove HAVE_GCC_PRAGMA_DIAGNOSTIC_SCOPE check and macroMichael Stahl
This is supported in GCC 4.6.0 already: https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Diagnostic-Pragmas.html Change-Id: I2f67e588eea3a323a2e9c81e39e56ab2e715a817
2014-10-02remove HAVE_GCC_PRAGMA_DIAGNOSTIC_MODIFY check and macroMichael Stahl
This has been supported by GCC and clang for a very long time. Change-Id: I410a2b39004c932003f8cbefe935aedb109b1163
2014-09-11(Rudimentary) C++11 support is a hard requirement nowStephan Bergmann
Change-Id: I43ed776d52336b822aa6152f0f2a29e39303bb75
2013-08-05do not base feature checks on gcc versionLuboš Luňák
Clang reports itself to be gcc4.2, so there fail there, instead use configure checks. Change-Id: Idb44a5c875b24a15546a6495de02a1b4af898443
2013-07-23adjust for upstreaming of warn_unused attributeLuboš Luňák
The warn_unused attribute has been upstream to GCC and Clang, so use it if present. Still warn about STL types if those do not use it yet (which is the status as of now). Change-Id: I3c003e44c08d1d141e23bba38cf92e663a5ac353
2013-06-13rename HAVE_CXX0X->HAVE_CXX11 and clean up to #define in a config headerLuboš Luňák
Change-Id: Id13e77fe890301a8510952994a91853568a7aea6
2013-04-08Check for the C++11 "final" specifier and introduce SAL_FINALTor Lillqvist
I think it is useful to use SAL_FINAL mainly as a documentation aid, to make it clear to a code reader when a class is not expected to be derived from, and when a virtual function is not expected to be overridden in a derived class. Possibly there is also some class of bugs that using SAL_FINAL will help find? Change-Id: I45002f020dcb52e8a9f2962ff98780f2b80627af
2013-04-04remove HAVE_SFINAE_ANONYMOUS_BROKENLuboš Luňák
Since we no longer support the old Apple SDK using gcc-4.0.1, we can remove the cruft to work around its problems. Woohoo. Change-Id: Idf275e76449443f1f0314e75dab993f213a77eb7
2013-03-26autoconf can actually handle #define HAVE_FOO 0 as the defaultLuboš Luňák
Change-Id: I6cd70d885a3fe3ab53f7523d1a5da6ae30ee01e3
2013-03-25Introduce HAVE_GCC_PRAGMA_DIAGNOSTIC_{MODIFY,SCOPE}Stephan Bergmann
...replacing hard-coded GCC version checks. Those checks that guard #pragma GCC diagnostic ignored "-Wnon-virtual-dtor" appear relevant only for GCC itself, not Clang (which used to fail the old guards because it typically announces itself with a rather low __GNUC__/__GNUC_MINOR__ version), see 6e67c03dc0225fc66343546b14e902b9d238b1a3 "Enable -Wnon-virtual-dtor for GCC 4.6" Change-Id: I6bfa4d5caa6192e7a203ce829682bf6bb8d61a1b
generated by cgit (git 2.34.1) at 2024-07-04 12:03:42 +0000