and for now, ignore methods with params so we don't fall into the trap
of thinking that calls to methods like:
Bar& foo(Bar &p) { return p; }
can be converted from
Bar f() { return foo(Bar()); }
to
Bar const & f() { return foo(Bar()); }
Change-Id: Ia3795eb2baf353cb6bec4ebf40451f2789d66ad7
Reviewed-on: https://gerrit.libreoffice.org/47034
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
improve the detection of stuff we can return by const &, instead of by
copying
Change-Id: I479ae89d0413125a8295cc3cddbc0017ed61ed69
Reviewed-on: https://gerrit.libreoffice.org/46915
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
merge the droplong and convertuintptr into one new plugin.
Limit the analysis to looking at var decl's, since that seems to be
safest proposition, even if that too needs some careful analysis.
Change-Id: Id005baaf05cfb157ce44a06a1c81f08559a07d1f
Reviewed-on: https://gerrit.libreoffice.org/46851
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Similar to libc++ in C++17 mode, some types like std::auto_ptr are indeed
removed in C++17 mode by default, and need _HAS_AUTO_PTR_ETC=1 to be enabled
(see <https://blogs.msdn.microsoft.com/vcblog/2017/12/08/c17-feature-removals-
and-deprecations/>).
Unlike libc++, also std::binary_function and std::unary_function are removed
(and need the same _HAS_AUTO_PTR_ETC=1 to enable). So either set that flag to
make external code build, or use patches (for external/mdds) to make externals'
files included in LO proper still work there.
Change-Id: I886cc0de8196255334ee03ec48cb4bc54d460afd
Reviewed-on: https://gerrit.libreoffice.org/46514
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
"Indirect" calls to isSallCallFunction (for canonic and overridden
FunctionDecls) already needed to handle many cases of FunctionDecls spanning
macros, so it isn't that much more work to make that also work for cases called
directly from VisitFunctionDecl.
Change-Id: I529f148c8872b86aa1ef082c6cb73db8ab1866e7
Reviewed-on: https://gerrit.libreoffice.org/46367
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
since cdecl is the default calling convention on Windows for
such functions, the annotation is redundant.
Change-Id: I1a85fa27e5ac65ce0e04a19bde74c90800ffaa2d
Reviewed-on: https://gerrit.libreoffice.org/46164
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...after a31267be1bb42e8a5f80a3b660bbf969eeb5b647 "Fix isSalCallFunction so it
also works on Windows", so that it actually does work on Windows.
Change-Id: I0218fb41b3e1000e2325967a18dfaafaa95fe415
Reviewed-on: https://gerrit.libreoffice.org/46193
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after a31267be1bb42e8a5f80a3b660bbf969eeb5b647 "Fix isSalCallFunction so it
also works on Windows"
Change-Id: Ic770230f2dd6183f5937801f27e929ebfd39bb4a
Reviewed-on: https://gerrit.libreoffice.org/46111
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to enable debug-only code in the plugins. Some situations in the plugin code
should never happen, yet must not by default report errors or trigger
assertions, as some newly written LO code could trigger them nevertheless (in
which case the plugin code will likely need to be adapted, to cater for these
presumed-impossible situations).
Such code can now be included in the plugins behind an if(isDebugMode()) guard,
and can explicitly be enabled with --enable-compiler-plugins=debug.
I deliberately made this a runtime rather than a compile time option (using
some #ifdef guards in the plugin code, say), as it IMO keeps the code more
readable, and also allows overridding COMPILER_PLUGINS_DEBUG=... on the make
command line.
Change-Id: Iea4f0c2783ad968a0de097fa710b3be1a248de73
Reviewed-on: https://gerrit.libreoffice.org/46096
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where FunctionDecl::getReturnTypeSourceRange returns an invalid range because
it fails to take AttributedTypeLoc (as caused by SAL_CALL -> __cdecl) into
account.
Change-Id: I7835dfca7b890ba1bfdb99adaad78a627b6e0e17
Reviewed-on: https://gerrit.libreoffice.org/45909
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
At least recent libc++ has a std::string ctor overload without a (defaulted)
Allocator argument (which otherwise causes creation of a temporary Allocator
object and thus a ExprWithCleanups), so in C++17 mode (i.e., with no implicit
move CXXConstructExpr -> MaterializeTemporaryExpr -> CXXBindTemporaryExpr chain
in the way) CellInfo::toString (sw/source/filter/ww8/WW8TableInfo.cxx) has a
ReturnStmt of just
> ReturnStmt
> `-ImplicitCastExpr 'std::string':'class std::__1::basic_string<char>' <ConstructorConversion>
> `-CXXConstructExpr 'std::string':'class std::__1::basic_string<char>' 'void (const char *)'
> `-ImplicitCastExpr 'const char *' <NoOp>
> `-ImplicitCastExpr 'char *' <ArrayToPointerDecay>
> `-DeclRefExpr 'char [256]' lvalue Var 'sBuffer' 'char [256]'
that erroneously triggered loplugin:passstuffbyref.
Change-Id: I53c8911cb1356560692c003808280a103c399e25
Reviewed-on: https://gerrit.libreoffice.org/45916
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in various places, which is gone by default at least from recent libc++ in
C++17 mode. So bring it back there for now, until Boost is fixed.
Change-Id: I0b3128d114ab2b5693a84bdc7d2b9b9b9b5c3c76
Reviewed-on: https://gerrit.libreoffice.org/45910
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
CXXFLAGS_CXX11 is for the compiler used to compile LO proper. The plugin needs
to be compiled in a way compatible with compiling Clang, and the compiler and
any relevant flags can be controlled with COMPILER_PLUGINS_CXX. (And at least
on macOS when compiling LO against a locally-built recent Clang trunk,
CXXFLAGS_CXX11 will now contain -std=gnu++17, but COMPILER_PLUGINS_CXX can still
point at Apple's Xcode clang++, which does not understand -std=gnu++17.)
Also, if COMPILER_PLUGINS_CXX is not set, simply default it to g++ instead of
trying to construct an acceptable CLANGCXX value from CXX (which would be
Clang). (The problem with using Clang without CXXFLAGS_CXX11 is that Clang,
unlike GCC, typically defaults to C++03, but building compilerplugins requires
C++11 at least. That would cause e.g. the Gerrit/Jenkins linux_clang_dbgutil_64
builds to fail---but which also needs COMPILER_PLUGINS_CXX to be explicitly set
to "g++ -std=c++11" as GCC on those machines is still 4.8.5 defaulting to
C++03.)
Change-Id: Id4ee4e54fa871cb6e621069cd050ae5b31922b34
Reviewed-on: https://gerrit.libreoffice.org/45856
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(as std::mem_fun is gone by default at least from recent libc++ in C++17 mode)
Change-Id: Ib66134bd4072dfe0ce3bc36aa684cee710921235
Reviewed-on: https://gerrit.libreoffice.org/45868
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
first, since those are safer to change than virtual methods
Change-Id: Ie3b624019d75ee2b793cee33b3c5f64e994e8bfe
Reviewed-on: https://gerrit.libreoffice.org/45798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In this first commit, I use the plugin to verify the consistency of our
SAL_CALL annotations.
The point being to make the next commit more mechanical in nature,
purely using the rewriter.
There are various chunks of unix-only code that have never had to be
compiled by MSVC, hence the inconsistencies.
In bridges, I had to inline some typedefs to make the verification code
happy, since it cannot see into typedefs.
Change-Id: Iec6e274bed857febf7295cfcf5e9f21fe4a34da0
Reviewed-on: https://gerrit.libreoffice.org/45502
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...preventing the dtor from ever being called. (DocumentEvents forwards its
acquire/release calls to its m_pData->rParent, i.e., the ODatabaseDocument, for
better or worse.) This caused ODatabaseDocument instances to be leaked during
e.g. JunitTest_dbaccess_complex. Regression introduced with
de2ac128da025502c533f8cede5862e054dd9c44 "loplugin:useuniqueptr in dbaccess".
Change-Id: Ida073c7e576b88e0d1d1a90253445e946e6eac99
Reviewed-on: https://gerrit.libreoffice.org/45652
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The mnRequestedLength fields in formula/ were introduced in
commit 6ef6dd0122b8e44d8547ec31f40def42173e4e41
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date: Wed Feb 26 14:32:57 2014 -0500
Store the length of originally requested array size prior to
trimming.
but then partially removed in
commit d7f1f91b194da1cb96e66268ce7ef38602aa5754
Author: Noel Grandin <noel@peralex.com>
Date: Mon Mar 3 13:29:43 2014 +0200
remove unused code in formula/vectortoken
Change-Id: Ic56b6e42682131ee45df7838867145f980f3d601
Reviewed-on: https://gerrit.libreoffice.org/45571
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...after bc4e8de8eea1ccebda479c8e2db2f3c6dfff60d2 "Silence new
loplugin:fpcomparison for now":
> Nov 30 08:33:16 <sberg> noelgrandin, thoughts on whether fpcomparison is actually worth it, seeing the loooooooong blacklist there?
> Nov 30 08:34:11 <noelgrandin> sberg, that's wasn't my idea, can't remember who came up with it. vmiklos was that you?
> Nov 30 08:34:36 <noelgrandin> sberg, the original commit message was "Find code that compares floating point values with == or !=
> Nov 30 08:34:36 <noelgrandin> It should rather use rtl::math::approxEqual"
> Nov 30 08:34:45 <noelgrandin> so in theory the replacement should be fairly manual
> Nov 30 08:34:48 <vmiklos> i don't think so :)
> Nov 30 08:35:15 <noelgrandin> might have been moggi, but he's not around so.... just disable it
> Nov 30 08:36:19 <sberg> noelgrandin, yeah, in theory; in practice, I guess there's also cases where x==1.0 is what you want exactly (given x tends not to be a computed value after all, but some literal that's being passed around)
> Nov 30 08:36:33 <sberg> noelgrandin, yeah, I'll disable it then
Change-Id: I35f5328efa0ec02d9be837c12efab2b03a3dae52
Reviewed-on: https://gerrit.libreoffice.org/45550
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
for some reason we're hitting more template AST nodes now? Anyhow,
updated singlevalfields and unusedenumconstants to cope.
For unusedfields, ignore field access inside Clone() methods, since it's
like a constructor.
Similarly for unusedmethods.
Change-Id: Icb2f76fb2f06ae5df21f9d75312e42a2800befb9
Reviewed-on: https://gerrit.libreoffice.org/45470
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
