/source/sv/wizards/

Age	Commit message (Collapse)	Author
2023-08-22	tdf#146619 Remove unused includes from sal/qa	Gabor Kelemen
	also drop now-unused osl_Condition_Const.h Change-Id: I40beb5b1ad49c126a126bb444d5f66703664d56d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155820 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-08-07	Drop unnecessary header osl_Mutex_Const.h	Gabor Kelemen
	It only contained a single define used in a single file Change-Id: If9f16ab13bb28d2923b97390f1acb013101d0a09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155349 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-03-04	Avoid "ThreadSanitizer: unlock of an unlocked mutex"	Stephan Bergmann
	...in (somewhat contorted) test code Change-Id: I247a30e580b3d458eb748a833100a662c9890d99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130991 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-08-02	Fix typos	Andrea Gelmini
	Change-Id: Ie183c445bf8a545f59aac7b0e29f72ab679a6cf3 Reviewed-on: https://gerrit.libreoffice.org/76852 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2019-02-09	loplugin:indentation in registry..sax	Noel Grandin
	Change-Id: I4b877751818febaec8e64018335dca691a476a43 Reviewed-on: https://gerrit.libreoffice.org/67561 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-07-08	tdf#84323 - sal - add sane sleep interface: cleanup osl_waitThread	Kevin Dubrulle
	Replace osl_waitThread by osl::Thread::wait. Use std::chrono instead of TimeValue. Change-Id: I71691d014feeeb0c5d0ba29d048bda8e25e6e7dd Reviewed-on: https://gerrit.libreoffice.org/57130 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>