/extensions/test/ole/unloading/

Age	Commit message (Collapse)	Author
2024-02-29	tdf#147021 replace SAL_N_ELEMENTS() with std::size()	Keldin Maldonado (KNM)
	Change-Id: I2a415e7c20d134d400e48745278597b475076d52 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163927 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2024-02-29	Simplify a bit	Mike Kaganski
	Change-Id: I9fbc43916fe0d7af87001e48854a87636115a1f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164133 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-05-01	use more string_view in various	Noel Grandin
	found by examining uses of OUString::copy() for likely places Change-Id: I6ff20e7b273ad6005410b82719183c1122f8c018 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133617 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-02-14	Recheck modules s[a-c]* with IWYU	Gabor Kelemen
	See tdf#42949 for motivation Change-Id: I867e1f7a2c44210de3281b36e22708a5d32ddb7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129476 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-10-11	In O[U]StringBuffer, make string_view params replacements for OUString ones	Stephan Bergmann
	...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That way, loplugin:bufferadd and loplugin:stringviewparam found many further opportunities for simplification (all addressed here). Some notes: * There is no longer an implicit conversion from O[U]String to O[U]StringBuffer (as that goes via user-defined conversions through string_view now), which was most noticeable in copy initializations like OStringBuffer buf = someStr; that had to be changed to direct initialization, OStringBuffer buf(someStr); But then again, it wasn't too many places that were affected and I think we can live with that. * I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to get them in line with their counterparts taking O[U]String. * I added an OUStringBuffer::lastIndexOf string_view overload that was missing (relative to OUStringBuffer::indexOf). * loplugin:stringconstant needed some addition to keep the compilerplugins/clang/test/stringconstant.cxx checks related to OStringBuffer::append and OStringBuffer::insert working. * loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea "loplugin:stringviewparam extend to new.." Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-21	Some more unit conversion unification	Mike Kaganski
	Change-Id: I1a906d918bb4255a75c62c68a57244f59d51d2b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111269 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-29	loplugin:stringviewparam extend to new..	Noel
	O[U]StringBuffer methods Change-Id: I0ffbc33d54ae7c98b5652434f3370ee4f819f6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110090 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-26	tdf#139167 XLSX export: fix proliferation of conditional styles	Tibor Nagy
	Run-time created styles “ExtConditionalStyle_N N” for extended conditional styles were written back to the XLSX file, growing the cell style list by each save-reload with unused styles. Co-authored-by: Attila Szűcs (NISZ) Change-Id: Icccb9f5333311556132b760efd4e8c8c2db00858 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109667 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-01-02	introduce Degree100 strong_int type	Noel
	Change-Id: I78f837a1340be0ca5c49097f543a481b7b43a632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108367 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-16	replace std::min(std::max()) with std::clamp	Noel
	Change-Id: I76e34e8020d98292e8ffde387542b7029f85a42d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105754 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11	make tools::Long 64-bit on Windows platform	Noel Grandin
	This is only for the 64-bit windows platform. I don't see the point in messing with the 32-bit platforms, they are (a) become more and more rare (b) unlikely to even have enough available process memory to load extremely large calc spreadsheets The primary problem we are addressing here is bringing Windows-64bit up to same capability as Linux-64bit when it comes to handling very large spreadsheets, which is caused by things like tools::Rectangle using "long", which means that all the work done to make Libreoffice on 64-bit Linux capable of loading large spreadsheets is useless on Windows, where long is 32-bit. The operator<< for tools::Rectangle needs to be inside the tools namespace because of an interaction with the cppunit printing template stuff that I don't understand. SalPoint changed to use sal_Int32, since it needs to be the same definition as the Windows POINT structure. Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-06	tdf#134161: Revert "tdf#132137 Rename Default Style in Calc."	Xisco Fauli
	This reverts 4111ed76906bf6be05b704bf52fa91353dfef183 the document would also hang if define STR_STYLENAME_STANDARD NC_("STR_STYLENAME_STANDARD", "Default"); is replaced by define STR_STYLENAME_STANDARD NC_("STR_STYLENAME_STANDARD", "DefaultTest"); meaning somewhere in the code 'Default' is harcoded as git grep "\"Default\"" sc/source/ shows Reverting for now so we can backport it to libreoffice-7-0 while a better solution is provided for tdf#132137 Some other problems of the reverted commit are mentioned in comment 4 and comment 5 of tdf#134161 I'm adding a unittest in another commit so this one can be easily reverted in the future Change-Id: Ib7c4a99ff4957eba7ec0b644e989c7a08b46f2a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105381 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-10-20	use tools::Long in sc	Noel
	Change-Id: I8f37a8d1174ed816df971b8cee036d4e88d4a7fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-16	Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString	Stephan 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-07-01	Upcoming improved loplugin:staticanonymous -> redundantstatic: sc	Stephan Bergmann
	Change-Id: Ie2d2d26bac69f4b228eadef712b06b665b3974eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97650 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-10	tdf#132137 Rename Default Style in Calc.	Srijan Bhatia
	Change-Id: I0f7c5ffc64b2387fbb63bb5724594480d3135f58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95484 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>