Resolves: tdf#98389 check memory requirement of matrix

Attachment 123203 of tdf#98389 has external references of the form
[1]Data!$1:$1048576
which effectively address the entire cell range of sheet Data and
allocating a matrix for a billion cells attempted to allocate 8GB+xGB of
memory which the system said no-no ...

Some brave soul along the road once decided that a check on the number
of elements wasn't needed anymore and dared to remove it during
refactoring.. This change reintroduces the check and adds it also to
other places that try to instanciate or resize a matrix.

When allocation of a matrix for an external range reference fails it is
checked whether the request is for such nasty entire rows or entire
columns ranges and if so tries to shrink the range to the actual data
area used, which at least in this case helps and works.

Additionally it fixes a long standing bug in the cached area to array
mapping which caused the cache to not be hit but instead the matrix was
aquired over and over again for the same range, causing a serious
performance bottle neck specifically for VLOOKUP and related functions
where the same external range is used in a lot of cells.

(cherry picked from commit 9e60bbdb3aa5f80ca80c9c4fdf7accd12c4a5d1c)

Change in convertToTokenArray() backported to older code flow.

disable means Enable(false), not true.. tdf#98389 related

EnableAdjustHeight(true) lead to the side effect that when clearing the
range of a pivot table during import, formulas in the same rows were
recalculated with then empty data. Through xSheetOp->clearContents() in
PivotTable::finalizeImport() of
sc/source/filter/oox/pivottablebuffer.cxx

In the case of the bugdoc attached to tdf#98389 that lead to all
VLOOKUP() calls resulting in #N/A errors because an empty string was
looked up.

(cherry picked from commit 088ba465d6bb0931c7034d564a3077e21078cb13)

e629ce871d255cc871671165c4da974f21041cec

setCellRangeData: check matrix size before operating, tdf#98389 follow-up

Now that we can have the one element error matrix we can't blindly call
ExecuteOperation() on it that would access elements out of bounds.

(cherry picked from commit 9cae3a88587deaf22ee83b2e36487013a1220a3b)

Backported to older code flow.

b6e5525f685c9324235f128a943dd716ea7a3fca

Change-Id: I35f67b48e665bf1cc8d672325c32b889f2e05c57
Reviewed-on: https://gerrit.libreoffice.org/22988
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

0 files changed, 0 insertions, 0 deletions