...seen at least with gcc-c++-13.0.1-0.7.fc38.x86_64,
> connectivity/source/manager/mdrivermanager.cxx: In lambda function:
> connectivity/source/manager/mdrivermanager.cxx:621:41: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
> 621 | const DriverAccess& ensuredAccess = EnsureDriver(m_xContext)(driverAccess);
> | ^~~~~~~~~~~~~
> connectivity/source/manager/mdrivermanager.cxx:621:81: note: the temporary was destroyed at the end of the full expression ‘drivermanager::{anonymous}::EnsureDriver(this->drivermanager::OSDBCDriverManager::m_xContext).drivermanager::{anonymous}::EnsureDriver::operator()((* & driverAccess))’
> 621 | const DriverAccess& ensuredAccess = EnsureDriver(m_xContext)(driverAccess);
> | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
and
> vcl/source/window/layout.cxx: In function ‘array_type assembleGrid(const VclGrid&)’:
> vcl/source/window/layout.cxx:952:30: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
> 952 | const GridEntry &rEntry = A[x][y];
> | ^~~~~~
> vcl/source/window/layout.cxx:952:45: note: the temporary was destroyed at the end of the full expression ‘boost::multi_array_ref<T, NumDims>::operator[](index) [with T = {anonymous}::GridEntry; long unsigned int NumDims = 2; reference = boost::detail::multi_array::sub_array<{anonymous}::GridEntry, 1>; index = long int](((boost::multi_array_ref<{anonymous}::GridEntry, 2>::index)x)).boost::detail::multi_array::sub_array<{anonymous}::GridEntry, 1>::operator[](((boost::detail::multi_array::sub_array<{anonymous}::GridEntry, 1>::index)y))’
> 952 | const GridEntry &rEntry = A[x][y];
> | ^
> vcl/source/window/layout.cxx: In function ‘void calcMaxs(const array_type&, std::__debug::vector<VclGrid::Value>&, std::__debug::vector<VclGrid::Value>&)’:
> vcl/source/window/layout.cxx:1075:30: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
> 1075 | const GridEntry &rEntry = A[x][y];
> | ^~~~~~
> vcl/source/window/layout.cxx:1075:45: note: the temporary was destroyed at the end of the full expression ‘boost::multi_array_ref<T, NumDims>::operator[](index) const [with T = {anonymous}::GridEntry; long unsigned int NumDims = 2; const_reference = boost::detail::multi_array::const_sub_array<{anonymous}::GridEntry, 1, const {anonymous}::GridEntry*>; index = long int](((boost::multi_array_ref<{anonymous}::GridEntry, 2>::index)x)).boost::detail::multi_array::const_sub_array<{anonymous}::GridEntry, 1, const {anonymous}::GridEntry*>::operator[](((boost::detail::multi_array::const_sub_array<{anonymous}::GridEntry, 1, const {anonymous}::GridEntry*>::index)y))’
> 1075 | const GridEntry &rEntry = A[x][y];
> | ^
> vcl/source/window/layout.cxx:1106:30: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
> 1106 | const GridEntry &rEntry = A[x][y];
> | ^~~~~~
> vcl/source/window/layout.cxx:1106:45: note: the temporary was destroyed at the end of the full expression ‘boost::multi_array_ref<T, NumDims>::operator[](index) const [with T = {anonymous}::GridEntry; long unsigned int NumDims = 2; const_reference = boost::detail::multi_array::const_sub_array<{anonymous}::GridEntry, 1, const {anonymous}::GridEntry*>; index = long int](((boost::multi_array_ref<{anonymous}::GridEntry, 2>::index)x)).boost::detail::multi_array::const_sub_array<{anonymous}::GridEntry, 1, const {anonymous}::GridEntry*>::operator[](((boost::detail::multi_array::const_sub_array<{anonymous}::GridEntry, 1, const {anonymous}::GridEntry*>::index)y))’
> 1106 | const GridEntry &rEntry = A[x][y];
> | ^
Change-Id: I498bb468ade52f83117c8cf57f8d64697978d9ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148921
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Some unused functions and variables and many missing
HAVE_FEATURE_NSS warnings, because the native-code.py
stubs were missing the config_crypto.h header.
Change-Id: I88ff7d8f96e7382027a21f205db982fd797bd6af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127392
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Except for platform specific drivers/ado and drivers/macab dirs
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I24b741cded8995e29ac3d518aeaa0d60b3c55b56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86317
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Except for non Linux specific parts:
connectivity/source/drivers/macab/
connectivity/source/inc/ado/
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Iba6d0cd0effdac777be6fbc8f12f2e92cae47887
Reviewed-on: https://gerrit.libreoffice.org/84174
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I22ba2c8aec235e34cd7835b8a0a716bf3057db7a
Reviewed-on: https://gerrit.libreoffice.org/60837
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ib420e9216b8313f5ed7634ec375e39ceb741fd45
Reviewed-on: https://gerrit.libreoffice.org/59297
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: Idbefb16acae20ab137497e78c9bc5dc5634c07fe
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, 3af500580b
"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>
Gabor Kelemen