to getParentStmt and rename parentFunctionDecl to getParentFunctionDecl,
so I don't keep using accidentally naming my variables the same as the
functions.
Change-Id: I66f9452458c8b439e5132191ac5219fb6d420708
...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
81892b2037453108b9bde1512a500cf3b2ce438a "loplugin:unnecessaryparen when
compiling as C++17, so the ParenExpr is no longer hidden behind
ExprWithCleanups/CXXConstructExpr/MaterializedTemporaryExpr wrappers" gave me
the idea to generally look though IgnoreImplicit instead of IngoreImpCasts in
loplugin:unnecessaryparen. However, that would still not look through implicit
CXXConstructExpr, so would still not have found the occurrences in
81892b2037453108b9bde1512a500cf3b2ce438a when compiling in pre-C++17 mode.
Therefore, let ignoreAllImplicit also look through CXXConstructExpr. (I am not
entirely sure in which situations non-implicit CXXConstructExpr---that should
thus not be ignored---would occur, but assume they would be underneath something
like a CXXFunctionalCastExpr, which is not ignored.)
Change-Id: I947d08742e1809150ecc34a7abe84cca5e0ce843
and fix bug in ScriptDocument::getTitle
which has been there since
commit e304ba66f4aba5cc55612508b5738a1ed26a7904
Date: Thu Mar 15 14:59:30 2007 +0000
INTEGRATION: CWS basmgr02 (1.1.2); FILE ADDED
plugin is off by default since it uses expensive parentStmt() calls
Change-Id: Id0f16baec48e0381e0083594d7e59b58b023da2f
Reviewed-on: https://gerrit.libreoffice.org/43750
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Consistently use the #include "..." form for exactly those cases where the
included file is located next to the including file, see the mail thread
starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-October/078601.html>
"C[++]: Normalizing include syntax ("" vs <>)". (For UNO API include files,
see 189abcf0db61c41a565bd355294bf6e712fc3e5a "loplugin:includeform: UNO API
include files".)
(Some of the commits done earlier with messages containing "Change done in
preparation of loplugin:includeform" etc. were based on a somewhat different
earlier version of this plugin and would not be necessary with the current form.
But they are harmless and reverting them would probably cause more noise than
benefit, so just leave them in.)
Change-Id: I9fe9268ed84d31b5df71857a2e535972b11254ce
Reviewed-on: https://gerrit.libreoffice.org/43730
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that the compiler is free to elide anyway. (See
4e7ffc0a69dac31ca7e0f1649f1697a1ff8d6e5f "Avoid compiler eliding#redundant
dynamic_cast" and 380d6afe5fd691f6ad4b17fc38b79b9fca4ba906 "Remove redundant
asserts involving dynamic_cast".)
Change-Id: I3f75154fee3e978b7ba95a5a27589417065599bd
...as needed by
> core/compilerplugins/clang/check.cxx:19:19: error: call to implicitly-deleted default constructor of 'loplugin::TypeCheck'
> ? *this : TypeCheck();
> ^
> core/compilerplugins/clang/check.hxx:76:5: note: explicitly defaulted function was implicitly deleted here
> TypeCheck() = default;
> ^
> core/compilerplugins/clang/check.hxx:78:27: note: default constructor of 'TypeCheck' is implicitly deleted because field 'type_' of const-qualified type 'const clang::QualType' would not be initialized
> clang::QualType const type_;
> ^
after https://llvm.org/svn/llvm-project/cfe/trunk@315194 "Make SourceLocation,
QualType and friends have constexpr constructors" defaulted the clang::QualType
ctor.
Change-Id: Idaeaa4499cea877fd5d66c18b8fce24b7808ba04
...even if they implement PPCallbacks, so filtering them out in
HandleTranslationUnit was ineffective.
Change-Id: I9df8103a50739f3176e6d63accfd0334da7faa9a
Reviewed-on: https://gerrit.libreoffice.org/43575
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
this is the code I used to find naked acquire/release stuff
No need to run it all the time, so leave it in store
Change-Id: I9ac4a6f5db7cd4cbb1b63698340425eed7cb8713
...that are included from both lotuswordpro/source/filter and
lotuswordpro/source/filter/xfilter. Change done in preparation of
loplugin:includeform.
Change-Id: I7b65d3232e164af662b7de5bb49d59597803d41c
Reviewed-on: https://gerrit.libreoffice.org/43453
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that are included from various source directories. Change done in
preparation of loplugin:includeform.
Change-Id: I9191e80aa721c376f17219e4d10eb83929e38e14
...of measuring loplugin performance, when gathering data with perf and all
plugins that used "Visitor" as class name were lumped together. (Cf.
<https://whatofhow.wordpress.com/2016/06/28/plugin-flamed/>.)
Change-Id: Ie482f443faced7469528da4772e735bc2eda596d
Reviewed-on: https://gerrit.libreoffice.org/43324
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...as it was the last remaining enabled-by-default plugin that calls expensive
parentStmt. It isn't immediately clear to me how to rewrite the plugin to not
call that, but a superset of this plugin's warnings are now also emitted by
GCC 6 -Wmisleading-indentation.
Change-Id: Ifa55cb14f6763594fe48926585df29d4d30355df
...by avoiding calls to parentStmt, thereby also improving the precision of
exactly which comma operators to ignore (which turned up a handful more finds).
Also added tests.
Change-Id: Ie74f824fd7f54131aab09b59086452fb4f3ff827
Reviewed-on: https://gerrit.libreoffice.org/43181
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...invovling preprocessing conditionals, to actually make the unhelpful warning
on Windows about OleEmbeddedObject::changeState go away. And while at it, make
the check for preprocessing conditionals more targeted (similar to
1084e8be44661aaeacb8801707701013eb3fcdbc "More targeted check for preprocessing
conditionals in loplugin:blockblock").
Change-Id: I0300e0a547e969520a90cd126ea8f788cc17560f
Reviewed-on: https://gerrit.libreoffice.org/42975
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit a599eeab786ecbe1b5b6509e3c792e5c1ba31248, plus follow-up
fa4431449d0306e8179f53a2a69c549800bd24bd "Avoid bogus loplugin:dllmacro
'unnecessary *DLLPUBLIC declaration ...'". See (abandoned)
<https://gerrit.libreoffice.org/#/c/42983/> "loplugin:dllmacro: Handle implicit
member functions" how this would have needed to be extended to give consistent
results across Linux and macOS, but then would have started to remove DLLPUBLIC
from entities that apparently need to at least have default type visibility on
macOS and started to make tests fail.
...as needed to avoid an unhelpful warning about Player::createPlayerWindow in
avmedia/source/gstreamer/gstplayer.cxx when included from
avmedia/source/gstreamer/gst_0_10.cxx (so that ENABLE_GTKSINK is not defined).
Change-Id: I6de9cc59cf8e611c4c9d939dd837499b1d2c8787
instead of trying to share the css::i18n namespace, which is just very
confusing and should be left to actual UNO artifacts
Change-Id: I2f5c36bf1af9a2a98c4f997dd450d015e75ed3f6
Reviewed-on: https://gerrit.libreoffice.org/43079
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
look for classes which are effectively final, but contain protected
members. These members can be made private.
Change-Id: If53d535b068b668d1aff548ebfd0fe6c51a48a0e
(unless as the callee of a function call). In response to
<https://gerrit.libreoffice.org/#/c/42912/> "DO NOT MERGE - error in clang
static plugin". Many of the whitelisted functions can now be taken off the
list.
Change-Id: I04c2ee445e7973a288f42fd663d8b2d78cd3c5aa
Reviewed-on: https://gerrit.libreoffice.org/42958
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...as needed by clang-cl on Windows to avoid unhelpful warnings about
OleEmbeddedObject::changeState (embeddedobj/source/msole/oleembed.cxx)
containging an "if" in an "#ifdef _WIN32" block followed by "else throw".
Change-Id: I95bed29b9003db08499156ae7f885aeeea5a0158
Reviewed-on: https://gerrit.libreoffice.org/42963
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This works at least with a recent Clang trunk (towards Clang 6.0).
In order for the plugin.dll to find the LLVM/Clang symbols, it needs to be
loaded into clang.exe not clang-cl.exe, so set CC/CXX to 'clang.exe
--driver-mode=cl ...'.
Buidling the plugin requires some linker flags that must go at the very end of
the COMPILER_PLUGINS_CXX command line, after a /link switch, so introduce
another COMPILER_PLUGINS_CXX_LINKFLAGS variable for that. Also, clang.lib is
not installed as part of LLVM's 'cmake --build ... --target install' step, so
is not available under CLANGDIR and needs to be taken from the build tree
instead, so introduce another CLANGLIBDIR variable for that. autogen.input
settings that work for me on Windows 8.1 with Microsoft Visual Studio 14.0 are:
> CLANGDIR=C:/llvm/inst
> CLANGLIBDIR=C:/llvm/build/lib
> COMPILER_PLUGINS_CXX=C:/PROGRA~2/MICROS~3.0/VC/bin/amd64/cl.exe /IC:\PROGRA~2\MICROS~3.0\VC\INCLUDE /IC:\PROGRA~2\MICROS~3.0\VC\ATLMFC\INCLUDE /IC:\PROGRA~2\WI3CF2~1\10\include\100102~1.0\ucrt /IC:\PROGRA~2\WI3CF2~1\NETFXSDK\46D346~1.1\include\um /IC:\PROGRA~2\WI3CF2~1\8.1\include\shared /IC:\PROGRA~2\WI3CF2~1\8.1\include\um /IC:\PROGRA~2\WI3CF2~1\8.1\include\winrt
> COMPILER_PLUGINS_CXX_LINKFLAGS=/LIBPATH:C:/PROGRA~2/MICROS~3.0/VC/LIB/amd64 /LIBPATH:C:/PROGRA~2/MICROS~3.0/VC/ATLMFC/LIB/amd64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/10/lib/100102~1.0/ucrt/x64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/NETFXSDK/46D346~1.1/lib/um/x64 /LIBPATH:C:/PROGRA~2/WI3CF2~1/8.1/lib/winv6.3/um/x64
(The last two are "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/
amd64/cl.exe" and translations of %INCLUDE% and %LIB% as set in the "VS2015 x64
Native Tools Command Prompt" shell.
AC_CHECK_HEADER(clang/AST/RecursiveASTVisitor.h, ...) in configure.ac wouldn't
like CXX to start with INCLUDE=... LIB=... environment variable settings, so it
wouldn't work to instead pass %INCLUDE% and %LIB% to cl.exe that way. See
<https://wiki.documentfoundation.org/Development/clang-cl> for general
information about building with clang-cl on Windows.)
There's still some room for improvement marked "TODO". (And some of the unused*
plugins, which are not run by default anyway, use Unix-style functionality, so
have been disabled for now.)
Change-Id: I6c28bdeb801af39ce2bae03111f455e2338d66c9
Reviewed-on: https://gerrit.libreoffice.org/42931
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so spell out its single use, locking the appropriate mutex around the access
Change-Id: I8e8f47de1979f5a80cf1ad65e5ec24d25145c463
Reviewed-on: https://gerrit.libreoffice.org/42908
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...about the definition of __cxxabiv1::__cxa_exception in
bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx, when a declaration of that
struct has already been seen in /usr/include/c++/7/cxxabi.h in a
#pragma GCC visibility push(default)
...
#pragma GCC visibility pop
block (so that decl->getAttr<VisibilityAttr>() would point at the first of those
two pragmas).
Change-Id: I4af56be8ce84ace57a809a09da5c44d86fc4237a
...which is there for MSVC compatibility, but can cause getBody() to return null
even when doesThisDeclarationHaveABody() is true.
And in staticmethods.cxx we need to check doesThisDeclarationHaveABody() instead
of hasBody(): For some class template member functions that are only defined
outside their class definition, as is the case for
OSequenceIterator::hasMoreElements in include/comphelper/sequence.hxx, hasBody()
may be true for the original member function declaration inside the class (as
there is some later definition that does have a body), but
isLateTemplateParsed() is not (it is only true for the later definition). So
just skip any such declarations that are not definitions (which is sane anyway,
as otherwise such functions could pointlessly be inspected multiple times).
Change-Id: I724f652a8f060a931f8b5fc3e4feb5f307a922bf
Reviewed-on: https://gerrit.libreoffice.org/42914
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
on classes which are fully defined in a header file
Rename the dllprivate plugin to dllmacro and add the functionality
there.
Change-Id: I4581d551c46a8f61213d95973f323359d08278d8
which makes absolutely no difference to the results, but anyhow, would
be a shame to waste the work
Change-Id: I4576528f30986a5ce522c76fdf21873f0ce23f0a
also make the plugin ignore the case where we have var decl's in the
clause we want to flatten, which could lead to problematic extension of
variable lifetime
Change-Id: I3061f7104e8c6a460bf74f5eac325a516ec50c59
Reviewed-on: https://gerrit.libreoffice.org/42889
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...as happens on Windows when looking at
maControlToPropertyMap.clear();
in PrintDialog::dispose (vcl/source/window/printdlg.cxx), where std::map's clear
happens to be declared at some base class std::_Tree.
Change-Id: I41810514bca59af8b4f2812d9412ce6a8d43576c
<noelgrandin> sberg, new plugin flatten just went active
<sberg> noelgrandin, with a measure to avoid extending lifetime of (problematic) local vars?
<noelgrandin> sberg, no
<sberg> noelgrandin, how can you make it active then?
<noelgrandin> sberg, ok, will disable
Change-Id: I595d1a50ff34417faf73b777714f9dc92e2a43d2
