summaryrefslogtreecommitdiff
path: root/svx/source/xml
AgeCommit message (Collapse)Author
2021-10-31Prepare for removal of non-const operator[] from Sequence in svxMike Kaganski
Change-Id: Ib5fda9469f9a1987cf9071c0e228c582cfb3dfa1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124397 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-15loplugin:constvarsNoel Grandin
Change-Id: I9b35d6333afa6b305bf73fc55a7e60c8365674e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122134 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-30tdf#137310 ODF import: fix loading of images with multiple slashes in pathMiklos Vajna
Regression from commit 1b02ba03bd62a712e15c15384a3d105d2c088120 (shapes: don't use "GraphicURL" property, always use "Graphic", 2018-02-13), the problem was that now the loading of Models/Fallbacks/duck.png goes via SvXMLGraphicHelper::ImplGetGraphicStream(), which assumed that the directory part of the picture path contains no slashes, so can be handled via ImplGetGraphicStorage(). That functions works with Pictures/something.png, but not with Models/Fallbacks/duck.png. Fix the problem by using openStreamElementByHierarchicalName() to open the picture stream in case we got no stream and the storage name contains a slash. Change-Id: I0e04fb4286777b04286c4979af31e6df19988873 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121308 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
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-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-03osl::Mutex->std::mutex in OutputStorageWrapper_ImplNoel Grandin
Change-Id: Idb5e46d91cd933e4dcc1b3cd751c65d9ddd9e077 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119913 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-07-16tdf#92796 ODF import: remove unused bitmap fillsMichael Stahl
With CWS impress64 a partial fix for this was implemented to drop unreferenced named items including all non-color fills after ODF import, but this is only done in sd so move the code that does that to svx and call it from sc and sw as well. Implement some UNO interface for this, it's at least better than a magic string, and not obvious how a better solution would look like since it's known only at the end of the import if a bitmap is used or not. Another problem: when the Area tab is used to change to a different kind of fill, the items with the details for the previous fill aren't cleared, and so they are written to ODF files. Hence bitmaps in the file can be referenced even if they aren't actually used, and bloat up the files. Fix this by dropping all unused draw:fill-image-name attributes in ODF import. Also do the same for Gradient and Hatch fills; Transparency gradients can be combined with anything so leave them as they are. Change-Id: I0b591fd9f963d974d0c3e7208b99621ad61dd93c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118950 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-06-29constructing SaveOptions just to read default versionNoel Grandin
can be a little expensive sometimes, since it loads a bunch of other stuff at the same time. So create a custom method that just loads the version Change-Id: Ic480d95c4d64c68e57faf1b52f1d102141b7e246 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118047 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-06-10Simplify Sequences initializations (sot/stock/svl/svtools/svx)Julien Nabet
Change-Id: Iec21851d69f4a8d5f557e9ed2d30e5f680cd62c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116943 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-29no need to allocate these on the heapNoel Grandin
Change-Id: Ia839a25cb75782b7b92372d876a41a7fd2e830d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116370 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-02throw() -> noexcept, part 2/3: Automatic loplugin:noexcept rewriteStephan Bergmann
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-15loplugin:referencecasting in svxNoel
Change-Id: I072ba9da976cefd61f4a916e70b0601439e8a123 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110818 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-11loplugin:refcounting generalise type checkingNoel
Change-Id: Ia013878ac9c2918d8eaf9aab16b291d8211e708f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110700 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-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-25tdf#42949 Fix new IWYU warnings in directory svxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: If578c5119b85f991825e91df37c42e28f16e9de5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100555 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-02create common macro and method for logging unknown attributesNoel
instead of repeating the code everywhere Change-Id: Idb94054b392ed256e64259cdb17d1522bf3c52b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105184 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02make SvXMLImport capable of mixing fast- and slow- contexts adhocNoel
so I can convert even *ImportContext subclasses in the middle of a context stack, and thus break the cyclic dependency nature of the writer import. and adjust the xmlimport loplugin for the new rules. As a consequence of the loplugin:xmlimport's checking, we remove a bunch of now unnecessary overrides of startFastElement. Change-Id: I97464522ede8ec5e345e928cdafa4b18364b1b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-16svx: use the fastparser API when possibleNoel
part of the process of making SvXMLImport fastparser-only Change-Id: I30aa8a429fabf54e39cf401419f627cc13ed719c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104427 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-05use more TOOLS_WARN_EXCEPTIONMike Kaganski
Change-Id: I3e8bfdf717dd8896ab16e396f671651ca4f7f01c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103932 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-09-30loplugin:reducevarscope in svxNoel
Change-Id: I88fdaa74c4944f9ffc81db6df08a29283362375a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103647 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-01Fix typoAndrea Gelmini
Change-Id: I03dc9ad3ad496524efbbb2f1a48f76fb95d1bfc5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101781 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>
2020-08-22use fastparser for fill stylesNoel Grandin
Change-Id: I2dcc34863eec5f3ba02ee6df4e64604926b072d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101171 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-14rename xmlnmspe -> xmlnamespaceNoel Grandin
Change-Id: I8fdf9833dede6f4c9ba4bbb76b9ab9b6b419f155 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100722 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-14rename nmspmap.hxx -> namespacemap.hxxNoel Grandin
we're not in DOS anymore, Dorothy Change-Id: I79926e0d694163940ba7ebf20419724dd0a486f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100721 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-06loplugin:flatten in svxNoel Grandin
Change-Id: I31f33a5f693d5fdb8282181c5bd7f31971efe784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100236 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: svxStephan Bergmann
Change-Id: I6f4b927f9c869925825cc83cc36f0494d06c8faa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97698 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-29loplugin:constantparamNoel Grandin
Change-Id: I54f0e2864cb4ef00fea8f9e4369a1f76721e7503 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97369 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-05Upcoming loplugin:elidestringvar: svxStephan Bergmann
Change-Id: Ia7b4f69361b6cc29f6e5c0093b13cf0b48e25ba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95576 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-22tdf#41995: sxx: ODF export: save SVG to ODF 1.2 as wellMichael Stahl
... and SVM into ODF 1.2 Extended (compatibility mode). Change-Id: I2056ddac40570fdf69178349ff546cd313709b25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94575 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-05-07replace ODFDefaultVersion usage with ODFSaneDefaultVersionMichael Stahl
Compare with ODFSVER_012 mostly works the same, except for places where namespaces are defined where the ODFSVER_EXTENDED bit should be checked. Change-Id: I86469b763bc2f903632976bc9d6ec04d543d705e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92727 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-29simplify handling of comparing XML_NAMESPACE valuesNoel Grandin
Change-Id: I18bbf1ee206285842250891ce556d523489855b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93075 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-28move the castToFastAttributeList functionNoel Grandin
to the slightly higher namespace, to make it easy and more readable to use directly in a for-loop-range expression. And make it return a reference rather than a pointer, since it is never allowed to be nullptr. Change-Id: I15d0b32493ef65cfc601b247c272b318f1eadfd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93049 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-17pdfium: Make Insert -> Image... use VectorGraphicData for PDF.Jan Holesovsky
In principle, the current Svg/Emf/Wmf and PDF handling is trying to achieve the same thing: Keep the original stream untouched, provide a replacement graphics, and a kind of rendering. To hold the data, the Svg/Emf/Wmf and PDF were using different structures though. This commit consolidatates that, and makes the Insert -> Image... (for PDF) actually using the VectorGraphicData to hold the original stream. This breaks loading the PDF as a document via PDFium - I'll fix it in the next commit(s). Change-Id: Iac102f32b757390a03438c165e430283851cc10b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90561 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-03-13Revert "loplugin:constfields in svx"Noel Grandin
This reverts commit 1a6397030381a45f27ab7a2a02e6e6d0f9987c84. Change-Id: Iaa706bb4ea3144ef57ab359b982400abc589b97e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90454 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-10tdf#42949 Fix IWYU warnings in svx/source/[t-x]*/*cxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I8d8a3e13932b004678b305f9a6883062854f9201 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90140 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-27remove duplicate tokens from xmloffNoel Grandin
Which causes trouble when converting stuff to use FastParser APIs. I see we used to use dummy entries to avoid perfhash complaining, which is fine for exporting, but doesn't work when we use these constants for fast-parser importing, because the imported element/attribute ends up mapped to what looks like the "wrong" constant. So let's just make the constants match their textual representation. Change-Id: I173d4b1e5fedede18375a6f7c15b1f36a48e4063 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89627 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-01make update_pch also consider files in <module>/src/**/incLuboš Luňák
With --enable-pch=full there's not much difference between a "public" header in <module>/inc and a private one in <module>/src/somewhere/inc . And since the script searches recursively, this apparently helps to find even more headers for lower pch levels. Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-28tdf#75280 Convert inappropriate use of sal_uIntPtr to better integer typesEda Nur Var
Change-Id: I2829cccb526084590889d0618bc89a921aa8cdf7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87475 Tested-by: Jenkins Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
2020-01-15clang-tidy modernize-concat-nested-namespace in svxNoel Grandin
Change-Id: I8a00f2823aa956afb995ee68c9f995bf08ad5239 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86824 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-14use FastParser APIs in SvxXMLXTableImportNoel Grandin
Change-Id: I744943bdcdecc10219898d23038eb5d0c2dfb5d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85479 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-07extract some common code from ImportContext classesNoel Grandin
which reduces code bloat, and lets us log when elements are ignored Change-Id: I5ca12bc1fcbfa3bea49ebde819fd80bd233a96a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86338 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>
2019-11-18use FasterParser for SvxXMLXTableImport::loadNoel Grandin
the SvXMLImport superclass of XMLVersionListImport already constructs a parser, so we can just use that one Change-Id: I28402467f63e166a2c5ffc3bf0c851de81ba2108 Reviewed-on: https://gerrit.libreoffice.org/83061 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-17Extend loplugin:external to warn about enumsStephan Bergmann
To mitigate the dangers of silently breaking ADL when moving enums into unnamed namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79 "New loplugin:external"), note all functions that are affected. (The plan is to extend loplugin:external further to also warn about classes and class templates, and the code to identify affected functions already takes that into account, so some parts of that code are not actually relevant for enums.) But it appears that none of the functions that are actually affected by the changes in this commit relied on being found through ADL, so no adaptions were necessary for them. (clang::DeclContext::collectAllContexts is non-const, which recursively means that External's Visit... functions must take non-const Decl*. Which required compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support such Visit... functions with non-const Decl* parameters.) Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd Reviewed-on: https://gerrit.libreoffice.org/83001 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-30 05:11:05 +0000