summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/implicitboolconversion.cxx
AgeCommit message (Collapse)Author
2023-03-16Adapt loplugin:implicitboolconversion to _G_STR_NONNULLStephan Bergmann
...from glib2-devel-2.76.0-1.fc38.x86_64, causing > libreofficekit/source/gtk/lokdocview.cxx:390:28: error: implicit conversion (IntegralCast) from 'bool' to 'int' [loplugin:implicitboolconversion] > pLOEvent->m_pCommand = g_strdup(pCommand); > ^~~~~~~~~~~~~~~~~~ > /usr/include/glib-2.0/glib/gstrfuncs.h:212:35: note: expanded from macro 'g_strdup' > const char *const __str = _G_STR_NONNULL (___str); \ > ^~~~~~~~~~~~~~~~~~~~~~~ > /usr/include/glib-2.0/glib/gstrfuncs.h:157:34: note: expanded from macro '_G_STR_NONNULL' > #define _G_STR_NONNULL(x) ((x) + !(x)) > ^~~~ Change-Id: Iec20b20992a61fd48155f338a10dc313411448f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148948 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-26Adapt compilerplugins to recent Clang 16 trunk changeStephan Bergmann
<https://github.com/llvm/llvm-project/commit/1acffe81ee9117691812b9bf8747c03354177d15> "NFC: [clang] Template argument cleanups." Change-Id: I84bc276c21efcc11643ae7003e0fee6c7592130f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141860 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-18Adapt compilerplugins to recent Clang 16 trunk changeStephan Bergmann
<https://github.com/llvm/llvm-project/commit/bcd9ba2b7e64f6ce54defd2fa73fc8e0fee5707c> "[clang] Track the templated entity in type substitution." Change-Id: I314d1567512dc0332b3c61c95978b0230f52b274 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141462 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-15Introduce rtl::createUriCharClassStephan Bergmann
...to make those char class array initializations more readable. (Making the corresponding variables constexpr is mostly done so that failures in the provided `unencoded` arguments, like non-ASCII characters or duplicate character typos, would lead to compile-time errors also for !HAVE_CPP_CONSTEVAL. And assigning to a sal_Bool std::array needs another hack to avoid false loplugin:implicitboolconversion warnings.) Change-Id: Ieb8827f69f55f1212a9428817d5331fcb18ef1d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133058 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-14Use DeclCheck at one place in loplugin:implicitboolconversionStephan Bergmann
...and add tests for those additions to isBoolExpr done in 8e4d82cd1125502c26ddaaa85c49c4aa44f65811 "loplugin:implicitboolconversion: warn about conversions to unsigned char" (and which were added to avoid false warnings like > testtools/source/bridgetest/bridgetest.cxx:643:21: error: implicit conversion (IntegralToBoolean) of call argument from 'unsigned char' to 'bool' [loplugin:implicitboolconversion] > (xLBT->transportPolyBoolean( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ and > cui/source/options/optaboutconfig.cxx:359:62: error: implicit conversion (IntegralToBoolean) of call argument from 'unsigned char' to 'bool' [loplugin:implicitboolconversion] > sValue.append(OUString::boolean( seq[j] )); > ^~~~~~ ) Change-Id: I0683144e1c39d31303faf678afaafd708ef7ff79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133018 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-17Bump compiler plugins Clang baseline to 12.0.1Stephan Bergmann
...as discussed in the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2020-November/086234.html> "Bump --enable-compiler-plugins Clang baseline?" (and now picked up again at <https://lists.freedesktop.org/archives/libreoffice/2022-February/088459.html> "Re: Bump --enable-compiler-plugins Clang baseline?"), and clean up compilerplugins/clang/ accordingly Change-Id: I5e81c6fdcc363aeefd6227606225b526fdf7ac16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129989 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-02Tweak loplugin:implicitboolconversion to allow some more bool -> sal_BoolStephan Bergmann
...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 <https://github.com/llvm/llvm-project/commit/0a42fe70a566f22599e04a6f1344ca2dc5565e17> "[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>
2021-06-16Move enable_if from dummy template parameter to return typeStephan Bergmann
...and drop the no-longer necessary loplugin:implicitboolconversion exclusion (which had been necessary to avoid > [CXX] vcl/source/window/dockingarea.cxx > In file included from vcl/source/window/dockingarea.cxx:26: > In file included from vcl/inc/svdata.hxx:26: > include/o3tl/hash_combine.hxx:14:78: error: implicit conversion (Dependent) from 'bool' to 'std::enable_if_t<(sizeof(N) == 4), bool>' (aka 'typename enable_if<(sizeof(N) == 4), bool>::type') [loplugin:implicitboolconversion] > template <typename T, typename N, std::enable_if_t<(sizeof(N) == 4), bool> = false> > ^~~~~ etc.) Change-Id: If764365213cf29f7dec6fdd6a773dc9894dd15bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117330 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-11loplugin:implicitboolconversion workaroundNoel Grandin
after commit eb6819e74a66750235d3a4a894479faeee8146e2 Date: Sat May 1 22:13:37 2021 +0900 change usage of boost::hash_combine to o3tl::hash_combine Change-Id: Idc70726f7e762b49111e6505ba3f978370d7cf7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115399 Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2020-10-15Fix checks for "older than Clang 11"Stephan Bergmann
...following up on b6d0ca04581eae01817aac18d32a312bc9a2d514 "The Clang RecursiveASTVisitor change is already in Clang 11"; no longer sure why I originally wrote the checks using <= rather than < in 5d546de67b44dec23ecfa5a6378e2968912f8253 "Adapt to Clang 12 trunk RecursiveASTVisitor change" Change-Id: I79877e21823334c939ecdf9c64e4efe5e0b1571b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104349 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-14The Clang RecursiveASTVisitor change is already in Clang 11Stephan Bergmann
...see 5d546de67b44dec23ecfa5a6378e2968912f8253 "Adapt to Clang 12 trunk RecursiveASTVisitor change"; no longer sure why I thought <https://github.com/ llvm/llvm-project/commit/5689b38c6a4220cc5f6ba68a56486229b10071bf> "Removed a RecursiveASTVisitor feature to visit operator kinds with different methods" would not be included in the release/11.x branch Change-Id: I1e206368c447b74cc6adec4c1d4790c80f0cb744 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104309 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-19Adapt to Clang 12 trunk RecursiveASTVisitor changeStephan Bergmann
<https://github.com/llvm/llvm-project/commit/ 5689b38c6a4220cc5f6ba68a56486229b10071bf> "Removed a RecursiveASTVisitor feature to visit operator kinds with different methods". That change is incompatible in that before the change individual TraverseUnary* and TraverseBin* functions were called, while now TraverseUnaryOperator and TraverseBinaryOperator/TraverseCompoundAssignOperator are called for all the different operators. Fixed that with a few #if for the non-shared plugins, but that doesn't work for the shared plugin. So made the two affected plugins non- shared for now and left a better fix as a TODO. Change-Id: I5b87d329ae2c4c93bf605bb1ecc9641039f014a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99000 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-26Adapt to clang::MaterializeTemporaryExpr::GetTemparyExpr renameStephan Bergmann
...in <https://github.com/llvm/llvm-project/commit/ b0561b3346e7bf0ae974995ca95b917eebde18e1> "[NFC] Refactor representation of materialized temporaries" Change-Id: I02fbf6765f9713e4d457f07521129cc9d8db5751 Reviewed-on: https://gerrit.libreoffice.org/83669 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-26loplugin:implicitboolconversion: Filter out bool -> std::atomic<bool>Stephan Bergmann
...as used since patch set 8 of <https://gerrit.libreoffice.org/#/c/81542/8> "WIP: tdf#120006 New Document converter" Change-Id: I79c2237a2e5839162272c0d49bdb4d87c9e35102 Reviewed-on: https://gerrit.libreoffice.org/83655 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-18Missing includesStephan Bergmann
...with recent Clang trunk Change-Id: I9ea0f1692df8d269356df0d6b20ea2173f632425 Reviewed-on: https://gerrit.libreoffice.org/83086 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-07fix various warnings in compilerpluginsLuboš Luňák
These are triggered when using llvm-config --cxxflags for building, and sometimes there's -Werror. The warnings were mostly unused variables because of being used only in assert(), or default case in switch that covers all enums (it's better to not handle default to get warning if a case is not handled). Change-Id: I0ecdd1f27390aadf033852b0d1ee0ca424ae3c37 Reviewed-on: https://gerrit.libreoffice.org/80317 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2018-11-30Make some loplugin:implicitboolconversion code use TypeCheckStephan Bergmann
Change-Id: If675d629784894573085122beadc6abc3e67f457 Reviewed-on: https://gerrit.libreoffice.org/64335 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-10-01implicitboolconversion: ignore quint64 bitfieldJan-Marek Glogowski
Change-Id: I97380455b9f526b75c7d3855d188d2f659035ba2 Reviewed-on: https://gerrit.libreoffice.org/61170 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-09-08Replace find_if with proper quantifier algorithmsArkadiy Illarionov
Missed in 085269d25a705b656436feac47149296b4b4b35d Change-Id: I3cfab57232908b48d090658e0fbc948d62b3fc6f Reviewed-on: https://gerrit.libreoffice.org/60180 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-14filter out some of the AST in the pluginsNoel Grandin
by checking if the current namespace decl is in our code, so we have to scan less stuff, which results in a 10% perf improvement for me Change-Id: Idf0e30d57b6d0dcd13daa9ed679c28b9d233d387 Reviewed-on: https://gerrit.libreoffice.org/58942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-10Avoid -Werror=deprecated-declarations with recent Clang trunkStephan Bergmann
...which first added alternative names to and then deprecated getLocBegin/End Change-Id: Iaefb8ce259057abfa6cd20f0b63c0ef2949a96b2 Reviewed-on: https://gerrit.libreoffice.org/58820 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-19Bump --enable-compiler-plugins to Clang 3.8.0Stephan Bergmann
<https://lists.freedesktop.org/archives/libreoffice/2017-December/079107.html> "Clang baseline bump" Change-Id: I18fca8794ea34118fc6308458064d0c28cf5caf7 Reviewed-on: https://gerrit.libreoffice.org/46557 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-15Try even harder to get at template args in loplugin:implicitboolconversionStephan Bergmann
After f82dc45bdb9e930878447015291c5b90c9325b57 "Use the canonical TemplateDecl", builds on macOS (at least those using C++17 and recent trunk libc++) started to emit false warnings for that std::pair< Reference<XConnection>,sal_Bool> aRet; aRet.second = false; code in dbaccess/source/ui/dlg/DbAdminImpl.cxx. There's a declaration of std::pair in type_traits and a definition in utility, and for some reason the declaration in type_traits was deemed the canonical one, while the SubstTemplateTypeParmType pointed at the definition in utility. So just check both, the original and the canonical TemplateDecl. Change-Id: I2fb9d5172c031e6ad4989b215f19d11a4b17f743 Reviewed-on: https://gerrit.libreoffice.org/46474 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-25Use the canonical TemplateDeclStephan Bergmann
...in case there are multiple, as is the case at least with recent (towards GCC 8) libstdc++, where std::pair is forward-declared also in include/c++/8.0.0/bits/stl_iterator.h, so that in dbaccess/source/ui/dlg/DbAdminImpl.cxx std::pair< Reference<XConnection>,sal_Bool> aRet; aRet.second = false; failed to reconstruct the sal_Bool template argument and issued a loplugin:implicitboolconversion warning. Change-Id: I0054f2596d3f8837b857f1dca2f25952828b12cc Reviewed-on: https://gerrit.libreoffice.org/45254 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-07Clean away temporarily added using declarationsStephan Bergmann
Change-Id: I26734c13515394162d88351a1cbe2b20abdac865
2017-10-26Make loplugin:implicitboolconversion find the same in C++17 and pre-C++17Stephan Bergmann
...see a2d814ac1d7beb6fbe4b9cb7b75814f4b08b8e59 "loplugin:implicitboolconversion" and 24eeb4d286471e4a2103c15efc624a565112ca32 "loplugin:implicitboolconversion" for things previously only found in C++17. As expected, no further occurrences were found. Change-Id: Id0ab621b82dc3c40c8b5801413fceb73ade1408a
2017-10-26Use compat::getSubExprAsWritten; clean upStephan Bergmann
Change-Id: I8f984c3b3833437f6b4d65ab99da608a6868ff74
2017-09-11More clang::*Type vs. llvm::*Type ambiguitiesStephan Bergmann
Change-Id: I21133976793ab018c633dda077029666308526db
2016-12-22Also don't warn for plain C codeStephan Bergmann
...as needed by clang-cl for bean/native/win32/com_sun_star_comp_beans_LocalOfficeWindow.c Change-Id: I862afb6b549015d951a898ee415370540ffab1f6
2016-06-29Remove support for Clang < 3.3Stephan Bergmann
Change-Id: I185852a738bac10dc6d331afccfcbc7ae1225cb1
2016-06-28More Clang 3.4 "(anonymous namespace)" fixesStephan Bergmann
Change-Id: I7cb43f915565dadd611b90ee30373e472f97efb5 Reviewed-on: https://gerrit.libreoffice.org/26748 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-06-28Adapt to Clang 3.4 (in preparation of a buildbot on CentOS 7)Stephan Bergmann
Change-Id: Ie2859f03b31c57deb7fd0deba3285f782e33b239
2016-06-19loplugin:salbool: Implicit conversions from non-Boolean fundamental typesStephan Bergmann
Change-Id: I67eac95686678e6f5a2d60798535b2c65a9ba5d7
2016-04-27cppcheck: silence warnings in compilerpluginsJochen Nitschke
mostly missing explicit before ctors and uninitialized member vars one odd use of std::find > compilerplugins/clang/implicitboolconversion.cxx > 800 stlIfFind warning Suspicious condition. > The result of find() is an iterator, but it is not properly checked. Change-Id: Iade53494cd7fe8ddb0e110e431449ae5a517fe3b Reviewed-on: https://gerrit.libreoffice.org/24398 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-04-21Use Sequence ctor taking initializer_listStephan Bergmann
needed adapting loplugin:implicitboolconversion to not warn about Sequence<sal_Bool> arBool({true, false, true}); Change-Id: I971918aab7c958ef8f1e4e0548a84314e95f8325
2016-04-20Use cast to bool to normalize sal_Bool valuesStephan Bergmann
Change-Id: I8a886f752d2a16ec4c10656bcd0b3631647971b2
2016-02-26These version checks are about the Clang the plugins are built /against/Stephan Bergmann
...not the (Clang) compiler they are being built /with/. (Also simplifies the checking #if code.) Change-Id: I416321be4ef4478785be40571f81500fd3b6feb8
2016-01-05Adapt loplugin:implicitboolconversion to changes in Clang trunk towards 3.8Stephan Bergmann
Change-Id: I7841eee5b66a118c52258c0226d73a1139a0df9a
2015-11-02tdf#94269: Replace "n" prefix for bool variables with "b"Benjamin Ni
Change-Id: I178545792c7354a362658ac7ef8b1d4cf0865797 Signed-off-by: Michael Stahl <mstahl@redhat.com>
2015-08-04Adapt to current Clang trunk towards 3.7Stephan Bergmann
Change-Id: Ibb2c641d49a1773be789c9259f53a040db6f605f
2015-05-11Suppress loplugin:implicitboolconversion warnings in Objective-C codeStephan Bergmann
...(but not Objective-C++ code) where BOOL (aka unsigned char) expressions are routinely implicitly converted to int per the C rules, e.g., as operands of &&. Change-Id: I17e5dae9f065aaa814850196b1ef31f8fb07c99b
2015-05-08lopluign:implicitboolconversion: warn about conversion from sal_Bool etc., tooStephan Bergmann
Change-Id: I5bc23a2b599742c579ad82c1b1f68df130ac426b
2015-04-23Mac OS X ctype.h isdigit is not extern "C"Stephan Bergmann
Change-Id: Ied43178bacc020b848ee3196080713e08c780133
2015-04-23Improve loplugin:implicitboolconversion cond. expr. handlingStephan Bergmann
...so that ... ? isdigit(...) : true will not trigger a warning (where isdigit is the standard C function returning int). (Odd code like that will fall out of the improved loplugin:literaltoboolconversion rewriter shortly.) Change-Id: If51402bd5f4b3f8b0630e874988f4b836ae246f8
2015-04-17loplugin:implicitboolconversion: warn about conversions to unsigned charStephan Bergmann
...while avoiding warnings about conversions to bool-like typedefs (sal_Bool etc.), also in cases where those typedefs are used as type arguments of template specializations (which is no little feat, and the current code is only an approximation of it, one that appears to cover the relevant cases in our code base though). Change-Id: I0ed3801aec7787bf38b429b66e25244ec00cac9b
2014-06-17Fix logic to obtain callee's FunctionProtoType (if any)Stephan Bergmann
Change-Id: I1bfdd865429cc6fa89ea3b6b4fc132b5d5b57b0d
2014-02-24implicitboolconversion: warn about implicit conversion of call args to boolStephan Bergmann
...to be able to find problems like 6e0bdf04add338b7d5b29fc7b3fc9f08cfd5e96f "sal_Bool arg of SetUseImagesInMenus was abused to squeeze '2' through it" earlier when converting occurrences of sal_Bool to bool. Restricting this check to function call arguments avoids too much noise while hopefully still catching all the relevant problems. (This check partially overlaps the pointertobool check, so implicit conversions from pointers to bool call arguments will now generate two loplugin warnings, but that's harmless.) Change-Id: I0b03b1d1615aaf8bc18e7a84c56fff3ef9903508
2014-02-21Special handling of __builtin_expect in boolean expressionsStephan Bergmann
...as found in Mac OS X' assert macro definition, __builtin_expect(!(e), 0) ? ... : ... with type long __builtin_expect(long, long) The code in literaltoboolconversion.cxx is needed for assert(false); Change-Id: I42f87482c56986af74b2ec849db9852f74c7c938
2014-02-21implicitboolconversion: support for Objective C BOOLStephan Bergmann
Change-Id: Id63f42fa8875211af9f41c21f3fa128403f8a880
generated by cgit (git 2.34.1) at 2025-05-06 04:22:28 +0000