Age | Commit message (Collapse) | Author |
|
Change-Id: Icd90eeb492002c45ddd8ff562a6da411abead122
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88185
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
jurt.jar and unoil.jar are kept as effectively empty jars, each with a
Class-Path: ridl.jar
in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or
without also loading ridl.jar) will still have access to their content.
Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi)
are not part of the URE, but are now made available by URE's ridl.jar. This
should probably not cause problems in practice.
At least for now, we seal exactly those packages in ridl.jar that were
originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now,
but that would be mildly incompatible, as it would prevent 3rd-party code from
introducing additional UNOIDL entities in the relevant namespaces (even if that
is something we do not want 3rd-party code to do anyway).
However, some JunitTest_jurt_* define classes in those sealed packages. In the
past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt.
Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the
gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes
that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the
UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the
udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests
get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use
gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets
leave that for a follow-up clean up.)
As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/.
Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I69cc1b352221ca053ccd0c5b78e926480a8c9ccd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87884
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie5a381fc5e5b73490ab8b2036ef2a1164e475e8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87557
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@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 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>
|
|
found by my new aggressive unused var plugin. these are unused return
values from function calls
Change-Id: I3359c583f535828f192cb833762dfedc008d82f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87439
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iffb8512c530b33f87076aec9f85b45219c7d07e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87528
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
Change-Id: If95f1ea5a81de62eb4f725e5fcb30ccb8530062a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87372
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ib20fec3a7b6bfe2f94c6f5f2f9fa0be6f7c21e97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87320
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I59a63e81cf317094ad60a88d3cdd20fc426c93b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87235
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
https://gerrit.libreoffice.org/c/core/+/87210 makes unopkg proper
console application, which doesn't need old complexity of sending
UTF-16 strings to console redirected to pipes, so this workaround
is not needed anymore.
This reverts commit 015e9f780bc133788f79868bb7fb0b1d4e81f5f3.
Change-Id: I9ab49df2b9c9cb841e591c07fcea191119dbe382
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87217
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I5ec8c55f9afac8d6f7f697c0e5e387e88db4fde7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86517
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: If130c8a4861998d7eafd2e9525592f3c811ec21c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87069
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic6ed5dcf6343a4ff59a1f69c77c82b03b4ee6198
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib4ea839a6fffa202a98472d47933efb0ff4fff20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86888
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4eae284cf763b260dd9349bf8d31f46612916de1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86654
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9b285a80e0d52f412e2738995d66aa65cf93d16a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86606
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
found using 'git grep', I tried using clang-tidy, but it only
successfully found a tiny fraction of these
Change-Id: I61c7d85105ff7a911722750e759d6641d578da33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
its ok to show a page that's already shown
Change-Id: Iaf014669fcfbb4f91dd114fe8053ac4f91617b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86267
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I983b0106da9e41cd923603aa8bba685f61963abf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86184
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5ee29d9b9c6511aa71d592d6f85a724200645df8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86183
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
I don't really know how the bibliography functionality works and how
it is connected to database stuff. Until now Library_bib for
instance was excluded for iOS because it was seen to be part of the
"DBCONNECTIVITY" feature. Change that now. Also, build the dba and
dbahsql libraries also in the non-DBCONNECTIVITY case. This at least
avoids the crash and avoids new warnings about missing constructors or
factories.
Change-Id: I8a8c62a895fcd43e7fa725a4707ac5ad428a64b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86043
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86045
Tested-by: Jenkins
|
|
so we get more useful log messages when stuff goes wrong
Change-Id: Ia55db7ab1a4d79b0f281673fbbb06c61745fa89e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85829
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iad97bdbcbec4cbbccf3df9b9d682e744b0c1982e
Reviewed-on: https://gerrit.libreoffice.org/85709
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib2314f23efe953398ed0a5e88305842c812e18bb
Reviewed-on: https://gerrit.libreoffice.org/85708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic035497bd07633bd4af02a8fe69ac701d4a45492
Reviewed-on: https://gerrit.libreoffice.org/85537
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
duplicate in same file
Change-Id: I08d713fa48bd603def0d87844bb8d6cbf327ffdc
Reviewed-on: https://gerrit.libreoffice.org/85553
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If65aef1249f54a87d7854c3fa2db4319a24a5a05
Reviewed-on: https://gerrit.libreoffice.org/85326
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I69b0922ebf1aae9d5a22842745b7f0e4f914d2be
Reviewed-on: https://gerrit.libreoffice.org/85495
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I123a5091c5c07de49beba8f4e1d3e4704644ec68
Reviewed-on: https://gerrit.libreoffice.org/85473
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 1e73a1bfab8abe658e2864ae1512737e489dfb0f.
Change-Id: I5f3c62ffafd3e15b62227766e15a944c76d11978
Reviewed-on: https://gerrit.libreoffice.org/84294
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib0965f57cb929a220fc9df381abdca654985c9de
Reviewed-on: https://gerrit.libreoffice.org/85330
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8ad75d1251df4d6f8097aaa68e4ec92331e38ad4
Reviewed-on: https://gerrit.libreoffice.org/85077
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
These expressions depend on evaluation order, and when arguments are
constructed from right to left, std::move(xBuilder) has already reset
xBuilder to an empty value prior to xBuilder dereference calling weld_*.
Change-Id: I89f8ab04aeeab684e8f2edd90310515b2256f9fd
Reviewed-on: https://gerrit.libreoffice.org/84912
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iabdf93b7728ffaa9b2b03067c3d9eac78b4d32b3
Reviewed-on: https://gerrit.libreoffice.org/84780
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ibd41ddd94763a3b79065dca38c74901e84b3fc66
Reviewed-on: https://gerrit.libreoffice.org/84779
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I9f06ce16f6e40b3e0760469217c56cba2ae22f8d
Reviewed-on: https://gerrit.libreoffice.org/84730
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Replaced the odd HyperlinkField Edit whose text can be clicked on to activate
listeners, with an ordinary Edit and a Button beside it which can be clicked
instead to do that. I couldn't find a real world use of this HyperlinkField in
the forms or control properties, nor in casual experimentation in the sidebar
in the basicide dialog editor.
Also replaced the other strange Edit-alike TextView with a real Edit entry and
a dropdown which can be used to support entry of multi-line labels
Change-Id: Iad5265e404f6de14c8e760d617dbad49cd6ddead
Reviewed-on: https://gerrit.libreoffice.org/82213
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...plus loplugin:consttobool and loplugin:fakebool fallout
Change-Id: Ie3d8121815c080b13bea6d9deca1eb138ca56138
Reviewed-on: https://gerrit.libreoffice.org/84515
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
so is of no use
Change-Id: Ibb1187183abff6b8dc26ed5011b43af1a86a7d04
Reviewed-on: https://gerrit.libreoffice.org/84458
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I567c703734fcd9679ae366d69fec4d43b57ad069
Reviewed-on: https://gerrit.libreoffice.org/84479
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins
|
|
Change-Id: I71c1a83f0c85f522c533ae075882211e26f78ef0
Reviewed-on: https://gerrit.libreoffice.org/84478
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
which merely announce that the next declaration is a class
Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc
Reviewed-on: https://gerrit.libreoffice.org/84229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icdf93751b00453eb033fd577413bd6bc3527f87c
Reviewed-on: https://gerrit.libreoffice.org/84286
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib2ad0f0fe17c4db66693ef91e3cdbc8511eb8314
Reviewed-on: https://gerrit.libreoffice.org/84166
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I81fea38cd737a8be74e6ece333ca37cc434a1c33
Reviewed-on: https://gerrit.libreoffice.org/83765
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>
|
|
...plus follow-up loplugin:implicitboolconversion and loplugin:redundantcast
Change-Id: I9fc9c5cb46fbb50da87ff80af64cb0dfda3e5f90
Reviewed-on: https://gerrit.libreoffice.org/83207
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
To mitigate the dangers of silently breaking ADL when moving enums into unnamed
namespaces (see the commit message of 206b5b2661be37efdff3c6aedb6f248c4636be79
"New loplugin:external"), note all functions that are affected. (The plan is to
extend loplugin:external further to also warn about classes and class templates,
and the code to identify affected functions already takes that into account, so
some parts of that code are not actually relevant for enums.)
But it appears that none of the functions that are actually affected by the
changes in this commit relied on being found through ADL, so no adaptions were
necessary for them.
(clang::DeclContext::collectAllContexts is non-const, which recursively means
that External's Visit... functions must take non-const Decl*. Which required
compilerplugins/clang/sharedvisitor/analyzer.cxx to be generalized to support
such Visit... functions with non-const Decl* parameters.)
Change-Id: Ia215291402bf850d43defdab3cff4db5b270d1bd
Reviewed-on: https://gerrit.libreoffice.org/83001
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|