Age | Commit message (Collapse) | Author |
|
...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.)
366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "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
|
|
createTable looked into the requested operation, and depending on
that, either created the table or fetched the existing one. For a
function named createTable, that made for confusing reading.
Split that into:
* createTable that creates the table
* getTable that fetches the existing table
* returnTable that automagically creates or fetches an existing
table, depending on the requested operation.
Change-Id: I91be67c24026c850530dcaef5ec95ab508e81434
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93882
Tested-by: Jenkins
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I6bf360b331589692141f6fca52eee5b8e11ef7bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92827
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ifcfd3637fbce6dc3a07a1859f102a6ac85149190
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92237
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
"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 0288c8ffecff4956a52b9147d441979941e8b87f "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>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "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>
|
|
Change-Id: I47328f76342ac023628d9042bdfa8213a1c93d0c
Reviewed-on: https://gerrit.libreoffice.org/79469
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Now that there's no need to support weld/unwelded mixes of
pages in dialog any more.
inherit from a BuilderPage which contains a Builder and
Toplevel container
BuilderPage Activate and Deactivate replace TabPage ActivatePage and
DeactivatePage, allowing disambiguation wrt SfxTabPage ActivatePage and
DeactivatePage.
Change-Id: I5706e50fd92f712a25328ee9791e054bb9ad9812
Reviewed-on: https://gerrit.libreoffice.org/79317
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I36217924d6082e65d570e218da317916b67f45eb
Reviewed-on: https://gerrit.libreoffice.org/79139
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
cid#1453560 silence Unchecked return value
cid#1453562 silence Unchecked return value
Change-Id: I6b7dc42d6f2ebd8abb47fb71805c66c7f45d7748
Reviewed-on: https://gerrit.libreoffice.org/78838
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I52547defb0e7ba328ec20d41a955e545556ffd16
note: get the toplevel parent by getting it from the XInteractionHandler
Reviewed-on: https://gerrit.libreoffice.org/78751
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
In case of a MySQL direct connection the current schema in use cannot be
queried with the getUserName() method of the DatabaseMetadata interface,
because the user name and the schema name can (and usually do) differ.
Instead, we can always query for the current schema with the DATABASE()
SQL function.
Change-Id: Ibb026519e1a63e29c5a7c9b04ab64901faec0f85
Reviewed-on: https://gerrit.libreoffice.org/78297
Tested-by: Jenkins
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
|
|
Change-Id: If44176f85f460afca92cfa77b3cc1f7107a41690
Reviewed-on: https://gerrit.libreoffice.org/75938
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I78c5fa16e035cebe71869bfea57ef2741b5b7f58
Reviewed-on: https://gerrit.libreoffice.org/75829
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Similar to clang-tidy readability-container-size-empty
Change-Id: I81c0ff78d2ecc7d984e3ed5e5ce60efe327fc162
Reviewed-on: https://gerrit.libreoffice.org/71799
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
By creating deleted methods for the wrong calls.
Avoids the compiler needing to construct a temporary
Change-Id: I3b8c648d6bb22d22827bf74f21ea5a2a17fc0f6a
Reviewed-on: https://gerrit.libreoffice.org/72103
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I988a205025cd62d479adc2fbc9c2c86f05414fb5
Reviewed-on: https://gerrit.libreoffice.org/72166
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I3f3108daf208fa8c6be90b28da5503846c27732e
Reviewed-on: https://gerrit.libreoffice.org/70698
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I47c469c0fcdff41d83729be9489c946e81ef3686
Reviewed-on: https://gerrit.libreoffice.org/68020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after 7ffdd830d5fb52f2ca25aa80277d22ea6d89970b
"HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true now"
Change-Id: I54e5ff4e036a6bb3e5774d1c0524158aae18e937
Reviewed-on: https://gerrit.libreoffice.org/64800
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I474b5762e6a07982fddc0315a67181399ea4c30e
Reviewed-on: https://gerrit.libreoffice.org/64156
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic0ca695a1d9d05418213475a68e233953136cc8e
Reviewed-on: https://gerrit.libreoffice.org/63468
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1df70b7dff5ebb6048f7fc618789faa15ca5d422
Reviewed-on: https://gerrit.libreoffice.org/61967
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icc820a47ac891c358883f9c01224f676c58fdd11
Reviewed-on: https://gerrit.libreoffice.org/59744
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
look for places where we are appending the temporary result of adding
strings together, to an OUStringBuffer, where we could rather call
append repeatedly and avoid the temporary creation
Change-Id: I481435124291ac7fb54b91a78344a9fe5b379a82
Reviewed-on: https://gerrit.libreoffice.org/59708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@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 6ff2d84ade299cb3d14d4110e4cf1a4b8070c030 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>
|
|
Change-Id: I32b63d2435d36b869823ea022ebd7f8347a46ea0
Reviewed-on: https://gerrit.libreoffice.org/58211
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and fix the fallout
Change-Id: I5d0c2040f57a3ac354a7e277592da31d09a5f359
Reviewed-on: https://gerrit.libreoffice.org/52894
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
|
|
and update sallogareas plugin to enforce this
Change-Id: Id0782c8a1f619372e10d931aec3c6a4743a4c86a
Reviewed-on: https://gerrit.libreoffice.org/52249
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and fix fallout
Change-Id: Id06bf31f2075111e426ba40c84c885ae70697bee
Reviewed-on: https://gerrit.libreoffice.org/52206
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
|
|
Change-Id: Idbdb07bc342a91695d15ea1a87d1863798ca34b0
Reviewed-on: https://gerrit.libreoffice.org/51676
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic7872adf8a7e8e4a8e1503dd21e22ec69509efaf
Reviewed-on: https://gerrit.libreoffice.org/51652
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
mainly by using for-range loops but also by simplifying some simple algo
Change-Id: If5ce6d901761db2b872a99e6de0eb6d2f098df99
Reviewed-on: https://gerrit.libreoffice.org/51044
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
When we chose to create a primary key, be sure the other existing
columns won't be in primary key
Change-Id: I523f1b3a4b56c92d48b65cb3d83793b5459c630c
Reviewed-on: https://gerrit.libreoffice.org/47732
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
|
|
mostly so I can track down more accurately what values are being stored
in this vector<pair<>>
Change-Id: I3755a098a577facef1c1af62c5583f0e2f7ca90b
Reviewed-on: https://gerrit.libreoffice.org/46500
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia13d0931bbdf642fe04119ea1112788fb143eba8
Reviewed-on: https://gerrit.libreoffice.org/44110
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Insert constructor everywhere, except a couple places that apparently
want to compare GetMapUnit().
Change-Id: I1910deb60562e5e949203435e827057f70a3f988
|
|
Change-Id: I15aee966012612033ab7e2ee03ac1a553802f540
|
|
Change-Id: I79ac90faf24b4c741545e411dbaea7826c2df531
Reviewed-on: https://gerrit.libreoffice.org/42150
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ief8bd59c903625ba65b75114b7b52c3b7ecbd331
Reviewed-on: https://gerrit.libreoffice.org/41019
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4994c4f0ae614c8f98466f440412f28380ddd6a6
Reviewed-on: https://gerrit.libreoffice.org/40589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Mainly about "core_resource.hxx" and "strings.hrc".
It passed "make check" on Linux.
Change-Id: I994420d5e33d02b64929f8a51c548a7322d88a79
Reviewed-on: https://gerrit.libreoffice.org/40311
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
|
|
Change-Id: Ib7b4f2b2403ce766a7db2f6ffc118468e7677776
Reviewed-on: https://gerrit.libreoffice.org/39889
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5456aad61fb0dfe6830eae62b91d1a6399d6343f
Reviewed-on: https://gerrit.libreoffice.org/39128
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3247894fe022dce7f0aa351bd85fefcd7c545dd4
Reviewed-on: https://gerrit.libreoffice.org/34377
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I6087a3eff46926646ac1637615a0af30b38956a4
Reviewed-on: https://gerrit.libreoffice.org/30712
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I left a prefix on the names "Map" so that I would not have to re-arrange
each name too much, since I can't start identifiers with digits like "100thMM"
And remove RSC_EXTRAMAPUNIT, which doesn't seem to be doing anything anymore.
Change-Id: I5187824aa87e30caf5357b51b5384b5ab919d224
Reviewed-on: https://gerrit.libreoffice.org/29096
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which was introduced with 3ead3ad52f9bb2f9d1d6cf8dfc73a0a25e6778ed "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c390154619c385414bdbe6f6e461173
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
|
|
Change-Id: I4258bcc97273d8bb7a8c4879fac02a427f76e18c
Reviewed-on: https://gerrit.libreoffice.org/27317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|