look for
#define FOO "foo"
that can be converted into OUStringLiteral.
This is the first pass of this plugin, only doing those #define which
are local to a single compilation unit.
Change-Id: Ic8610e29ec42c36d03db5014a93c244315d5bbea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124962
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which are reserved in UNOIDL (though unoidl-write does not enforce that for
now, see the TODO in unoidl/source/sourceprovider-scanner.l, and idlc only
warned about it with an explicit -cid option)
Change-Id: I529f385e9c263d2dab9baf3b99f0208457da04c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121346
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
For one, the loop in x86_64::fill_struct was backwards.
And for another, privateSnippedExecutor does not need special handling of FLOAT
and DOUBLE return values (they can simply be moved to %xmm0, as covered by the
general case), but rather for those small structs where floating-point member(s)
in a first eightbyte (targeting %xmm0) are followed by integer member(s) in a
second eightbyte (targeting %rax). Extended testtools to cover two such cases.
Change-Id: I8e775a1d1ce2312610f265bcc8e40b09bdac56df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119576
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
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>
The C++/UNO bridge for macOS on arm64 currently uses the Linux code.
Apple's ABI uses slightly different parameter passing on the stack,
though. See
https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms?language=objc
That has not been taken into account yet in the bridge code. The
bridgetest, when run on macOS on arm64, didn't notice, sadly, but
succeeded. With this change it crashes, as one would expect it to do.
Add one more byte and short parameter to the setValues(), setValues2()
and getValues() calls in the XBridgeTestBase interface. The stack
allocation for those [in] parameters to setValues() differ between the
Linux and Apple ABIs. Add corresponding attributes to the interface,
and members to the SimpleTest struct.
The changes to the source files in the cli subdirectory (C++/CLI,
VB.NET, and C#) are done blindly as they aren't compiled even on
Windows currently. Most likely the changes to them are incomplete and
erroneous.
Change-Id: I6f689a130d89b23cad9918829107d7da49a79c55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105770
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Consequently put each parameter/argument on a separate line for the
get/setValues methods.
Will make it easier to add more parameters of such types and at such
positions that they catch errors in the C++/UNO bridge on more
platforms (specifically, the one for macOS on Apple Silicon).
Change-Id: I68578d0401358317f3baf913ef4d53009c8f5f2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105633
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
which are not portable between Linux and Windows because long
is not portable.
In preparation for converting long -> tools::Long
Change-Id: I8bf1aa1570946ca887a6c83dd5f99c024d437336
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104374
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Clang and gcc have moved this out of experimental and into std::source_location,
but only in their very latest releases.
Change-Id: I9d9d9155788ee4240455ac4628b298dface4ad24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93868
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The main reason for the "home-grown" UpCast introduced with
904b3d1fce "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 39a1edd6fe "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>
Fix IdentationError and mixture of spaces and tabs found by
python -m py_compile <file>.
Change-Id: I1dc99196410d736ca33ead5deadfc61bc6584428
Reviewed-on: https://gerrit.libreoffice.org/83594
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
...following up on 314f15bff0 "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>
looks for variables that can be declared const and static i.e. they can
be stored in the read-only linker segment and shared between different
processes
Change-Id: I8ddc6e5fa0f6b10d80c75d5952df8ddd311cf892
Reviewed-on: https://gerrit.libreoffice.org/61591
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...where "inline" (in its meaning of "this function can be defined in multiple
translation units") thus doesn't make much sense. (As discussed in
compilerplugins/clang/redundantinline.cxx, exempt such "static inline" functions
in include files for now.)
All the rewriting has been done automatically by the plugin, except for one
instance in sw/source/ui/frmdlg/column.cxx that used to involve an #if), plus
some subsequent solenv/clang-format/reformat-formatted-files.
Change-Id: Ib8b996b651aeafc03bbdc8890faa05ed50517224
Reviewed-on: https://gerrit.libreoffice.org/61573
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>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ib420e9216b8313f5ed7634ec375e39ceb741fd45
Reviewed-on: https://gerrit.libreoffice.org/59297
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Gabor Kelemen