As well as send the CrashSignal as part of the analytic crash event
#rb LouisPhilippe.Seguin
#ROBOMERGE-SOURCE: CL 11761085 via CL 11761165 via CL 11761195
#ROBOMERGE-BOT: (v656-11643781)
[CL 11867914 by brandon schaefer in Main branch]
Windows implemented at CL 3292685
Mac implemented at CL 1993104
#jira UE-80753
#rb none
#ROBOMERGE-SOURCE: CL 11147417 via CL 11147465 via CL 11147477
#ROBOMERGE-BOT: (v640-11091645)
[CL 11147478 by brandon schaefer in Main branch]
Add SSE and AVX defines to allow specifying availability on PC, MAC, and Linux.
SSE and AVX defines have ALWAYS_HAS and MAYBE_HAS variants to distinguish between available to compile and available to run without the need to check cpuid.
Add templated base classes TUnrealPlatformMathSSEBase and TUnrealPlatformMathSSE4Base to remove the boilerplate overrides added by each of the platformmaths that use the sse overrides.
#rb Steve.Robb
#rn Minor
[CL 10942197 by Matt Peters in Dev-Core branch]
#rnx
#rb none
#ROBOMERGE-OWNER: ryan.durand
#ROBOMERGE-AUTHOR: ryan.durand
#ROBOMERGE-SOURCE: CL 10869210 via CL 10869511 via CL 10869900
#ROBOMERGE-BOT: (v613-10869866)
[CL 10870549 by ryan durand in Main branch]
Replicated from CL# 7924370.
#rb none
#ROBOMERGE-OWNER: steve.robb
#ROBOMERGE-AUTHOR: steve.robb
#ROBOMERGE-SOURCE: CL 9279060 via CL 9279063
#ROBOMERGE-BOT: (v443-9013191)
[CL 9279836 by steve robb in Main branch]
Most UE4 platforms use a 2-byte TCHAR, however some still use a 4-byte TCHAR. The platforms that use a 4-byte TCHAR expect their string data to be UTF-32, however there are parts of UE4 that serialize FString data as a series of UCS2CHAR, simply narrowing or widening each TCHAR in turn. This can result in invalid or corrupted UTF-32 strings (either UTF-32 strings containing UTF-16 surrogates, or UTF-32 code points that have been truncated to 2-bytes), which leads to either odd behavior or crashes.
This change updates the parts of UE4 that process FString data as a series of 2-byte values to do so on the correct UTF-16 interpretation of the data, converting to/from UTF-32 as required on platforms that use a 4-byte TCHAR. This conversion is a no-op on platforms that use a 2-byte TCHAR as the string is already assumed to be valid UTF-16 data. It should also be noted that while FString may contain UTF-16 code units on platforms using a 2-byte TCHAR, this change doesn't do anything to make FString represent a Unicode string on those platforms (ie, a string that understands and works on code points), but is rather just a bag of code units.
Two new variable-width string converters have be added to facilitate the conversion (modelled after the TCHAR<->UTF-8 converters), TUTF16ToUTF32_Convert and TUTF32ToUTF16_Convert. These are used for both TCHAR<->UTF16CHAR conversion when needed, but also for TCHAR<->wchar_t conversion on platforms that use char16_t for TCHAR along with having a 4-byte wchar_t (as defined by the new PLATFORM_WCHAR_IS_4_BYTES option).
These conversion routines are accessed either via the conversion macros (TCHAR_TO_UTF16, UTF16_TO_TCHAR, TCHAR_TO_WCHAR, and WCHAR_TO_TCHAR), or by using a conversion struct (FTCHARToUTF16, FUTF16ToTCHAR, FTCHARToWChar, and FWCharToTCHAR), which is the same pattern as the existing TCHAR<->UTF-8 conversion. Both the macros and the structs are defined as no-ops when the conversion isn't needed, but always exist so that code can be written in a portable way.
Very little code actually needed updating to use UTF-16, as the vast majority makes no assumptions about the size of TCHAR, nor how FString should be serialized. The main places were the FString archive serialization and the JSON reader/writer, along with some minor fixes to the UTF-8 conversion logic for platforms using a 4-byte TCHAR.
Tests have been added to verify that an FString representing a UTF-32 code point can be losslessly converted to/from UTF-8 and UTF-16, and serialized to/from an archive.
#jira
#rb Steve.Robb, Josh.Adams
#ROBOMERGE-SOURCE: CL 8676728 via CL 8687863
#ROBOMERGE-BOT: (v421-8677696)
[CL 8688048 by jamie dale in Main branch]
#rb Ryan.Gerleve
[FYI] Ryan.Gerleve, Bart.Hawthorne, Jake.Leonard
#ROBOMERGE-SOURCE: CL 8501844 via CL 8502107
#ROBOMERGE-BOT: (v406-8472469)
[CL 8509142 by john barrett in Main branch]
