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

99 lines
2.4 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4; fill-column: 100 -*- */
/*
* 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 <sal/config.h>
#include <atomic>
#include <vcl/vclptr.hxx>
#include <vcl/vclreferencebase.hxx>
struct Widget : public VclReferenceBase
{
VclPtr<Widget> mpParent;
void widget1()
{
// test that we ignore assignments from a member field
Widget* p = mpParent;
(void)p;
// test against false+
Enable -Wunreachable-code ...motivated by <https://gerrit.libreoffice.org/#/c/41565/2> adding dead code at the end of a switch statement, after the last case's "break". -Wunreachable-code appears to work well on Clang, while it appears to have no effect on GCC. Most of the affected places are apparently temporary/TODO/FIXME cases of disabling code via "if (false)", which can be written with an extra set of parentheses as "if ((false))" to silence -Wunreachable-code on Clang (which thus needed loplugin:unnecessaryparen to be adapted accordingly). In some cases, the controlling expression was more complex than just "false" and needed to be rewritten by taking it out of the if statement to silence Clang. One noteworthy case where the nature of the disabled code wasn't immediately apparent: Sep 12 16:59:58 <sberg> quikee, is that "if (false)" in ScExponentialSmoothingDialog::ApplyOutput (sc/source/ui/StatisticsDialogs/ExponentialSmoothingDialog.cxx) some work-in- progress or dead code? Sep 12 17:02:03 <quikee> sberg: WIP, but you can remove it Sep 12 17:04:47 <sberg> quikee, I'll wrap the false in an extra set of parentheses for now, to silence -Wunreachable-code (I wouldn't want to remove it, as I have no idea whether I should then also remove the "Initial value" comment preceding it) Sep 12 17:07:29 <quikee> sberg: both are different ways to calculate the "intital value"... so no Another case where the nature of the dead code, following while (true) loops without breaks, is unclear is sd/source/ui/remotecontrol/BluetoothServer.cxx, where I added TODO markers to the workarounds that silence the warnings for now. basic/source/sbx/sbxvalue.cxx had a variable of type double, of automatic storage duration, and without an initalizer at the top of a switch statement. Clang warning about it is arguably a false positive. Apart from that, this didn't find any cases of genuinely dead code in the existing code base. Change-Id: Ib00b822c8efec94278c048783d5997b8ba86a94c Reviewed-on: https://gerrit.libreoffice.org/42217 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-09-12 18:24:46 +02:00
p = (true) ? mpParent.get() : nullptr;
}
~Widget() override
{
disposeOnce();
}
void dispose() override
{
mpParent.clear();
VclReferenceBase::dispose();
}
};
VclPtr<Widget> f()
{
return nullptr;
}
Widget* g()
{
return nullptr;
}
// test the variable init detection
void bar()
{
Widget* p = f(); // expected-error {{assigning a returned-by-value VclPtr<T> to a T* variable is dodgy, should be assigned to a VclPtr. If you know that the RHS does not return a newly created T, then add a '.get()' to the RHS [loplugin:vclwidgets]}}
(void)p;
Widget* q = g();
(void)q;
Widget* r = nullptr;
(void)r;
}
// test the assignment detection
void bar2()
{
Widget* p;
p = nullptr;
p = f(); // expected-error {{assigning a returned-by-value VclPtr<T> to a T* variable is dodgy, should be assigned to a VclPtr. If you know that the RHS does not return a newly created T, then add a '.get()' to the RHS [loplugin:vclwidgets]}}
(void)p;
Widget* q;
q = g();
(void)q;
}
// test against false+
template<class T>
T * get() { return nullptr; }
void bar3()
{
Widget* p;
p = get<Widget>();
}
void bar4() {
VclPtr<Widget> p1;
//TODO: one error should be enough here?
// expected-error@+2 {{calling delete on instance of VclReferenceBase subclass, must rather call disposeAndClear() [loplugin:vclwidgets]}}
// expected-error@+1 {{calling delete on instance of VclPtr, must rather call disposeAndClear() [loplugin:vclwidgets]}}
delete p1;
std::atomic<int *> p2;
// No false positive here:
delete p2;
}
/* vim:set shiftwidth=4 softtabstop=4 expandtab cinoptions=b1,g0,N-s cinkeys+=0=break: */