This requires 2 fixes
(*) First, we are deleting from the front of a block in the mdds
storage, so apply a similar patch to mdds to the previous improvement,
(*) Then, we end up with an O(n^2) situation in ScRangesList::Join.
But we are only displaying this data, and in fact, we only display the
first 1000 ranges anyway, so just clamp the list to 1000 entries, and
pass a flag up to the dialog so that we can report that we stopped
counting.
(*) I had to tweak the testSharedStringPool unit test, since
we are not actually clearing the underlying mdds storage, the
reference counts do not drop until we have removed all the
elements in that block of mdds storage (because then the entire
block is destructed, including the not-yet destructed elements)
Change-Id: I2c998f81dfb46453a48fce1254fd253d299d12b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139400
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Normally, the answer to repeated erase(begin()) is to walk backwards
through the array.
However, sometimes (like here), doing so will mean that we end up
inserting at the front of a different array, which means we don't gain
anything.
So, store an extra field in the mdds block, which implements a kind
of very simple approximation of a circular array.
This gives me a 50% speedup for this bug.
This is the simplest possible thing that could work.
It could probably be made a lot more sophisticated in terms of not
wasting space.
Change-Id: I036349786896f28b617dfd0924f5743db6a57695
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135896
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
> In file included from workdir/UnpackedTarball/mdds/include/mdds/flat_segment_tree.hpp:37,
> from sc/inc/columnspanset.hxx:16,
> from sc/source/core/data/columnspanset.cxx:10:
> In function ‘void mdds::__st::intrusive_ptr_add_ref(node<T>*) [with T = mdds::flat_segment_tree<int, bool>]’,
> inlined from ‘boost::intrusive_ptr<T>::intrusive_ptr(const boost::intrusive_ptr<T>&) [with T = mdds::__st::node<mdds::flat_segment_tree<int, bool> >]’ at workdir/UnpackedTarball/boost/boost/smart_ptr/intrusive_ptr.hpp:93:44,
> inlined from ‘boost::intrusive_ptr<T>& boost::intrusive_ptr<T>::operator=(const boost::intrusive_ptr<T>&) [with T = mdds::__st::node<mdds::flat_segment_tree<int, bool> >]’ at workdir/UnpackedTarball/boost/boost/smart_ptr/intrusive_ptr.hpp:154:9,
> inlined from ‘mdds::flat_segment_tree<_Key, _Value>::flat_segment_tree(const mdds::flat_segment_tree<_Key, _Value>&) [with _Key = int; _Value = bool]’ at workdir/UnpackedTarball/mdds/include/mdds/flat_segment_tree_def.inl:88:25:
> workdir/UnpackedTarball/mdds/include/mdds/node.hpp:244:10: error: pointer used after ‘void operator delete(void*, std::size_t)’ [-Werror=use-after-free]
> 244 | ++p->refcount;
> | ~~~^~~~~~~~
> In function ‘void mdds::__st::intrusive_ptr_release(node<T>*) [with T = mdds::flat_segment_tree<int, bool>]’,
> inlined from ‘void mdds::__st::intrusive_ptr_release(node<T>*) [with T = mdds::flat_segment_tree<int, bool>]’ at workdir/UnpackedTarball/mdds/include/mdds/node.hpp:248:13,
> inlined from ‘boost::intrusive_ptr<T>::~intrusive_ptr() [with T = mdds::__st::node<mdds::flat_segment_tree<int, bool> >]’ at workdir/UnpackedTarball/boost/boost/smart_ptr/intrusive_ptr.hpp:98:44,
> inlined from ‘boost::intrusive_ptr<T>& boost::intrusive_ptr<T>::operator=(const boost::intrusive_ptr<T>&) [with T = mdds::__st::node<mdds::flat_segment_tree<int, bool> >]’ at workdir/UnpackedTarball/boost/boost/smart_ptr/intrusive_ptr.hpp:154:9,
> inlined from ‘mdds::flat_segment_tree<_Key, _Value>::flat_segment_tree(const mdds::flat_segment_tree<_Key, _Value>&) [with _Key = int; _Value = bool]’ at workdir/UnpackedTarball/mdds/include/mdds/flat_segment_tree_def.inl:87:19:
> workdir/UnpackedTarball/mdds/include/mdds/node.hpp:252:9: note: call to ‘void operator delete(void*, std::size_t)’ here
> 252 | delete p;
> | ^~~~~~~~
etc. The warning is apparently new in GCC 12 trunk (see
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=671a283636de75f7ed638ee6b01ed2d44361b8b6>
"Add -Wuse-after-free [PR80532]"), and I'm not entirely sure whether this
is a true or false positive, but the fix looks somewhat plausible, and at least
also my (Clang) ASan+UBSan build does a successful `make check` with (and
without) this change.
Change-Id: I63fafceba8d1b4e0ddd7cf2e58403a3bc763e53c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129008
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> In file included from svl/source/misc/gridprinter.cxx:16:
> In file included from workdir/UnpackedTarball/mdds/include/mdds/multi_type_matrix.hpp:37:
> In file included from workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector.hpp:1358:
> workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_def.inl:851:15: error: variable 'start_pos' set but not used [-Werror,-Wunused-but-set-variable]
> size_type start_pos = m_cur_size;
> ^
> workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_def.inl:3926:15: error: variable 'start_row_itr' set but not used [-Werror,-Wunused-but-set-variable]
> size_type start_row_itr = start_row_in_block1;
> ^
Change-Id: I1f5e7e1f6a2b8457eb6d65dbd65336d3684c2b89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116808
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
> In file included from sc/source/core/data/cellvalues.cxx:12:
> In file included from sc/inc/column.hxx:28:
> In file included from sc/inc/mtvelements.hxx:30:
> In file included from workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector.hpp:33:
> workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_itr.hpp:74:9: error: definition of implicit copy assignment operator for 'private_data' is deprecated because it has a user-declared copy constructor [-Werror,-Wdeprecated-copy]
> private_data(const private_data& other) :
> ^
> workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_itr.hpp:44:8: note: in implicit copy assignment operator for 'mdds::detail::mtv::iterator_value_node<unsigned long, mdds::mtv::base_element_block>::private_data' first required here
> struct iterator_value_node
> ^
> workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_itr.hpp:219:20: note: in implicit copy assignment operator for 'mdds::detail::mtv::iterator_value_node<unsigned long, mdds::mtv::base_element_block>' first required here
> m_cur_node = other.m_cur_node;
> ^
> workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_itr.hpp:238:7: note: in instantiation of member function 'mdds::detail::mtv::iterator_common_base<mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> >, sc::CellStoreEvent>::iterator_trait>::operator=' requested here
> class iterator_base : public iterator_common_base<_Trait>
> ^
with recent Clang 10 trunk, similar to
<https://gerrit.libreoffice.org/#/c/83698/> "Remove some redundantly
user-declared copy ctors and assignment ops"
Change-Id: I156674bad367ca68404c3c75d61ec72b401c6305
Reviewed-on: https://gerrit.libreoffice.org/83700
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Turns out the earlier mdds 1.5.0 package was not correctly packaged.
I've fixed that now, and re-published the 1.5.0 package, which does
contain the patch from Lubos.
Change-Id: I1ff7d6568568860f7cccd3be3bc29aaaebe7fd73
Reviewed-on: https://gerrit.libreoffice.org/77483
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
Make RefUpdateContext and ScColumn::UpdateReferenceOnCopy() use the same
sc::ColumnBlockPositionSet that CopyFromClipContext uses. Without it
pathological cases like in tdf#112000 trigger quadratic cost because
of repeated mdds searches from the start.
Includes also an mdds patch that allows it to search backwards
from a position hint. Without it, this would be very difficult to fix
otherwise, as CopyFromClip() in ScDocument::CopyBlockFromClip()
moves the position hint past the area that UpdateReferenceOnCopy()
would use. It also just plain makes sense to try to go backwards
in an std::vector.
Change-Id: I985e3a40e4abf1a824e55c76d82579882fa75cc2
Reviewed-on: https://gerrit.libreoffice.org/72424
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The largest change in 1.4.x relevant to the calc code is that the
multi_type_matrix::walk() methods now take a copy of the function
object rather than a reference, to allow for it to take an inline
lambda function. Instead, it does return a instance of the input
function object, similar to how std::for_each() behaves.
In case the function object contains a large data member, try to
make it a moveable so that it will get moved rather than copied
when going through one of the walk() methods.
Change-Id: Ifd08fc4a2ed75039e5292a35ff08726e0126c77f
Reviewed-on: https://gerrit.libreoffice.org/59584
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
...by removing explicitly user-provided functions that do the same as their
implicitly-defined counterparts, but whose presence may prevent implicitly
declared copy functions from being defined as non-deleted in the future
Change-Id: Ie9b943af57bd8081c06a531fb3c634e52f0a99b6
Reviewed-on: https://gerrit.libreoffice.org/58048
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Similar to libc++ in C++17 mode, some types like std::auto_ptr are indeed
removed in C++17 mode by default, and need _HAS_AUTO_PTR_ETC=1 to be enabled
(see <https://blogs.msdn.microsoft.com/vcblog/2017/12/08/c17-feature-removals-
and-deprecations/>).
Unlike libc++, also std::binary_function and std::unary_function are removed
(and need the same _HAS_AUTO_PTR_ETC=1 to enable). So either set that flag to
make external code build, or use patches (for external/mdds) to make externals'
files included in LO proper still work there.
Change-Id: I886cc0de8196255334ee03ec48cb4bc54d460afd
Reviewed-on: https://gerrit.libreoffice.org/46514
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
when there is associated data in the src. Its copies those pointers
into the block that will appear in the destination. Then can destroy
the source block, which deletes the contents of those pointers, and
then inserts the new block which has dangling pointers to the deleted
data.
https://gitlab.com/mdds/mdds/merge_requests/2
Change-Id: Id9614d95652c8032b03cb5748a284917043d8d21
Xisco Fauli