Age | Commit message (Collapse) | Author |
|
Change-Id: Ic3d9e55b2730a3ea01cc6c7c9fbdd80a1e653c7e
|
|
(useful when types involve typedefs)
Change-Id: I93e8962fd4b9c4ef79990e057dfa07538380008c
|
|
Change-Id: I74e4ebda40f95661c5ae344132fcabbbf08ab0a4
|
|
Change-Id: I65f95e7245f08592ea11cc75e1cf34dcbdf16b40
|
|
should not have been committed in the first place, was an accident
Change-Id: Ie38cc77624bae5b3f9cc110085d0fe19b26c75c6
|
|
Change-Id: Ic7fbd750321e4cfde1cfb0e04ffb545bb1f66d9c
Reviewed-on: https://gerrit.libreoffice.org/37921
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ic336b33bd747cd55955231cbe0b5a9d474adf3ab
|
|
Change-Id: I5c39a745b70655f92953ec785d01a3a52d9ec42b
|
|
...since f1bbda1c26dc16642038ea70288eec60b43520b6 "loplugin:cstylecast: deal
with remaining pointer casts"
Change-Id: Idecc702344c674e6f39051e4f8c2114017e317cb
|
|
(r253948 "Use data recursion in RecursiveASTVisitor when traversing Stmt and
Expr nodes")
Change-Id: I393474048ecbe0f6b7f19f00c2f830f495b2b6f0
|
|
Change-Id: Ifc9de898e5c9a084cbfd739625c679185c3a1534
|
|
Arbitrarily chosing to traverse the semantic instead of the syntactic form.
Change-Id: Id1b4e49421a5550bb2fa9f0d7e6f83bf7abb6ebb
|
|
Change-Id: I4e96c55c246cf806f17df31844a00d0e8a5e4f56
|
|
Change-Id: Iac8ccd17d9e46ebb2cb55db7adb06c469bbd4ea0
Reviewed-on: https://gerrit.libreoffice.org/37910
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
add the results files so I can just see the diff in future
Change-Id: Ia20a1aa6418be95ed620719cde340c00b7b053e1
Reviewed-on: https://gerrit.libreoffice.org/37988
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib91c6d23a1af3735d9c030eaf9efae817f513c58
Reviewed-on: https://gerrit.libreoffice.org/37982
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
teach it to look for the following sequence in a destructor:
delete m_pfoo;
m_pfoo = nullptr;
Change-Id: Icd6271a63a024e32b53cc9e599f8f59952160380
Reviewed-on: https://gerrit.libreoffice.org/37900
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I438b6719817e0bbb47370ec54561eed2bc402cba
Reviewed-on: https://gerrit.libreoffice.org/37783
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
<http://reviews.llvm.org/D22128> "Make CastExpr::getSubExprAsWritten look
through implicit temporary under CK_ConstructorConversion" was biting me again.
(I had originally developed loplugin:stringcopy against a Clang build that
includes my local fix for that issue. I really need to see to get that resolved
upstream...)
(And while 957874168491f4b030fda85c65dd969aae82a670 "loplugin:stringcopy" was
actually a false positive, it doesn't hurt either, so just keep it.)
Change-Id: I726956adfbe67681005173cfdfed2e4b4cd6253d
|
|
Some versions of Clang apparently have an issue with
CastExpr::getSubExprAsWritten, causing false postivies as in
957874168491f4b030fda85c65dd969aae82a670 "loplugin:stringcopy", where
getSubExprAsWritten in
> CXXFunctionalCastExpr 0x114a333a8 'class rtl::OUString' functional cast to class rtl::OUString <ConstructorConversion>
> `-CXXBindTemporaryExpr 0x114a33388 'class rtl::OUString' (CXXTemporary 0x114a33380)
> `-CXXConstructExpr 0x114a33348 'class rtl::OUString' 'void (class rtl::OUString &&)' elidable
> `-MaterializeTemporaryExpr 0x114a33330 'class rtl::OUString' xvalue
> `-CXXBindTemporaryExpr 0x114a33310 'class rtl::OUString' (CXXTemporary 0x114a33308)
> `-ImplicitCastExpr 0x114a332f0 'class rtl::OUString' <UserDefinedConversion>
> `-CXXMemberCallExpr 0x114a332c8 'class rtl::OUString'
> `-MemberExpr 0x114a33290 '<bound member function type>' .operator OUString 0x1149b3b60
> `-DeclRefExpr 0x114a324b8 'class jfw::CXmlCharPtr' lvalue Var 0x114a31ce0 'sUser' 'class jfw::CXmlCharPtr'
erroneously returns the MaterializeTemporaryExpr instead of looking through all
the way down to the DeclRefExpr. Will need further investigation.
Change-Id: I579cd6047b8bbf8833123ce5ad47ae7e3a33eb12
|
|
Change-Id: Ib04ef019996888166c25ad140b7c718a173a782a
|
|
make it a little smarter in dealing with fields that are smart pointers
Change-Id: I44072105170882dc29fb19558f1065cffc7e5f11
Reviewed-on: https://gerrit.libreoffice.org/37751
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idc0db273f7ad2d6b11113752ca01a1f2a327e991
|
|
Change-Id: I6ae619edac26fe06d1f86f139b7cf71ce31146d4
|
|
...which would come out garbled. One place is
> bool bRet = SfxItemState::SET == pSet->GetItemState( i, rAttr.Which() != RES_TXTATR_AUTOFMT, &pItem );
in SwAttrHandler::PushAndChg (sw/source/core/text/atrstck.cxx)
Change-Id: I1486313b25850dc59e10edb38b8bd28a30e6aa63
|
|
...instead of merely getting a warning from PluginHandler::HandleTranslationUnit
after the fact. Such automatic rewriting should probably never be what one
wants.
Change-Id: I3829007224a197ebb4d55d24323b375cbbdf815c
|
|
Change-Id: I91bc89a9076c6642e06b238f65f2d31a1d20c6b5
|
|
Change-Id: I1c50d176e793397a1f9625f797a3750cf191a61c
Reviewed-on: https://gerrit.libreoffice.org/37679
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I187df1a6f5bf5d870820f60c6dca1ac3beb8cf22
|
|
Change-Id: Id0266ad01eaabf2d9555e99f4a4c1c2300bb8be7
|
|
Change-Id: Id3a8fd5d8b9975d3ae49af0648b39454310495fa
|
|
...that had plagued 2e293a731c1559c9869dfcb32491bc600fc18e4e "new
loplugin/rewriter comparisonwithconstant" (in sal/osl/unx/pipe.cxx), and
auto-rewrite the remaining occurrences in sal (that the mentioned commit had
failed to address, for whatever reason)
Change-Id: I3dc3bae8dd92ba8bf576f6e06e7c9ee21f883661
|
|
Change-Id: I934c78ec8daec656ca656d5c784f80895abfd2e4
Reviewed-on: https://gerrit.libreoffice.org/37666
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...to avoid -Werror,-Wunused-command-line-argument in case some ASan build
setting passes in such flags
Change-Id: Ia613a10e3564a23715019ee0c7c755cdcbf7a47c
|
|
Change-Id: Ic19364d2daa064a20da0ed9d9641f1646d8f6ce3
|
|
by whitelisting a couple of methods we know only write to their
parameters
Change-Id: Id7aef9c03c23d10c27707b21eb9a0db4a6c2757c
Reviewed-on: https://gerrit.libreoffice.org/37647
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ignore SAL_LOG type stuff in the destructor
Change-Id: If014382ca0c96edd3f2b325a28451d83b3d1f278
Reviewed-on: https://gerrit.libreoffice.org/37539
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I67d74072c776c32a1f91df94c621efe180baf5dc
Reviewed-on: https://gerrit.libreoffice.org/37481
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I204178ed4cf0fd3f43043cf1dfde85bb27002fee
Reviewed-on: https://gerrit.libreoffice.org/37498
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I8f6974e34e686fc97014de97f072b81aa73f969b
|
|
Change-Id: I8f67212271a798d544b7aad46f08890122cd5e18
|
|
Change-Id: Id3df69b38fd35f46735246a6d307a89aa10d4294
Reviewed-on: https://gerrit.libreoffice.org/37426
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7d2a28ab5951fbdb5a427c84e9ac4c1e32ecf9f9
Reviewed-on: https://gerrit.libreoffice.org/37280
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I92cfd5043c084d64fdfba3a1df817ee035388797
|
|
Change-Id: I2d733ed3ce9395d11700d739cbd6d123649b4013
|
|
...since <http://llvm.org/viewvc/llvm-project?view=revision&revision=301449>
"PPCallbacks::MacroUndefined, change signature and add test."
Change-Id: I6a420dc4ca33607fef1356e8869cedee87192e93
|
|
For the c-char in the u'...' literal, the preceding commits consistently use:
* a simple-escape-sequence if the original code already used one
* \0 for U+0000
* the (\ escaped, for ' and \) source character matching U+0020..7E (even if it
is not a basic source character)
* a consistently four-digit hexadecimal-escape-sequence otherwise, \xNNNN
For non-surrogate code points, the last case could probably also use \uNNNN
universal-character-names. However, for one, it isn't quite clear to me whether
conversion of such to members of the execution chacacter set in character
literals (in translation phase 5) is implementation-specific. And for another,
the current C++ standard references the dated (no pun intended) ISO/IEC
10646-1:1993 specification, rather than the current ISO/IEC 10646:2014, and
requires that a universal-characrer-name designate a character with a specific
"character short name in ISO/IEC 10646", but I do not find a specification of a
"short name" in ISO/IEC 10646:2014 and don't have access to ISO/IEC
10646-1:1993, so am not sure whether that would e.g. cover noncharacters like
U+FFFF.
(The only exception is one occurrence of u'\x6C' in bestFitOpenSymbolToMSFont,
filter/source/msfilter/util.cxx, where it is clear from the context that the
value denotes neither a Unicode code point nor a UTF-16 code unit, but rather an
index into the Wingdings font glyph table.)
Change-Id: If36b94168428ba1e05977c370aceaa7e90131e90
|
|
Change-Id: Ib8ac5acacb1dab80943b1193201021f9890121c3
|
|
* 994e38e336beeacbd983faafac480afc94d3947e "loplugin: use TypeCheck instead of
getQualifiedNameAsString" had effectively disabled this plugin (Asserter is a
struct, not a namespace). Fixed that.
* Also improved the checks, for one removing the---expensive---use of
Plugin::parentStmt, for another making the plugin look into (...), !..., and
...&&... expressions.
* However, as the plugin had effectively already been disabled (see above) when
it was switched on generally with 839e53b933322b739a7f534af58c63a2c69af7bd
"compilerplugins: enable loplugin:cppunitassertequals by default", it now hit
way more places than I had initially anticipated. To keep the amount of work
manageable, midway-through I disabled looking into ...&&... expressions for
now. That will be enabled (and resulting warnings fixed) in follow-up
commits.
* Checks like
CPPUNIT_ASSERT(a == b)
that actually want to check a specific overloaded operator == implementation,
rather than using such an operator == to actually check that a and b are
equal, can be rewritten as
CPPUNIT_ASSERT(operator ==(a, b))
to avoid false warnings from this plugin.
Change-Id: If3501020e2d150ad0f2454a65a39081e31470c0f
|
|
Change-Id: I67a0372d6982648717651f736c51e447d0b7d6a2
Reviewed-on: https://gerrit.libreoffice.org/37047
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|