On Windows, on exit, the backend will deref (and then implicitly start
deletion of) a COM object. This object tries to communicate with an
object in another thread, though it seems this other thread quits before
the main thread in _most_ cases.
To get around this we move the deletion to earlier in the program. While
this is only reported as a Windows issue it makes for more consistent
behavior if all platforms behave the same.
Document and test that recreation of QNI works as expected after the
destruction (and recreation) of QCoreApplication.
Amends: 0875626e22
Fixes: QTBUG-92568
Pick-to: 6.1 6.1.0
Change-Id: Iffc07f38673019aa059efd4d64d2ad706a03f6fe
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The plugins are meant to indicate what they do support, meaning users of
QNetworkInformation can choose to not care about which plugin is used
and rather just request what they want.
Task-number: QTBUG-86966
Change-Id: Ie130e1791250ec2a4470e3ba7081d982654af06c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Macros and the await helper function from qfunctions_winrt(_p).h are
needed in other Qt modules which use UWP APIs on desktop windows.
Task-number: QTBUG-84434
Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
