and
cid#1557287 Use of auto that causes a copy
cid#1558003 Use of auto that causes a copy
cid#1557568 Use of auto that causes a copy
cid#1556546 Use of auto that causes a copy
cid#1557377 Use of auto that causes a copy
cid#1608325 Use of auto that causes a copy
Change-Id: I84e59d2b14bb1e5856f9cac521ad6542b1784243
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170821
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
In various places, the code checks if we are running as a unit test or a
UI test. This code grew organically, and is most re-using environment
variables that were designed for narrower purposes.
Rather than being clever, just add two new explicit and simple
environment variables in the natural place (the command that runs them),
and check for those variables in the code.
Change-Id: Icce0997914fa0be30a5ac1f29bd870bdb5893a8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170618
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
dependency for XLOOKUP and XMATCH because of better compatibility.
The idea is to specify, that the global setting 'search-criteria-must-apply-to-whole-cell'
is ignored and XMATCH and XLOOKUP always behaves as if 'search-criteria-must-apply-to-whole-cell'=true.
That would affect exact search in Match_mode value 0. Users would need to use wildcard or regex
to get a match to part of the content. But removing dependency to the global setting increases
interoperability with MS Excel.
Also the ODF TC will follow that in the final specification of these functions:
https://issues.oasis-open.org/browse/OFFICE-4154
Follow-up commit: 17d578ba91
(Related: tdf#127293 Add new Match_mode option for XLOOKUP and XMATCH functions.)
Change-Id: I1317865631d2925eaff72e9c1425d93386c3d016
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169582
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Tested-by: Jenkins
and ScSortedRangeCache classes to support binary search mode in case of
different columns. Which is used by the new XLOOKUP function from now on
in case of binary search mode.
Change-Id: Ibb2ae33670cbe9b47110de57afb6376cd829b465
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166758
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
search than Excel.
Some rework for xlookup binary search in rows to get the correct results
when we are searching with binary mode in rows.
Change-Id: I7ef710c4ae638e2cf5d4bee45810cec7057f5d4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166451
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
and for the duration of Threaded calculation where there will be
no new formats required we can drive number formatting with the
unlocked RO policy.
Change-Id: Ic0e449acdcf834bc569d13b4a984f13c55316801
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165160
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Purpose is to use one set of code for all similar lookup functions, as
they now each have their own code, which is largely identical.
Next steps will be to make the code used by XLOOKUP and MATCH work with
each similar lookup function.
This patch just changes the interface to accomodate other functions.
Change-Id: I6950aa69404f3eb8acbf2d55e247058f3e798814
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163230
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
...that are used in inline functions in sc/inc/queryiter.hxx, but where the
template definition is only available in sc/source/core/data/queryiter.cxx, and
which had caused at least Clang PCH builds to now fail with
> ld.lld: error: undefined symbol: bool ScQueryCellIteratorAccessSpecific<(ScQueryCellIteratorAccess)1>::IncPosImpl<false>()
> >>> referenced by queryiter.hxx:111 (sc/inc/queryiter.hxx:111)
> >>> workdir/CxxObject/sc/inc/pch/precompiled_sc.o:(ScQueryCellIteratorAccessSpecific<(ScQueryCellIteratorAccess)1>::IncPos())
>
> ld.lld: error: undefined symbol: bool ScQueryCellIteratorAccessSpecific<(ScQueryCellIteratorAccess)1>::IncPosImpl<true>()
> >>> referenced by queryiter.hxx:112 (sc/inc/queryiter.hxx:112)
> >>> workdir/CxxObject/sc/inc/pch/precompiled_sc.o:(ScQueryCellIteratorAccessSpecific<(ScQueryCellIteratorAccess)1>::IncPosFast())
> clang++: error: linker command failed with exit code 1 (use -v to see invocation)
> make[1]: *** [sc/Library_sc.mk:10: instdir/program/libsclo.so] Error 1
Change-Id: If87b268a69e7acd411164ce53c549be32ded41cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163434
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
https://issues.oasis-open.org/browse/OFFICE-4154
What is working already: xlookup with normal forward,
backward search in columns/rows. Binary search in rows with
real binary search algorithm, in columns only works with linear search yet.
Linear forward backward wildcard/regex search in columns/rows.
Looking for the first smaller or greater value with linear and binary search
ALso all the combination of all these options. Except XLOOKUP
not supperted wildcard/regex search with binary search.
TODO in next patches:
- add the binary search option for searching in columns.
- Evaluate Formula calculation not working in general.
Co-authored-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Change-Id: I15fd4479b63ec13b093d269760d1bbb5957553e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131905
Tested-by: Jenkins
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Temporary measure until the actual cause is fixed.
The by string query of binary search on sorted cache is broken for
mixed types like here the numeric date cells and text cells.
Change-Id: Icfe0b0c30987fcefdd6ed11066ea9113f3b4dabe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151074
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
the same case, though non-fatal in that instance, can be seen with
sc/qa/unit/data/functions/spreadsheet/fods/hlookup.fods
with a maParam.nCol2 of 27, nFoundCol of 23, nCol of 28 so a nColDiff
of 5. rParam.nField was originally reduced from 27 to 22 with
-= nColDiff, while with this approach of restoring the original
position it is restored to the value of 23 it had before the
last call to GetNext()
Change-Id: Ia6ca73be03fe313c81a23f176a40a5e619a75d3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148415
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Both the documents from the bugreport use COUNTIF where the range
includes the cell itself. So trying to create ScSortedRangeCache
for the range would try to read the values of the cells in the range
including the cell itself, which would try to interpret COUNTIF,
which would recurse and deadlock on the mutex.
Change-Id: I95c33d0b75015dcd1d628740ef52c2d680864791
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136581
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
My fix for tdf#149071 actually disabled the optimization for all
ByValue lookups, because in fact all such lookups have maString set.
So lookups where the cells are a mix of numeric and string values
need different handling. A simple solution is detecting such a mix
when collecting the values for ScSortedRangeCache and disabling
the optimization in such a case. But it turns out that queries
containing such a mix are not that rare, as documents may e.g.
do COUNTIF($C:$C) where the given column has numeric values that
start with a textual header. So bail out only if the string cell
actually could affect the numeric query.
Also fix ScSortedRangeCache usage depending on query parameters,
different instances are needed for e.g. different ScQueryOp,
because the ScQueryEvaluator functions may return different
results (isQueryByString() is automatically true for SC_EQUAL).
Change-Id: Ib4565cbf6194e7c525c4d10d00b1c31707952a79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136403
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Those fields are meant to be uninitialized by the ctor. And if they get
used by mistake, I'd prefer to hear that from e.g. Valgrind rather
than cover it up with some dummy default value.
Change-Id: Ide57f84e9dc0fcc8c7395af99e216c7626d50913
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134512
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The comparison depends on the cell encountered, which makes it hard
to prepare the sorted data.
Change-Id: I22f55003acde7eedadb8a4c8d61390dd30b6ac8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134287
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
It should not be necessary in that case, since the rows are restricted
only to those that match, selected by BinarySearch(). Still at least
assert that, just in case I'm missing something (or BinarySearch()
doesn't quite match what validQuery() does).
Change-Id: Ie91d3ba997692e5b3650b1549e8a38b6c5f44c01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134130
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
If the amount of data or size of the formula group is small, the caching
is probably not worth it. And if rows are not absolute, then each
formula cell would use a different range instead of reusing the cache.
Change-Id: I42a82aaa5f4ffccc63e527793f46fc52fd539af6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134129
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
ScQueryEvaluator::isQueryByString() makes everything a string search
in this case, so this one should too.
Change-Id: Ic1ebd14515cfb7f253f022ca4f76699a6cb63468
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134137
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This enables use for e.g. VLOOKUP or COUNTIFS (as COUNTIFS does
not use the specialized code for COUNTIF).
Change-Id: Idad7503750d421f3f1c9ac34dfe95393fa3ead15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134124
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The idea is that there's a cache for a given range, which keeps
a vector of SCROW items, sorted by values of those cells. This
allows some specific cases of e.g. COUNTIF to simply use
BinarySearch() to find the range that matches and work only with
that. This commit implements using this cache for COUNTIF.
Change-Id: I5b36b289b4aecb3b8245bbb447fbb299371262e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134120
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
If the code detects the range is not actually properly sorted,
set position to the first row and return false to force
linear search. If the searched for value belongs before the first
item, do the same, in which case the linear search should see
that it is this case (before this case nRow was set to the first
row regardless of where the searched for value belonged).
Change-Id: I8ff346783d93d74ff409b19aea394e202885647d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134100
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
If the code found a matching value, it didn't bother finding
the last one in the range if there were several adjacent ones.
Change-Id: Ie1f4c7bd3dcbd2aaf653f5b74e159902de4cf93d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134098
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
This moves code related to accessing cells to query to a template
base class. Creating more specialization of that class will allow
queries that use a cache of sort order for the cells.
Change-Id: I47d1bc2d038717ff64f1d11fa6c7dba2359fec11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134096
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
d468958331 improved COUNTIF performance
by copy&pasting the generic query iterator and then basically removing
what was not necessary. Which is in general a good way to improve
the performance, except for the copy&paste part, as the code has
already started to diverge (e.g. fc3b904b67).
So instead make the shared code into a template and reuse that from
specific code. This has exactly the same performance as the copy&paste
way.
Change-Id: I168319a1f4273bafc8c0742a114dafbf433968bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133324
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Caolán McNamara