summaryrefslogtreecommitdiff
path: root/l10ntools
AgeCommit message (Collapse)Author
2021-11-10new loplugin:stringliteraldefineNoel Grandin
look for #define FOO "foo" that can be converted into OUStringLiteral. This is the first pass of this plugin, only doing those #define which are local to a single compilation unit. Change-Id: Ic8610e29ec42c36d03db5014a93c244315d5bbea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124962 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-11In O[U]StringBuffer, make string_view params replacements for OUString onesStephan Bergmann
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That way, loplugin:bufferadd and loplugin:stringviewparam found many further opportunities for simplification (all addressed here). Some notes: * There is no longer an implicit conversion from O[U]String to O[U]StringBuffer (as that goes via user-defined conversions through string_view now), which was most noticeable in copy initializations like OStringBuffer buf = someStr; that had to be changed to direct initialization, OStringBuffer buf(someStr); But then again, it wasn't too many places that were affected and I think we can live with that. * I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to get them in line with their counterparts taking O[U]String. * I added an OUStringBuffer::lastIndexOf string_view overload that was missing (relative to OUStringBuffer::indexOf). * loplugin:stringconstant needed some addition to keep the compilerplugins/clang/test/stringconstant.cxx checks related to OStringBuffer::append and OStringBuffer::insert working. * loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea "loplugin:stringviewparam extend to new.." Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-04drop 'using namespace std' in l*Julien Nabet
Change-Id: I88909cf813f39a52c70d3cbcb19ff326d9bb42d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123069 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann
...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-23Extend loplugin:stringviewparam to starts/endsWith: l10ntoolsStephan Bergmann
Change-Id: I2c8c8e0fb034f79bb844a1d09defc3227324e686 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122494 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-22Fix typosAndrea Gelmini
Change-Id: Icd2f83bddcb993a6430d328d0bc51f38d70374ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122412 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-09-01clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-18Simplify a OUString constructionStephan Bergmann
Change-Id: Ie7bf010f6864db19b7cc64761b34e203ce70784d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117458 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-16Adapt implicit OString return value construction to C++23 P2266R1Stephan Bergmann
With the recent implementation of <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1: Simpler implicit move" in Clang 13 trunk as <https://github.com/llvm/llvm-project/commit/bf20631782183cd19e0bb7219e908c2bbb01a75f> "[clang] Implement P2266 Simpler implicit move", a --with-latest-c++ build started to fail with > comphelper/source/xml/xmltools.cxx:103:20: error: no viable conversion from returned value of type 'char [39]' to function return type 'rtl::OString' > return str; > ^~~ [...] > include/rtl/string.hxx:277:5: note: candidate constructor [with T = char [39]] not viable: expects an lvalue for 1st argument > OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() ) > ^ [...] etc. Change-Id: If34f143a1855fdd7cd22ea3d7594f9381d50a7ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-03-Werror,-Wunused-but-set-variable (Clang 13 trunk)Stephan Bergmann
sLanguage and sTmpStrVal are unused since c9611c5e6465948de029e9c2fbd17e75ee07d31f "loplugin:unusedfields in l10ntools..sax". Simplify the for loop now that it only checks for a single item, and expand the ID macro at its last remaining use. Change-Id: I3cf6692fc5a4efd58d0df1dbc24b3610916b2fd1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116665 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-28no need to allocate these on the heapNoel Grandin
Change-Id: Ic1a1577ed837d3fa2b7b99474f4cee30300628f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116290 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-19use more string_view in OString APINoel Grandin
some parts of the OString seem to have fallen behind its more popular sibling OUString. Change-Id: Ie6d64c3005b2df5da49ba79d0c38282dd5057a23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114252 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-30HelpParser::ProcessHelp: Tidy Null checksDr. David Alan Gilbert
cppcheck spotted a repeated nullptr pair of if's near the start that can be squashed. Those gurantee that later pXMLElement is non-null, so we don't need the test later. Change-Id: Ie8fc24490ef031416709d55e6fbdd99e9853c4f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110157 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-29loplugin:stringviewparam extend to new..Noel
O[U]StringBuffer methods Change-Id: I0ffbc33d54ae7c98b5652434f3370ee4f819f6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110090 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-28add string_view variants of methods to O[U]StringBufferNoel
and update the stringview loplugin to detect cases where we can use these new methods. Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-27pocheck: don't require reference for stock labelsChristian Lohmaier
See d5d905b480c2a9b1db982f2867e87b5c230d1ab9 and related commits for the rationale on why those are not extracted like other strings. Change-Id: I2a339747626e0fb314cac7f57bccb2b91853249c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109916 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-15prep to replace stock button labelsCaolán McNamara
a) as per https://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html use-stock=gtk-ok is deprecated and plain "OK", "Cancel" are indicated instead. b) to avoid adding thousands of extra labels to translate we'll convert use-stock buttons to use the translatable strings, but give them all the same "stock" translation context. Our translation rules don't like duplicates in the output .po's so strip "stock" contents from the translation collection rules in uiex and add a single set per .po in l10ntools/source/localize.cxx c) a script to rewrite the .uis to the new rules the previously use-stock labels won't appear translated until there has been a round trip of extraction, translations and import of translations Change-Id: Ibe4d0d27f2abbf5aa3df9c63af1561cd01d9fddd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108812 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-27Simplify loplugin:stringviewparam comparison operator handlingStephan Bergmann
In practice, it works fine to look at all of them, regardless of actual argument types. Change-Id: Ifc49cbcd6003c8837c1b3f81d432c59fb0657bf1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108366 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-12-09Apparently, Windows doesn't have the concept of a set but empty env varStephan Bergmann
...so in an (implicitly) --disable-release-build build (where config_host.mk contains a export ENABLE_RELEASE_BUILD= line), getenv("ENABLE_RELEASE_BUILD") returns null, and after a5484e496dcee9b110ef696101576a14b7a5a20e "Assert that certain env vars are set in these build-time tools" e.g. `make CustomTarget_librelogo/locproperties` started to fail with > [build PRP] CustomTarget/librelogo/locproperties/LibreLogo_de.properties > S=C:/lo/core && I=$S/instdir && W=$S/workdir && MERGEINPUT=C:/cygwin64/tmp/gbuild.iDa6ga && PATH="C:\lo\core\instdir\program;C:\lo\core\instdir\program;$PATH" $W/LinkTarget/Executable/propex.exe -i $S/librelogo/source/pythonpath/LibreLogo_en_US.properties -o $W/CustomTarget/librelogo/locproperties/LibreLogo_de.properties -m ${MERGEINPUT} -l de && rm -rf ${MERGEINPUT} > Assertion failed: env != nullptr, file C:/lo/core/l10ntools/source/merge.cxx, line 117 > make[1]: *** [C:/lo/core/librelogo/CustomTarget_librelogo.mk:38: C:/lo/core/workdir/CustomTarget/librelogo/locproperties/LibreLogo_de.properties] Error 3 The other asserts added with a5484e496dcee9b110ef696101576a14b7a5a20e should be OK, though: * SRC_ROOT should never be empty. * WORKDIR_FOR_BUILD could presumably be empty in a cross-compilation build ($cross_compile = yes in configure.ac), but the code in l10ntools/source/localize.cxx apparently expects WORKDIR_FOR_BUILD not to be empty anyway. (And at least in a nominally cross-compilation build with --host=i686-pc-cygwin on Windows x64, $cross-compile is left empty in configure.ac and WORKDIR_FOR_BUILD is set to a non-empty value.) * ALL_LANGS should never be empty given how it is set in configure.ac, even if the code in l10ntools/source/pocheck.cxx contains an explicit if( aLanguages.isEmpty() ) check. Change-Id: I06b216587f5d76e4b5d5abc748ff34308f2e9dbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107462 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2020-12-08Assert that certain env vars are set in these build-time toolsStephan Bergmann
All of those env vars are exported from config_host.mk or config_host_lang.mk. The asserts guard potential future changes from using OString to using std::string_view, where OString has an undocumented feature of allowing construction from a null pointer. Change-Id: I7bb2217fb1d38300bf169b17e9e72dafc6970b2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107414 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08Use OString::Concat(...) + ... instead of ... + OStringLiteral(...)Stephan Bergmann
...in some places Change-Id: Ia1d6135c89bcc18d436d8c0d353ca93195dda432 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107412 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-16Clean up --disable-assert-always-abort loplugin:stringviewparamStephan Bergmann
(457d76327a57303124804a201d58b52ba23ccefe "loplugin:stringviewparam (l10ntools)") Change-Id: Iebe0f61de4fd4d4744b47d17d8e3ff3f80217d18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105929 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-14loplugin:stringviewparam (l10ntools)Julien Nabet
Change-Id: I9102a00e19af87de4f666d1759551be3af311fe0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105828 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-11-13tdf#123936 Formatting files in module l10ntools with clang-formatPhilipp Hofer
Change-Id: I5f8c2aec02e160a22e9ff484170303927f0c9c05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105686 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-11-11loplugin:stringviewNoel
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11disable O(U)String::concat for internal codeNoel Grandin
in favour of the more widely used, and better optimised, operator+ Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-10new loplugin:reducevarscopeNoel Grandin
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: l10ntoolsStephan Bergmann
Change-Id: I9b97f64f27dee5fe0c17ceaf93f7d137141be249 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97600 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-24add Central Kurdish (ckb) language packChristian Lohmaier
Change-Id: I007edc0e339bd9cfd8caf95ecc954628d450664f
2020-06-15Don't return too early, clean vars first (l10ntools/treemerge)Julien Nabet
Change-Id: Ib99e0897fa36bdd0c8d805e38e77c3d626c0569a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96302 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-10Use xmlFreeDoc since pXhpFile is a xmlDocPtr (l10ntools/treemerge)Julien Nabet
Change-Id: I32fb8824aa91464d2198c76ba9357c82ec87a0ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95666 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-15loplugin:buriedassign in l,o,p*Noel Grandin
Change-Id: Ib2dd157d43c4387eda009475311761fe2eb627cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92241 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-07loplugin:flatten in l10ntoolsNoel Grandin
Change-Id: Ib1f698eddea1da2a6e06e17d1c4fec9ef717e132 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91804 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-03avoid flex-caused warnings about unused functionsLuboš Luňák
Change-Id: If6a028efbf2403fd92dcab914ae3197d34579392 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87869 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-14loplugin:finalclasses in i18npool..linguisticNoel Grandin
Change-Id: Ib903fb2fdb4c4c25f73053065b828dade8b63785 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86687 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-19sal_Char->char in idlc..linguisticNoel Grandin
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2 Reviewed-on: https://gerrit.libreoffice.org/85477 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-03remove some useless comment linesNoel Grandin
which merely announce that the next declaration is a class Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc Reviewed-on: https://gerrit.libreoffice.org/84229 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-17Extend loplugin:external to warn about enumsStephan Bergmann
To mitigate the dangers of silently breaking ADL when moving enums into unnamed namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79 "New loplugin:external"), note all functions that are affected. (The plan is to extend loplugin:external further to also warn about classes and class templates, and the code to identify affected functions already takes that into account, so some parts of that code are not actually relevant for enums.) But it appears that none of the functions that are actually affected by the changes in this commit relied on being found through ADL, so no adaptions were necessary for them. (clang::DeclContext::collectAllContexts is non-const, which recursively means that External's Visit... functions must take non-const Decl*. Which required compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support such Visit... functions with non-const Decl* parameters.) Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd Reviewed-on: https://gerrit.libreoffice.org/83001 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-03loplugin:stringaddNoel Grandin
tweak the plugin to be more permissive, then validate by hand afterwards Change-Id: I40c5c911fe6ff7e45baaca372abf7dac211d9654 Reviewed-on: https://gerrit.libreoffice.org/81942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-02pocheck: also preserve header in check for function namesChristian Lohmaier
Change-Id: I53b67e8c690b110d2d77e100b8170ac968e35e2b
2019-10-01loplugin:stringadd in helpcompiler..ooxNoel Grandin
Change-Id: I858870d883de10a673d7ce2798bda8c8f511cee5 Reviewed-on: https://gerrit.libreoffice.org/79889 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-27loplugin:referencecasting find more redundant static_castNoel Grandin
Change-Id: I3a51812bbd3fcdc6b11e47cb12962f0d4fa7a2ae Reviewed-on: https://gerrit.libreoffice.org/78191 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2024-05-22 09:53:08 +0000