Age | Commit message (Collapse) | Author |
|
...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 1250aecd71fabde4dba990bfceb61bbe8e06b8ea
"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>
|
|
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
With the recent implementation of
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" in Clang 13 trunk as
<https://github.com/llvm/llvm-project/commit/bf20631782183cd19e0bb7219e908c2bbb01a75f>
"[clang] Implement P2266 Simpler implicit move", a --with-latest-c++ build
started to fail with
> comphelper/source/xml/xmltools.cxx:103:20: error: no viable conversion from returned value of type 'char [39]' to function return type 'rtl::OString'
> return str;
> ^~~
[...]
> include/rtl/string.hxx:277:5: note: candidate constructor [with T = char [39]] not viable: expects an lvalue for 1st argument
> OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() )
> ^
[...]
etc.
Change-Id: If34f143a1855fdd7cd22ea3d7594f9381d50a7ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117336
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and update the stringview loplugin to detect cases where we can
use these new methods.
Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See d5d905b480c2a9b1db982f2867e87b5c230d1ab9 and related commits for the
rationale on why those are not extracted like other strings.
Change-Id: I2a339747626e0fb314cac7f57bccb2b91853249c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109916
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
|
|
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>
|
|
This should enable using move semantics where possible e.g. in standard
containers.
According to https://en.cppreference.com/w/cpp/language/move_constructor:
To make strong exception guarantee possible, user-defined move
constructors should not throw exceptions. For example, std::vector
relies on std::move_if_noexcept to choose between move and copy
when the elements need to be relocated.
Change-Id: I6e1e1cdd5cd430b139ffa2fa7031fb0bb625decb
Reviewed-on: https://gerrit.libreoffice.org/77957
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I98476e17e0ab6009d822205c7b31935173da2722
Reviewed-on: https://gerrit.libreoffice.org/76666
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If863d28c6db470faa0d22273020888d4219e069e
Reviewed-on: https://gerrit.libreoffice.org/74559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use range-based loop or replace with STL functions
Change-Id: Ib3fab47318d1bfbb4df8f886a8cd9596525a420f
Reviewed-on: https://gerrit.libreoffice.org/67914
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found with
git grep -n -A4 'if.*!.*empty' | grep -B3 -P
'(\bfor)|(\bwhile)|(\bdo)'
Change-Id: I582235b7cf977a0f9fb4099eb306fdb4a07b5334
Reviewed-on: https://gerrit.libreoffice.org/64169
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia3c094ee65be3f5048df6896a4a6428bdd8fed10
Reviewed-on: https://gerrit.libreoffice.org/63527
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
also don't change POT creation date when rewriting a po file, update
Po-Revision instead.
When creating templates, put X-Accelerator before X-Generator (like
pootle would order it)
Change-Id: I7fec4cb1c50e27b87decd9a892de3f01a02253ed
Reviewed-on: https://gerrit.libreoffice.org/63416
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I51a82ce5fc09d44ebc6f7c06c67b475ee2adf68b
Reviewed-on: https://gerrit.libreoffice.org/62419
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
Change-Id: Ica102309627fade2a064ee5516e84801affe4082
Reviewed-on: https://gerrit.libreoffice.org/61184
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I43978811056692623344239d2c6e4763fa7de16b
Reviewed-on: https://gerrit.libreoffice.org/61165
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: Icbe0dd5e63eb5b10d162f34347ab86dde547dc62
Reviewed-on: https://gerrit.libreoffice.org/61164
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: I220fce194813f783c807c23eeffd2421cadd7636
Reviewed-on: https://gerrit.libreoffice.org/61163
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: I7d1d344e79e0c23886a21032d2ce85e5abb199cb
Reviewed-on: https://gerrit.libreoffice.org/61162
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
This reverts commit 3d604d1cd6cc70ef96782ef769f0479b509987a8.
comments from sberg:
I assume dropping the std::move from aCurSel(std::move(aSel)) is caused
by performance-move-const-arg's warning "if std::move() is called with
an argument of a trivially-copyable type"
(<https://clang.llvm.org/extra/clang-tidy/checks/performance-move-const-arg.html>).
For my taste, that approach is too tightly tied to a class's current
implementation details, something that may change over time. Imagine a
trivially copyable class C with a raw pointer member (where the
lifecycle of the pointed-to object is tracked by some higher-level,
likely broken protocol). Now, that protocol is fixed and the raw
pointer member is replaced with a std::shared_ptr. C is no longer
trivially copyable, and the dropped std::move would turn out to be
beneficial again.
(Also, if Clang and clang-tidy did implement the fixed rules for
trivially copyable classes from CWG1734/C++17, where a subset of a
trivially copyable class's copy/move members may be deleted, the above
rule to warn "if std::move() is called with an argument of a
trivially-copyable type" would no longer make sense as written; consider
a trivially copyable class whose copy ctor has been deleted.)
Change-Id: Icb91610e50ed98b8f55fe6323bdfa48c8cb9b4b9
Reviewed-on: https://gerrit.libreoffice.org/60166
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I607891e120688b746c8a4c577018d97147a79217
Reviewed-on: https://gerrit.libreoffice.org/60029
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
This is a continuation of commit 6ff2d84ade299cb3d14d4110e4cf1a4b8070c030 to be able to remove those unneeded includes.
This commit adds missing headers to every file found by:
grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
to directories from l10ntools to reportdesign
Change-Id: Ia2dc93dd848c2dc0b6a8cb6e19849c614ec55198
Reviewed-on: https://gerrit.libreoffice.org/58205
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
look for OUString being appended to in a loop, better to use
OUStringBuffer to accumulate the results.
Change-Id: Ia36e06e2781a7c546ce9cbad62727aa4c5f10c4b
Reviewed-on: https://gerrit.libreoffice.org/58092
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I73eed5cbaaa1a0668f0dfa89a1a26883f64b3107
|
|
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
|
|
Change-Id: Ifa228ca02ea79a1309e1875414028aade7e5f12d
Reviewed-on: https://gerrit.libreoffice.org/39801
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This patch is graciously offered by Arnaud Versini.
Change-Id: I3ed5e1758d09542a2ca0533e3f4a6ceb2dbb6346
Reviewed-on: https://gerrit.libreoffice.org/38404
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0490efedf459190521f4339854b3394d57765fdb
Reviewed-on: https://gerrit.libreoffice.org/38058
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
otherwise pocheck will file on strings like like e.g.
#: analysis.src
msgctxt ""
"analysis.src\n"
"ANALYSIS_Weeknum\n"
"Returns the number of the calendar week in which the specified date occurs.\n"
"This function exists for interoperability with older Microsoft Excel documents, for new documents use WEEKNUM instead.\n"
"itemlist.text"
msgid ""
"Returns the number of the calendar week in which the specified date occurs.\n"
"This function exists for interoperability with older Microsoft Excel documents, for new documents use WEEKNUM instead."
msgstr ""
Change-Id: Ib64a989933ca42c5119b0ecf2339f693793d4e96
|
|
Change-Id: I732e2e22c6f953f0982fbc8833453e7c23cf9d49
Reviewed-on: https://gerrit.libreoffice.org/33166
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I806cb0a1ede9c025c00fab58a3fd8835887c0a44
|
|
Change-Id: I5c628a063fb5309f493729ee4bd7b122a3d2c3d5
|
|
Change-Id: I4258bcc97273d8bb7a8c4879fac02a427f76e18c
Reviewed-on: https://gerrit.libreoffice.org/27317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Tested with output of "make translations", it apparently computes the
same CRC function, despite the documentation specifying different
polynomials, but maybe that is just different notations...
Change-Id: Ia28a881f5cdf54326fe5051527acd445e7a5771c
|
|
Change-Id: I80070c83204e531c2f599f8a56193d6ffe0e5022
|
|
Change-Id: I21620816a80e542fe9771ef22322c4bc42ce50bd
|
|
Change-Id: If86e2df6d24766c5685466c4c6fc63ecba798000
|
|
changes due a log from clang tinderbox.
minor changes to interpret more files
Change-Id: I3821aab91dc21e74c870628a4f2265ab61d37cca
|
|
Change-Id: I2e495243b75fc239dafbf63c7644115f0a923f4a
Reviewed-on: https://gerrit.libreoffice.org/23607
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I3760e50796605ce50ef2e91951fc839b84669b89
Reviewed-on: https://gerrit.libreoffice.org/22733
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Id63bbdd11af66de6be8a3e9dfca1c7efbe74b08a
|
|
Change-Id: I87dbff06345f24064b87c375e5381cb27118e614
|
|
find places where we should be using std::unique_ptr
Change-Id: I5b9defe778fdc4738ecea381215396874db59e66
|
|
Where we can prove that the virtual method is never overriden.
In the case of pure-virtual methods, we remove the method entirely.
Sometimes this leads to entire methods and fields being
eliminated.
Change-Id: I138ef81c95f115dbd8c023a83cfc7e9d5d6d14ae
|
|
Change-Id: Id2eb27132fd6c1734e50c02617ce1bbb75e294a0
|
|
Change-Id: I2ed53b4f902ae694fc064375e8a9cfeba32f9d1c
|
|
Change-Id: Ia10056ae9e1b9adfe74f299afac5c3c84fa8cea7
Reviewed-on: https://gerrit.libreoffice.org/8278
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|