What has been done in:
https://gerrit.libreoffice.org/c/core/+/187567
only solves part of the problem.
Since cancelRowUpdate() is now indeed called when the ResultSet is no longer on the insert row, but it is still called even though the cursor is not positioned, in fact, at this point the cursor must be beforeFirstRow() and therefore cancelRowUpdate() should not be called until the cursor is positioned on a valid row.
These three instructions (ie: moveToInsertRow(), moveToCurrentRow() and cancelRowUpdate()) are apparently only there to ensure that the resultSet is modifiable, so I consider that if we only perform moveToInsertRow() and moveToCurrentRow() this is sufficient to ensure that the ResultSet is modifiable.
Moreover, this first correction introduces a nice regression because now, as cancelRowUpdate() is no longer called while the ResultSet is on its insert row, it becomes difficult to manage such a case.
Change-Id: I5924376d1b483451a439db97580b81fa8e4546c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190322
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
It is not possible to use the css.sdbcx.XRowLocate interface in
ResultSets because Base, in order to ensure that this ResultSet
is editable, performs cancelRowUpdates() when the cursor is on
the insertion row.
Change-Id: I4624623754c40dbef1f83b4d6498db17f996c65e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187567
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
where it was obsoleted by commits 2484de6728
(Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and
fb3c04bd19 (Drop non-const Sequence::operator[]
in internal code 2021-11-05).
Change-Id: I4f8dc4f430dc49fa29012b8f064094daceb5e1b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166818
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so use o3tl::make_unsigned when comparing it against an expression of
unsigned integer type, instead of casting that expression to a signed type
Change-Id: Ic47c6d96919b2aba2d16ce6d1a2a8e4c5761a480
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135219
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where a signed and an unsigned value are compared, and the signed value has
just been proven to be non-negative here
Change-Id: I20600d61a5d59d739bc1bee838c0038e4611aec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134875
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
in favour of the existing get*() methods.
The get*() methods 0 or false or empty in the case of "null", which
is exactly the same behaviour as the conversion methods.
These implicit conversion methods cause lookup problems when combined
with some upcoming OUString changes.
And the code looks cleaner this way too, and has less magic when calling
methods.
Change-Id: Ieb4756bf693e83b996a32667fc1b955f89193496
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125690
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
by making it extend std::vector - it wants to be a ref-counted vector,
so let it be, and we can simplify the usage sites
Change-Id: I93ff6ee1522da965e16223dca171401d36fd67b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90664
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Except for source/ui/
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: If3e2a4cea3c44bd26f1c44309c52eae522904ae3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89299
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffec "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
these methods do nothing except forward to their similar named variants,
so just remove them
Change-Id: I28d31bbe2c1e39fe5a9c2d7eaa9e14006213ab27
Reviewed-on: https://gerrit.libreoffice.org/81247
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for places we are doing code like:
Reference<XProperty>(model, css::uno::UNO_QUERY)->getAsProperty()
which might result in a SIGSEGV is the query fails
Change-Id: I5cbdbc9e64bd0bed588297c512bf60cbacb9442e
Reviewed-on: https://gerrit.libreoffice.org/69044
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I04c5ba277d5b3398c07de6ae66713d977636088d
Reviewed-on: https://gerrit.libreoffice.org/61347
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
This is a continuation of commit 6ff2d84ade to be able to remove those unneeded includes.
This commit adds missing headers to every file found by:
grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
to directories from dbaccess to extensions
Change-Id: I4d15aa35e11664ef78c836ffc2937c7e0bb6ea59
Reviewed-on: https://gerrit.libreoffice.org/58165
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Found by searching for the header names and the localization function:
git grep -l -e \<core_resource.hxx\> -e \<strings.hrc\> dbaccess | xargs grep -c -e "loadString" -e "DBA_RES" | grep :0$ | grep -v /pch
Since certain files use the strings with other functions as well
the above command still gives some false positives.
Change-Id: Ib41c5d8d18f3a00729fcf2c4cd8203a2047ef0df
Reviewed-on: https://gerrit.libreoffice.org/52480
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I96df8923f7791288bbd350d75582a9220006ece6
Andrea Gelmini