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>

0 files changed, 0 insertions, 0 deletions