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
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 platform specific drivers/ado and drivers/macab dirs
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I24b741cded8995e29ac3d518aeaa0d60b3c55b56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86317
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
regression from
commit d425658bd9
Date: Wed Dec 19 16:10:51 2018 +0200
pass OSQLParseNode around by unique_ptr
We have a OSQLNode being deleted at
connectivity::OSQLParseNodesContainer::clearAndDelete() at
connectivity/source/parse/sqlnode.cxx:2781
connectivity::OSQLParser::parseTree(rtl::OUString&, rtl::OUString
const&, bool)
(this=0x38eba90, rErrorMessage="syntax error, unexpected UNION,
expecting $end", rStatement="CREATE VIEW \"View1\" AS SELECT
\"Tab1\".\"Name\" AS \"Name1\", \"Tab1\".\"Geburtsdatum\" AS
\"Geburtsdatum1\", 1 AS \"MonatZahl1\",
COALESCE(\"Tab1\".\"MonatZaehler\",999) AS \"MonatZaehler1\", 'Januar'
AS \"Monat1\", \"Tab2"..., bInternational=false)
at workdir/YaccTarget/connectivity/source/parse/sqlbison.cxx:10914
namespace)::parseStatement_throwError(connectivity::OSQLParser&,
rtl::OUString const&,
com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&)
(_rParser=..., _rStatement="CREATE VIEW \"View1\" AS SELECT
\"Tab1\".\"Name\" AS \"Name1\", \"Tab1\".\"Geburtsdatum\" AS
\"Geburtsdatum1\", 1 AS \"MonatZahl1\",
COALESCE(\"Tab1\".\"MonatZaehler\",999) AS \"MonatZaehler1\", 'Januar'
AS \"Monat1\", \"Tab2"..., _rxContext=uno::Reference to
(dbaccess::OSingleSelectQueryComposer *) 0x38eb8d0)
at dbaccess/source/core/api/SingleSelectQueryComposer.cxx:106
and then again at
std::unique_ptr<connectivity::OSQLParseNode,
std::default_delete<connectivity::OSQLParseNode>
>::operator=(decltype(nullptr))
(this=0x38eba90) at connectivity/source/parse/sqlnode.cxx:1500
Change-Id: I292627a06369208e0010743063c7eb5a38921a19
Reviewed-on: https://gerrit.libreoffice.org/77106
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Caolán McNamara