Age | Commit message (Collapse) | Author |
|
Change-Id: Ic3506ee6194ac4e74e572a10db96f100bc9e6ac2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95149
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
(cherry picked from commit f2c6bc3c1ba640f95555151607dfe9da502d506a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95123
|
|
Change-Id: Ie862bb782b4c3e203af88d45c850ce0cab60f2e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94123
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I30d6f8436cc85097a4d8e64db266fc31773e5351
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ica1a10a8f8fff7c3780adcc30b2c8d0e385b1326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93307
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: If8549e62de1007fccf9a5becac356f8d1ffc5090
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92513
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I7f5201e2ea6c74329336e16bf219630e38ff92cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92264
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1caeeb8e0a6f02f1dd37f7399702af1b2a400b28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92242
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To make the code easier to read.
Change-Id: Iebc648150391939fba5d1cd815c72dbcf02ceec6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90378
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie8568f524a1f804e07890ee7828a81f1752fcfd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91793
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6d8b2730cede4453e7afd581cc24ed101ca6c81b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91557
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia7f3441404d8d2e5de501e70da496b6fdc6c9a4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90728
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Update() is effectively "paint immediately". Rather just let the
invalidate do it's thing and have the widget paint on the next paint
loop, along with the rest of the stuff.
This is probably mostly cargo-cult, from the days when our
invalidate/paint timer could take a long time to kick in.
Change-Id: Idff06526e9a2892244cfd8ce6947916032b0d1a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90567
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
This reverts commit d4d37662b090cb237585156a47cd8e1f1cbe2656.
Now that we know that making fields has negative side effects
like disabling assignment operator generation.
Change-Id: Idef4937b89a83d2efbfaf0ab87d059a0143c0164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90364
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
noticed something that wasn't being picked up, wrote some tests,
and found an unhandled case in Plugin::getParentFunctionDecl
Change-Id: I52b4ea273be6614e197392dfc4d6053bbc1704de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90141
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
note: non-standard dnd via parent so the treeview triggers the dnd but doesn't
itself strictly speaking drive the dnd, see copying a range from the navigator
where the calc main edit window shows the outline where the copy of the range
from the calc main window will go
Change-Id: Ideecbe779e3d9bb5b392357a93ec25f625180ba8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89597
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
In addition:
- .uno:BackColor was unused, and internally mapped to the same
id as .uno:DBBackgroundColor which is used and has a label. So
remove the former, and make the latter visible in the
customization dialog instead.
- .uno:DSBEditDoc is mapped to SID_EDITDOC, and handled by the
code, but has no label. On the other hand, the toolbar has an
.uno:EditDoc item, which has no mapping in reportdesign, but
happens to be mapped to SID_EDITDOC elsewhere. So assume this
was a mistake, and .uno:DSBEditDoc should be used instead of
.uno:EditDoc.
Change-Id: I9da2ed36167571627b32a4055b734847c3ea1e64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88342
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
after commit c34edadf5bd3d1d9f3c9c056af28b8964d8f1ca0
("rework SvxUndoRedoControl to be a PopupWindowController")
accidentally enabled them there, instead of the simple
buttons those modules used to have. Just implement the
necessary stuff, instead of hiding the dropdown again.
Change-Id: Ic93114f7f3cec8e96f3389ceb0d52552cde02a83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88333
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
I checked return values.
Long variables didn't affect the calculation.
Change-Id: Ia3713eedf275de71b1096d1fe7e22da012a7f94e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87493
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.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>
|
|
...in what might be attempts to avoid warnings about signed vs. unsigned
comparisons.
Change-Id: I0e689d8b730170f35107cbdf46c3d8cd9a593367
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87456
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...plus loplugin:unnecessaryparen fallout in sw/source/uibase/docvw/edtwin.cxx.
Each of the files contained at least one #define that would have caused warnings
with upcoming loplugin:unsignedcompare. For consistency, I changed all #defines
in those files (using a variable of a specific type if the original #define used
a cast to that type, otherwise using 'auto').
Change-Id: I66f71b2d83394c9dc6952ae19df774cdd4d0b76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87374
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3f7cb6010142c8bdce96bf541a7efb650233942e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87325
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I993ed47c6b4a43f6293bdf5c2803599d75337bb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86918
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@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>
|
|
Change-Id: I768c5ae5a4c2c0b2f50a8eb541a5c7397c355345
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86206
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I5f4c4b43067b99cd57f8ea941002481ef5977e09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86144
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
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: I6d32942960a5e997f16eb1301c45495661cd4cea
Reviewed-on: https://gerrit.libreoffice.org/85514
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
looks like these were left behind when the associated *Item classes were
moved from svx to editeng
Change-Id: I09bf48396e18a9f1a6dddb65618affc782777c25
Reviewed-on: https://gerrit.libreoffice.org/85341
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia8192e03feda9e8ae70e29d8dc98d995f015f9ce
Reviewed-on: https://gerrit.libreoffice.org/85135
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>
|
|
Change-Id: Ife9ab434888bfbcdc6ff4446b92f2aa83e6cb449
Reviewed-on: https://gerrit.libreoffice.org/84913
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Section Setup, Page Setup, and Character Settings dialogs
Change-Id: I31275ba45f5659fa7fe3988ae0f8ed3978196425
Reviewed-on: https://gerrit.libreoffice.org/64673
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I8ac3957579c76a89b9692bdb50cbe7a56e1693e3
Reviewed-on: https://gerrit.libreoffice.org/84444
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>
|
|
Change-Id: Ibeac785fb1b1f30187fa5aa5350292bf96b307a0
Reviewed-on: https://gerrit.libreoffice.org/84489
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ib7ea1dc2e2919430f4b3c9feb98344dbadf4a109
Reviewed-on: https://gerrit.libreoffice.org/84368
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0b1ae0d50fa8b4c01c36ece0fdd1c2b316ccd27b
Reviewed-on: https://gerrit.libreoffice.org/84357
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I49f9cfb4df670c68d21082a81e1a0aad225cc408
Reviewed-on: https://gerrit.libreoffice.org/84279
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic88ed0d36f1aae9f32a0097354042526fc18d649
Reviewed-on: https://gerrit.libreoffice.org/84244
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1e0ca144943fd37769c7b6cfc7e77c4f001b31a0
Reviewed-on: https://gerrit.libreoffice.org/84233
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
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: 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>
|
|
...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: I2eab990c15f845b44a3b598571aca361dadf9ff3
Reviewed-on: https://gerrit.libreoffice.org/81946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7dd5fc3d53df63fd2ee2caa71586f0f5e13f187e
Reviewed-on: https://gerrit.libreoffice.org/81078
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I95e63105654952d12c1dfd62f51593de114be569
Reviewed-on: https://gerrit.libreoffice.org/81077
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|