diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2022-01-28 15:01:31 +0100 |
---|---|---|
committer | Caolán McNamara <caolanm@redhat.com> | 2022-02-05 22:45:32 +0100 |
commit | 31c071c72b40194778742ec3fb7e919aebb20c02 (patch) | |
tree | 7f525b81d5677557cc36784bbd30e3cb2c27dd1a /icon-themes/colibre | |
parent | 6da6e942409d8a9bd4d9a95c43f489443e88346f (diff) |
We no longer know how to contact TLX anyway
GCC 12 trunk started to warn
> svtools/source/control/asynclink.cxx: In member function ‘void svtools::AsynchronLink::HandleCall_PostUserEvent(void*)’:
> svtools/source/control/asynclink.cxx:76:15: error: storing the address of local variable ‘bDeleted’ in ‘*this.svtools::AsynchronLink::_pDeleted’ [-Werror=dangling-pointer=]
> 76 | _pDeleted = &bDeleted;
> | ~~~~~~~~~~^~~~~~~~~~~
> svtools/source/control/asynclink.cxx:75:10: note: ‘bDeleted’ declared here
> 75 | bool bDeleted = false;
> | ^~~~~~~~
> svtools/source/control/asynclink.cxx:75:10: note: ‘<unknown>’ declared here
And while that is arguably a false warning, it points at some dubious code
anyway: The only reason for the AsynchronLink _bInCall and _pDeleted members is
to potentially SAL_INFO some "valuable historical artefact", if
AsynchronLink::Call were ever called recursively. But
0de7513cd73f1f35265e42f9a2b9befe81302c2c "osl::Mutex->std::mutex in
AsynchronLink" apparently already argued that such recursive calls can never
happen, as locking _aMutex in a recursive call of Call would now deadlock.
Change-Id: I9ee47ac65652e40e23a37be3d0694fa1185b877a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129104
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit a4348ec796e6efe0edce7bb8bfa47b1fa95d0e34)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129445
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Diffstat (limited to 'icon-themes/colibre')
0 files changed, 0 insertions, 0 deletions