summaryrefslogtreecommitdiff
path: root/compilerplugins
AgeCommit message (Collapse)AuthorFilesLines
2020-10-26Remove unmaintained Executable_libtestStephan Bergmann1-2/+1
<https://lists.freedesktop.org/archives/libreoffice/2020-October/086169.html> "Re: Is Executable_libtest still useful?": >> so I wonder whether that program is actually still maintained and used by >> anybody. (At least the last dozen or so changes to smoketest/libtest.cxx >> were of the generic loplugin/typos/tools::Long etc. kind, and we could spare >> ourselves future such work if we removed the file should it indeed be dead >> code.) > > I think this can be removed. https://gitlab.com/ojwb/lloconv does the > same and it seems to be maintained. Change-Id: I039e161ecf4904210e246e389cf4ba85124a66fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104803 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-26loplugin:toolslong (--enable-online-update)Stephan Bergmann1-1/+2
...but where > ~/lo/core/extensions/source/update/check/download.cxx:297:17: error: VarDecl, use "tools::Long" instead of 'long' [loplugin:toolslong] > long nError; > ^~~~~~~~~~~ > ~/lo/core/extensions/source/update/check/download.cxx:153:9: error: VarDecl, use "tools::Long" instead of 'long' [loplugin:toolslong] > long nCode; > ^~~~~~~~~~ were false positives (the third argument to curl_easy_getinfo(..., CURLINFO_RESPONSE_CODE, ...) must be a pointer to long). Change-Id: I9596ff32c32fddc7c1240d7fec3672d36265631a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104794 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-26loplugin:toolslong exclude pyuno fileNoel1-0/+5
Change-Id: I1b4b3f48e3195c31fb6b95932e9d4893829058dd
2020-10-26switching long to a 64-bit type on 64-bit windowsNoel1-0/+556
(*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21Fix loplugin:salcallStephan Bergmann2-101/+59
For one, the addressOfSet filtering was only done for member functions, not for free functions, which caused false positives in the wild like the one discussed in the comments at <https://gerrit.libreoffice.org/c/core/+/102024/ 4#message-36ec6ee09ed5badae93c552b82a90068e65d19e2> "call xDesktop->terminate() when catching SIGTERM/SIGINT" regarding a free function `terminationHandlerFunction` passed to `osl_createThread`. For another, it failed to identify some cases where the address of a function is taken implicitly, like for `f3` in compilerplugins/clang/test/salcall.cxx. So make this plugin reuse the existing `loplugin::FunctionAddress` functionality (which also meant to get rid of this plugin's two-phase design). Change-Id: Ie290c63b03825d5288d982bc8701cfb886fc84b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104585 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-19clang-cl: Adapt Windows-specific code to extended loplugin:cstylecastStephan Bergmann1-1/+1
...after 1ebeacb20ad0165e399629fcfd7795ad0da3edf8 "Extend loplugin:cstylecast to certain function-style casts" Change-Id: I99bd383f5b3bee861d442d2e1be6ecd356b78315 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104523 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-19tdf#136073 combine glow and softedge sidebar sectionandreas kainz1-7/+7
Change-Id: I19381009f5b286b051ae0cb90a794ed51a413a7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103835 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-10-15Fix checks for "older than Clang 11"Stephan Bergmann5-8/+8
...following up on b6d0ca04581eae01817aac18d32a312bc9a2d514 "The Clang RecursiveASTVisitor change is already in Clang 11"; no longer sure why I originally wrote the checks using <= rather than < in 5d546de67b44dec23ecfa5a6378e2968912f8253 "Adapt to Clang 12 trunk RecursiveASTVisitor change" Change-Id: I79877e21823334c939ecdf9c64e4efe5e0b1571b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104349 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-14The Clang RecursiveASTVisitor change is already in Clang 11Stephan Bergmann5-8/+8
...see 5d546de67b44dec23ecfa5a6378e2968912f8253 "Adapt to Clang 12 trunk RecursiveASTVisitor change"; no longer sure why I thought <https://github.com/ llvm/llvm-project/commit/5689b38c6a4220cc5f6ba68a56486229b10071bf> "Removed a RecursiveASTVisitor feature to visit operator kinds with different methods" would not be included in the release/11.x branch Change-Id: I1e206368c447b74cc6adec4c1d4790c80f0cb744 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104309 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-02drop these unused inlinesCaolán McNamara1-12/+0
Change-Id: I566be7eaf2ee73d3dac8c137ba783eea960cb586 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103778 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-01loplugin:unusedfieldsNoel5-411/+305
Change-Id: Icd1dc03c2f783e11e3e52038a8ae9f19705561c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103746 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-30loplugin:unusedmethodsNoel2-242/+270
Change-Id: I4f5262af08bb35540e6330775a91df42e4c9977e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103684 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara1-2/+2
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21static_assert that O[U]StringLiteral are layout compatible with rtl_[u]StringStephan Bergmann1-8/+17
...as was suggested by Mike Kaganski in a comment at <https://gerrit.libreoffice.org/c/core/+/102222/10# message-aa8bcf42f04686766440e2848c7d1f76f474f2f8> "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString". Doing so revealed that at least lopglugin:unusedmember needs to handle InjectedClassNameType as an alternative to RecordType in at least one place. (More places across compilerplugins might benefit from handling InjectedClassNameType too, but which did not lead to assertion failures for now and should be addressed in follow-up issues.) Change-Id: Icdb8b069324b5ce5f3c7c6b92989379ccb67fc8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103125 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-21weld infobarsCaolán McNamara1-4/+0
note: "pushed" status listener case dropped. Doesn't seem to be an expectation for it to something in infobars, and there doesn't seem to be a working case anyway. Change-Id: I7869cc05de9918f0dd70e28b0087205db6c9506c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101945 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-20loplugin:xmlimport check for bad conversions to fastparserNoel Grandin2-47/+141
add a check for classes which have been partly converted to fastparser, but not completedly. This is to help me when I convert stuff. and it uncovers a bug introduced with commit 998308c363dfad03143591aa18256d2669b4da11 use more FastParser in SvXMLStylesContext Change-Id: Ib50e7136da10a1a7a346102aa47efef2f543e2ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102669 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-17Adapt compilerplugins/clang/test/unusedvarsglobal.cxxStephan Bergmann1-3/+3
...to e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString". (The original code would have started to fail with > error: 'error' diagnostics seen but not expected: > File compilerplugins/clang/test/unusedvarsglobal.cxx Line 22: declaration of variable 'literal1' with deduced type 'const OUStringLiteral' requires an initializer when built with Clang >= 11.) Change-Id: If51a39c8fb42200f064d62f472e8cddcc6e4c434 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102898 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann11-40/+39
...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-09-12Replace remaining uses of sal_CharJulien Nabet2-4/+2
+ remove sal_Char check on compilerplugins Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9 Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-09improve loplugin:unusedvarsglobalNoel Grandin4-282/+460
to find any global variable, was checking the wrong property of VarDecl Change-Id: I454b4e0c1701bb0771768a1ee10cd738c4ab0726 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102278 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-08longer watchdog timeouts for debug Skia buildLuboš Luňák1-1/+5
Skia runs internal checks, which occassionally actually may take a bit. Also abort() in dbgutil build already in case the watchdog disables Skia, to make finding these easier. Change-Id: I9ed09c57414e056de20a561b6945cba930edd37b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102096 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-07loplugin:singlevalfieldsNoel Grandin2-37/+103
Change-Id: Ib3c8dc4e98ca46026ec9a8171bae4066bcec7b22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102176 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07loplugin:constantparamNoel Grandin4-302/+306
Change-Id: I83722d99fa0d5919a7e878d32311dbb6de1c6714 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102175 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07loplugin:unusedfieldsNoel Grandin4-99/+79
Change-Id: Id1b1c07ddcacca8eef8af71890d9392f29b6be6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102172 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07loplugin:unnecessaryvirtualNoel Grandin2-21/+9
Change-Id: I596ef2603560f521386e273b6f0fb2f672db56d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102171 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-04tdf#124176 Use #pragma once in compilerpluginsGeorge Bateman9-36/+9
This commit was carried out by a Python script, source of which is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97. Change-Id: Id60579406a5aa16c3dc05a1bb5f1c1c828d39c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100251 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-03Fix check for member Decl's nameStephan Bergmann1-1/+2
...as some members like OUString::operator std::u16string_view() don't have a name Change-Id: I3ac9bbc43cdf899d4ab0483a95f00097f4b6f20a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102001 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-03restore m_aModelChangeListenerCaolán McNamara1-2/+0
which disappeared, apparently by accident with... commit 56e1133f724896aec3f5b5c409fb5917a3b13eb4 Date: Sun Dec 8 19:33:42 2013 -0200 Convert chart 3D scene illumination to .ui and then a bunch of cleanups removed the unused code Change-Id: I53fe4f6878dda4f7b8d76a04213b5c6d1366a165 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101917 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02-Werror,-Wrange-loop-analysisStephan Bergmann4-7/+7
Change-Id: I254e1b69f66b985d66c9ce3707614c3b505f2335 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101975 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02drop unused MinimalSystemDependentDataManagerCaolán McNamara2-4/+0
Change-Id: I6e5413bb79acac93abfb8398550c157e7b667a67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101942 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02remove some unused methodsCaolán McNamara1-4/+0
Change-Id: Ie86cc069b9c69087012b15597e548d1d745d6e2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101941 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02MergeNotebookBarMenuAddons has only static methodsCaolán McNamara1-2/+0
Change-Id: I962003d4753b726184d87916ba012b3808424653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101916 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02drop unused weld_windowCaolán McNamara1-2/+0
Change-Id: I0c52d992aba4d466048956ea9e8c49feb56862d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101915 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02drop some unused methodsCaolán McNamara1-116/+0
Change-Id: I4da391591d30db9e51c1dd543bcf128f2e8621c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101914 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02remove SfxCommonTemplateDialog_Impl vcl::Window memberCaolán McNamara1-2/+0
Change-Id: Ib1ab0e76cb56c909f1e16f58b61ce29d1a70a893 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101911 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02<http://reviews.llvm.org/D22128> has been fixed since LLVM 5Stephan Bergmann1-29/+6
...so compat::getSubExprAsWritten is now only needed for the ConstantExpr issue that cannot hit for LLVM < 8 (see TODO "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String") Change-Id: I12ad4624d353b1d801136e9988b261290e2f94d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101905 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02loplugin:unusedmethodsNoel Grandin1-71/+27
Change-Id: I523a42b721056f17a04870229834b0f2db00ff39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101836 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-02loplugin:unusedfieldsNoel Grandin4-30/+40
Change-Id: Icecc024c4385ec69508369d2645d8412e6dbff69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101835 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-02Turn OStringLiteral into a consteval'ed, static-refcound rtl_StringStephan Bergmann4-4/+27
...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-09-01Fix typo in codeAndrea Gelmini1-2/+2
It passed "make check" on Linux Change-Id: I9f3d98df05495e7d655a93c5cd5bbd41db6a9bea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101788 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-29loplugin:unusedfieldsNoel Grandin4-52/+40
Change-Id: I3f14647eed72898b641fbd583d18f914c7461628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101630 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29loplugin:unusedmethodsNoel Grandin1-69/+117
Change-Id: I2be47d2faf883b519f693e2d5ad58a5ab111849f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101629 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29Make the OUString ConstCharArrayDetector::TypeUtf16 overloads are actually usedStephan Bergmann2-0/+9
0c8fa58a2d73702770687ed15b98822d09f96ac3 "Support ConstCharArrayDetector also for UTF-16 arrays" had introduced those LIBO_INTERNAL_ONLY ctor and operator == overloads, but they never got called because the existing 'sal_Unicode const *' overloads always won. (The other function overloads introduced with 0c8fa58a2d73702770687ed15b98822d09f96ac3 should be unproblematic, as they do not have any 'sal_Unicode const *' overload counterparts.) Also fix the resulting loplugin:elidestringvar and loplugin:stringconstant fallout. For one, those plugins look at the actual ctor overloads being used, so had missed those cases that accidentally had used an unexpected overload. And for another, the heuristic the plugins used to detect the ConstCharArrayDetector overloads turned out to be too simplistic now and would have started to cause false positives. Change-Id: I4426890979fb832d53f391c7e1b62bc1ad501a65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101582 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-28drop newly unused VertSplitViewCaolán McNamara1-1/+0
Change-Id: Ib70905dd22ddd7a5f529501be10bdbfb9164a65f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101549 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann6-12/+15
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-08-27SvtIconChoiceCtrl can move into toolkit only headersCaolán McNamara1-2/+2
Change-Id: Ice3c01019d3e961c0ef1dce7d3eaf4f602269fff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101488 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-26[API CHANGE] Drop OSL_THIS_FUNC, directly use C++11 __func__Stephan Bergmann2-31/+1
It had been documented as "the macro OSL_THIS_FUNC is intended to be an office internal macro for now", so take the liberty of removing it, even if technically that can be considered an incompatible API change. Change-Id: I7580a932e1da54845934378a650e894f3f3a9062 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101406 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-24remove unused XIM.hCaolán McNamara2-5/+0
Change-Id: Icf15604a2d449159fceb212717264952e8cacb33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101282 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-21Silence some clang-cl loplugin:stringstaticStephan Bergmann3-0/+57
For one, do not warn about global declarations in included files, as generally not all uses of the variable are seen to decided whether it would be good to replace. That covers cases like > In file included from dtrans/source/win32/dtobj/DataFmtTransl.cxx:26: > dtrans/source/win32/dtobj/MimeAttrib.hxx(29,16): error: rather declare this using OUStringLiteral/OStringLiteral/char[] [loplugin:stringstatic] > const OUString CHARSET_UTF16 ("utf-16"); > ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For another, do not warn about variables whose pData member is used. That covers cases like > sal/osl/w32/procimpl.cxx(347,20): error: rather declare this using OUStringLiteral/OStringLiteral/char[] [loplugin:stringstatic] > const OUString ENV_COMSPEC ("COMSPEC"); > ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ Change-Id: I75c1048098b63164bdb583695951f73964cb24f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101134 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-20loplugin:singlevalfieldsNoel Grandin1-17/+14
Change-Id: I4cd20d1a449196b68c7dbe153c60e68b9563bea9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101049 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-24 02:13:35 +0000