summaryrefslogtreecommitdiff
path: root/scripting/source
AgeCommit message (Collapse)Author
2021-02-06tdf#124176 Used pragma once instead of include guardsViKrAm-Baisclear
Change-Id: I235462f3ce81816f3ce36c7423dd3e50fc03778a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109320 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-01-22tdf#133889 Upcasting the type of actual parameter.tushar
Type of actual parameter is made same as formal parameter.This is done to undo the conversions made in sbxToUnoValueImpl. Change-Id: I8c7a880503d927eb43ad38eac4bf01451442834b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109773 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-01-18tdf#133887 Set flag of variable when formal parameter is not expecting variant.tushar
If there is no param info for formal paramter then type of formal parameter and actual parameter will be same and there is no need to set the flag in that case. Change-Id: I12af64f82fc5b2d6d7fb920bde1cb96f8c7bd51b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109070 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-09fix coverity parse errorsCaolán McNamara
Change-Id: I3a1179947704452e3ffec02be59d0f7bf0b75ab0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109017 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 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-01tdf#42949 Fix new IWYU warnings in directories s*Gabor Kelemen
Except recently checked sc, sd, svx, sw Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ice1b86628e4f22a39f307b9c5fa567b6ab9d5acb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106917 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-12-01OSL_FAIL.*exception -> TOOLS_WARN_EXCEPTIONNoel
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-05loplugin:reducevarscope in scriptingNoel
Change-Id: I214f58c9d0bd8e574e8882234c84f595605d2fe7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105331 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-14Replace list by vector in scripting/eventhelpherJulien Nabet
Change-Id: Ia7a24649cc8f204fe412b240df02b3a814ed491c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104180 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-08-19Fix typosAndrea Gelmini
Change-Id: Ibe3cd52117f7f47e1806bde76114cb1644d78763 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100969 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-07-15scripting/basprov: create instances with uno constructorsNoel Grandin
See tdf#74608 for motivation. Change-Id: Id4a312df7b3ed4c4c81f7f1b42b8e8697d4bb784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98742 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-15scripting/protocolhandler: create instances with uno constructorsNoel Grandin
See tdf#74608 for motivation. Change-Id: I5618d68317a24bfe92dc166ffc81dcf5ffeba1e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98740 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-15scripting/stringresource: create instances with uno constructorsNoel Grandin
See tdf#74608 for motivation. Change-Id: I3ad9af6cff62ee822ac5f0cfd4da12eb36bfb50f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98739 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-14scripting/provider: create instances with uno constructorsNoel Grandin
See tdf#74608 for motivation. Change-Id: If5337702e4bdc583bbae34e90a89c20b7341937e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98738 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-14scripting/dlgprov: create instances with uno constructorsNoel Grandin
See tdf#74608 for motivation. Change-Id: Ia135b0696a52dd414b5187f33195e8b86d552c2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98741 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-10replace usage of blacklist with denylistThorsten Behrens
.. and a few cases of instead doing blacklist->excludelist where that made more sense. Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 [API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist [API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice [API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: scriptingStephan Bergmann
Change-Id: Iee244e5b7f3f768d2e58165ae438824a1f1a0d0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97654 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-09tdf#42949 Fix IWYU warnings in scripting/Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I014631ec79242d9a5f735d7401fe0f5e323c69a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95649 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-09remove the fake SvxScriptErrorDialog codeNoel Grandin
which just forwards to an async real dialog. Change-Id: I61936c4d105b9829042817e6a3cf5e60c451fb6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95830 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-05Upcoming loplugin:elidestringvar: scriptingStephan Bergmann
Change-Id: Ib900f42b41bf6a3b8f65132dd4c6eb46fb1e5171 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95539 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-14fix python 3.8 deprecation warningsNoel Grandin
the logo changes were caused by > Support of nested sets and set operations as in Unicode Technical Standard > #18 might be added in the future. This would change the syntax, so to facilitate > this change a FutureWarning will be raised in ambiguous cases for the time being. > That includes sets starting with a literal '[' or containing literal character > sequences '--', '&&', '~~', and '||'. > To avoid a warning escape them with a backslash. Change-Id: I4d48be3df2eaadf03a9d1f5750c0c94b3abbf674 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94191 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-10compact namespace in sal..svgioNoel Grandin
Change-Id: I7e70614ea5a1cb1a1dc0ef8e9fb6fd48e85c3562 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93904 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-22Fix typosAndrea Gelmini
Change-Id: I49d7dc8a2cbcba5413d05d97559321e672ed413a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92655 Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-04-09pyuno,*: kill Python 2 support with fireMichael Stahl
Python 2 support was retained for use with --enable-python=system on RHEL7 and SLES. The time has arrived to remove it. Some .py files that were imported from third parties are not changed to enable easier replacement with updated versions if necessary. solenv/gdb should continue to support Python 2. bin/get-bugzilla-attachments-by-mimetype requires Python 2 to access Launchpad. Change-Id: I26414ae8e9f8402c90336af82020135685694217 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91697 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-06scripting: mailmerge.py: remove Python 3.0/3.1 supportMichael Stahl
Change-Id: I934b8f07f99aca1cbc7489f019c905a79acab258 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91695 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-02loplugin:flatten in scriptingNoel Grandin
Change-Id: I8df38b4b581fb674a050ef32624b22498a8e340f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91549 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-12Revert "loplugin:constfields in scripting"Noel Grandin
This reverts commit 383a4f883d4a2932167695c761611b998f773f0e. Now that we know that making fields has negative side effects like disabling assignment operator generation. Change-Id: I9fc04024b12a977481d010950244cff05e18bd74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90368 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-31new loplugin:namespaceindentationNoel Grandin
check indentation of braces in namespace decls, and the comments that often appear with them. This is my penance for messing up the indentation with clang-tidy-modernize-namespaces. As such I have limited it to new-style namespaces for now, and the check is off by default. Change-Id: I4db7f10a81c79bc0eece8f8e3ee564da8bc7f168 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87723 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-28sys.version is for displaying; use sys.version_info for version checkMike Kaganski
Change-Id: If0d26019d9f842bcf56c1e01c46cc86c21523c3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87476 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-01-28remove some unused local varsNoel Grandin
found by my new loplugin:unusedvariableplus Change-Id: Ic3f55f492d43a53d8850a97d44059ff127fd69a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87573 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-07Fix typoAndrea Gelmini
Change-Id: I16245a94dd17dbb158a1a1f0a7c33ffd7b1731f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86303 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-12-22sal_Char->char in scaddins..sdextNoel Grandin
Change-Id: If2456800ace3696c2582e19a4c8612fee7d77f90 Reviewed-on: https://gerrit.libreoffice.org/85700 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-20tdf#124176: Use pragma once instead of include guardsKemal Ayhan
Change-Id: I4a045b450a5779bdd357a05a0efd4da7d521682d Reviewed-on: https://gerrit.libreoffice.org/85448 Tested-by: Jenkins Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
2019-12-09SbxArray: drop 16-bit indicesMike Kaganski
Change-Id: I43b478187636b9bb53fdf7ab938436ae364bd7a7 Reviewed-on: https://gerrit.libreoffice.org/84733 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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-24cppcheck: performing init in init list (sc/scripting/sd)Julien Nabet
Change-Id: I8bd4c1b7b551a96ecd5a2b50fbfdf225567175f6 Reviewed-on: https://gerrit.libreoffice.org/83621 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-09tdf#80731: Only check closing parenthesis when in IDEMike Kaganski
This reinstates the fix by Pierre Lepage, which was reverted in 351dead74b4c213b13102f81b5ae9bb47ad8ca39, and makes sure it only has effect when the compilation is started from IDE. The idea is that the IDE is used primarily for development, and that's a good opportunity to detect any error in the code. When the code is compiled from outside of the IDE (like running an extension), the error is tolerated to allow users run the legacy code having this error. Hopefully this is enough for tdf#106529. This re-uses comphelper's NoEnableJavaInteractionContext class, which is converted into general-purpose SetFlagContext class to avoid code duplication. Change-Id: Ie290019cb190b8d1d590699ec13bd63eac478d09 Reviewed-on: https://gerrit.libreoffice.org/81616 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-11-06Check if scripting disabled for each dispatch callSamuel Mehrbrodt
Not only when initializing. This way, changing the property during runtime has an effect. Change-Id: Iba5f00996f0079fc4bafb5d373f34c6fd86c7959 Reviewed-on: https://gerrit.libreoffice.org/82078 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-11-05Fix option to disable macrosSamuel Mehrbrodt
so that it indeeds disables any macro execution. Before, you could still add macros to the toolbar and execute them from there (and probably many more places). Now, if this option is set, any macro will no longer be executed. This includes Javascript, Beanshell and Python scripts Change-Id: Icfa845e836782c8e1b670a67694f79a60ad74fad Reviewed-on: https://gerrit.libreoffice.org/82052 Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de> Tested-by: Serge Krot (CIB) <Serge.Krot@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-17Remaining loplugin:bufferaddStephan Bergmann
...that had been missing because the plugin didn't implement postRun, so it didn't report anything when run as part of the shared plugin. (But did report the expected warnings when run as a standalone plugin during CompilerTest_compilerplugins_clang.) Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old preallocation of a 20 character OStringBuffer might have prevented buf.append( reinterpret_cast<char *>(escapedString), len -1 ); from potentially throwing std::bad_alloc, which would have caused escapedString to be leaked. Even though that 20-character preallocation was likely just random junk and not meant to address the potential leak, lets address it now. Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900 Reviewed-on: https://gerrit.libreoffice.org/80925 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-01loplugin:stringadd in scNoel Grandin
Change-Id: Idab16f785ca5e8954f8e50132938f6329106c927 Reviewed-on: https://gerrit.libreoffice.org/79891 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-26loplugin:constmethod in scNoel Grandin
Change-Id: I78c4fb4acf21756f91582caee5e30e3ad1fc2ae4 Reviewed-on: https://gerrit.libreoffice.org/79543 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2024-05-23 07:38:59 +0000