summaryrefslogtreecommitdiff
path: root/writerperfect/source
AgeCommit message (Collapse)Author
2022-12-14lok: hide customization in EPUB export dialogSzymon Kłos
Change-Id: I531aba2eb52e74904b6cba82add769d35a8a28c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144150 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2022-12-14Make EPUB Export dialog asyncSzymon Kłos
Change-Id: Iead5b4ff6064395fd5abbcdea73db38415dbb37c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143877 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
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-01Prepare for removal of non-const operator[] from Sequence in writerperfectMike Kaganski
Change-Id: Ifaa868e8e68be474c1e8b961b325ce2a7382650e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124414 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-06clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: Ib41556edafb03c770938c91cff89bfaefa23d7cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121691 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-04dynamic_cast -> static_cast (tdf#130795)Noel Grandin
the dynamic_cast is hot here, and none of these dynamic_casts are necessary, we already assert that they must succeed, so just use static_cast Change-Id: I88ade90431c4da4792c778b5cdab22332ed1c428 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121637 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-03Remove some unused includesMiklos Vajna
See tdf#42949 for motivation. Change-Id: I62354cf2ae750a91b72e91ad838a40e205e7cd61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121526 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-08-17Replace GDIMetaFile::Write and WriteGDIMetaFile with SvmWriter::Writepanoskorovesis
Use the new write functionality. This change also sets SvmWriter::Write second argument as const, as it's value does not change Change-Id: I1620756542a0bc54b5f8fc7ce3f57d0243a2ee55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120408 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-06-21bundle the FolderPicker instantiations behind a single callCaolán McNamara
in prep to add parent support Change-Id: I2aa4b9343f895ae866f600dd3260b7fdc4e1efec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117579 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-06-11Simplify Sequences initializations (writerfilter/writerperfect/x*)Julien Nabet
Change-Id: I1bd31fe6cf0f8aaf4f2cfe1d3d49e61a0633f361 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117057 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-05-17EPUB export: make sure txtparai.hxx is self-containedMiklos Vajna
txtparai.hxx was the first include in txtparai.cxx to make sure the header is self-contained, restore that. (Ignoring sal/config.h.) Change-Id: I430e1bef12191e15f416381cd8d83c503b284851 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115692 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-05-14Improve loplugin:stringviewStephan Bergmann
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-03-23tdf#124176 Use pragma once in w*Vincent LE GARREC
Change-Id: I693f6dafb743d39afd8e41e66a8066f04043f8a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112052 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-02-23loplugin:refcounting check for managing OWeakObject with raw pointerNoel
Change-Id: I7471725f1e658940b5e6993361c327be6ccf0d31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111064 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-18loplugin:referencecasting in writerperfectNoel
Change-Id: I2b8dfca7344caa4b9dd503fc3fca383a6cee8f04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111077 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-26tdf#124176 Use pragma once in writerperfecthalfhiddencode
Change-Id: I2484df85c3f3d6011f04844ff30de53c287ab36d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108317 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2020-12-19make *String(string_view) constructors explicitNoel Grandin
to make it more obvious when we are constructing heap OUStrings code and potentially inadvertently throwing away performance. And fix a handful of places so revealed. Change-Id: I0cf390f78026f8a670aaab53424cd31510633051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-11-30loplugin:stringviewparam include comparisons with string literalsNoel
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11make tools::Long 64-bit on Windows platformNoel 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-10-26switching long to a 64-bit type on 64-bit windowsNoel
(*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-16writerfilter: use the fastparser API when possibleNoel
part of the process of making SvXMLImport fastparser-only Change-Id: I9bb2d337954354be63984892e1fc4a7950ca3628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104411 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-27restore PocketWord filter, this time backed by libwpsDavid Tardon
Change-Id: If9843ae717f58e683252c8ea55360a567978395e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103514 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2020-09-17writerperfect: include sal/config.h firstMiklos Vajna
To confirm to the convention outlined at <https://gerrit.libreoffice.org/c/core/+/102899/2#message-96d023d6a393bfa29ea537d46f6975e935d649a4>. Change-Id: Ib3f5f872e7635df355ca0d9f12e55fc0b1da2cb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102964 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-17writerperfect: make sure "own" header is the first oneMiklos Vajna
So that we have a build-time check that the header is self-contained. Change-Id: Idbaab48c3f4dba03c383c3c152bca47883376396 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102899 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
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-09-02Remove some unused includesMiklos Vajna
Change-Id: I90d4e3db3eefa41f8492cfe23c5088ea93134afc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101890 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.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-11loplugin:flattenNoel Grandin
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100447 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-20compact namespace: writerperfectNoel Grandin
Change-Id: I178bc76636d7fc3f4b11d836555a8ad53725b072 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99013 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: writerperfectStephan Bergmann
Change-Id: I13fcde3b0c847a622be0305c6d2bd21057d3402c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97758 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-12filter,writerperfect: adapt XHTML,EPUB to draw:mime-type in ODF 1.3Michael Stahl
Change-Id: I6391f7b4f0183a0193aaa10f2a41fac416a22c09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92984 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2020-05-01improve loplugin:makesharedNoel Grandin
to find places where we are converting stuff to unique_ptr instead of using std::make_shared. As a bonus, this tends to find places where we are using shared_ptr where we can instead be using unique_ptr avoiding the locking overhead. Change-Id: I1b57bbc4a6c766b48bba8e25a55161800e149f62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93207 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-30no need to use strlen hereNoel Grandin
since librevenge's string class already has the length Change-Id: I194ae49596dacc1205bdfb10d0a6a1833914f884 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93171 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-27Make upcasting css::uno::Reference ctor require complete typesStephan Bergmann
The main reason for the "home-grown" UpCast introduced with 904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for css::uno::Reference" in 2013 was probably that we could not yet rely on C++11 std::is_base_of back then. A (welcome) side effect was that the derived class could be incomplete. However, specializations of UpCast relying on whether or not T2 is incomplete are obviously an ODR violation if the type is incomplete in some TUs and complete (and derived from T1) in others. And even if UpCast had internal linkage, it would still be brittle that its behavior depends on the completeness of T2 at the point of the template's instantiation, and not necessarily at the point of use. That means we should better base that ctor on std::is_base_of (which we can do now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on Clang and GCC if the completeness requirements are not met. This change fixes all the cases where types need to be complete now, plus any resulting loplugin:referencecasting warnings ("the source reference is already a subtype of the destination reference"). Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-25Remove unused using declarations in oox...xmlsecurityGabor Kelemen
Found by: run-clang-tidy-10 -checks=-*,misc-unused-using-decls Change-Id: I3e95791e223ef01e140a6217e29a9efae428a784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90876 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-16Revert "loplugin:constfields in writerfilter"Noel Grandin
This reverts commit e7c6c05ae5a62e1705ffda97c5405eecd1f62a1e. Change-Id: I9072c4ef9c1a941ac3169e2b53dfd25ae7863770 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90545 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-11tdf#42949 Fix IWYU warnings in writerperfect/Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ia1ac2b3d254487f6b4e85b52eead13635d30a5af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88416 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-31clang-tidy modernize-concat-nested-namespaceNoel Grandin
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-28New loplugin:unsignedcompareStephan Bergmann
"Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-24loplugin:makeshared in svgio..writerperfectNoel Grandin
Change-Id: I0f8de0f78c7a8fb78d47ee5dfed09019b4eb5288 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87357 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-10use more std::make_sharedNoel Grandin
found using 'git grep', I tried using clang-tidy, but it only successfully found a tiny fraction of these Change-Id: I61c7d85105ff7a911722750e759d6641d578da33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-09writerprefect: add missing braces around try-catchMiklos Vajna
Spelling them out helps readability. Change-Id: I878e1a258b7d15b673ff3dbb42e40147bf60b41a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86453 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-08Fix typo/grammarAndrea Gelmini
Change-Id: I8e7320224a9cb4ff9317b842a2c1c0b1a3ddcd17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86390 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-12-18writerperfect[libwps,tdf#128673]: use the inFilter option in headless mode...alonso
Change-Id: I494360ddb55e39e09edf03aaf0bf6a01dc432f83 Reviewed-on: https://gerrit.libreoffice.org/82595 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-13loplugin:expandablemethodsNoel Grandin
Change-Id: I333d91ea5ce78c82e9bb107f934614efc7bfb8f7 Reviewed-on: https://gerrit.libreoffice.org/85078 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
generated by cgit (git 2.34.1) at 2024-07-15 01:12:39 +0000