Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

428 lines
13 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*/
#include <cassert>
#include <clang/AST/DeclCXX.h>
#include <clang/AST/DeclTemplate.h>
#include "check.hxx"
#include "compat.hxx"
namespace loplugin {
TypeCheck TypeCheck::NonConst() const {
return !type_.isNull() && !type_.isConstQualified()
? *this : TypeCheck();
// returning TypeCheck(type_.getUnqualifiedType()) instead of *this
// may look tempting, but could remove sugar we might be interested in
// checking for
}
TypeCheck TypeCheck::NonConstVolatile() const {
return
(!type_.isNull() && !type_.isConstQualified()
&& !type_.isVolatileQualified())
? *this : TypeCheck();
// returning TypeCheck(type_.getUnqualifiedType()) instead of *this
// may look tempting, but could remove sugar we might be interested in
// checking for
}
TypeCheck TypeCheck::Const() const {
return
(!type_.isNull() && type_.isConstQualified()
&& !type_.isVolatileQualified())
? *this : TypeCheck();
// returning TypeCheck(type_.getUnqualifiedType()) instead of *this
// may look tempting, but could remove sugar we might be interested in
// checking for
}
TypeCheck TypeCheck::Volatile() const {
return
(!type_.isNull() && !type_.isConstQualified()
&& type_.isVolatileQualified())
? *this : TypeCheck();
// returning TypeCheck(type_.getUnqualifiedType()) instead of *this
// may look tempting, but could remove sugar we might be interested in
// checking for
}
TypeCheck TypeCheck::ConstVolatile() const {
return
(!type_.isNull() && type_.isConstQualified()
&& type_.isVolatileQualified())
? *this : TypeCheck();
// returning TypeCheck(type_.getUnqualifiedType()) instead of *this
// may look tempting, but could remove sugar we might be interested in
// checking for
}
Improved loplugin:staticanonymous -> redundantstatic ...now also covering variables with internal linkage that don't need a redundant "static". (Unlike with functions, with variables there are also cases that are not in an unnamed namespace, hence the rename of the plugin.) All the relevant changes across the code base have been done in the preceding "Upcoming improved loplugin:staticanonymous -> redundantstatic" commits. Ideally the changes would have been done with a rewriting plugin, but it can be quite tedious in general to identify the correct occurrence of "static" that must be removed, consider e.g. struct { int init() { static int n; return n++; } int x = init(); } static const a[10] = {}; However, it turned out that in all cases across the code base, the relevant "static" was either at the start of the declaration or came after an initial "const". So I temporarily changed the plugin with > --- a/compilerplugins/clang/redundantstatic.cxx > +++ b/compilerplugins/clang/redundantstatic.cxx > @@ -59,7 +59,7 @@ class RedundantStatic > } > report( > DiagnosticsEngine::Warning, "redundant 'static' keyword in unnamed namespace", > - decl->getLocation()) > + decl->getBeginLoc()) > << decl->getSourceRange(); > return true; > } > @@ -73,7 +73,7 @@ class RedundantStatic > DiagnosticsEngine::Warning, > "non-inline variable of non-volatile const-qualified type is redundantly marked as" > " 'static'", > - decl->getLocation()) > + decl->getBeginLoc()) > << decl->getSourceRange(); > return true; > } to report the diagnostics at the start of the declarations (instead of at a more natural place which is typically somewhere in the middle of the declaration), compiled LO from within Emacs and then ran a function > (defun doit () > (interactive) > (while t > (next-error) > (with-current-buffer (window-buffer) > (when (re-search-forward > "\\=\\(\\<static\\>\\s *\\|\\(\\<const\\>\\)\\s +\\<static\\>\\)" > nil t) > (replace-match "\\2"))))) to do all the replacements. (Plus solenv/clang-format/reformat-formatted-files where necessary.) Change-Id: Ie7efc8e0593a407c390a6a7a08c81e547410f18a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97779 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-02 21:12:04 +02:00
TypeCheck TypeCheck::ConstNonVolatile() const {
return
(!type_.isNull() && type_.isConstQualified()
&& !type_.isVolatileQualified())
? *this : TypeCheck();
// returning TypeCheck(type_.getUnqualifiedType()) instead of *this
// may look tempting, but could remove sugar we might be interested in
// checking for
}
TerminalCheck TypeCheck::Void() const {
return TerminalCheck(
!type_.isNull()
&& type_->isSpecificBuiltinType(clang::BuiltinType::Void));
}
TerminalCheck TypeCheck::Char() const {
return TerminalCheck(
!type_.isNull()
&& (type_->isSpecificBuiltinType(clang::BuiltinType::Char_S)
|| type_->isSpecificBuiltinType(clang::BuiltinType::Char_U)));
}
TerminalCheck TypeCheck::AnyBoolean() const {
if (type_->isBooleanType()) {
return TerminalCheck(true);
}
auto t = type_->getAs<clang::TypedefType>();
if (t == nullptr) {
return TerminalCheck(false);
}
auto n =t->getDecl()->getName();
return TerminalCheck(
n == "sal_Bool" || n == "BOOL" || n == "Boolean" || n == "FT_Bool"
|| n == "FcBool" || n == "GLboolean" || n == "NPBool" || n == "TW_BOOL"
|| n == "UBool" || n == "boolean" || n == "dbus_bool_t"
|| n == "gboolean" || n == "hb_bool_t" || n == "jboolean" || n == "my_bool");
}
TypeCheck TypeCheck::LvalueReference() const {
if (!type_.isNull()) {
auto const t = type_->getAs<clang::LValueReferenceType>();
if (t != nullptr) {
return TypeCheck(t->getPointeeType());
}
}
return TypeCheck();
}
TypeCheck TypeCheck::RvalueReference() const {
if (!type_.isNull()) {
auto const t = type_->getAs<clang::RValueReferenceType>();
if (t != nullptr) {
return TypeCheck(t->getPointeeType());
}
}
return TypeCheck();
}
TypeCheck TypeCheck::Pointer() const {
if (!type_.isNull()) {
auto const t = type_->getAs<clang::PointerType>();
if (t != nullptr) {
return TypeCheck(t->getPointeeType());
}
}
return TypeCheck();
}
double operator < is not a strict weak ordering due to NaN ...so recent LLVM 19 trunk libc++ in debug mode complained during CppunitTest_chart2_export2 about > ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering at > 5 libsystem_c.dylib 0x0000000183279a40 abort + 180 > 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0 > 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960 > 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268 > 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68 > 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508 > 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528 > 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440 > 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728 > 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692 > 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288 But the introduced use of `std::strong_order(first[0], second[0]) < 0` then triggered a false > lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] > 105 | return std::strong_order(first[0], second[0]) < 0; > | ^ so needed some hack in loplugin:nullptr. And old versions of libc++, still used at least on Android, do not have any implementations of std::strong_order. So detect those cases in configure.ac (checking for std::strong_order for double, which is what is actually being used in the code) and fall back to operator <=> for now, even if that will not provide a strict weak ordering and will thus continue to violate the requirements of std::sort. And then our venerable clang-format 5.0.0 would have broken the token `<=>` into `<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment. Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-07 09:39:27 +01:00
TypeCheck TypeCheck::MemberPointerOf() const {
if (!type_.isNull()) {
auto const t = type_->getAs<clang::MemberPointerType>();
if (t != nullptr) {
return TypeCheck(compat::getClass(t));
double operator < is not a strict weak ordering due to NaN ...so recent LLVM 19 trunk libc++ in debug mode complained during CppunitTest_chart2_export2 about > ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering at > 5 libsystem_c.dylib 0x0000000183279a40 abort + 180 > 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0 > 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960 > 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268 > 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68 > 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508 > 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528 > 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440 > 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728 > 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692 > 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288 But the introduced use of `std::strong_order(first[0], second[0]) < 0` then triggered a false > lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] > 105 | return std::strong_order(first[0], second[0]) < 0; > | ^ so needed some hack in loplugin:nullptr. And old versions of libc++, still used at least on Android, do not have any implementations of std::strong_order. So detect those cases in configure.ac (checking for std::strong_order for double, which is what is actually being used in the code) and fall back to operator <=> for now, even if that will not provide a strict weak ordering and will thus continue to violate the requirements of std::sort. And then our venerable clang-format 5.0.0 would have broken the token `<=>` into `<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment. Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-07 09:39:27 +01:00
}
}
return TypeCheck();
}
TerminalCheck TypeCheck::Enum() const {
if (!type_.isNull()) {
auto const t = type_->getAs<clang::EnumType>();
if (t != nullptr) {
return TerminalCheck(true);
}
}
return TerminalCheck(false);
}
TypeCheck TypeCheck::Typedef() const {
if (!type_.isNull()) {
if (auto const t = type_->getAs<clang::TypedefType>()) {
return TypeCheck(t->desugar());
}
}
return TypeCheck();
}
DeclCheck TypeCheck::TemplateSpecializationClass() const {
if (!type_.isNull()) {
if (auto const t = type_->getAs<clang::TemplateSpecializationType>()) {
if (!t->isTypeAlias()) {
if (auto const d = llvm::dyn_cast_or_null<clang::ClassTemplateDecl>(
t->getTemplateName().getAsTemplateDecl()))
{
return DeclCheck(d->getTemplatedDecl());
}
}
}
}
return DeclCheck();
}
TypeCheck TypeCheck::NotSubstTemplateTypeParmType() const {
return
(!type_.isNull()
&& type_->getAs<clang::SubstTemplateTypeParmType>() == nullptr)
? *this : TypeCheck();
}
ContextCheck DeclCheck::Operator(clang::OverloadedOperatorKind op) const {
assert(op != clang::OO_None);
auto f = llvm::dyn_cast_or_null<clang::FunctionDecl>(decl_);
return ContextCheck(
f != nullptr && f->getOverloadedOperator() == op
? f->getDeclContext() : nullptr);
}
ContextCheck DeclCheck::MemberFunction() const {
auto m = llvm::dyn_cast_or_null<clang::CXXMethodDecl>(decl_);
return ContextCheck(m == nullptr ? nullptr : m->getParent());
}
namespace {
bool isGlobalNamespace(clang::DeclContext const * context) {
assert(context != nullptr);
return context->getEnclosingNamespaceContext()->isTranslationUnit();
}
}
TerminalCheck ContextCheck::GlobalNamespace() const {
return TerminalCheck(context_ != nullptr && isGlobalNamespace(context_));
}
TerminalCheck ContextCheck::StdNamespace() const {
return TerminalCheck(
Make namespace checks look through LinkageSpecs 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>
2022-12-22 09:33:05 +01:00
context_ != nullptr && lookThroughLinkageSpec()->isStdNamespace());
}
namespace {
bool isStdOrNestedNamespace(clang::DeclContext const * context) {
assert(context != nullptr);
if (!context->isNamespace()) {
return false;
}
if (isGlobalNamespace(context)) {
return false;
}
if (context->isStdNamespace()) {
return true;
}
return isStdOrNestedNamespace(context->getParent());
}
}
TerminalCheck ContextCheck::StdOrNestedNamespace() const {
Make namespace checks look through LinkageSpecs 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>
2022-12-22 09:33:05 +01:00
return TerminalCheck(context_ != nullptr && isStdOrNestedNamespace(lookThroughLinkageSpec()));
}
ContextCheck ContextCheck::AnonymousNamespace() const {
Make namespace checks look through LinkageSpecs 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>
2022-12-22 09:33:05 +01:00
auto n = llvm::dyn_cast_or_null<clang::NamespaceDecl>(lookThroughLinkageSpec());
return ContextCheck(
n != nullptr && n->isAnonymousNamespace() ? n->getParent() : nullptr);
}
Make namespace checks look through LinkageSpecs 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>
2022-12-22 09:33:05 +01:00
clang::DeclContext const * ContextCheck::lookThroughLinkageSpec() const {
if (context_ != nullptr && context_->getDeclKind() == clang::Decl::LinkageSpec) {
return context_->getParent();
}
return context_;
}
namespace {
bool BaseCheckNotSomethingInterestingSubclass(const clang::CXXRecordDecl *BaseDefinition) {
if (BaseDefinition) {
auto tc = TypeCheck(BaseDefinition);
if (tc.Class("Dialog").GlobalNamespace() || tc.Class("SfxPoolItem").GlobalNamespace()) {
return false;
}
}
return true;
}
bool isDerivedFromSomethingInteresting(const clang::CXXRecordDecl *decl) {
if (!decl)
return false;
auto tc = TypeCheck(decl);
if (tc.Class("Dialog"))
return true;
if (tc.Class("SfxPoolItem"))
return true;
if (!decl->hasDefinition()) {
return false;
}
if (// not sure what hasAnyDependentBases() does,
// but it avoids classes we don't want, e.g. WeakAggComponentImplHelper1
!decl->hasAnyDependentBases() &&
!decl->forallBases(BaseCheckNotSomethingInterestingSubclass)) {
return true;
}
return false;
}
}
bool isExtraWarnUnusedType(clang::QualType type) {
auto const rec = type->getAsCXXRecordDecl();
if (rec == nullptr) {
return false;
}
auto const tc = TypeCheck(rec);
// Check some common non-LO types:
if (tc.Class("basic_string").StdNamespace()
|| tc.Class("deque").StdNamespace()
|| tc.Class("list").StdNamespace()
|| tc.Class("map").StdNamespace()
|| tc.Class("pair").StdNamespace()
|| tc.Class("queue").StdNamespace()
|| tc.Class("set").StdNamespace()
|| tc.Class("stack").StdNamespace()
|| tc.Class("unordered_map").StdNamespace()
|| tc.Class("unordered_set").StdNamespace()
|| tc.Class("vector").StdNamespace())
{
return true;
}
return isDerivedFromSomethingInteresting(rec);
}
namespace {
// Make sure Foo and ::Foo are considered equal:
bool areSameSugaredType(clang::QualType type1, clang::QualType type2) {
auto t1 = type1.getLocalUnqualifiedType();
if (auto const et = llvm::dyn_cast<clang::ElaboratedType>(t1)) {
t1 = et->getNamedType();
}
auto t2 = type2.getLocalUnqualifiedType();
if (auto const et = llvm::dyn_cast<clang::ElaboratedType>(t2)) {
t2 = et->getNamedType();
}
return t1 == t2;
}
bool isArithmeticOp(clang::Expr const * expr) {
expr = expr->IgnoreParenImpCasts();
if (auto const e = llvm::dyn_cast<clang::BinaryOperator>(expr)) {
switch (e->getOpcode()) {
case clang::BO_Mul:
case clang::BO_Div:
case clang::BO_Rem:
case clang::BO_Add:
case clang::BO_Sub:
case clang::BO_Shl:
case clang::BO_Shr:
case clang::BO_And:
case clang::BO_Xor:
case clang::BO_Or:
return true;
case clang::BO_Comma:
return isArithmeticOp(e->getRHS());
default:
return false;
}
}
return llvm::isa<clang::UnaryOperator>(expr)
|| llvm::isa<clang::AbstractConditionalOperator>(expr);
}
}
bool isOkToRemoveArithmeticCast(
clang::ASTContext & context, clang::QualType t1, clang::QualType t2, const clang::Expr* subExpr)
{
// Don't warn if the types are arithmetic (in the C++ meaning), and: either
// at least one is a typedef or decltype (and if both are, they're different),
// or the sub-expression involves some operation that is likely to change
// types through promotion, or the sub-expression is an integer literal (so
// its type generally depends on its value and suffix if any---even with a
// suffix like L it could still be either long or long long):
if ((t1->isIntegralType(context)
|| t1->isRealFloatingType())
&& ((!areSameSugaredType(t1, t2)
&& (loplugin::TypeCheck(t1).Typedef()
|| loplugin::TypeCheck(t2).Typedef()
|| llvm::isa<clang::DecltypeType>(t1) || llvm::isa<clang::DecltypeType>(t2)))
|| isArithmeticOp(subExpr)
|| llvm::isa<clang::IntegerLiteral>(subExpr->IgnoreParenImpCasts())))
{
return false;
}
return true;
}
Fix implementation of loplugin::isDerivedFrom ...where clang::CXXRecordDecl::forallBases is documented as: "This routine returns false if the class has non-computable base classes." So, presumably since <https://github.com/llvm/llvm-project/commit/bf099f4682bf088aaa49b2c72fb1ef3250213fbb> "[llvm][ADT] Structured bindings for move-only types in `StringMap` (#114676)" changed > -template <std::size_t I, typename ValueTy> > -struct tuple_element<I, llvm::StringMapEntry<ValueTy>> > - : std::conditional<I == 0, llvm::StringRef, ValueTy> {}; > +template <std::size_t Index, typename ValueTy> > +struct std::tuple_element<Index, llvm::StringMapEntry<ValueTy>> > + : std::tuple_element<Index, std::pair<llvm::StringRef, ValueTy>> {}; in LLVM's llvm/include/llvm/ADT/StringMapEntry.h, our !forallBases check here started to trivially always be true for that struct tuple_element specialization, so the isDerivedFrom check in CheckFileVisitor::VisitCXXRecordDecl in compilerplugins/clang/sharedvisitor/analyzer.cxx started to erroneously be true for that struct, so it started to generate compilerplugins/clang/sharedvisitor/*.plugininfo files with bogus extra > InfoVersion:1 > ClassName:tuple_element > InfoEnd content, which in turn caused the generated compilerplugins/clang/sharedvisitor/sharedvisitor.cxx to contain lots of > #include "tuple_element.cxx" and other nonsense, which caused the build to break with > [CXX] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx > lo/core/compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:20:10: fatal error: 'tuple_element.cxx' file not found > 20 | #include "tuple_element.cxx" > | ^~~~~~~~~~~~~~~~~~~ etc. (And now spelling out the implementation of forAnyBase here also reveals that BaseCheckSubclass will never be called with a null BaseDefinition, so the code handling that has been removed.) Change-Id: I8a6e42260eae86852ec37a80d058777653fac394 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176042 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-11-05 08:37:12 +01:00
static bool BaseCheckSubclass(const clang::CXXRecordDecl *BaseDefinition, void *p) {
assert(BaseDefinition != nullptr);
auto const & base = *static_cast<const DeclChecker *>(p);
if (base(BaseDefinition)) {
Fix implementation of loplugin::isDerivedFrom ...where clang::CXXRecordDecl::forallBases is documented as: "This routine returns false if the class has non-computable base classes." So, presumably since <https://github.com/llvm/llvm-project/commit/bf099f4682bf088aaa49b2c72fb1ef3250213fbb> "[llvm][ADT] Structured bindings for move-only types in `StringMap` (#114676)" changed > -template <std::size_t I, typename ValueTy> > -struct tuple_element<I, llvm::StringMapEntry<ValueTy>> > - : std::conditional<I == 0, llvm::StringRef, ValueTy> {}; > +template <std::size_t Index, typename ValueTy> > +struct std::tuple_element<Index, llvm::StringMapEntry<ValueTy>> > + : std::tuple_element<Index, std::pair<llvm::StringRef, ValueTy>> {}; in LLVM's llvm/include/llvm/ADT/StringMapEntry.h, our !forallBases check here started to trivially always be true for that struct tuple_element specialization, so the isDerivedFrom check in CheckFileVisitor::VisitCXXRecordDecl in compilerplugins/clang/sharedvisitor/analyzer.cxx started to erroneously be true for that struct, so it started to generate compilerplugins/clang/sharedvisitor/*.plugininfo files with bogus extra > InfoVersion:1 > ClassName:tuple_element > InfoEnd content, which in turn caused the generated compilerplugins/clang/sharedvisitor/sharedvisitor.cxx to contain lots of > #include "tuple_element.cxx" and other nonsense, which caused the build to break with > [CXX] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx > lo/core/compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:20:10: fatal error: 'tuple_element.cxx' file not found > 20 | #include "tuple_element.cxx" > | ^~~~~~~~~~~~~~~~~~~ etc. (And now spelling out the implementation of forAnyBase here also reveals that BaseCheckSubclass will never be called with a null BaseDefinition, so the code handling that has been removed.) Change-Id: I8a6e42260eae86852ec37a80d058777653fac394 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176042 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-11-05 08:37:12 +01:00
return true;
}
Fix implementation of loplugin::isDerivedFrom ...where clang::CXXRecordDecl::forallBases is documented as: "This routine returns false if the class has non-computable base classes." So, presumably since <https://github.com/llvm/llvm-project/commit/bf099f4682bf088aaa49b2c72fb1ef3250213fbb> "[llvm][ADT] Structured bindings for move-only types in `StringMap` (#114676)" changed > -template <std::size_t I, typename ValueTy> > -struct tuple_element<I, llvm::StringMapEntry<ValueTy>> > - : std::conditional<I == 0, llvm::StringRef, ValueTy> {}; > +template <std::size_t Index, typename ValueTy> > +struct std::tuple_element<Index, llvm::StringMapEntry<ValueTy>> > + : std::tuple_element<Index, std::pair<llvm::StringRef, ValueTy>> {}; in LLVM's llvm/include/llvm/ADT/StringMapEntry.h, our !forallBases check here started to trivially always be true for that struct tuple_element specialization, so the isDerivedFrom check in CheckFileVisitor::VisitCXXRecordDecl in compilerplugins/clang/sharedvisitor/analyzer.cxx started to erroneously be true for that struct, so it started to generate compilerplugins/clang/sharedvisitor/*.plugininfo files with bogus extra > InfoVersion:1 > ClassName:tuple_element > InfoEnd content, which in turn caused the generated compilerplugins/clang/sharedvisitor/sharedvisitor.cxx to contain lots of > #include "tuple_element.cxx" and other nonsense, which caused the build to break with > [CXX] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx > lo/core/compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:20:10: fatal error: 'tuple_element.cxx' file not found > 20 | #include "tuple_element.cxx" > | ^~~~~~~~~~~~~~~~~~~ etc. (And now spelling out the implementation of forAnyBase here also reveals that BaseCheckSubclass will never be called with a null BaseDefinition, so the code handling that has been removed.) Change-Id: I8a6e42260eae86852ec37a80d058777653fac394 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176042 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-11-05 08:37:12 +01:00
return false;
}
bool forAnyBase(
clang::CXXRecordDecl const * decl, clang::CXXRecordDecl::ForallBasesCallback matches)
{
// Based on the implementation of clang::CXXRecordDecl::forallBases in LLVM's
// clang/lib/AST/CXXInheritance.cpp:
for (auto const & i: decl->bases()) {
auto const t = i.getType()->getAs<clang::RecordType>();
if (t == nullptr) {
return false;
}
auto const b = llvm::cast_or_null<clang::CXXRecordDecl>(t->getDecl()->getDefinition());
if (b == nullptr || (b->isDependentContext() && !b->isCurrentInstantiation(decl))) {
return false;
}
if (matches(b) || forAnyBase(b, matches)) {
return true;
}
}
return false;
}
bool isDerivedFrom(const clang::CXXRecordDecl *decl, DeclChecker base, bool checkSelf) {
if (!decl)
return false;
if (checkSelf && base(decl))
return true;
if (!decl->hasDefinition()) {
return false;
}
Fix implementation of loplugin::isDerivedFrom ...where clang::CXXRecordDecl::forallBases is documented as: "This routine returns false if the class has non-computable base classes." So, presumably since <https://github.com/llvm/llvm-project/commit/bf099f4682bf088aaa49b2c72fb1ef3250213fbb> "[llvm][ADT] Structured bindings for move-only types in `StringMap` (#114676)" changed > -template <std::size_t I, typename ValueTy> > -struct tuple_element<I, llvm::StringMapEntry<ValueTy>> > - : std::conditional<I == 0, llvm::StringRef, ValueTy> {}; > +template <std::size_t Index, typename ValueTy> > +struct std::tuple_element<Index, llvm::StringMapEntry<ValueTy>> > + : std::tuple_element<Index, std::pair<llvm::StringRef, ValueTy>> {}; in LLVM's llvm/include/llvm/ADT/StringMapEntry.h, our !forallBases check here started to trivially always be true for that struct tuple_element specialization, so the isDerivedFrom check in CheckFileVisitor::VisitCXXRecordDecl in compilerplugins/clang/sharedvisitor/analyzer.cxx started to erroneously be true for that struct, so it started to generate compilerplugins/clang/sharedvisitor/*.plugininfo files with bogus extra > InfoVersion:1 > ClassName:tuple_element > InfoEnd content, which in turn caused the generated compilerplugins/clang/sharedvisitor/sharedvisitor.cxx to contain lots of > #include "tuple_element.cxx" and other nonsense, which caused the build to break with > [CXX] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx > lo/core/compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:20:10: fatal error: 'tuple_element.cxx' file not found > 20 | #include "tuple_element.cxx" > | ^~~~~~~~~~~~~~~~~~~ etc. (And now spelling out the implementation of forAnyBase here also reveals that BaseCheckSubclass will never be called with a null BaseDefinition, so the code handling that has been removed.) Change-Id: I8a6e42260eae86852ec37a80d058777653fac394 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176042 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-11-05 08:37:12 +01:00
if (forAnyBase(decl,
[&base](const clang::CXXRecordDecl *BaseDefinition) -> bool
Fix implementation of loplugin::isDerivedFrom ...where clang::CXXRecordDecl::forallBases is documented as: "This routine returns false if the class has non-computable base classes." So, presumably since <https://github.com/llvm/llvm-project/commit/bf099f4682bf088aaa49b2c72fb1ef3250213fbb> "[llvm][ADT] Structured bindings for move-only types in `StringMap` (#114676)" changed > -template <std::size_t I, typename ValueTy> > -struct tuple_element<I, llvm::StringMapEntry<ValueTy>> > - : std::conditional<I == 0, llvm::StringRef, ValueTy> {}; > +template <std::size_t Index, typename ValueTy> > +struct std::tuple_element<Index, llvm::StringMapEntry<ValueTy>> > + : std::tuple_element<Index, std::pair<llvm::StringRef, ValueTy>> {}; in LLVM's llvm/include/llvm/ADT/StringMapEntry.h, our !forallBases check here started to trivially always be true for that struct tuple_element specialization, so the isDerivedFrom check in CheckFileVisitor::VisitCXXRecordDecl in compilerplugins/clang/sharedvisitor/analyzer.cxx started to erroneously be true for that struct, so it started to generate compilerplugins/clang/sharedvisitor/*.plugininfo files with bogus extra > InfoVersion:1 > ClassName:tuple_element > InfoEnd content, which in turn caused the generated compilerplugins/clang/sharedvisitor/sharedvisitor.cxx to contain lots of > #include "tuple_element.cxx" and other nonsense, which caused the build to break with > [CXX] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx > lo/core/compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:20:10: fatal error: 'tuple_element.cxx' file not found > 20 | #include "tuple_element.cxx" > | ^~~~~~~~~~~~~~~~~~~ etc. (And now spelling out the implementation of forAnyBase here also reveals that BaseCheckSubclass will never be called with a null BaseDefinition, so the code handling that has been removed.) Change-Id: I8a6e42260eae86852ec37a80d058777653fac394 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176042 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-11-05 08:37:12 +01:00
{ return BaseCheckSubclass(BaseDefinition, &base); }))
{
return true;
}
return false;
}
}
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */