Age | Commit message (Collapse) | Author |
|
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I949971374a68156ba78dce3b8d058774b1bef816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112872
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I83618f54a4117cd81d8626307716129a761e14c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111274
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8ea476bfbaf27f8ab2daf4a370efc9917a5f9f8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110346
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Check for that in ctor.
Change-Id: Ia69b3d87ac4ccb5b6cc13169d7022c04607c609f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108803
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I220eecfa6aaf4d5cb12e3b4eacadf25843b41452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108403
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
...after cbe9a0a815e4a73bf8db425a7c5c651e67b2ed65 "Use Unicode paths on Windows
for pyuno"
Change-Id: I898ee8ebbc1dfb215c55940c6336756ae7b5ccc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108658
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
No need to convert to 8-byte string only to convert back to UTF-16.
No idea if this has some logic on Linux, so only changing Windows.
Change-Id: I87b7f25e5b1a2dd07ac3354f8f065485949ef229
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108480
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Idb31b3d00f35e0f90a4420f250f7a04535f5fe0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108476
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7cf95ab1f237e315e8bd80b47758839bca34f970
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107946
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
|
|
...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: I1ecc16ddf565ac1f7306289fd51b673ed928cc20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107329
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
trace:
/home/julien/lo/libreoffice/instdir/program/pythonloader.py:146: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/julien/lo/libreoffice/instdir/share/extensions/numbertext/reg.uno.py' mode='r' encoding='utf_8'>
mod = self.getModuleFromUrl( locationUrl )
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Change-Id: I106ab6c3c9024a8c1a4624a3b64958dc205e30e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107232
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I886b6f446293d3b1cfbf4ae05e8dbd7fabab9f20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105510
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit f0356b6128bb4e78041d53025ad7c2e0b8e0c299.
Reason for revert: There is a OUStringConcat overload for OUStringBuffer which would have kicked in here, so this is unnecessary
Change-Id: I3bafb6c30bd3a2c1912daf227554889f1e09c78a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id6f7268f12eb728dbb255aa19cd590b6813c4f01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105377
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I49157f373b0d5919492a0ba4ccdcd545c58730a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105333
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...where the goal is to check for a value in the range
[SAL_MIN_INT32 .. SAL_MAX_INT32], i.e., [-2^31 .. 2^31 - 1]: While C++17 (via C
LONG_MIN, LONG_MAX) only guarantees a range of [-(2^31 - 1) .. 2^31 - 1] for
long, C++20 now requires two's complement and a fitting range of at least
[-2^31 .. 2^31 - 1].
No need for 0d79d216886a71436e705c93829ed66a33270a9c "long->tools::Long in
pyuno..sd" here.
Change-Id: I6be60b50acfe5ed798cc8e9e1183c336c8d72059
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104712
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I67c1218d225f49ea9ce789433283ab85275e39a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104627
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I953dcc31445fc76d219903da56b2cc264f28c220
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103848
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See tdf#74608 for motivation.
Change-Id: I4bdc09b4ba5c2f7ecc4fc8184f2d8230896aef01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98716
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I188716d5da92d495b9511f000dd9c1a78259fa9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97621
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and don't insert any empty path entries if that situation
was to arise
Change-Id: I8d8183485f457c3e4385181fee07390c4bfef603
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96713
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I19eba57bc6058c317473d0746f06699a09ba2830
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94608
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8bdbf05f1357aea83a3cdda2f06d63c7d04de8f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94561
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Until Python 3.7, PyTypeObject had a member tp_print following tp_dealloc, which
had then been repurposed as
> /* Methods to implement standard operations */
>
> destructor tp_dealloc;
> - printfunc tp_print;
> + Py_ssize_t tp_vectorcall_offset;
> getattrfunc tp_getattr;
> setattrfunc tp_setattr;
> PyAsyncMethods *tp_as_async; /* formerly known as tp_compare (Python 2)
in <https://github.com/python/cpython/commit/
aacc77fbd77640a8f03638216fa09372cc21673d> "bpo-36974: implement PEP 590
(GH-13185)" towards Python 3.8. Then only on the 3.8 branch (and prior to tag
v3.8.0), <https://github.com/python/cpython/commit/
d917cfe4051d45b2b755c726c096ecfcc4869ceb> "[3.8] bpo-37250: put back tp_print
for backwards compatibility (GH-14193)" added
> destructor tp_finalize;
> vectorcallfunc tp_vectorcall;
>
> + /* bpo-37250: kept for backwards compatibility in CPython 3.8 only */
> + Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);
> +
> #ifdef COUNT_ALLOCS
> /* these must be last and never explicitly initialized */
> Py_ssize_t tp_allocs;
at the end of PyTypeObject. This was apparently done so that third-party code
containing initialization code like
X.tp_print = 0;
would continue to compile (by just adding back a member with that name, even if
at a "random" new---and otherwise unused---location). However, for our way of
list-initializing PyTypeObject instances in pyuno that new member caused
"missing field 'tp_print' initializer" -Wmissing-field-initializers warnings, so
50ccb7e82b7053306721cbe220323be072306a29 "python 3.8.2 compile: add tp_print to
PyTypeObject" added initializers for this new at-end member. But it did so in a
way that raises three concerns:
1 The new member was already added in Python 3.8.0 (prior to tag v3.8.0), not
only in 3.8.2.
2 The new member was only added to Python 3.8. It has not been added to
current master towards 3.9.
3 It is unclear why the comments mention "Py_ssize_t" as the type of that new
member, when actually it is of a function pointer type (see above). Probably
best to just drop that from the comments, to avoid confusion.
Change-Id: Ib44f43befd5f28d4c1ac1e9e14bd55bfb4473507
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94019
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...compared to d1786724b8e8e474e1f7e39012c1f19611841dc0 "prevent warnings in
pyuno with latest python". For one it is only the
/* bpo-37250: kept for backwards compatibility in CPython 3.8 only */
Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);
member (in /usr/include/python3.8/cpython/object.h) that causes a warning. And
for another it is only Clang that emits a warning when initializing a deprecated
member that way, <http://lists.llvm.org/pipermail/cfe-dev/2020-May/065392.html>
"[cfe-dev] Diagnosing initialization of deprecated data member?"
Change-Id: I36625118a6bb26f5468d436da4caa82911181202
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94016
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which has marked some members deprecated, but we can't stop initialising
them or we run the risk of ASAN complaining
Change-Id: I8f4ad0ae083fad9c040613ddde7c40f20d68c7d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93580
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9ed25c5efaa4b447ab14a497a58bbe1147a6e7b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91698
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Python 2 support was retained for use with --enable-python=system
on RHEL7 and SLES. The time has arrived to remove it.
Some .py files that were imported from third parties are not changed to
enable easier replacement with updated versions if necessary.
solenv/gdb should continue to support Python 2.
bin/get-bugzilla-attachments-by-mimetype requires Python 2 to access
Launchpad.
Change-Id: I26414ae8e9f8402c90336af82020135685694217
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91697
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I6074463579f1ffc18f5683a3c4b109402b650f9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91613
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found by:
run-clang-tidy-10 -checks=-*,misc-unused-using-decls
Change-Id: I3e95791e223ef01e140a6217e29a9efae428a784
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90876
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit 31138ff7729cbf179079a5e635d3a823e2971f08.
Now that we know that making fields has negative side effects
like disabling assignment operator generation.
Change-Id: I3f1ae65532f441c8be5ebca5866b8a1e1c69318c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90363
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I couldn't find this documented on the Internet though,
as the 3.9 and 3.8.2rc documentation didn't mention it
as an added item...
I'm using Ubuntu 20.04 alpha with python3 --version
Python 3.8.2rc1
This fixes pyuno/source/module/pyuno.cxx:1689:1: error:
missing initializer for member ‘_typeobject::tp_print’
[-Werror=missing-field-initializers]
Change-Id: Idec5720050572b34628267cd94557dabf7edbf3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89247
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...with recent Clant trunk, see <https://github.com/llvm/llvm-project/commit/
7ae1b4a0ce9c7f269cf3069e41496a78e3f28d49> " Implement P1766R1: diagnose giving non-C-compatible classes a typedef name for linkage purposes."
Change-Id: Ida0bbe8f4be7845b8663ea3c86e1faf1db7f55a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88349
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If0d26019d9f842bcf56c1e01c46cc86c21523c3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87476
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The use-after-free is easier to trigger than expected; i don't see how
it's possible to check this without a race.
Change-Id: I4afb7066d1bf6b34f4f56aa0f51be0643ae40a66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86481
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Ie0359efa8777439818e357a14db3e2474e936ef6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86403
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
|
|
pyuno/source/module/pyuno_runtime.cxx:984:57: error: use of undeclared identifier 'PyThread_get_thread_ident'
It's only an assert, so simply do it only for >=3.7.
Change-Id: Ia3fffc7a9af30780adff9bc7dbabe1727c1f8f54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86410
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
|
|
* external/python3/python-3.3.3-aix.patch.1:
most of it doesn't apply and AIX port isn't maintained anyway so
remove it for now
* external/python3/ubsan.patch.0:
apparently one of the files was removed
* 0001-3.6-bpo-17239-Disable-external-entities-in-SAX-parse.patch.1:
fixed upstream
* python3-osx-avoid-new-10.13.patch.1:
replace with simply passing ac_cv_func_utimensat=no to configure
* external/python3/python-3.5.4-ssl.patch.1:
project files to build OpenSSL removed upstream
* There have been changes to how python locates OpenSSL; new variables
OPENSSL_INCLUDES etc; it turns out that you have to pass one directory
to --with-openssl, as the variables cannot be passed
* libuuid.so.1 is a new dependency of the _uuid module
* libffi.so.6 is a new dependency of the _ctypes module (the bundled
copy of libffi for non-Darwin platforms was removed)
* python-3.3.0-pythreadstate.patch.1:
the PyThreadState functions have been changed such that
CppunitTest_services asserts when there is a PyThreadAttach on top of
PyThreadDetach on top of PyThreadAttach, i.e., 2 PyThreadState per
thread (PyGILState_Check() fails). Instead of patching in additional
workarounds, change PyThreadAttach so that it re-uses an existing
PyThreadState if one exists for the thread.
Change-Id: I24c19d79b43a30709261fd9db66312b2e3872fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84765
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Icc7f2a32696c30317c1ee77ef39d682d5f5a80b9
Reviewed-on: https://gerrit.libreoffice.org/85512
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
look for OUStringBuffer append sequences that can be turned
into creating an OUString with + operations
Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6
Reviewed-on: https://gerrit.libreoffice.org/80809
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...to find matches of
... << s.getStr()
(for the rtl string classes) that can be written as just
... << s
Some notes:
* The OUStringToOString(..., RTL_TEXTENCODING_UTF8) is left explicit in
desktop/source/app/crashreport.cxx (even though that would also be done
internally by the "<< OUString" operator) to clarify that these values are
written out as UTF-8 (and not as what that operator << happens to use, which
just also happens to be UTF-8).
* OUSTRING_TO_CSTR (include/oox/helper/helper.hxx) is no longer used now.
* Just don't bother to use osl_getThreadTextEncoding() in the SAL_WARN in
lingucomponent/source/hyphenator/hyphen/hyphenimp.cxx.
* The toUtf8() in the SAL_DEBUG in pyuno/source/module/pyuno_module.cxx can just
go, too.
Change-Id: I4602f0379ef816bff310f1e51b57c56b7e3f0136
Reviewed-on: https://gerrit.libreoffice.org/80762
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2cbbaad921b0a3d2ea6def4da2a2527dc4d94549
Reviewed-on: https://gerrit.libreoffice.org/79075
Tested-by: Jenkins
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
in hwpfilter, include/test, io, linguistic, oox, pyuno, reportdesign
Change-Id: I5c265c4fde85dd6d7faab8ae82809c4a0e6dd69b
Reviewed-on: https://gerrit.libreoffice.org/77646
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Use range-based loops, STL and comphelper functions
Change-Id: If738d8f4e792c4686870183b0c0fdfbb61fd3351
Reviewed-on: https://gerrit.libreoffice.org/77245
Tested-by: Jenkins
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
Change-Id: I86b9174c37e4a347a3a8ac6c2707052167e6fdc0
Reviewed-on: https://gerrit.libreoffice.org/77522
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|