V1037 Two or more case-branches perform the same actions. Check lines: 152, 194
V1037 Two or more case-branches perform the same actions. Check lines: 565, 592
Change-Id: I52ec0921c898ca74473631ba36a76f6444ce07d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175358
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Most of these don't use boost themselves, nor do they need
it transitively since the use of boost::optional was removed
Change-Id: Ic9dee1c4e160b313ec5b91677b02ffdea6c5779d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164440
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
When the typelib_TypeDescription is null, the following code would dereference a
null pointer anyway (but which doesn't necessarily cause an immediate crash on
some platforms like Wasm, so better be explicit). (Also, leave those checks out
of functions like uno_type_sequence_realloc, which would have been preceded by a
call to one of the functions creating a sequence of the given type, and which
would thus already have detected failure to obtain the relevant type
information.)
Change-Id: I36193ea837edeca451fd09a866623cf40d3cdb4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163813
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...which had been added all the way back in 2002 with
6cd0bbd8ce "adding new file to HEAD" to constants
group css.drawing.CaptionEscapeDirection, which has meanwhile been published, so
no chance of cleaning that up.
But cppumaker already has a mechanism to work around problematic UNOIDL
identifiers, but which was only used for "new-style" entities when they got
introduced, mainly to avoid compatibility issues when retroactively changing the
code generated for existing entities.
But for C++ keywords, the generated code was always broken, so no harm in fixing
it, so introduce an additional IdentifierTranslateMode::KeywordsOnly and use
that at least for constants, to address the immediate issue.
(And with that, a hack can be removed from gb_UnoApiEmbindTarget__add_embind.)
Change-Id: I5cf62fd8b3b298dff2ec28452fb97b424a4ba473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162305
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
after my patch to merge the bufferadd loplugin into stringadd
Change-Id: I66f4ce2fd87c1e12eefb14406e0e17212f68ceff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149497
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...and revert e1c6f36d8b "Add a to_string()
function to the code generated for UNO IDL constant groups". (But keep the
constants groups the latter had added to cppu/qa/cppumaker/types.idl, and use
them in the newly added CppunitTest_stoc_dump, for better or worse.)
Change-Id: I56e9eaeb1e45b83a72a25eceef13e719dc6f3a1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149281
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins
If the inpt matches one of the constants exactly, the result is the
name of that constant. If the input matches some combination of
constant values that are single bits, the result is the sequence of
the names of those constants joined with plus signs.
For instance, if the IDL has:
constants Constants {
const byte BIT0 = 1;
const byte BIT1 = 2;
const byte BIT2 = 4;
const byte BIT3 = 8;
}
The result of Constants::to_string(5) is "BIT0+BIT2", and the result
of Constants::to_string(17) is "17".
I am sure there are corner cases that aren't handled as would be
intuitive, especially with types that include unsigned values.
Correspondingly, the semantics of the generated to_string() functions
is not formally defined.
Also add a unit test for the new functionality.
Change-Id: I14aa826d0989ac6dfe97dd5c09119b1601c65643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148995
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...which were used by ildc, which is gone since
a8485d558f "[API CHANGE] Remove deprecated idlc
and regmerge from the SDK", and have always been ignored as legacy by its
unoidl-write replacement.
This change has been carried out (making use of GNU sed extensions) with
> for i in $(git ls-files \*.idl); do sed -i -z -E -e 's/\n\n((#[^\n]*\n)+\n)*(#[^\n]*\n)+\n?/\n\n/g' -e 's/\n(#[^\n]*\n)+/\n/g' "$i"; done && git checkout extensions/source/activex/so_activex.idl odk/examples/OLE/activex/so_activex.idl
which apparently happened to do the work. (The final two files are not UNOIDL
source files.)
Change-Id: Ic9369e05d46e8f7e8a304ab01740b171b92335cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(This was there ever since the beginning in
85c2477a94 "INTEGRATION: CWS bunoexttm", while for
the similar OuterThread it was always absent.)
Change-Id: I3c43f0e35435b6035f6a1f2a1ca9f104bd639689
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135240
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...introducing o3tl::cmp_equal etc. implementing C++23 std::cmp_equal etc., plus
an o3tl::IntCmp wrapper around it for convenient operator syntax
Change-Id: I1d2e0d1aef99c531039fb83de31ed8e6036fde03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135095
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and simplify the remaining code using the (now const) nCacheSize
Change-Id: I4468cf223c158a318ba56ba63f5f60121c94f42d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134879
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Adapt the GCC version check from the workaround introduced
in
commit 2c6cea672a
Date: Wed May 18 10:46:55 2022 +0200
Work around bogus -Werror=attributes with old GCC
...after 9c3c6a6b66 "Replace OFFSET_OF macro with
a function template", as seen at
<https://ci.libreoffice.org//job/lo_tb_master_linux_dbg/38076/>,
> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/uno/check.cxx:263:28: error: ‘maybe_unused’ attribute ignored [-Werror=attributes]
> [[maybe_unused]] Char3 chars;
> ^~~~~
(Not sure which versions of GCC are affected exactly; lets restrict this to
to all versions before 12.1.
My GCC 11.3.0 build on Debian testing failed just the
same way otherwise.
A `git log --grep=maybe_unused` in the GCC git repo suggests
that this is no longer necessary from the following
GCC 12.1 commit [1] on:
commit c0f769fa3114ea852a26d93f0ee3f9595463de0b
Author: Jason Merrill <jason@redhat.com>
Date: Fri Jun 11 16:10:50 2021 -0400
c-family: don't warn for [[maybe_unused]] on data member
The C++17 standard (and C2x) says that [[maybe_unused]] may be applied to a
non-static data member, so we shouldn't warn about it. And I don't see a
reason not to handle a FIELD_DECL the same as any other decl, by setting
TREE_USED on it. It doesn't look like anything yet cares about that flag on
a FIELD_DECL, but setting it shouldn't hurt.
gcc/c-family/ChangeLog:
* c-attribs.c (handle_unused_attribute): Handle FIELD_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/ext/attrib62.C: No longer warn.
* g++.dg/diagnostic/maybe_unused1.C: New test.
gcc/ChangeLog:
* doc/extend.texi (unused variable attribute): Applies to
structure fields as well.
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=c0f769fa3114ea852a26d93f0ee3f9595463de0b
Change-Id: I815e4a24da13e0ae66b1dff2941e636c7ebdfd9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134653
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
...after 9c3c6a6b66 "Replace OFFSET_OF macro with
a function template", as seen at
<https://ci.libreoffice.org//job/lo_tb_master_linux_dbg/38076/>,
> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/cppu/source/uno/check.cxx:263:28: error: ‘maybe_unused’ attribute ignored [-Werror=attributes]
> [[maybe_unused]] Char3 chars;
> ^~~~~
(Not sure which versions of GCC are affected exactly; lets restrict this to
GCC 7 for now.)
Change-Id: I28ec8914b60c98dce769ad40ef4141aec4960aa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134509
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(in preparation of extending loplugin:redundantcast to more reinterpret_cast
scenarios, which would have caused a false positive here). Required a tweak to
loplugin:fakebool (as the relevant reinterpret_cast to silence some occurrences
is no longer seen "inline" now), and the heuristics of loplugin:unused no longer
worked (also because of the now-hidden reinterpret_cast'ing), but adding a
maybe_unused attribute looks better than tweaking that plugin's heuristics even
further.
Change-Id: Iead1a9b31983918cf8f3b0e6c727c0081437c6d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134504
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... and use the same fake exception rethrowing code then the
mobile platforms.
Change-Id: Ic90de1cfd1e0092d6064d041a613d60d9f5f76b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128596
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
That flag is only supported by clang-cl, not by MSVC, and
c7c9f3f57a "use clang-cl's -Zc:dllexportInlines-
for clang-cl builds" apparently naively assumed that it would work to build LO
with clang-cl and that flag without actually trying it out, and
1040228c35 "My clang-cl build does not work with
-Zc:dllexportInlines-" effectively disabled it completely.
The way to avoid unresolved external symbols during linking of URE libraries
(see the 1040228c35 commit message) is apparently
to also build libraries that the URE libraries depend on with the flag, hence
the change from gb_Library_set_is_ure_library to
gb_Library_set_is_ure_library_or_dependency. For now, I only marked those
additional libraries (unoil and xmlreader) that actually caused issues when
linking the URE libraries.
Change-Id: I3a85c73246250981cd86b7ee41f87b41f393a4b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126012
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
This may be important with static empty sequence cppu::g_emptySeq, that is
common for sequences of different types.
The changes in sd/qa/unit/data/xml/*.xml fix places where anys with empty
Sequence<OUString> used to wrongly take 'if(aAny >>= aPropSeq)' branch in
dumpPropertyValueAsElement (drawinglayer/source/dumper/XShapeDumper.cxx).
Change-Id: I5b0544ca94b30437c01dd46f376408f91510bcb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124167
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
