The serialization code did stream out a function pointer as an integer, and then tried to set it back -- effectively, it has *never* worked since the beginning of public history, unless serialization/deserialization were done within the same process. While we cannot support streaming custom easing functions, we can recover the non-custom functions from the type, which was also streamed out; setType will take care of that, and we'll just ignore the subsequent field in the stream. If one tries to stream out a QEasingCurve with a custom curve, what do we do? I've decided to just print a warning and stream _something_ out, so I can keep some degree of behavioral compatibility and aggressively cherrypick this patch. AFAIK, there's no support for such a scenario in QDataStream: all out-stream operators have a wide contract, and there's no Status flag that meaningfully represents this case (and I doubt anyone checks QDS' status while writing into it). Change-Id: Ifa80cf3a9003cab074ddf112022c09b364497007 Fixes: QTBUG-132575 Pick-to: 6.8 6.5 6.2 5.15 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> (cherry picked from commit 78a46bf16b7061bfd77b7b3bcf392c28ee788bfc) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
…
…
Description
Languages
C++
84.3%
HTML
4.9%
C
3.9%
CMake
3.6%
Objective-C++
2%
Other
0.8%