And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
the only change should be to the two trailing cases in
OSQLParseNode::substituteParameterNames which do seem to leak. The
closest I got to triggering the actual code is toggling into sqlview
mode of a query but couldn't quite construct a sql statement to trigger
it.
Change-Id: I320dc4df3b18a18b236c91ee30329c10001c9a08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140081
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...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>
...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>
where we can convert that to
o3tl::toInt32(o3tl::getToken(
and avoid the heap allocation of a temporary string
Change-Id: Ib11c19c6e6cdc0de3e551affd3578d181e292de4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132810
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
this reverts
commit 1142dc2398
Date: Sun Feb 27 14:14:18 2022 +0100
cid#1500397: Resource leak
with an alternative that hopefully silences coverity and helps show
better what is going on
Change-Id: Ifb117d65789e80e66419911dbb6b327bdf7ed948
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130707
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The hack worked by accident as long as the internal index
constants didn't change. Which was the case with
commit f7d0c6b42a
CommitDate: Thu Sep 23 20:28:42 2021 +0200
Sort ZF_STANDARD_NEWEXTENDED_DATE_... into ZF_STANDARD_DATE category
convertDateString()
Standard + 36 == old ZF_STANDARD_DATE + 6 => DATE_SYS_DDMMYYYY
unchanged
convertDateTimeString()
Standard + 51 == old ZF_STANDARD_DATETIME + 1 => DATETIME_SYS_DDMMYYYY_HHMMSS
became wrong nothing (no format assigned, empty DATE slot)
convertTimeString()
Standard + 41 == old ZF_STANDARD_TIME + 1 => TIME_HHMMSS
became wrong ZF_STANDARD_DATE_SYS_DMMMMYYYY (DATE_SYS_DMMMMYYYY)
So time 08:00 double 0.33333... was converted to string
"30 December 1899" which then numeric was 0.
Change-Id: I642e0a977d4e167f78537d20624e86721e518c54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128507
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
instead of blindly assuming a SELECT is not a UNION, leading to an
out-of-bounds array access when it is.
Change-Id: I8f904ae65acba8d8ee23b95299058207af68c0ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113189
Reviewed-by: Lionel Mamane <lionel@mamane.lu>
Tested-by: Jenkins
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...where the get member function is defined on a std::__shared_ptr base class,
so loplugin:simplifypointertobool used to miss those until now. (While e.g.
using libc++ on macOS found those cases.)
366d08f2f6 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9 "Fix
detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had
introduced that indivisible two-step algorithm on purpose.
The amount of additional hits (on Linux) apparently asked for turning
loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed
that the naive adivce to just "drop the get()" is not sufficient in places that
are not contextually converted to bool, as those places need to be wrapped in a
bool(...) functional cast now. If the expression was already wrapped in
parentheses, those could be reused as part of the functional cast, but
implementing that showed that such cases are not yet found at all by the
existing loplugin:simplifypointertobool. Lets leave that TODO for another
commit.
Besides the changes to compilerplugins/ itself, this change has been generated
fully automatically with the rewriting plugin on Linux.
Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
otherwise when I add source/line to the uno::Exception in an
upcoming change, the message becomes non-empty, and hasErrors()
return true.
I note that we throw SQLException in lots of places without a
message, so it is possible that this change will cause us to notice
errors we previously missed.
Change-Id: Idf7c5b5143e20c992d8d7550043aa2ed875c78b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94108
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
bison rule
window_specification:
'(' window_specification_details ')'
{
$$ = SQL_NEW_RULE;
$$->append(newNode("(", SQLNodeType::Punctuation));
$$->append($2);
$$->append(newNode(")", SQLNodeType::Punctuation));
}
;
makes it look like rule "window_specification_details" is a single
node, but in reality it is a sequence of four nodes:
window_specification_details:
opt_existing_window_name
opt_window_partition_clause
opt_order_by_clause
opt_window_frame_clause
;
The result is that only the "opt_existing_window_name" clause was
being put in the parse tree, and the other three were simply
discarded.
Since that will forever be a trap, and this is the only place
where window_specification_details is used, we inline it into
window_specification and remove it.
Change-Id: I568904355174d2bc36155bde1d4dd09f57759cd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92894
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Tested-by: Jenkins
Mike Kaganski