After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
When representing a signed number, the rule may consist of two subnodes:
a punctuation bearing "+" or "-", and then the following digits (see
'factor:' in connectivity/source/parse/sqlbison.y). After punctuation
was added to the string buffer, the following number is passed to
parseLeaf, where it checks if the buffer is not empty, and then adds
a space between the preceding sign and the digits.
This change handles the 'factor' rule explicitly.
Change-Id: I0c929418ad88c5bf653a4e820f45b7d627b07da7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180917
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
and
cid#1633780 Initialization or destruction ordering is unspecified
cid#1633778 Initialization or destruction ordering is unspecified
cid#1633777 Initialization or destruction ordering is unspecified
cid#1633776 Initialization or destruction ordering is unspecified
Change-Id: I8ae7cbede6df2ad747fe57d0ac2800e1b6a31038
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175576
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
since my adaption of i18npool to use OUStringLiteral, this
data structure might get torn down after the i18npool data is
has pointers to.
Change-Id: If83d232d5bfb003ed4dbfb70d47f707a73d2bcc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153121
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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 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>
...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>
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>
Gabor Kelemen