Age	Commit message (Collapse)	Author
2024-05-13	loplugin:ostr in stoc	Noel Grandin
	Change-Id: I638b1e12781264770ce742d3303693e3b7fa82c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167597 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-30	tdf#146619 Drop unused 'using namespace' in: stoc/	Gabor Kelemen
	Change-Id: I86e2dd229e377995e52d323b1b5be5a9a280b68f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165514 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2023-12-10	cid#1546298 COPY_INSTEAD_OF_MOVE	Caolán McNamara
	and cid#1546297 COPY_INSTEAD_OF_MOVE Change-Id: I8fbb2bb1692cc822a79652312c6268379226a9c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160517 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-09	cid#1556778 COPY_INSTEAD_OF_MOVE	Caolán McNamara
	and cid#1546474 COPY_INSTEAD_OF_MOVE cid#1546473 COPY_INSTEAD_OF_MOVE cid#1546469 COPY_INSTEAD_OF_MOVE cid#1546467 COPY_INSTEAD_OF_MOVE cid#1546458 COPY_INSTEAD_OF_MOVE cid#1546448 COPY_INSTEAD_OF_MOVE cid#1546446 COPY_INSTEAD_OF_MOVE cid#1546441 COPY_INSTEAD_OF_MOVE cid#1546424 COPY_INSTEAD_OF_MOVE cid#1546377 COPY_INSTEAD_OF_MOVE cid#1546374 COPY_INSTEAD_OF_MOVE cid#1546352 COPY_INSTEAD_OF_MOVE cid#1546334 COPY_INSTEAD_OF_MOVE cid#1546328 COPY_INSTEAD_OF_MOVE cid#1546310 COPY_INSTEAD_OF_MOVE cid#1546303 COPY_INSTEAD_OF_MOVE Change-Id: I8a43fdd574857ba1d3ec416f23c8269a9a08e12f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160515 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-10-14	Use exception ctors, instead of setting members later	Mike Kaganski
	Avoids overwriting source location in message Change-Id: Ia0290c7dd1ab3ea1357712a27ecab75c7b583dd4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157893 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-06-18	Use getXWeak in stoc	Mike Kaganski
	Change-Id: Icd694eeae002ab28cbd06ba3097e9039e299de3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150871 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-03	Just use Any ctor instead of makeAny in stoc	Stephan Bergmann
	Change-Id: I3345444f356dd3df9069773eba2bab1b46a08c46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133772 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-15	Remove non-const Sequence::begin()/end() in internal code	Mike 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-14	Avoid COW overhead using css::uno::Sequence	Mike 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-05-02	throw() -> noexcept, part 2/3: Automatic loplugin:noexcept rewrite	Stephan Bergmann
	Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-15	stoc/invocation: create instances with uno constructors	Noel Grandin
	See tdf#74608 for motivation. Change-Id: Idf47e3fff2ca0e693834bcdd228159b5725837e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98700 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-02	Upcoming improved loplugin:staticanonymous -> redundantstatic: stoc	Stephan Bergmann
	Change-Id: I993e4c0aef41b0925678d7744a989ad5539cc80e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97693 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-14	Revert "loplugin:constfields in stoc..svgio"	Noel Grandin
	This reverts commit 0ddf3e0a628599d01356cb5262b93faca073ee9f. Change-Id: I3e476399a465950defc15ac4d6199a638c4a4baf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90452 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-22	sal_Char->char in sot..store	Noel Grandin
	Change-Id: Ia133c1a7549d81f2e88e34ab7e6c9ea578c745ae Reviewed-on: https://gerrit.libreoffice.org/85702 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-04	use scoped enum	Stephan Bergmann
	Change-Id: I8eadedbdf5f4bee218ae2f39c76300fc0624912b Reviewed-on: https://gerrit.libreoffice.org/84374 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-22	Extend loplugin:external to warn about classes	Stephan 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-07-31	Improved loplugin:stringconstant (now that GCC 7 supports it): stoc	Stephan Bergmann
	Change-Id: Id739d5ff815d3bb1db48e9b1c2b3f739e3f11dfd Reviewed-on: https://gerrit.libreoffice.org/76644 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-22	Simplify Sequence iterations in shell..svgio	Arkadiy Illarionov
	Use range-based loops, STL and comphelper functions Change-Id: I612d36abcc09a91c60f7212de6747a1a1bdcfc69 Reviewed-on: https://gerrit.libreoffice.org/76056 Tested-by: Jenkins Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
2019-05-20	tdf#42949 Fix IWYU warnings in stoc/	Gabor Kelemen
	Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I3c1b091d30449243faec3f875e6f0ac6d8b34259 Reviewed-on: https://gerrit.libreoffice.org/72214 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-03-04	simplify UNO getTypes methods	Noel Grandin
	Change-Id: Ia8b07edec54527fb4904536fabb03a18e8452550 Reviewed-on: https://gerrit.libreoffice.org/68659 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-10	loplugin:indentation in soltools..svl	Noel Grandin
	Change-Id: I270a12cdb68920b8fa23b82dd933724e30334485 Reviewed-on: https://gerrit.libreoffice.org/67565 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-29	loplugin:flatten in stoc..store	Noel Grandin
	Change-Id: Ib8c86179a3d13852cbb02b389b6103aca5456dba Reviewed-on: https://gerrit.libreoffice.org/67013 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-04	replace double-checked locking patterns with thread safe local statics	Mike Kaganski
	Change-Id: I1bf67196e97411aeecc13ed4f91d1088a315e323 Reviewed-on: https://gerrit.libreoffice.org/62839 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-10-09	Extend loplugin:redundantinline to catch inline functions w/o external linkage	Stephan Bergmann
	...where "inline" (in its meaning of "this function can be defined in multiple translation units") thus doesn't make much sense. (As discussed in compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions in include files for now.) All the rewriting has been done automatically by the plugin, except for one instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus some subsequent solenv/clang-format/reformat-formatted-files. Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224 Reviewed-on: https://gerrit.libreoffice.org/61573 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-10-08	loplugin:constfields in stoc..svgio	Noel Grandin
	Change-Id: Icfd936fe9b83e0e122af5b09f7ed6dde2ead4400 Reviewed-on: https://gerrit.libreoffice.org/61512 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-09-17	New loplugin:external	Stephan Bergmann
	...warning about (for now only) functions and variables with external linkage that likely don't need it. The problems with moving entities into unnamed namespacs and breaking ADL (as alluded to in comments in compilerplugins/clang/external.cxx) are illustrated by the fact that while struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } returns 1, both moving just the struct S2 into an nunnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { namespace { struct S2: S1 { int f() { return 1; } }; } int f(S2 s) { return s.f(); } } int main() { return f(N::S2()); } as well as moving just the function f overload into an unnamed namespace, struct S1 { int f() { return 0; } }; int f(S1 s) { return s.f(); } namespace N { struct S2: S1 { int f() { return 1; } }; namespace { int f(S2 s) { return s.f(); } } } int main() { return f(N::S2()); } would each change the program to return 0 instead. Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c Reviewed-on: https://gerrit.libreoffice.org/60539 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-05-31	Revert "Simplify: Use AutomationInvokedZone::isActive()"	Tor Lillqvist
	Can't have the URE library 'stoc' depend on the non-URE library 'comphelper'. This reverts commit 3c041720304ec77202741b5d5c8df9b93bc70a70.
2018-05-31	Must catch Exception here, not the more specific UnknownPropertyException	Tor Lillqvist
	Change-Id: I4b0b119af356f38f359f2ba5afa6081533790443
2018-05-31	Simplify: Use AutomationInvokedZone::isActive()	Tor Lillqvist
	Don't need the mbFromOLE boolean flag and the special "FromOLE" parameter passed to the InvocationService:: createInstanceWithArguments(). Change-Id: I05e10a78955d87cb7c37e198c60c3ddcfdbc4275
2018-05-31	Do same trick in setValue() as earlier in getValue() for Automation clients	Tor Lillqvist
	Also, it is UnknownPropertyException that we need to catch, not RuntimeException. Did I not actually exercise my change to getValue() back in February? Change-Id: If13eaa9bbecd15f5330a4102ae932f2ec0c7ecd4
2018-05-30	We might need to handle form controls as properties for OLE clients after all	Tor Lillqvist
	Start a bit of work on that. Change-Id: I7775f9598a81d64e9716996027b01f7f8e29745b Reviewed-on: https://gerrit.libreoffice.org/55043 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-05-30	Hack to make properties work better from Automation clients	Tor Lillqvist
	There were a couple of problems apparent at this stage when using the ooovbaapi things from a test Automation client (written in VBScript, to be precise). Accessing for instance the ActiveDocument property of an ooo::vba::word::XGlobals instance worked fine. But properties of other objects, like instances of ooo::vba::word::XDocument, did not work. When attempting to access any property of an ooo::vba::word::XDocument, the code ended up calling the hasProperty() of SwVbaDocuemnt. That function is for checking a totally different kind of "properties", namely named form controls. Why form controls are con-fused with oovbaapi properties I don't know. Maybe it is intentional and as expected when using the oovbaapi from the built-in Basic interpreter in LibreOffice. Or then just an accident in history. Still, surely it can't be changed, that would break Basic scripts embedded in existing ODF documents. Anyway, from an OLE Automation client, for instance when asking for the Content property of an ooo::vba::word::XDocument object, we definitely don't want any form control that happens to have the name "Content". We want an object with two integer properties, Start and End. Make this work by always creating an invocation factory instead of using the object itself. Pass the invocation factory's createInstanceWithArguments() function an extra argument indicating this is the case of use from OLE Automation. In the Invocation_Impl class in the stoc module, when this extra argument is noticed, set a new mbFromOLE flag. Modify the behaviour slightly when that is true. I am not at all sure that this will work in all cases, but let's see, at least for simple tests so far it had the intended effect. Another issue was that looking up these properties was case sensitive. This is wrong at least from languages like VBScript. Use the mbFromOLE flag also to affect the case sensitivity behaviour. Maybe I should simply make sure that _xDirect is null in the Automation case? _Direct (a reference to an XInvocation) being non-null probably means that we are using the document interface's own implementation of XInvocation, which is probably always wrong in the OLE Automation case. (Just see the SwVbaDocument implementations of hasProperty() and invoke(), for instance.) Change-Id: I2fd174f69f430893aef538cc9bf2a99d1c86b567 Reviewed-on: https://gerrit.libreoffice.org/55023 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-05-25	Improve re-throwing of UNO exceptions	Noel Grandin
	() if we are already throwing a WrappedException, get the exception using cppu::getCaughtexception. () when catching and then immediately throwing UNO exceptions, use cppu::getCaughtException to prevent exception slicing () if we are going to catch an exception and then immediately throw a RuntimeException, rather throw a WrappedTargetRuntimeException and preserve the original exception information. Change-Id: Ia7a501a50ae0e6f4d05186333c8517fdcb17d558 Reviewed-on: https://gerrit.libreoffice.org/54692 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-02-09	Fix exception message: add colon between function name and the word "expected"	Tor Lillqvist
	Change-Id: I80eadaa097afdbe4394aceca9f40b9753792f30b
2018-02-05	Remove code that has been commented out since initial import in 2000	Tor Lillqvist
	Change-Id: I42aaed79e88b6cb8bb0b93aa49555aad45050fe7