...in templated code, to cater for the needs of
<https://gerrit.libreoffice.org/c/core/+/124400> "Prepare for removal of
non-const operator[] from Sequence in testtools".
For one, by defining ImplicitBoolConversion::TraverseInitListExpr, make sure
that Clang versions before and after
<0a42fe70a5>
"[AST] Treat semantic form of InitListExpr as implicit code in traversals"
behave the same. Old versions of Clang would have erroneously reported
Sequence<Sequence<sal_Bool>> s2{ { false } };
(and reported
Sequence<Sequence<sal_Int32>> s4{ { false } };
twice) in compilerplugins/clang/test/implicitboolconversion.cxx when one of the
four combinations of syntactic/semantic visit of the outer/inner InitListExpr
defeated the intended suppression logic in
ImplicitBoolConversion::TraverseCXXStdInitializerListExpr.
And for another, ImplicitBoolConversion::TraverseInitListExpr can subsume the
exising ImplicitBoolConversion::TraverseCXXStdInitializerListExpr.
But for a third, that would still make
Sequence<Wrap2<sal_Bool>> s6{ { false } };
in compilerplugins/clang/test/implicitboolconversion.cxx emit a false warning,
so add a cheesy "TODO" chicken-out special case to
ImplicitBoolConversion::checkCXXConstructExpr for now.
Change-Id: Ib9a1b78a7812feb98c673b75a357af7737168342
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124583
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...similar to the "For some reason..." workaround already present in
VisitElaboratedTypeLoc. (Thanks to mst for finding this.)
Change-Id: Ic682e8290efa64093d3c4a831dfb4d23091b6056
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124559
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by modifications done to the plugin in
af908d9f18 "Avoid usage of incomplete types in
member functions defined in-class" (if the dtor's definition is spelled
`= default;` rather than `{}`, but which should always be possible)
Change-Id: Iddce2baf3635a12131854e86a609951309ffbc26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123656
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that started to fail now at least with clang-cl (where the MSVC rules when to
emit inline member function definitions are more aggressive than for other ABIs)
with --with-latest-c++ and --with-visual-studio=2022 (where usage of incomplete
types in std::vector now triggered
> In file included from C:/lo-clang/core/slideshow/source/engine/opengl/TransitionerImpl.cxx:31:
> In file included from C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\memory:11:
> In file included from C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\exception:12:
> C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\type_traits(744,50): error: incomplete type 'Primitive' used in type trait expression
> struct is_trivially_destructible : bool_constant<__is_trivially_destructible(_Ty)> {
> ^
> C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\type_traits(59,53): note: in instantiation of template class 'std::is_trivially_destructible<Primitive>' requested here
> struct conjunction<_First, _Rest...> : _Conjunction<_First::value, _First, _Rest...>::type {
> ^
> C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\type_traits(64,44): note: in instantiation of template class 'std::conjunction<std::is_trivially_destructible<Primitive>, std::disjunction<std::_Is_default_allocator<std::allocator<Primitive>>, std::_Has_no_alloc_destroy<std::allocator<Primitive>, Primitive *>>>' requested here
> _INLINE_VAR constexpr bool conjunction_v = conjunction<_Traits...>::value;
> ^
> C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\xmemory(934,20): note: in instantiation of variable template specialization 'std::conjunction_v<std::is_trivially_destructible<Primitive>, std::disjunction<std::_Is_default_allocator<std::allocator<Primitive>>, std::_Has_no_alloc_destroy<std::allocator<Primitive>, Primitive *>>>' requested here
> if constexpr (!conjunction_v<is_trivially_destructible<_Ty>, _Uses_default_destroy<_Alloc, _Ty*>>) {
> ^
> C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\vector(1632,13): note: in instantiation of function template specialization 'std::_Destroy_range<std::allocator<Primitive>>' requested here
> _Destroy_range(_Myfirst, _Mylast, _Al);
> ^
> C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\vector(583,9): note: in instantiation of member function 'std::vector<Primitive>::_Tidy' requested here
> _Tidy();
> ^
> C:/lo-clang/core/slideshow/source/engine/opengl/TransitionImpl.hxx(74,5): note: in instantiation of member function 'std::vector<Primitive>::~vector' requested here
> TransitionScene(
> ^
> C:/lo-clang/core/slideshow/source/engine/opengl/TransitionImpl.hxx(42,7): note: forward declaration of 'Primitive'
> class Primitive;
> ^
etc.).
Which in turn required tweaking of loplugin:unnecessaryoverride to avoid false
> In file included from C:/lo-clang/core/slideshow/source/engine/opengl/TransitionerImpl.cxx:67:
> C:/lo-clang/core/slideshow/source/engine/opengl/TransitionImpl.hxx(389,18): error: unnecessary user-declared destructor [loplugin:unnecessaryoverride]
> TransitionScene::~TransitionScene() = default;
> ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
> C:/lo-clang/core/slideshow/source/engine/opengl/TransitionImpl.hxx(81,12): note: declared here [loplugin:unnecessaryoverride]
> inline ~TransitionScene();
> ~~~~~~~^~~~~~~~~~~~~~~~~~
Change-Id: Ia72fb44e6e92ff47376d7b7159c0df7cbf883b69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123648
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... to avoid hidden cost of multiple COW checks, because they
call getArray() internally.
This obsoletes [loplugin:sequenceloop].
Also rename toNonConstRange to asNonConstRange, to reflect that
the result is a view of the sequence, not an independent object.
TODO: also drop non-const operator[], but introduce operator[]
in SequenceRange.
Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Empirically, when we are passing a collection type to a constructor,
80% of the time, we are passing a local temporary that can be moved
instead of being copied.
Change-Id: I5acc9d761c920691934a4be806a3d3ab6cdbab96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123056
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...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>
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>
...by assuming that all const member functions are side-effect free. (This
presumably means that some of the special cases in
StringAdd::isSideEffectFree are obsoleted by this more general case, but any
such removal is postponed to later clean-up.)
(Came across this when idly wondering why
8b7f948d9d "sc, VmlFormControlExporter: avoid
OStringBuffer style" had not been found by the plugin before.)
Change-Id: I6bca10df53885b14a590543aabd61f23b3748572
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118675
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
With the recent implemenation of
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" in Clang 13 trunk as
<bf20631782>
"[clang] Implement P2266 Simpler implicit move", a --with-latest-c++ build
started to fail with
> In file included from sal/rtl/random.cxx:25:
> include/o3tl/temporary.hxx:21:62: error: non-const lvalue reference to type 'double' cannot bind to a temporary of type 'double'
> template <typename T> constexpr T& temporary(T&& x) { return x; }
> ^
> sal/rtl/random.cxx:97:37: note: in instantiation of function template specialization 'o3tl::temporary<double>' requested here
> return std::modf(random, &o3tl::temporary(double()));
> ^
etc. (And fixing that by adding the recommended static_cast then triggered a
false loplugin:redundantcast warning.)
Change-Id: I222429e9872afdedf77a07014c0a2e9e06c60b50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...new with Clang trunk 13. As a rule of thumb, this change adds explicit
cast-to-void silencing in those .cxx that already contained other such silencing
casts and adds wholesale #pragma clang diagnostic ignored in all others.
Change-Id: I1884496ee1aa81aaf3c8b3533534a4b69b185e9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116660
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 ad48b2b02f "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>
Say what the O[U]String is constructed from (to make it easier to decide on an
optimal rephrase of the whole surrounding expression), and find more cases that
could use O[U]StringChar.
Change-Id: I64a3851544498c26ca3f46f5df7f593d2fdcb0ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115579
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
when calling a function, and passing only one arg, but the
function has defaulted args, we were ignoring this case.
Change-Id: I86517f18e30531127664088ddc09ef96dbd8bdf5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115033
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
An attempt that did not find anything convincing enough to finish it up
and make it permanently active.
So just leave it in /store for now.
Change-Id: I1750e177655a4a510da100f880ba81bf762be277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114742
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to O[U]String from char array literals, we can convert the char literals
to O[U]StringLiteral and avoid a runtime allocation
Change-Id: I15d8dddb2cd428b90740e39f20daf98e0941aa6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...as caused the
assert(!returnTypes_.empty());
in VisitReturnStmt to hit for the return statement in the permutation2D lambda
body (which does not happen to be nested within any other function declaration)
in patch sets 1 and 2 of <https://gerrit.libreoffice.org/c/core/+/113522>
"Compute permutation2D at compile time".
Change-Id: Ic4aa55bef4361e40c2cd6247b5646f7b1ba82e6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113699
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
because it wasn't quite there yet - now checks for casts with and
without const, because const doesn't really matter here.
Change-Id: I319025b2095a803fcaad2a7a696d2730b7fd2f81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112098
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
check that when we return ref-counted objects, we do so using
rtl::Reference, so that the object actually has a non-zero
ref count.
Change-Id: Ib3ffae0d2502f6d117550c82fde5449729c27324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111487
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for places we are dynamic_cast'ing after static_cast'ing,
which means the dynamic_cast is a waste of time.
Change-Id: Ife11bb675020738040646230bbd038278d84f7f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111631
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...causing e.g. false positive
> In file included from shell/source/win32/spsupp/COMOpenDocuments_x64.cxx:11:
> In file included from shell/source/win32/spsupp/COMOpenDocuments.cxx:16:
> In file included from shell/inc/spsupp\COMOpenDocuments.hpp:21:
> shell/inc/spsupp/COMRefCounted.hpp(35,13): error: cppu::OWeakObject subclass 'COMRefCounted<Interfaces...>' being deleted via delete, should be managed via rtl::Reference [loplugin:refcounting]
> delete this;
> ^~~~~~~~~~~
with clang-cl on Windows. (Ideally, this would be made up for with setting this
plugins' shouldVisitTemplateInstantiations() to true, see the TODO added in
compilerplugins/clang/test/refcounting.cxx, but that would cause lots of other
findings, so is left out for now.)
Change-Id: Ia52b13498a0c7169b37ecf4882ce84c3cc1d2cc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111339
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The error was:
error: 'error' diagnostics seen but not expected:
File /libreoffice/master-clang/compilerplugins/clang/test/referencecasting.cxx Line 113: unnecessary get() call [loplugin:referencecasting]
1 error generated.
I.e. it seems clang7 has the same problem as clang5 that it emits
multiple diagnostics for that problematic code line. Adapt the ifdef
accordingly.
Change-Id: I232ff9a158663e2cb3030e51f655249ff315361e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111196
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
rtl::Reference now has a conversion operator to uno::Reference,
so look for places where we can simplify the code and use that.
Change-Id: Ic81db50d670bed5e875300577d4bf5f3599cc2c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110798
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...detection of
OUString( const sal_Unicode * value, sal_Int32 length )
ctor. (On platforms where sal_Int32 is a typedef for int, an argument that
already is of type int will not be wrapped in an ImplicitCastExpr to the
sal_Int32 typedef.)
Change-Id: Ifc5456a62d42c1acad76ea949549dc24bd67201a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110654
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by re-enabling the code temporarily #if'ed-out in
a528392e71 "Fixed/improved
loplugin:cppunitassertequals" (and which then triggers lots of other
lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings).
For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it
was more straightforward to rewrite them with an explicit call to operator ==
(which silences loplugin:cppunitassertequal) than to adapt them to
CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types.
In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been
implemented trivially for now, but might want to combine that with the
DEBUG_PIVOT_TABLE-only ScDPItemData::Dump.
Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
