summaryrefslogtreecommitdiff
path: root/android
ModeNameSize
-rw-r--r--.gitignore270logplain
d---------Bootstrap112logplain
-rw-r--r--CustomTarget_lo_android.mk1602logplain
-rw-r--r--Makefile1367logplain
-rw-r--r--Module_android.mk494logplain
-rw-r--r--README13671logplain
d---------default-document39logplain
-rwxr-xr-xmobile-config.py5052logplain
d---------source515logplain
generated by cgit (git 2.34.1) at 2025-02-12 02:28:52 +0000
special handling for a single Item in SC, the ScPatternAttr. In former code that method was used from SfxItemSet and ::PutImpl at the pool directly, so it was only used in one place. I am not sure if it was used from the SfxItemSet functionality, but better offer it for now. To not waste too much runtime the callbacks depend on the boolean 'NewItemCallback' at the SfxPoolItem, it gets set for that single Item in SC and only then the callbacks trigger. I hope to get rid of those again, e.g. newItem_UseDirect is only needed since we have no 'real' StaticPoolDefaults currently - another thing that needs to be cleaned up in a next step. Since usages of impl(Create|Cleanup)ItemEntry and Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it globally available in svl and use it also directly for Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that fallback (e.g. tryToGetEqualItem) was used before, thus this is the same class of errors (SfxPoolItem ptr-compare) as the others which I will need to find anyways. Also fixed some missing stuff. Have now idenified and redirected all SfxPoolItem ptr-compares to be able to debug these - one cause for the remaining errors is probably that before with bPoolable those often were sufficient, but are no longer. Used the [loplugin:itemcompare] and a local clang build to do so, see https://gerrit.libreoffice.org/c/core/+/157172 Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter to implCreateItemEntry to signal that it gets called from DirectPool stuff - currently needed. Hopefully when getting rid of that DirectPool stuff we can remove that again Added two more debug functionalities: - Added a SerialNumber to allow targeted debugging for deterministic cases - Added registering & listing of still-allocated SfxPoolItems at office shutdown Found PtrComp error in thints.cxx - POC, thanks to areSfxPoolItemPtrsEqual. Will hopefully help more with other tests Found some wrong asserts/warnings where I was too careful and not finding something/succeeding is OK, fixes some UnitTests for SC For SC I now just tried to replace all areSfxPoolItemPtrsEqual with the full-ptr-content compare SfxPoolItem::areSame. I also needed to experiment/adapt the newItem_Callback solution but got it working. Did that replacement now for SW too, found some places where the direct ptr compare is OK. Continued for the rest of occurrences, now all 160 places evaluated. Also done some cleanups. Massive cleanups of stuff no longer needed with this paradigm change. Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now. It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that already needs many exceptions. Also useful for testing if errors come up on this change to test if it is related to this. Added forwarding of target Pool for ::Clone in SvxSetItem and SvxSetItem, simplified SfxStateCache::SetState_Impl and returned to simple ptr compares in SfxPoolItem::areSame to not do the test in areSfxPoolItemPtrsEqual. Debugged through UITest_calc_tests9 and found that in tdf133629 where BoxStyle is applied to fully selected empty calc the Item- reuse fallback has to be used not only for ATTR_PATTERN, see comment @implCreateItemEntry. Maybe more... Problem with test_tdf156611_insert_hyperlink_like_excel. Found that in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField is found and returned as ptr, but it's usage crashes. That is due to the SfxItemSet aEditSet used there gets destroyed at function return what again deletes the SvxFieldItem that is holding the SvxURLField that gets returned. This shows a more general problem: There is no 'SfxPoolItemHolder' that safely holds a single SfxPoolItem - like a SfxItemSet for a single Item (if Items would be shared_ptrs, that would be a safe return value). That will be needed in the future, but for now use another solution: Since I see no reason why EE_FEATURE_FIELD should not be shareable I wil change this for ow in the SfxItemInfo for EditCharAttribField. That way the Item returned will be shared (RefCnt > 1) and thus not be deleted. I changed the return value for GetURLField() and GetFirstURLFieldFromCell() in ScEditShell: At least for GetFirstURLFieldFromCell the return type/value was not safe: The SvxFieldItem accessed there and held in the local temporary SfxItemSet may be deleted with it, so return value can be corrupted/deleted. To avoid that, return a Clone of SvxFieldData as a unique_ptr. With all that UnitTest debugging and hunting and to get the paradigm change working to no longer rely on shared/pooled items I lost a little bit focus on speed, so I made an optimization round for the two central methods implCreateItemEntry/implCleanupItemEntry to get back to the speed improvements that I detected when starting this change. It was mainly lost due to that 'strange' chained pool stuff we have, so I added to detect the target pool (the one at which the WhichID is registered) directly and only once. Next thing to cleanup will/should be the pool and it's concept, all this is not needed and really costs runtime. Since implCreateItemEntry/implCleanupItemEntry are executed millions of times, each cycle counts here. Had an error in the last changes: pool::*_Impl methods use index instead of WhichID - most of them. Another bad trap, I really need to cleanup pool stuff next. Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2023-06-29Use getXWeak in svxMike Kaganski Change-Id: I7e5c029a79b8437ae5f803df5ad20217c240d1d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150874 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2022-05-03Just use Any ctor instead of makeAny in svxStephan Bergmann Change-Id: I59b1b3f817a9028f132456ea5094f38f88674d00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133768 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 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> 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> 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-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): svxStephan Bergmann Change-Id: Idbdee862f96a3d9e6baaa7203528a423c017eb80 Reviewed-on: https://gerrit.libreoffice.org/76640 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-06-18tdf#42949 Fix IWYU warnings in include/svx/[t-v]*Gabor Kelemen Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I345b8c54890b5bc27f51addd2e6e73ba68b6b327 Reviewed-on: https://gerrit.libreoffice.org/73977 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2019-04-20simplify SfxPoolItemArray_Impl (tdf#81765 related)Noel Grandin Since we want to look up items by pointer, just store them in a std::unordered_set, which allows fast find(). This dramatically simplifies most operations on this data structure. Fix a dodgy sd test that was relying on items with the same whichid being in the pool being in a certain order. Change-Id: I4d79fc718f95e3083a20788be1050fbe9fca7263 Reviewed-on: https://gerrit.libreoffice.org/70881 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>