summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/stringadd.cxx
AgeCommit message (Collapse)Author
2023-12-18-Werror,-Wdeprecated-declarationsStephan Bergmann
> compilerplugins/clang/casttovoid.cxx:452:18: error: 'endswith' is deprecated: Use ends_with instead [-Werror,-Wdeprecated-declarations] > .endswith(".h")); > ^~~~~~~~ > ends_with > ~/llvm/inst/include/llvm/ADT/StringRef.h:276:19: note: 'endswith' has been explicitly marked deprecated here > [[nodiscard]] LLVM_DEPRECATED( > ^ etc. after <https://github.com/llvm/llvm-project/commit/5ac12951b4e9bbfcc5791282d0961ec2b65575e9> "[ADT] Deprecate StringRef::{starts,ends}with (#75491)" on Clang 18 trunk, where <https://github.com/llvm/llvm-project/commit/1b97645e56bf321b06d1353024339958b64fd242> "[ADT] Introduce StringRef::{starts,ends}_width{,_insensitive}" had been added towards Clang 16 Change-Id: Icb3e43b7d6be6f877815285913d846f766eddebf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160919 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-04-17loplugin:stringadd: Adapt O[U]StringBuffer ctor detection for WindowsStephan Bergmann
...where sal_Int32 is not int, so a literal argument like 16 actually calls the O[U]StringBuffer(T length, std::enable_if_t<std::is_integral_v<T>, int> = 0) overload Change-Id: I1d151efbc723cbfa76690e02491b05a9a4147e91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150473 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-06loplugin:stringadd also check O[U]StringBuffersNoel Grandin
For similar code sequences that can be improved. Also move containsComment from collapseif plugin code to plugin.cxx so we can use it from stringadd. Change-Id: Ie07d9aedf2c31cb0b2080e1b8584294d7046a8e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149217 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-18loplugin:stringadd use more O[U]StringCharNoel Grandin
Change-Id: I196e4539ad430a39415eff9d7170b33df7228230 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149062 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-10-14Clean up loplugin:stringaddStephan Bergmann
...after 3d236177be255b2027a997bfc12fe0833ca9a2f7 "Deduplicate O(U)StringConcatenation" changed OStringConcat and OUStringConcat into aliases (so they can never show up here in a "getUnqualifiedDesugareType"), but apparently forgot to drop their respective checks here. (That the then-added check for StringConcat works as intended is verified by compilerplugins/clang/test/stringadd.cxx, btw.) Change-Id: I2b589d977dbf2a384348cb7ee62acce30031ccec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141364 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-13Deduplicate stringconcat moreMike Kaganski
In the process, drop ToStringHelper::allowO(U)StringConcat, because we can deduce this information from ToStringHelper's addData itself. To do that, addData was converted to ToStringHelper::operator(), which allows to use std::is_invocable_v on the helper class. Change-Id: Ic77878ca0ff65ada8c0a942191bc11de15b9ad2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141254 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-02-17Bump compiler plugins Clang baseline to 12.0.1Stephan Bergmann
...as discussed in the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2020-November/086234.html> "Bump --enable-compiler-plugins Clang baseline?" (and now picked up again at <https://lists.freedesktop.org/archives/libreoffice/2022-February/088459.html> "Re: Bump --enable-compiler-plugins Clang baseline?"), and clean up compilerplugins/clang/ accordingly Change-Id: I5e81c6fdcc363aeefd6227606225b526fdf7ac16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129989 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-09Remove redundant duplicate checkStephan Bergmann
Change-Id: I311496e25ac617c6b174b828978a1298231bd433 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118686 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-09Make loplugin:stringadd slightly more aggressiveStephan Bergmann
...by assuming that all const member functions are side-effect free. (This presumably means that some of the special cases in StringAdd::isSideEffectFree are obsoleted by this more general case, but any such removal is postponed to later clean-up.) (Came across this when idly wondering why 8b7f948d9d79393bc6c1b11d239706666fd5d7de "sc, VmlFormControlExporter: avoid OStringBuffer style" had not been found by the plugin before.) Change-Id: I6bca10df53885b14a590543aabd61f23b3748572 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118675 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-03loplugin:stringadd improvement for appending numbersNoel Grandin
I was wrong, the Concat framework already optimised appending numbers by stack-allocating small buffers, so include them in the plugin Change-Id: I922edbdde273c89abfe21d51c5d25dc01c97db25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115037 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-27loplugin:stringadd convert chained append to +Noel Grandin
which can use the more efficient *StringConcat Also fix a crash in stringview plugin which started happening while I working on this. Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-21loplugin:stringadd replace OUStringLiteral temporaries with OUString::ConcatNoel Grandin
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral 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 container 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::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral 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 OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_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. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::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). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-10replace usage of whitelist with allowlistThorsten Behrens
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 [API CHANGE] officecfg::Office::Common::Misc::OpenCLWhiteList -> OpenCLAllowList Change-Id: I65636b19b13e4af1e4851f70e78053f3443d6bb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98181 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-10-31Fix StringAdd::isCompileTimeConstantStephan Bergmann
...to find StringLiteral on the RHS of +=. Which revealed that the VisitCompoundStmt/checkForCompoundAssign logic needed to be fixed, too, so that s += side_effect(); s += "literal"; s += side_effect(); only gets combined to s += side_effect() + "literal"; s += side_effect(); and not all the way to s += side_effect() + "literal" + side_effect(); Change-Id: I432e3458b933a7d0ad6141c747b675cc8b0f0ba4 Reviewed-on: https://gerrit.libreoffice.org/81804 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-28Completely remove lambda capture that is unusedStephan Bergmann
...since 6d6fad522a2cd6a2959ea774969a86288f5a3cb7 "Introduce OStringChar" (and had needlessly been kept alive with ce3badb157c58941608f878a7de98c7739e30aec "compilerplugins: fix -Werror,-Wunused-lambda-capture") Change-Id: Ie34ef1197f97ecab5b8f30741f1e2c4b3a9db594 Reviewed-on: https://gerrit.libreoffice.org/81591 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-28loplugin:stringadd improve detectionNoel Grandin
if one side of the expression is a compile-time-constant, we don't need to worry about side-effects on the other side Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b Reviewed-on: https://gerrit.libreoffice.org/81589 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-25compilerplugins: fix -Werror,-Wunused-lambda-captureMiklos Vajna
Change-Id: I2a1374a1e79401c2107d003102ab797fac9a3d66
2019-10-24Introduce OStringCharStephan Bergmann
...similar to OUStringChar, to be used in string concatenation expressions. And enable the corresponding loplugin:stringadd check, and fix its findings. Change-Id: I35ebb2253ba82bda6c98ae6ebd2ad4f27cf9abf9 Reviewed-on: https://gerrit.libreoffice.org/81456 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-23Don't use broken StringAdd::getSourceAsStringStephan Bergmann
it caused clang-cl to crash when processing desktop/source/app/opencl.cxx Change-Id: I0a39697e75242cd00f12b60477d51a1e5bf96a4f Reviewed-on: https://gerrit.libreoffice.org/81409 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-17loplugin:stringadd fix conditionNoel Grandin
Change-Id: I7752c281b1b6dd0d26bd7d6c4a6896c663f4cbc3 Reviewed-on: https://gerrit.libreoffice.org/80921 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-16loplugin:stringadd look through a couple more known-good methodsNoel Grandin
Change-Id: Ifbdb3e41eae665f7dcaf5301aaba2b6e4662cf48 Reviewed-on: https://gerrit.libreoffice.org/80855 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-15Improve loplugin:stringadd diagnosticsStephan Bergmann
Change-Id: I8b87c4e56f10417acd538b765b3f8e4cc6e12fb9 Reviewed-on: https://gerrit.libreoffice.org/80844 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-15Improve loplugin:stringaddStephan Bergmann
...after 9b5dad13b56bdde7c40970351af3da3a2c3c9350 "loplugin:stringadd look for unnecessary temporaries". There was no reason to check for implicit MaterializeTemporaryExpr instead of explicitly written CXXFunctionalCastExpr, and checking for the latter makes it easier to report the casted-from type, which gives useful information how to change code that exhibits the warning. See the comments at <https://gerrit.libreoffice.org/#/c/80724/> "loplugin:stringadd look for unnecessary temporaries" for details. (And while at it, remove some commented-out debug code that is probably no longer relevant now.) Change-Id: I7d4cab85432885d617dd7114c75163c1eb376fc2 Reviewed-on: https://gerrit.libreoffice.org/80823 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-14Comment out a lambda capture that isn't used, to avoid compiler warningTor Lillqvist
(The use of it is also commented out.) Change-Id: Ie015a8cbd0f7a982721a389487c2134a1aba8ed1
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-02new loplugin:stringaddNoel Grandin
look for places where we can replace sequential additions to OUString/OString with one concatentation (i.e. +) expression, which is more efficient Change-Id: I64d91328bf64828d8328b1cad9e90953c0a75663 Reviewed-on: https://gerrit.libreoffice.org/79406 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-01-24 03:37:41 +0000