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>
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...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>
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>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I444cb71bc3d045072a4b1f9eed279ed7e425a0d4
Reviewed-on: https://gerrit.libreoffice.org/69481
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
largely based on the relevant portion of the unusedfields loplugin, but
adapted for local vars
Change-Id: Ic522a941573940e8f75c88f90ba5f37508ca49b1
Reviewed-on: https://gerrit.libreoffice.org/66835
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: Ie87d27dd2c385a63349e0b322fd067ba03d2d152
Reviewed-on: https://gerrit.libreoffice.org/64479
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.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>
...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>
just the straight-forward MessageDialog cases first
a) remove border_width from message dialog .ui so as to take
the default border width
b) retain 12 as default message dialog border for vcl widget case
c) remove layour_style from message dialog button boxes so as to
take the default mode (a no-op for vcl widget case)
d) use gtk response ids (vcl builder will converts to vcl ones)
Change-Id: I7de281093a1b64f92f71ca11e7cbba42bb658154
Reviewed-on: https://gerrit.libreoffice.org/50143
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
e.g. helpid[s].hrc -> helpids.h
and insert include guards where missing
move "ordinary" defines into .hxx files
remove .hrc entries that are used as arguments to dialog factory
when a dedicated method can be added instead
Change-Id: I792fb8eb0adfaa63cf354e6e57401fc943e9196e
* 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
Caolán McNamara