FMessageLog::CriticalError has a delay before throwing an assert to allow compositing of the message. As a result the assert isn't thrown at the location of the problem, but somewhere in the surrounding area, which makes the problem harder to debug and generates misleading log entries. Due to these problems FMessageLog::CriticalError and EMessageSeverity::CriticalError have been deprecated. It's recommended to use checkf instead.
When FMessageLog goes out of scope or is destroyed explicitly it will flush its messages to the log, which in turn means the log may immediately use the messages. In a few places a reference to the message was kept that outlived the lifetime of the owning FMessageLog in order to add arguments later on. The found cases have been updated to make sure FMessageLog doesn't outlive the addition of the arguments so the arguments are correctly passed to the log.
#jira: UE-155605
#rb brooke.hubert francis.hurteau jerome.delattre
#preflight 62cc4fca9922f7e5129e4e0a
[CL 21042765 by ronald koppers in ue5-main branch]
Core public headers still will contain CoreMinimal.h if any included it before my IWYU changes.
#preflight 62c73594756222ced4e48707
[CL 20991367 by bryan sefcik in ue5-main branch]
Things to note regarding this pass:
* No includes are currently being removed from public headers.
* Any private file that has a #if is currently not being updated.
#preflight 62c703bbd13fac04f11da948
[CL 20985655 by bryan sefcik in ue5-main branch]
Things to note regarding this pass:
* No includes are currently being removed from public headers.
* Any private file that has a #if is currently not being updated.
#rb Devin Doucette and Marc Audy
#preflight 62c62086756222ced497ff95
#preflight 62c626d12f2d04691814d331
#preflight 62c630107e606620fdd64e31
#preflight 62c635c6756222ced49a13cf
[CL 20979027 by bryan sefcik in ue5-main branch]
Also used the opportunity to convert from MakeShareable to MakeShared.
#jira UE-142104
#preflight 627ec6b70f72dc21c7e13a93
#rb Steve.Robb
[CL 20223845 by jorgenpt in ue5-main branch]
original code contributed by: The Coalition
#rb richard.malo, jeanfrancois.dube
#preflight 61e6f268b56c33b8ecef210e
#ROBOMERGE-AUTHOR: patrick.enfedaque
#ROBOMERGE-SOURCE: CL 18642284 in //UE5/Release-5.0/... via CL 18642299 via CL 18642303
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v900-18638592)
[CL 18642316 by patrick enfedaque in ue5-main branch]
- Issues with UObject* properties are upgraded from Warning to Error
- Other types remain the same for both engine and project modules (Display), but engine will soon change to Error as well
Settings can be overridden for either project or engine modules in DefaultEngine.ini (engine defaults are in BaseEngine.ini), e.g.,
[CoreUObject.UninitializedScriptStructMembersCheck]
EngineModuleReflectedUninitializedPropertyVerbosity=Error
ProjectModuleReflectedUninitializedPropertyVerbosity=Warning
#rb marc.audy
[CL 16826159 by Michael Noland in ue5-main branch]
The following code would call the int overload rather than the name overload when passed an EName constant, which could easily lead to confusion and bugs:
using FMyId = uint8;
void DoThing(FName);
void DoThing(FMyId);
DoThing(NAME_Actor);
The change to use enum class requires that any code that actually deals with EName as an int (mostly internal name code and serialisation) be updated to explicitly cast, but prevents the implicit conversion that causes the issue above.
In order to preserve the NAME_X aliases that the old-style enum added to the global scope, new aliases have been added that point to the EName scoped versions. Unfortunately these can cause shadowing warnings if NAME_X is defined in the local scope, as the old-style enum used to allow that without shadowing, however there is no way to prevent this so we'll just need to fix any warnings that occur.
#rb Johan.Torp
#preflight 6087e06349a9840001414708
[CL 16126708 by Jamie Dale in ue5-main branch]
