summaryrefslogtreecommitdiff
path: root/scripting
AgeCommit message (Collapse)Author
2021-12-03Fix --disable-scripting for DESKTOP buildJan-Marek Glogowski
Unfortunatly we cannot add --disable-scripting to sub_conf_defaults, because Java currently has no equivalent to the PYTHON_FOR_BUILD setting. Change-Id: I89938a17307a363f5de808200914940503312829 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126186 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-11-28use more OInterfaceContainerHelper2 in scriptingNoel Grandin
and remove unnecessary guards, OInterfaceContainerHelper3 will already take the mutex Change-Id: I951d9e02582768c5da9a7a3cc8412381f9f7e9fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125970 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-24Fix typos and translationsAndrea Gelmini
Change-Id: Ic358f008e09718b6f726a55edfe3a3f78bba2942 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125728 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2021-11-23Add more beanshell samplesSamuel Mehrbrodt
For Writer & Calc Change-Id: I85815acf11b750ec76d138ff8fe72cc4791e9038 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125689 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2021-11-08use more OUStringLiteral in MediaDescriptorNoel Grandin
Change-Id: I0567d103db8db401c737fed98483912a39352929 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124835 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-07Typo: implemnented->implementedJulien Nabet
Change-Id: I3171c95523408b69587aaa2bb064c750bc56c55d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124809 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-30Prepare for removal of non-const operator[] from Sequence in scriptingMike Kaganski
Change-Id: Ia85fe6de38674c7982b0f983a798a4d99ec1fb70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124384 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-18Revert incompatible ScriptEditor changeStephan Bergmann
...from interface to abstract class, in 1c42afc194da2288c5a738b727952e80c323885c "Respect DisableMacrosExecution option in javascript editor". It caused 3rd- party code like ScriptProviderForooRexx.oxt to fail to install. Change-Id: I532f27fdce806e471a8551646adbb3aecf80bcee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123745 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-15Remove non-const Sequence::begin()/end() in internal codeMike Kaganski
... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-14Avoid COW overhead using css::uno::SequenceMike Kaganski
The scenarios are: 1. Calling sequence's begin() and end() in pairs to pass to algorithms (both calls use getArray(), which does the COW checks) 2. In addition to #1, calling end() again when checking result of find algorithms, and/or begin() to calculate result's distance 3. Using non-const sequences in range-based for loops, which internally do #1 4. Assigning sequence to another sequence variable, and then modifying one of them In many cases, the sequences could be made const, or treated as const for the purposes of the algorithms (using std::as_const, std::cbegin, and std::cend). Where algorithm modifies the sequence, it was changed to only call getArray() once. For that, css::uno::toNonConstRange was introduced, which returns a struct (sublclass of std::pair) with two iterators [begin, end], that are calculated using one call to begin() and one call to getLength(). To handle #4, css::uno::Sequence::swap was introduced, that swaps the internal pointer to uno_Sequence. So when a local Sequence variable should be assigned to another variable, and the latter will be modified further, it's now possible to use swap instead, so the two sequences are kept independent. The modified places were found by temporarily removing non-const end(). Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-01loplugin:constmethodNoel Grandin
Change-Id: I3ed657c5c5e6840e38e3c8505505b4b372125df0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122910 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-20New loplugin:unusedcapturedefaultStephan Bergmann
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building without --with-latest-c++) requires ROW_RANGE (a local const int variable from the enclosing TestFormula::testTdf97369) to be captured, even though all uses of that variable within the lambda body are constant expressions. That is still true at least for the latest Visual Studio 2019 version 16.11.1. (This is not an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down, as they, in addition to using that ROW_RANGE, also use the local const double variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so they are implicitly captured and loplugin:unusedcapturedefault does not suggest dropping those lambdas' capture-defaults in the first place.) Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-20Make some scripts more portableIlmari Lauhakangas
Change-Id: Ia89059eea51ca396a7c74143625ac9a6706de198 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120773 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-08-05Pass context and resource string down to boost::locale separatelyNoel Grandin
because this is often on a hot path, and we can avoid the splitting and joining of strings like this. Change-Id: Ia36047209368ca53431178c2e8723a18cfe8260a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119220 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-04tdf#143582 - Clear return value of the method before calling itAndreas Heinisch
Otherwise the function keeps a copy of its return value, which may be used in an upcoming call. Change-Id: I4977c39e1ce48cfd5ab067a4df4783f10505a9ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119905 Tested-by: Jenkins Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
2021-08-03Consolidate on C++17 std::scoped_lock instead of std::lock_guardNoel Grandin
as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-02convert #defines to OUStringLiteralNoel Grandin
mostly by doing $ git grep -l '#define.*\"' -- *.cxx | xargs perl -pi -e 's/^#define\s+(\w+)\s+(\".*\")/constexpr OUStringLiteral \1 = u\2;/g' Change-Id: Idface893449b0ef2a3c5254865a300585d752fbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119669 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-01osl::Mutex->std::mutex in ProviderCacheNoel Grandin
Change-Id: Icf3afc783804c376fae94d0132e5040453e0d47a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119820 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-01osl::Mutex->std::mutex in MasterScriptProviderNoel Grandin
Change-Id: I40c2add3863ba284e6436a81424e3bbc7d501116 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119819 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-05-29std::unique_ptr -> std::optionalNoel Grandin
Change-Id: I15779eca607f27a758575f4f095910277aa85eda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-13inline some typedefsNoel Grandin
Change-Id: I1608e03ff9f6fbc55987010e88897e034b690b3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115552 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-29loplugin:stringadd simplify some *StringBuffer operationsNoel Grandin
pulled from a larger patch which I created with a more permissive variant of this plugin Change-Id: I7abf1f3f09e84703b6e0e52fe9587dff691b2187 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114875 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-28use string_view in INetURLObject::encodeNoel Grandin
Change-Id: Ib686c6872388b02c8939d3b65f6bd25cda348bc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114754 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-15loplugin:stringliteralvar look for assignmentsNoel Grandin
to O[U]String from char array literals, we can convert the char literals to O[U]StringLiteral and avoid a runtime allocation Change-Id: I15d8dddb2cd428b90740e39f20daf98e0941aa6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114125 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-31Use javax.xml.transform instead of reflection to write a DocumentStephan Bergmann
At least on Fedora 34 when building with --with-jdk-home=/usr/lib/jvm/java-16 against java-latest-openjdk-headless-16.0.0.0.36-1.rolling.fc34.x86_64, CustomTarget_odk/build-examples_java failed with > ERROR: Exception occurred: An error occurred while enabling: SayHello .../desktop/source/deployment/registry/dp_backend.cxx:645 > > ERROR: unopkg failed. > > make[2]: *** [Makefile:92: .../workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/ScriptingFramework/SayHello/devguide_scriptingframework_SayHello_register_scriptpkg.flag] Error 1 because of > info:bridges:1209707:1209707:bridges/source/jni_uno/jni_uno2java.cxx:117: exception occurred uno->java: [com.sun.star.lang.WrappedTargetException] java.io.IOException > java stack trace: > com.sun.star.lang.WrappedTargetException: java.io.IOException > at com.sun.star.script.framework.container.UnoPkgContainer.writeUnoPackageDB(UnoPkgContainer.java:279) > at com.sun.star.script.framework.container.UnoPkgContainer.processUnoPackage(UnoPkgContainer.java:330) > at com.sun.star.script.framework.provider.ScriptProvider.insertByName(ScriptProvider.java:563) > Caused by: java.io.IOException > at com.sun.star.script.framework.container.XMLParserFactory$DefaultParser.write(XMLParserFactory.java:190) > at com.sun.star.script.framework.container.DeployedUnoPackagesDB.write(DeployedUnoPackagesDB.java:107) > at com.sun.star.script.framework.container.UnoPkgContainer.writeUnoPackageDB(UnoPkgContainer.java:270) > ... 2 more > Caused by: java.lang.IllegalAccessException: class com.sun.star.script.framework.container.XMLParserFactory$DefaultParser cannot access class com.sun.org.apache.xml.internal.serialize.XMLSerializer (in module java.xml) because module java.xml does not export com.sun.org.apache.xml.internal.serialize to unnamed module @50860e85 > at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:385) > at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:687) > at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:489) > at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:128) > at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:350) > at java.base/java.lang.Class.newInstance(Class.java:642) > at com.sun.star.script.framework.container.XMLParserFactory$DefaultParser.write(XMLParserFactory.java:145) > ... 4 more The javax.xml.transform functionality appears to be available since Java 1.4, so it should not be a problem if we unconditionally use it. Change-Id: Idc31f8f6fb092b6603c537414497d24aec886ce7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113421 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.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-03-23tdf#124176 Use pragma once in s*Vincent LE GARREC
sc, scaddins, sccomp, scripting Change-Id: Ia99fec9e238033821cb784810edd4762c09bd5db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112049 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-03-09Drop "32" from names of SbxArray methods taking 32-bit indicesMike Kaganski
... a leftover from times when there were methods for 16-bit as well as for 32-bit indices. 16-bit indices were removed in commit 62f3f3d92aa204eaaa063b30d7ade44df501b997. Change-Id: Idf8b1160e68e8b303cf75ea79dd7dbb3bd00275d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112187 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
2021-01-01Fix typosAndrea Gelmini
Change-Id: I085ff68b4550468eb163d88978c81d8b5335e6ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108561 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-01tdf#128463: Revert the change to license informationKevin Suo
per comment by Tor Lillqvist in: https://bugs.documentfoundation.org/show_bug.cgi?id=128463#c18 The Apache part of the license was added by commit 8c9cc54bd7b6f3ba723d7a42ccc6a5372a80f970 due to misunderstanding. Change-Id: I861e7b13e1900de9287c768a4da8740fdb2e517f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108537 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-31tdf#128463: Rewrite NamedRanges.py to make it work when run from UIKevin Suo
This commit: 1. Updated the license header; 2. Added docstrings and notes to help the users to understand the API and code. 3. Make the code to create a new sheet named "data", define named ranges in it, modify the named range, define another named range, fill values in the cells related to the named ranges, the calcualte sum of each named range, and also calculate the difference between the two named ranges. The results are stored in the sheet named "information". 4. Cell alignment and background color methods are also used in this example. 5. Only show the parent function in the UI. Change-Id: Iba6111dc3754f054deeb0baf902dbff1eb3bfa2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108530 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-31tdf#128463: Make SetCellColor python example actually do sthKevin Suo
The previous one, when run from within the application, gives a runtime exception. This commit rewrites this example to: 1. Hide the private function from the UI; 2. Create a new blank Calc file instead of operating directly in the existing file; 3. Set cell colors to draw a "LO" picture in the sheet. 4. Added docstrings and API reference links. Change-Id: I120a3ede0629a5657fec18f1b0909dfc4bc7ad1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104720 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-10-10Improve example python code in scripting.Kevin Suo
* Modified the code to be more pythonic. * If "len(theString) == 0", then "not theString" evaluates to True. * "theString[0].isupper()" and "theString[1].isupper()" can be combined. * Remove unused imported string module * Wrap long lines * run autopep8 to prettify * ... Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104136 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
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-31Fix typos in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: Id7c7ac1b88d290ed71f03fa28dec144bcd29b692 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101590 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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>
generated by cgit (git 2.34.1) at 2025-01-10 12:35:21 +0000