Age | Commit message (Collapse) | Author |
|
Change-Id: Id58484eb9b955948a8edb48000b86cec3b721060
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124377
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
look for places where the statements inside a block are
not indented
Change-Id: I0cbfa7e0b6fb194b2aff6fa7e070fb907d70ca2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123885
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I15d56d133cf464a3cb6483be785b1259c7f35b43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123120
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the
lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building
without --with-latest-c++) requires ROW_RANGE (a local const int variable from
the enclosing TestFormula::testTdf97369) to be captured, even though all uses of
that variable within the lambda body are constant expressions. That is still
true at least for the latest Visual Studio 2019 version 16.11.1. (This is not
an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down,
as they, in addition to using that ROW_RANGE, also use the local const double
variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so
they are implicitly captured and loplugin:unusedcapturedefault does not suggest
dropping those lambdas' capture-defaults in the first place.)
Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic7410f836e584df45101e78e345c8b3c8d355e09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120680
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2a957cd72d71fea717734488cdb3670e0bcdd6f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114657
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>
|
|
Add bad Intel driver reported by a new developer.
Remove superfluous AMD allowlist entry.
Change-Id: Ide5092dab7e0fa7f40ee512ba2dc9283bd9e95be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110749
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I569c7f34acbdf8451cd5c9acf1abd334637072d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110051
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>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I16a00ceee4c2b772ec9ed6b1b349253114b22239
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105695
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
found by grepping and changed by hand.
Change-Id: I3c720859dba430fde3abc76c6c5cb58269efaf4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105512
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Common::Misc::OpenCLWhiteList -> OpenCLAllowList
Change-Id: I65636b19b13e4af1e4851f70e78053f3443d6bb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98181
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
.. and a few cases of instead doing blacklist->excludelist where that
made more sense.
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist
[API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice
[API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList
Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I9f45510eddb022013af751d232d4704432717ef6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91617
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit a84e3df74eecc8778e3d5be5dd80ad4ddb511edf.
Now that we know that making fields has negative side effects
like disabling assignment operator generation.
Change-Id: I7b45b7ead281cf3a9202ca6aabc55ee5033e5331
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90332
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To be used also by Skia code to detect problems with Vulkan drivers.
The watchdog does not handle OpenCL because neither did the original
code, but also because OpenCLZone::hardDisable() called from it
would deadlock on SolarMutex for some reason.
Change-Id: I483d8cb0b11a4e1e65c564f4e4c29ab68843ff71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88008
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
so might as well return the BestDeviceIndex instead of passing
it by ref
Change-Id: Ic92fa3b5bfe3d319ff9fcb61b7f5404b5a624be5
Reviewed-on: https://gerrit.libreoffice.org/84971
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I708efa3dc4d9d145b1000d24cea4a4ff02628178
Reviewed-on: https://gerrit.libreoffice.org/84970
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
unused since 4eea4af8924e3b1bb00c22cf1f9d21fc4dec6e83 "tdf#103204 opencl:
initialize command queue on demand"
(found by upcoming loplugin:unusedmember)
Change-Id: Ic8ab914699d5a99338abdfc315001603a8255e1b
|
|
Change-Id: Ibccde3ec84b0ea4e4af74122013229a1793f5ca5
Reviewed-on: https://gerrit.libreoffice.org/81128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Replace them with default initialization or calloc
Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1
Reviewed-on: https://gerrit.libreoffice.org/80805
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...(which got introduced with 9b5dad13b56bdde7c40970351af3da3a2c3c9350
"loplugin:stringadd look for unnecessary temporaries", and had reportedly
broken CppunitTest_sc_ucalc on tml's Windows build by hitting the
"strlen( str ) == N - 1" assert at include/rtl/string.hxx:1867), by introducing
rtl::OStringView (and rtl::OUStringView, for consistency).
Change-Id: I766b600274302ded66a6bffc91be189b20ed1ac3
Reviewed-on: https://gerrit.libreoffice.org/80778
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
Recent GCC 10 trunk in C++20 mode reports issues like
> include/opencl/OpenCLZone.hxx:27:9: error: ‘++’ expression of ‘volatile’-qualified type is deprecated [-Werror=volatile]
> 27 | gnEnterCount++;
> | ^~~~~~~~~~~~
But unlike in the case of ec17c8ec5256386b0197a8ffe5d7cad3e7d70f8f
"-Werror=volatile in OpenGLZone",
* it looks like there are no multi-threading issues here, and the counters are
just accessed (via OpenCLZone::isInZone) from the VCLExceptionSignal_impl
signal handler in addition to being modified (via OpenCLZone RAII objects)
from mainline code; and
* from the usage pattern of gnEnterCount and gnLeaveCount it appears that they
can be combined into a single counter.
(f41eb66302208f384a475fb20c98b6d1b0676cb6 "opencl: OpenCLZone, detect CL
device change and disable CL on crash" presumably modelled OpenCLZone naively
after OpenGLZone, without simplifying it where possible.) One minor advantage
of having two monotonically increasing counters is that when they overflow,
the implementation of isInZone (comparing them for equality) still gives
~useful results (assuming that a false "match" of non-overflown gnEnterCount
against overflown gnLeaveCount is highly unlikely). But instances of
OpenCLZone RAII objects are presumably never nested very deeply (if at all),
so that the newly added "TODO: overflow" comment (which would even cause UB if
std::sig_atomic_t is signed) is probably of no practical concern.
Change-Id: I92e1f2c46ca996a0a86bacabcda2accba5eb6298
Reviewed-on: https://gerrit.libreoffice.org/79106
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iee965c3f720827b20347f6228e891562c8295d22
Reviewed-on: https://gerrit.libreoffice.org/78327
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I82738a18ff116fdc78f07b453c93b1b631632caf
Reviewed-on: https://gerrit.libreoffice.org/77775
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8e06da641db39d529426064e6c3412bc75a67fb2
Reviewed-on: https://gerrit.libreoffice.org/76661
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iea3bd498b1c8934f37085bdf6df71b073e4a871c
Reviewed-on: https://gerrit.libreoffice.org/76203
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: I7013e5ef67ae58c42886a4ba6ea0c9a47074ac8e
Reviewed-on: https://gerrit.libreoffice.org/75834
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I0aedc40c49c8cb1382f45571f54873d6017ec62c
Reviewed-on: https://gerrit.libreoffice.org/72637
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...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>
|
|
Some OpenCL implementations may be broken, e.g. pocl simply
asserts and aborts if it can't find Clang. In order to protect
against crashes caused by faulty OpenCL drivers, when testing OpenCL
functionality on OpenCL setup change, first do a simple test
in a separate helper.
Change-Id: I1cf328e731c48f47745b27c7130e7521254209f5
Reviewed-on: https://gerrit.libreoffice.org/71080
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Use range-based loop or replace with STL functions
Change-Id: I91405920d91383bc6cf13b9497d262b1f6f0a84d
Reviewed-on: https://gerrit.libreoffice.org/67848
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which is more general
Change-Id: I94f28f8eda887120cf5f143b4549e0339b60e6a7
Reviewed-on: https://gerrit.libreoffice.org/66155
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I285e2e75c8d9cad35445c89f00ef68b155806ea2
Reviewed-on: https://gerrit.libreoffice.org/63703
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
So that e.g. unit tests can be easily run with OpenCL forced. This forces
even single cells to be evaluated using the forced method (many correctness
tests are just a single cell which normally would not be used for grouped
calculation).
Change-Id: If5c6e77a6e0d8696d5416d760cf5e47b8acf3d27
Reviewed-on: https://gerrit.libreoffice.org/63188
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Iaa255b39928ac45dec1ed37e368c149d6027f561
Reviewed-on: https://gerrit.libreoffice.org/62701
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
which seem to have snuck back in since the great rounds of removals.
Change-Id: I85f7f5f4801c0b48dae8b50f51f83595b286d6a1
Reviewed-on: https://gerrit.libreoffice.org/62229
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: I76f15a8e7724384e8ba773621bdcac1351b32a0a
Reviewed-on: https://gerrit.libreoffice.org/62086
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I78fa01a6c803dec782488490b730af3a11814d64
Reviewed-on: https://gerrit.libreoffice.org/61902
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1e110d193ebfa30ab1ab0d85bfb6dc409e341439
Reviewed-on: https://gerrit.libreoffice.org/61728
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|