Can easily happen at least on WSL.
Also avoid warnings about the deprecated readdir_r(). In current
POSIX, readdir() is required to be thread-safe. (It might well have
been for a long time in those POSIXish platforms we care for, I don't
know.)
Change-Id: I2b89b7aa170f661365580979d151c1b0557955fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197053
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
fast_float implements C++17 from_chars for floating-point types, which
is still unavailable even in the latest versions of compilers e.g. for
macOS. It is maintained, unlike dtoa; it is said to be adopted as the
from_chars implementation for gcc. It is header-only, which simplifies
many things.
Change-Id: I6b597d4d35a076930e6e35f4f8cff3ca84f48ba1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191248
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
and
cid#1555637 Variable copied when it could be moved
cid#1555640 Variable copied when it could be moved
cid#1555863 Variable copied when it could be moved
cid#1556471 Variable copied when it could be moved
cid#1556634 Variable copied when it could be moved
cid#1556731 Variable copied when it could be moved
cid#1556751 Variable copied when it could be moved
cid#1556807 Variable copied when it could be moved
cid#1557366 Variable copied when it could be moved
cid#1558026 Variable copied when it could be moved
Change-Id: I187cb364877d35acd843d8391e5b376437ec96f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188935
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
and
cid#1660246 Variable copied when it could be moved
cid#1660243 Variable copied when it could be moved
cid#1660240 Variable copied when it could be moved
cid#1660237 Variable copied when it could be moved
cid#1660235 Variable copied when it could be moved
cid#1660234 Variable copied when it could be moved
cid#1660230 Variable copied when it could be moved
cid#1660228 Variable copied when it could be moved
cid#1660225 Variable copied when it could be moved
cid#1660223 Variable copied when it could be moved
Change-Id: I3cd87174e8e88a9c55101a73399117c3f2b80644
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188926
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Trying to do
$ instdir/sdk/bin/unoidl-read udkapi
(i.e., parsing the udkapi/com/sun/star/**.idl tree and printing it out): first
failed with
> Bad input <file:///.../udkapi/com/sun/star/beans/theIntrospection.idl>: source file defines more than one entity
because of its
> published interface XIntrospection;
forward declaration, so ignore such interface forward declarations; then failed
with
> Bad input <file:///.../udkapi/com/sun/star/modules.idl>: source file defines no entity
because "this file contains documentation of the modules", so ignore such
effectively empty files; then failed with
> Bad input <file:///.../udkapi/type_reference/udkapi.idl>: source file defines more than one entity
so instead do
$ mkdir TMP
$ cp -r udkapi/com TMP/
$ instdir/sdk/bin/unoidl-read TMP
$ rm -r TMP
which succeeded.
Change-Id: I465052539b474733e7945b312c996af27a034335
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164094
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...that had caused unoidl-write to generate garbage values when writing
constants of type double to binary type libraries. (But which had apparently
gone largely unnoticed until now, as the only actual use so far of such a
constant of type double that I could find is
> const double aConstDouble = 3.14e-10;
in the unused stoc/test/testcorefl.idl test file.)
Change-Id: I9a6fdb7a4aaff1008b8264cbbc64a84e60bd3813
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164096
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
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>
...now that idlc is gone since "[API CHANGE] Remove deprecated idlc and regmerge
from the SDK". (idlc implemented some dubious conversions from floating-point
to integer types, which unoidl-write does not implement, so the original version
of idlc/test/parser/conversion.tests was not usable in
CustomTarget_unoidl/unoidl-write_test.)
Change-Id: I3b69920dda24c54c9313cd5c2cd0c0fdd9951ca7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123614
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Client code must replace uses of idlc and regmerge with uses of unoidl-write,
see the changes to odk/examples/ and ure/source/uretext/ in
40f2aee658 "Provide unoidl-write also for the
SDK" for examples.
* The new types.rdb format is not compatible with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
* For compatibility with old extensions, reading the legacy types.rdb format is
still supported.
* The SDK no longer ships an idl/ sub-directory containing the udkap and offapi
.idl files (as, unlike idlc, unoidl-write does not need them).
odk/config/cfgWin.js had to be adapted to look (somewhat arbitrarily) for an
examples/ sub-directory instead of idl/ when checking for "an sdk folder".
gb_UnoApi_package_idlfiles became unused and has been removed.
* The idlc and regmerge executables have been removed. Module idlc has been
removed except for idlc/test/parser/, which is also used by
CustomTarget_unoidl/unoidl-write_test, and which may eventually be moved into
module unoidl. Module external/ucpp and the corresponding configure options
have also been removed.
Change-Id: I42a0231699b863b5ebe2bee63bc32c8f79278cc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for local variables that can be std::move'd to parameters
off by default, since it doesn't do proper data flow analysis
Change-Id: I3403a0fcffd165bdea6a772528bc53995c5fdb40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Fixes the ODK cross-build used for Windows Arm64.
Regression from commit 40f2aee658
("Provide unoidl-write also for the SDK").
Change-Id: I54d2732358ed1d48911e206ed02bfca2d3a78782
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132718
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...after the new types.rdb format that unoidl-write generates has been used
internally since LibreOffice 4.1 in 2013; following up on
6db34b6b33 "Directly build UNOIDL .rdb files from
.idl files" and its "The legacy tools idlc, regcompare, regmerge, and regview
are still contained in the URE or SDK for now."
The tools idlc and regmerge are deprecated but still shipped in the SDK for now.
The plan is to drop them completely for LO 7.5.
odk/examples/ and ure/source/uretest/ are adapted to use unoidl-write instead of
idlc and regmerge:
* unoidl-write does not use a C preprocessor and the # directives in .idl files,
it supports reading a single .idl file (containing an arbitrary number of
declarations) or a directory tree where each directory corresponds to a UNOIDL
module of the same name and each .idl file contains the declaration of the
(non-module) UNOIDL entity of the same name. For some of the odk/examples/,
that required moving individual .idl files into sub-directories named after
the respective modules. In odk/settings/std.mk, definitinos of IDL and
REGMERGE have been replaced with a new UNOIDLWRITE.
* unoidl-write always enforces reserved UNOIDL identifier restrictions (see
04af4e4f55 "[API CHANGE] Fix all bad UNOIDL
identifiers across offapi" and 6201792406
"Enforce the UNOIDL identifier scheme") (which idlc only enforced optionally
with -cid -we). That required renaming "my_module" in
odk/examples/DevelopersGuide/Components/CppComponent/.
* The new types.rdb format is not compatibly with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
Change-Id: I1a248fd96e86ecbf407f829bc100d44bfe7f4e7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130533
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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
532b47a650 "[ABI CHANGE] In SDK, replace
regcompare with unoidl-check" had left "registry/CustomTarget_regcompare_test.mk
around to verify that unoidl-check behaves the same as did regcompare on those
old-format .urd/.rdb files." Behavior of unoidl-check on those old-format .rdb
files will become less relevant with the planned move from the old-format
idlc/regmerge toolchain to the new-format unoidl-write toolchain also for the
SDK. But there appear to be no unit tests for unoidl-check, so repurpose (and
move around) the existing test (switching it from using idlc/regmerge to using
unoidl-write).
Change-Id: I4c33e9c16aaf0f99e35d9257a40f3bc2ae2725ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121783
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which reserves identifiers containing underscores and starting with a
lowercase letter for the implementation. That TODO can finally be resolved now
after 04af4e4f55 "[API CHANGE] Fix all bad UNOIDL
identifiers across offapi".
Change-Id: Id63ba96aa77f8666fbdfa90f7b260af42e6856bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122362
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>
Devansh Varshney