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>
...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>
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>
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>
...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>
This is clang-cl's equivalent of -fvisibility-inlines-hidden,
and it seems to be also sort of the equivalent of MSVC's
-Zc:inline. So it saves build time and disk space.
Clang docs say that this is binary compatible in only one
direction, so our public C++ code shouldn't be using this,
as external C++ code could try to use exported inlines
that are no longer there.
Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Gabor Kelemen