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>
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>
(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>
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>
... 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>
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>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
no need to delay-init something we always need, and laying
out a std::unordered_map is something we can normally do at
link time anyway.
Change-Id: Ide791d20394580bca615aa3ad564c154037e0816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119137
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Caolán McNamara