Use it instead of classname::getImplementation from UNO3_GETIMPLEMENTATION_*
Change-Id: Ifcc8cfcd6369c576250008c76ce31ba79ea3a596
Reviewed-on: https://gerrit.libreoffice.org/74107
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Replace with UNO3_GETIMPLEMENTATION* macros.
Replace single usage of IMPL_XUNOTUNNEL_MINIMAL with it's body.
Change-Id: I7d4ad76399b999ebb2178ecf57edcf6bd2aa6c3e
Reviewed-on: https://gerrit.libreoffice.org/73424
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
All of those have been broken with recent loplugin:sequentialassign changes (and
have been found with a new plugin to be commited).
The code in SbUnoClass::Find (basic/source/classes/sbunoobj.cxx) looks
suspicious, but has been effectively like that ever since at least
c25ec0608a "initial import", so just marked it
with a TODO comment for now.
Change-Id: I0d691cb55ef317cf2b16b0490169de7ec97375cf
Reviewed-on: https://gerrit.libreoffice.org/70874
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Also use scope where possible. This allows to limit guard scope at
language level; visualises the scope clearly; and helps avoiding
errors like fixed in commit 61e4437c85.
Change-Id: Ifeca96e2df8e8a0897770d9546b2536806275f41
Reviewed-on: https://gerrit.libreoffice.org/70376
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
V572 It is odd that the object which was created using 'new' operator
is immediately cast to another type.
Change-Id: I54976062dc3f62eaaa79f89eff54454f0b24ac2c
Reviewed-on: https://gerrit.libreoffice.org/69989
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If current control (for example TabPageContainer) is missing
resource listener property we should not fail script with
exception. Just behave as with empty ResourceListener.
Change-Id: I260feec775a5d197bebc9414b652dd6f89e35035
Reviewed-on: https://gerrit.libreoffice.org/69740
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
V572 It is odd that the object which was created using 'new' operator
is immediately cast to another type.
Change-Id: I6d1523e71b3e06be1cf41abaabb44e49fe11cd8e
Reviewed-on: https://gerrit.libreoffice.org/69369
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This reverts commit 9865440d21.
This is not ready to land yet, seems like the latest update
of the logic reveals a bunch more places I need to fix before it can land.
verify that parameters use the exact same typedef-names (if any)
in definition and declaration
Change-Id: I55d2817f599b0253904dce2d35a1a93967e15a77
Reviewed-on: https://gerrit.libreoffice.org/68439
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which is supposed to make the dialog resizable, but was silently ignored.
Change-Id: Ifa2d2ea70c769f7785ac044ab2b681802c54bc17
Reviewed-on: https://gerrit.libreoffice.org/68515
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
The userformscontainers is required property to pass checks in
getter/setter, but returning true instead of actual type is
not a best idea. So let's return actually expected dummy empty
container.
Change-Id: I5cc3e5462ed82f6f2f8e5a45d9fc2d9f9ce1c76f
Reviewed-on: https://gerrit.libreoffice.org/67431
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
UnoControlTabPageModel had no USERFOMRCONTAINERS property
and this was causing an exception during any attempt to set
its properties.
Change-Id: Icc432d7a431ecd861ac4f00a96ec75165bec168c
Reviewed-on: https://gerrit.libreoffice.org/66801
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Icebcf1a6ab073dce935a74ce79ee0f302b62e8a8
Reviewed-on: https://gerrit.libreoffice.org/65947
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ie87d27dd2c385a63349e0b322fd067ba03d2d152
Reviewed-on: https://gerrit.libreoffice.org/64479
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I444c43b9d549977039f25bec2b5bf666c3e15e0e
Reviewed-on: https://gerrit.libreoffice.org/62041
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This mostly affects explicitly defaulted functions that had recently been user-
declared to silence new GCC trunk -Wdeprecated-copy. It is not entirely clear
to me what the best approach is overall, see my mail
<http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20181001/245321.html>
"Re: r343285 - [cxx2a] P0641R2: (Some) type mismatches on defaulted functions
only", but lets just explicitly delete those functions for now.
Change-Id: If8c72f612f67a8feb8b03c2fb988c807e704ef03
Reviewed-on: https://gerrit.libreoffice.org/61259
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Arkadiy Illarionov