The goal is to make the script more readable. The format is done with
command:
black --line-length 120 <filename>
No manual modification to these files.
Change-Id: I8ebbac936924277308fc011b20cba60849fa9c45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179438
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
4256c764ae "do not pass XComponentContext to
officecfg::...::get() calls" had removed it, for performance reasons, but
8a695046cf "tdf#158375 Hack to make sure process
service factory is set" is a case where it should be passed in. To hopefully
avoid performance regressions, don't default to
comphelper::getProcessComponentContext() for what gets passed in, but default to
an empty Reference and only call comphelper::getProcessComponentContext() when
actually needed in the implementation.
Change-Id: I5b75ac2c28f36e21d1c8bc368b0b972c33c61a51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162205
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Similar to what is done in bootstrap_expandUri, expandUnoRcUrl,
UrlReference::expand, JavaLoader.expand_url, and is documented
in XVndSunStarExpandUrl interface.
Change-Id: I92917adb38e42c3926494427e4df2451298033e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140042
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
1fb53a6375 "pyuno_loader::CreateInstance: delete
the initial PyThreadState" had added the PyThreadState_Delete for claimed
benefits but whose details appear lost to history (cf. the comment thread
starting at
<https://gerrit.libreoffice.org/c/core/+/3452/2#message-602ff52abdd1c95fd5c13cfe405b5fadd0048c5f>
"pyuno_loader::CreateInstance: delete the initial PyThreadState"). And at least
a recent master Linux --enable-python=fully-internal build with the bundled
Python 3.8.12 appears to succeed `make check` just fine with the
PyThreadState_Delete temporarily removed.
But on the other hand, building against upcoming Python 3.11 now started to make
CppunitTest_services fail with
> Fatal Python error: init_threadstate: thread state already initialized
> Python runtime state: initialized
> Thread 0x0000ffff81c8b020 (most recent call first):
> <no Python frame>
> Fatal exception: Signal 6
> Stack:
> /builddir/build/BUILD/libreoffice-7.3.4.2/instdir/program/libuno_sal.so.3(+0x37c28)[0xffff81be7c28]
> /builddir/build/BUILD/libreoffice-7.3.4.2/instdir/program/libuno_sal.so.3(+0x37e40)[0xffff81be7e40]
> linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffff81ccb7ec]
> /lib64/libc.so.6(+0x82878)[0xffff81742878]
> /lib64/libc.so.6(raise+0x20)[0xffff816fae00]
> /lib64/libc.so.6(abort+0xe8)[0xffff816e72b8]
> /lib64/libpython3.11.so.1.0(+0x104e28)[0xfffee4de4e28]
> /lib64/libpython3.11.so.1.0(+0x105200)[0xfffee4de5200]
> /lib64/libpython3.11.so.1.0(PyThread_get_thread_native_id+0x0)[0xfffee4ed6764]
> /lib64/libpython3.11.so.1.0(PyThreadState_New+0x14)[0xfffee4ed6628]
> /builddir/build/BUILD/libreoffice-7.3.4.2/instdir/program/libpyuno.so(_ZN5pyuno14PyThreadAttachC2EP3_is+0x78)[0xfffee4c8c52c]
> /builddir/build/BUILD/libreoffice-7.3.4.2/instdir/program/libpythonloaderlo.so(pyuno_Loader_get_implementation+0x5c)[0xfffee5243060]
> /builddir/build/BUILD/libreoffice-7.3.4.2/instdir/program/libuno_cppuhelpergcc3.so.3(+0x544b4)[0xffff815544b4]
because of the PyThreadState_Delete. (The deleted PyThreadState, while not
reused again directly, is still recorded in the state obtained from
PyInterpreterState_Head() later.)
So conservatively keep the PyThreadState_Delete of unclear benefit for older
Python versions and only drop it for 3.11 where it is known to have negative
effects now.
Change-Id: I9b99f1e947f0b165ddc95c2bfbd764858dda39db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136006
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>
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>
...following up on 314f15bff0 "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>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I95575d41a822ff7b1ac5bdba03057f6d3fa61b51
Reviewed-on: https://gerrit.libreoffice.org/71141
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Previously __file__ was set after executing the module. This meant,
however that it was not available during execution.
This patch moves setting __file__ before the execution.
As __file__ is a string (and not bytes), we remove the encoding.
Change-Id: I63fe34b6f5d30f53aab16627d413c87b9de81992
Reviewed-on: https://gerrit.libreoffice.org/70048
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
According to the crash reports, it's possible for the grammar checking
thread to call GetGrammarChecker, instantiating lightproof, at the same
time as the main thread instantiates LngSvcMgr, which also instantiates
(some?) (all?) grammar checkers.
Ensure that pyuno_loader::CreateInstance() initialises Python only
once with a C++11 thread safe static.
Change-Id: I5b1faba9107355c508831a078366e4a29fdbfadf
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I11e4fde47c5da601e4ffeada31083c3bdb4286f9
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Bunch of these were setting C++ or Make modes and icky tabs...
Also, reportedly Emacs can figure out to enable python-mode
automatically.
Change-Id: I50072488fb92cb4d27aa3f74f717a28ae3967543
Mike Kaganski