...that started to cause false
> In file included from svl/source/items/itemiter.cxx:20:
> include/svl/itemiter.hxx:25:1: error: SfxPoolItem subclass SfxPoolItem declares new fields, but does not override operator== [loplugin:sfxpoolitem]
> class SfxPoolItem;
> ^~~~~~~~~~~~~~~~~
etc. now as a side effect of
<https://github.com/llvm/llvm-project/commit/b6121432da79c4b3d21f191864ff6c583e2e62eb>
"[C++20] Fix a crash with modules."
Change-Id: Ibbf7a7c840ecea2605d6ea76afd04a2c2720e54d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146544
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
"Find classes that derive from css::uno::XAggregation, but which implement
queryInterface in violation of the protocol laid out in the documentation at
udkapi/com/sun/star/uno/XAggregation.idl (which implies that such a class either
doesn't actually make use of the deprecated XAggregation mechanism, which should
thus be removed from that class hierarchy, or that its implementation of
queryInterface needs to be fixed)." (compilerplugins/clang/unoaggregation.cxx)
The basesHaveOnlyPureQueryInterface check in
compilerplugins/clang/unoaggregation.cxx is "a crude approximation (but which
appears to work OK)" to filter out any queryInterface base implementations of
class hierarchies supporting XAggregation (i.e.,
cppu::OWeakAggObject::queryInterface). It only fails for the odd
ChartDocumentWrapper::queryInterface, which manually implements the XAggregation
functionality rather than (indirectly) deriving from OWeakAggObject. But
changing that manual implementation looks tricky, so leave that alone for now
and add a loplugin warning suppression there, and leave proper clean up for
later.
Change-Id: Ib16e26237bd703e60b0d9cb7134cb39840842d54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145912
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
to catch places where we are converting a weak reference to a strong
reference, and then using a pointer to store the result
Change-Id: I69b132907b574e5c6974fadf18bd9658107d3a0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145877
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
drop getSurfaceOffset because both impls just set these to 0, so its
a no opt
Change-Id: Ie4f28d57fb8a170c7a46d3cafceef3e049c26e2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145325
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...after ef53355355 "Rudimentary support for
dynamic_cast on UNO proxy objects" added those
> extern "C" IMAGE_DOS_HEADER const __ImageBase;
Change-Id: I4d9cf2b7617180d66a8527e0e36631f81e0fb18d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145379
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
My clang-cl --with-visual-studio=2022preview build against VS 2022 Preview
17.5.0 Preview 2.0 had started to fail with
> [build CPT] compilerplugins/clang/test/getstr.cxx
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/getstr.cxx Line 42: directly use object of type '{{(rtl::)?}}OString' in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr]
> File compilerplugins/clang/test/getstr.cxx Line 48: directly use object of type 'S' (aka 'rtl::OString') in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr]
> File compilerplugins/clang/test/getstr.cxx Line 49: directly use object of type 'rtl::OString' in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr]
> File compilerplugins/clang/test/getstr.cxx Line 55: directly use object of type 'rtl::OString' in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr]
> File compilerplugins/clang/test/getstr.cxx Line 57: directly use object of type '{{(rtl::)?}}OString' in a call of 'operator <<', instead of calling 'getStr' first [loplugin:getstr]
> 5 errors generated.
apparently because
C:/Program Files/Microsoft Visual Studio/2022/Preview/VC/Tools/MSVC/14.35.32124/include/ostream
now contains
[...]
> _EXPORT_STD extern "C++" template <class _Elem, class _Traits>
> class basic_ostream : virtual public basic_ios<_Elem, _Traits> { // control insertions into a stream buffer
[...]
with a wrapping extern "C++", so the call to StdNamespace() in
> if (!loplugin::TypeCheck(expr->getArg(0)->getType())
> .ClassOrStruct("basic_ostream")
> .StdNamespace()) //TODO: check template args
in compilerplugins/clang/getstr.cxx no longer matched
Change-Id: Iaeb461d5aa855a8602c5c6f791407c08a1c5d309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144735
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 99b5e216f1. It should only
have been necessary after
<https://github.com/llvm/llvm-project/commit/205c0589f918f95d2f2c586a01bea2716d73d603>
"Revert '[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to
std::optional'" dropped the #include <optional> from
clang/include/clang/Lex/PPCallbacks.h, and has been obsoleted by
3d7181caf3444d086be910545047550bac618968 "Adapt to
PPCallbacks::InclusionDirective change in Clang 16 trunk".
Change-Id: I89238a779fdda4c3ba15de93a4e647051e5844b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144594
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Attempt to follow the unfolding debate here, it was std::optional
briefly, but then that was reverted with
commit 205c0589f918f95d2f2c586a01bea2716d73d603
Revert "[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr
to std::optional"
and then a different changed landed with
commit 854c10f8d185286d941307e1033eb492e085c203
Date: Tue Dec 20 00:15:11 2022 +0100
[Clang] Prepare for llvm::Optional becoming std::optional.
Change-Id: I0068960a45695014405437206d8d4565562b0af9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144575
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
home/noel/libo2/compilerplugins/clang/includeform.cxx:33:9: error: no
template named 'optional' in namespace 'std'; did you mean 'Optional'?
std::optional<FileEntryRef> File,
after
commit b5023fa9ab
Date: Mon Dec 19 13:16:29 2022 +0100
Adapt to clang::PPCallbacks::InclusionDirective change in Clang 16
trunk
Change-Id: I7acbfeac4fd138a1f6ae89f8b4b8cf918da04e30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144574
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...when building against recent Clang 16 trunk,
> In file included from compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:30:
> In file included from compilerplugins/clang/cppunitassertequals.cxx:13:
> compilerplugins/clang/compat.hxx:40:14: error: 'value' is deprecated: std::optional::value is throwing. Use *X instead [-Werror,-Wdeprecated-declarations]
> return o.value();
> ^~~~~
> *X
> compilerplugins/clang/pointerbool.cxx:118:52: note: in instantiation of function template specialization 'compat::value<llvm::APSInt>' requested here
> if (compat::has_value(ret) && (compat::value(ret) == 1 || compat::value(ret) == 0))
> ^
> ~/llvm/inst/include/llvm/ADT/Optional.h:273:3: note: 'value' has been explicitly marked deprecated here
> LLVM_DEPRECATED("std::optional::value is throwing. Use *X instead", "*X")
> ^
> ~/llvm/inst/include/llvm/Support/Compiler.h:143:50: note: expanded from macro 'LLVM_DEPRECATED'
> #define LLVM_DEPRECATED(MSG, FIX) __attribute__((deprecated(MSG, FIX)))
> ^
Change-Id: I4320c279a464e52ad608df2a340f62795558a7b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144472
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...when the target type is a reference type and the source and target type have
different cv qualifiers. (And fix the fallout. And make the tests cover that
somewhat more exhaustively; and while at it also test that the plugin can cope
with dynamic_cast to void pointers, which is the only legitimate case where a
dynamic_cast can involve types that are not (pointers or references to)
non-class types.)
Change-Id: Ia568ddb5dbc4a84c275db172791c345d95964857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143133
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
69e9925ded "sdext.pdfimport: resolves tdf#104597:
RTL script text runs are reversed" and f6004e1c45
"tdf#151546: RTL text is reversed (Writer pdfimport)" had introduced two calls
to comphelper::string::reverseString into sdext. That function reverts on the
basis of individual UTF-16 code units, not on the basis of Unicode code points.
And while at least some pre-existing callers of that function want the former
semantics (see below), these two new callers in sdext apparently want the latter
semantics. Therefore, introduce an additional function
comphelper::string::reverseCodePoints with the latter semantics.
I identified three other places that call comphelper::string::reverseString:
* SbRtl_StrReverse in basic/source/runtime/methods1.cxx apparently implements
some StrReverse Basic function, where a (presumably non-existing) Basic spec
would need to decide which of the two semantics is called for. So leave it
alone for now.
* SvtFileDialog::IsolateFilterFromPath_Impl in fpicker/source/office/iodlg.cxx
reverts a string, operates on it, then reverts (parts of) it back. Whether or
not that is the most elegant code, using the latter semantics here would
apparently be wrong, as double invocation of
comphelper::string::reverseCodePoints is not idempotent when the input is a
malformed sequence of UTF-16 code units containing a low surrogate followed by
a high surrogate.
* AccessibleCell::getCellName in svx/source/table/accessiblecell.cxx apparently
always operates on a string consisting only of Latin uppercase letters A--Z,
for which both semantics are equivalent. (So we can just as well stick with
the simpler comphelper::string::reverseString here.)
(Extending the tests in comphelper/qa/string/test_string.cxx ran into an issue
where loplugin:stringliteralvar warns about deliberate uses of sal_Unicode
arrays rather than UTF-16 string literals wrapped in OUStringLiteral, as those
arrays deliberately contain malformed UTF-16 code unit sequences and thus
converting them into UTF-16 string literals might be considered inappropriate,
see the newly added comment at
StringLiteralVar::isPotentiallyInitializedWithMalformedUtf16 in
compilerplugins/clang/stringliteralvar.cxx for details. So that loplugin had to
be improved here, too.)
Change-Id: I641cc32c76b0c5f6339ae44d8aa85df0022ffb05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
"Find occurrences of std::move on const-qualified types. While there might
theoretically be legitimate uses for such (for which this plugin would generate
false positives and would need to be updated), in practice they tend to point at
suspicious code that should be cleaned up in some way."
(All issues found for a Linux build have already been addressed with eleven
recent commits mentioning in their commit messages: "I came across this code
with an upcoming loplugin:constmove that flags suspicious uses of std::move
involving const-qualified types.")
Change-Id: I891a66eb0ec5f9b7d93536bbccea0359893383df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so it's unclear why 2f5f45921b "support
O(U)String::number() for fast string concatenation" added that here.
On the contrary, variables of type OStringNumber can be useful replacements for
calls to std::sprintf (which started to emit deprecation warnings with
macOS 13 SDK now), so this is in preparation for follow-up commits that will
replace many uses of that across the code base with various alternatives.
Change-Id: I6f8508d49dc84773c50f4c33dba38fe08c4c8969
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142318
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after 3d236177be "Deduplicate
O(U)StringConcatenation" changed OStringConcat and OUStringConcat into aliases
(so they will get looked through by loplugin::TypeCheck::Struct's use of
getAs<clang::RecordType> in compilerplugins/clang/check.hxx), but apparently
forgot to drop their respective checks here. (That the then-added check for
StringConcat works as intended is verified by
compilerplugins/clang/test/stringview.cxx, btw.)
Change-Id: I3f8e26998d0a55704f0433a818493ef541fd05eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141370
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after 3d236177be "Deduplicate
O(U)StringConcatenation" changed OStringConcat and OUStringConcat into aliases
(so they can never show up here in a "getUnqualifiedDesugareType"), but
apparently forgot to drop their respective checks here. (That the then-added
check for StringConcat works as intended is verified by
compilerplugins/clang/test/stringadd.cxx, btw.)
Change-Id: I2b589d977dbf2a384348cb7ee62acce30031ccec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141364
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after af2879e434 "Deduplicate stringconcat
more" changed the *StringNumberBase::toAsciiUperCase return typr from
O[U]StringNumber to the underlying StringNumberBase. (And where that commit had
added some odd check for a non-existing "StringNumber" type to
compilerplugins/clang/stringconcatauto.cxx, presumably in error.)
Change-Id: I622e6ae30fcec8f081c978eaf67ffb716a10ee4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where at least my recent Clang 16 trunk build now started to fail after
af2879e434 "Deduplicate stringconcat more" with
> error: 'error' diagnostics expected but not seen:
> File compilerplugins/clang/test/stringview.cxx Line 171 (directive at compilerplugins/clang/test/stringview.cxx:170): instead of an '{{(rtl::)?}}OString' constructed from a 'OStringConcat<rtl::OString, rtl::OString>' (aka 'StringConcat<char, rtl::OString, rtl::OString>'), pass a 'std::string_view' via 'rtl::Concat2View' [loplugin:stringview]
> File compilerplugins/clang/test/stringview.cxx Line 196 (directive at compilerplugins/clang/test/stringview.cxx:195): instead of an '{{(rtl::)?}}OUString' constructed from a 'OUStringConcat<rtl::OUString, rtl::OUString>' (aka 'StringConcat<char16_t, rtl::OUString, rtl::OUString>'), pass a 'std::u16string_view' via 'rtl::Concat2View' [loplugin:stringview]
> error: 'error' diagnostics seen but not expected:
> File compilerplugins/clang/test/stringview.cxx Line 171: instead of an 'OString' constructed from a 'OStringConcat<OString, OString>' (aka 'StringConcat<char, rtl::OString, rtl::OString>'), pass a 'std::string_view' via 'rtl::Concat2View' [loplugin:stringview]
> File compilerplugins/clang/test/stringview.cxx Line 196: instead of an 'OUString' constructed from a 'OUStringConcat<OUString, OUString>' (aka 'StringConcat<char16_t, rtl::OUString, rtl::OUString>'), pass a 'std::u16string_view' via 'rtl::Concat2View' [loplugin:stringview]
> 4 errors generated.
> make[1]: *** [solenv/gbuild/LinkTarget.mk:337: workdir/CxxObject/compilerplugins/clang/test/stringview.o] Error 1
Change-Id: I0b8c7d4a012c40c2c2c3cc8a9e55c52f45e8cfc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141295
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In the process, drop ToStringHelper::allowO(U)StringConcat, because
we can deduce this information from ToStringHelper's addData itself.
To do that, addData was converted to ToStringHelper::operator(),
which allows to use std::is_invocable_v on the helper class.
Change-Id: Ic77878ca0ff65ada8c0a942191bc11de15b9ad2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141254
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Stephan Bergmann