Age | Commit message (Collapse) | Author |
|
Change-Id: I37cdd52d965112598249b929fa49c759a88606c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131002
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7ad212dfff8b34d05e3b45107a1ef033a4efc454
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129651
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I4f5258ca5b37e9b1b4237c5d29e4a9e5362fa855
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129116
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
For example, in de3898aecb11307789644a1814e9cbb1ee4cc29b "Add missing test
dependency" it would have output
> warn:svx:680849:680849:svx/source/unodraw/unoshape.cxx:1779: DBG_UNHANDLED_EXCEPTION in setPropertyValues exception: com.sun.star.beans.UnknownPropertyException message: "URL at svx/source/unodraw/unoshape.cxx:1600"
rather than
> warn:svx:680849:680849:svx/source/unodraw/unoshape.cxx:1779: DBG_UNHANDLED_EXCEPTION in setPropertyValues exception: com.sun.star.beans.UnknownPropertyException message: URL svx/source/unodraw/unoshape.cxx:1600
making it slightly clearer that what follows "URL" is not the value of that URL
but rather the source location where the exception was thrown.
Change-Id: Ia3abd232fce3d95a8b66ff4ed5bab2fcc248df2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128788
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I208767eaa60d913fe2882403f1f9351eb08256f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127224
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I058cf9ff4f7ce3f49f1dc3abb6b02268d208b225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124350
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7a2925116928e16381c95b59a45200fa5f05935e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123575
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Idaac78579d7845a1908bc3c02ff917432ca6a7d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117513
Tested-by: Jenkins
Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
|
|
...instead of going via raw `char const *`. (This changes the code's semantics
if buffer can contain embedded NULs, but it is unlikely that the original code
using getStr() was even meant to stop comparison at the first embedded NUL.)
Change-Id: I00a0a08b3ba8c318e3b898548ef185efa3f93ef2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115713
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The legacy `throw()` dynamic exception specification is gone for good from C++20
(even if compilers typically still accept it, but e.g. Clang has
-Wdeprecated-dynamic-exception-spec to at least warn about it).
Introduce SAL_NOEXCEPT for use in URE interface include files. (For both the
existing SAL_THROW_EXTERN_C and the new SAL_NOEXCEPT, base usage of `noexept`
not on LIBO_INTERNAL_ONLY, but on the actual compiler C++ version, so that e.g.
building CppunitTest_cppu_any-external, which uses
gb_CppunitTest_set_external_code but not gb_CXX03FLAGS, will not potentially
complain about those macros expanding to the legacy `throw()`, like when
building with Clang -Wdeprecated-dynamic-exception-spec manually enabled.)
Change-Id: I7e5c7f8d5f0fd622cfc9987d656b1f68541375aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114908
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I95877c014d16426622e7114384c8e189c140943c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114836
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I41df4af812cd225a0bd8e49df9e8b3c322698d28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110825
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
O[U]StringBuffer methods
Change-Id: I0ffbc33d54ae7c98b5652434f3370ee4f819f6f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110090
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Icd006d12942489a10fc2b3b801233c9527284721
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105652
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.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>
|
|
This commit was carried out by a Python script, source of which
is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97.
Change-Id: I421f0594d5f4389f7800a5bd0e339edde5627bb3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100182
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...from which an OString can cheaply be instantiated.
The one downside is that OStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a containers that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::string_view, without loss of efficiency
compared to the original OStringLiteral, and without loss of expressivity (esp.
with the newly introduced OString(std::string_view) ctor).
The new OStringLiteral ctor code would probably not be very efficient if it were
ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OStringLiteral is in all cases where an
object that shall itself not be an OString (e.g., because it shall be a
global static variable for which the OString ctor/dtor would be detrimental at
library load/unload) must be converted to an OString instance in at least one
place. Other string literal abstractions could use std::string_view (or just
plain char const[N]), but interestingly OStringLiteral might be more efficient
than constexpr std::string_view even for such cases, as it should not need any
relocations at library load time. For now, no existing uses of OUStringLiteral
have been changed to some other abstraction (unless technically necessary as
discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC
bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". Those places, as
well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx
and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been
replaced with OString::Concat (and which is arguably a better choice, anyway),
also caused failures with at least Clang 5.0.2 (but would not have caused
failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that
have meanwhile been fixed).
This change also revealed a bug in at least recent Clang 12 trunk
CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least
in some calls from loplugin code (for which it can be fixed for now in the
existing compat::getSubStringAsWritten).
A similar commit for OUStringLiteral is planned, too.
Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
O[U]StringView had an odd mixture of uses. For one, it was used like
std::[u16]string_view, for which directly using the latter std types is clearly
the better alternative. For another, it was used in concatenation sequences,
when neither of the two leading terms were of our rtl string-related types.
For that second use case introduce O[U]String::Concat (as std::[u16]string_view
can obviously not be used, those not being one of our rtl string-related types).
Also, O[U]StringLiteral is occasionally used for this, but the planned changes
outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral
from char[] to char16_t[]" commit message will make that no longer work, so
O[U]String::Concat will be the preferred solution in such use cases going
forward, too.
O[U]StringView was also occasionally used to include O[U]StringBuffer values in
concatenation sequences, for which a more obvious alternative is to make
O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat
machinery.
Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(see the <https://gerrit.libreoffice.org/c/core/+/93868/19#
message-77dcd3b30c4ae3919354f84b46b27d934164a938> comment to "use
std::experimental::source_location in uno::Exception")
Change-Id: I5d682dcf97be59f1798c5c08ad13025dfee0dd4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94495
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Clang and gcc have moved this out of experimental and into std::source_location,
but only in their very latest releases.
Change-Id: I9d9d9155788ee4240455ac4628b298dface4ad24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93868
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7bd0c2a55b936896fcfe7e1a374871008a18618f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93706
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I973ecef5df990511a41e422b73ed2314434f2871
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92479
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6fc81e6ef13f77dea410f95e159a932089603aeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89801
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This reverts commit 5b22433d79823372744038c5ae28094bc938fb48.
Reason for revert: <INSERT REASONING HERE>
Change-Id: I4a104ca86dadbcc7f797df41326d48a53ca1c990
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89800
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I31434d2b979aff20a53b164ffbb3d19247cd1ce3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89826
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I48452480fae169e11d60b125bbd0226b6a35a25c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86800
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaf46b42a17bc00da0f86daeafea7b5346c4a6360
Reviewed-on: https://gerrit.libreoffice.org/85372
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
if one side of the expression is a compile-time-constant, we don't need
to worry about side-effects on the other side
Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b
Reviewed-on: https://gerrit.libreoffice.org/81589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I385587a922c555c320a45dcc6d644315b72510e9
Reviewed-on: https://gerrit.libreoffice.org/81278
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by the simple expidient of putting asserts in
the resize routine. Where an explicit const size is used,
I started with 32 and kept doubling until that site
did not need resizing anymore.
Change-Id: I998787edc940d0a3ba23b5ac37131ab9ecd300f4
Reviewed-on: https://gerrit.libreoffice.org/81138
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and create conversion methods on *StringBuffer to make this work
Change-Id: I3cf5ee3e139826168894b46eff8ee4bcde00cb7e
Reviewed-on: https://gerrit.libreoffice.org/80949
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which defeat the *StringConcat optimisation.
Also make StringConcat conversions treat a nullptr as an empty string,
to match the O*String(char*) constructors.
Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b
Reviewed-on: https://gerrit.libreoffice.org/80724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I12517651fb3f777fd08e384992bb3e84b340ad85
Reviewed-on: https://gerrit.libreoffice.org/80382
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2fdeb7eb3ead3512ad6d3fe793305038ab3aa7ae
Reviewed-on: https://gerrit.libreoffice.org/79886
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6ca5ae6f700747e726e531231b3a5cd1586c54d7
Reviewed-on: https://gerrit.libreoffice.org/78652
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...following up on 1453c2c8f13bac64ecd1981af7cebf1c421808ac "prefer vector::data
to &vector[0]"
Change-Id: I7c113747d92d144a521d49b89384dd8bf1215c01
Reviewed-on: https://gerrit.libreoffice.org/72765
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
V522 There might be dereferencing of a potential null pointer.
Change-Id: Ie4bc74a734a6d5a73838a27e0d80cc8e51595839
Reviewed-on: https://gerrit.libreoffice.org/70730
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I9776431ebce95a88ae42715aaba2ddc28fb52471
Reviewed-on: https://gerrit.libreoffice.org/70642
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 84662e9030a855c8db7cd40d9ce354b773d78c16.
Change-Id: I1cc98d3201390609ae3615baa8e92c926cdcde9a
Reviewed-on: https://gerrit.libreoffice.org/70294
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... to take into account possible differences of results of dynamic_cast
vs static_cast; the change casts dynamically, as before the commit, and
only adds asserts on the result of the cast.
Thanks to sberg for pointing my mistake out!
Change-Id: Ib77d443e5a858e744f369f58542de603f948fd1c
Reviewed-on: https://gerrit.libreoffice.org/70274
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
These helpers are used in code generator code; so any invalid UTF-8
or UTF-16 in the conversion is programmer's error which needs fixing.
Thus, the behavior of toUtf8/fromUtf8 which asserts the validity is
fine here.
Change-Id: I3004e233c9de59f8e348455f1f04d23e8c51ed3d
Reviewed-on: https://gerrit.libreoffice.org/70249
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
V522 There might be dereferencing of a potential null pointer.
Change-Id: Ie617b41a8f8d334022cf5313b242a236baedba48
Reviewed-on: https://gerrit.libreoffice.org/70017
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I47c469c0fcdff41d83729be9489c946e81ef3686
Reviewed-on: https://gerrit.libreoffice.org/68020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|