These crashes were surfaced by CL 29712224 which exposed that these values were not being null checked.
#rnx
#rb dan.kaufman, Mic.Rooney
[REVIEW] [at]Dan.Kaufman, [at]Beth.Reid, [at]Anthony.Glueck
[FYI] Jon.Cain
[CL 29870018 by christopher daniel in ue5-main branch]
Add a small bug fix to it. When attempting to create an auto-cast node from an Interface -> Object type, the UEdGraphSchema_K2::FindSpecializedConversionNode will NewObject whatever node type is required as a template to copy. This Template node does not have a parent graph (rightfully so) which means that the call to GetSchema would return null. When this happened with a Dynamic Cast node, it was checking on the schema being available in the SetPurity function where it was not before.
We don't want to set the parent graph on the template node during conversion because that isn't accurate because its a dummy template node, not something that is actually on the graph. It would also be adding references to that parent graph unnecessarily.
#rb Phillip.Kavan
Original CL Desc
-----------------------------------------------------------------
Fix potential crash when `bFavorPureCastNodes` is enabled.
`K2Node_Message` attempted to create an impure cast node when expanded, but `SetPurity(false)` had no effect in this case because inside it `IsNodePure` returned `false` even if the default cast purity was `Pure`. It resulted in the creation of a pure node, causing a crash because the Message node attempted to work with its (non-existent) exec pins.
#rb Phillip.Kavan
#ushell-cherrypick of 25757919 by kristof.morva1
[CL 25792482 by ben hoffman in ue5-main branch]
#fyi Phillip.Kavan
Original CL Desc
-----------------------------------------------------------------
Fix potential crash when `bFavorPureCastNodes` is enabled.
`K2Node_Message` attempted to create an impure cast node when expanded, but `SetPurity(false)` had no effect in this case because inside it `IsNodePure` returned `false` even if the default cast purity was `Pure`. It resulted in the creation of a pure node, causing a crash because the Message node attempted to work with its (non-existent) exec pins.
#rb Phillip.Kavan
#preflight 6479d868e319748a83f72c54
#ushell-cherrypick of 25757919 by kristof.morva1
[CL 25790092 by ben hoffman in ue5-main branch]
`K2Node_Message` attempted to create an impure cast node when expanded, but `SetPurity(false)` had no effect in this case because inside it `IsNodePure` returned `false` even if the default cast purity was `Pure`. It resulted in the creation of a pure node, causing a crash because the Message node attempted to work with its (non-existent) exec pins.
#rb Phillip.Kavan
#preflight 6479d868e319748a83f72c54
#ushell-cherrypick of 25757919 by kristof.morva1
[CL 25758302 by ben hoffman in ue5-main branch]
Notes:
- See 24252017 for additional context/review notes. The original change was backed out due to not handling mismatched object->object pin contexts on existing function call nodes (rare), so this version adds that part. An A/B screenshot is attached to the latest swarm review.
#rnx
#jira UE-157527
#rb Dave.Jones2
#preflight 63e75b9e043416e7ad4699b3
[CL 24315905 by phillip kavan in ue5-main branch]
[FYI] Phillip.Kavan
Original CL Desc
-----------------------------------------------------------------
Generated Blueprint skeleton class functions will no longer parent themselves to interface class functions in the fast path, while also ensuring backwards-compatibility for existing call sites to implemented interface functions.
Epidemiology:
- There was a regression introduced with the change to BPCM in 4.17 which started causing all newly-placed function call nodes to use the interface class as the Target pin type, rather than the 'self' type.
- However, the compiled function context was still inferred as the 'self' type, which resulted in emitting to bytecode only EX_Context w/o the required EX_InterfaceContext.
- This meant at runtime the VM would read an FScriptInterface value (16 bytes) into a UObject* ptr value (8 bytes) allocated on the stack (execContext), which caused a stack overrun (recently surfaced by ASAN).
- That regression is now fixed in the BPCM, however..
- Since we also allow object->interface connections to pass w/o casting when the object type implements the interface, this appeared to work the same as before the regression from a user perspective. However, it created an inconsistency for Target pin types that led to some odd UX; for example, if you choose to no longer implement the interface, now you might have a local function call site w/ an interface-typed Target pin that you can no longer connect self to/broken connection.
- Fixing the BPCM issue also meant that Target pins reverted back to 'self' object type on existing nodes, which caused a backcompat issue from being linked to interface pins (as that requires an interface->object conversion and will fail validation).
- Fixing that *seemed* relatively straightforward; I added a bit of code to modify the node expansion to spawn an intermediate cast node. However..
- Discovered that dynamic cast nodes had an issue where ones we dropped as an autocast via TryCreateConnection() would not be pure (i.e. no exec pins) even though it was explicitly being set in the autocast logic.
- This meant that any intermediate autocast nodes for interface->self end up being dropped as impure, with no connection to the exec pins, so they would end up being pruned at compile time. (this problem was due to another regression that traced back a long long ways..it was introduced in UE 4.6).
- Fixing that required a change to the way in which Dynamic Cast nodes manage the internal pure/impure state (since it can be toggled by the user, and it also has a default setting for new nodes).
- After fixing that, existing connections now continue to work (including previously-connected interface array outputs), while dragging new connections from interface->self will now add an explicit autocast node.
- An additional fix was made to prevent users from connecting an array of interfaces output to a function call node's Target pin for new connections (existing connections will continue to function per above).
--> Since call nodes support a ForEach-style expansion, the array connection was being allowed to pass, but then it would try to add an autocast node as if it were a scalar type, which doesn't support the expansion, so it could not be connected (broken UX).
#jira UE-157527
#rb Dave.Jones2, Dan.OConnor, Ben.Zeigler, Marc.Audy
#preflight 63dd78f4cc75b137677aaa32
[CL 24067070 by bob tellez in ue5-main branch]
Epidemiology:
- There was a regression introduced with the change to BPCM in 4.17 which started causing all newly-placed function call nodes to use the interface class as the Target pin type, rather than the 'self' type.
- However, the compiled function context was still inferred as the 'self' type, which resulted in emitting to bytecode only EX_Context w/o the required EX_InterfaceContext.
- This meant at runtime the VM would read an FScriptInterface value (16 bytes) into a UObject* ptr value (8 bytes) allocated on the stack (execContext), which caused a stack overrun (recently surfaced by ASAN).
- That regression is now fixed in the BPCM, however..
- Since we also allow object->interface connections to pass w/o casting when the object type implements the interface, this appeared to work the same as before the regression from a user perspective. However, it created an inconsistency for Target pin types that led to some odd UX; for example, if you choose to no longer implement the interface, now you might have a local function call site w/ an interface-typed Target pin that you can no longer connect self to/broken connection.
- Fixing the BPCM issue also meant that Target pins reverted back to 'self' object type on existing nodes, which caused a backcompat issue from being linked to interface pins (as that requires an interface->object conversion and will fail validation).
- Fixing that *seemed* relatively straightforward; I added a bit of code to modify the node expansion to spawn an intermediate cast node. However..
- Discovered that dynamic cast nodes had an issue where ones we dropped as an autocast via TryCreateConnection() would not be pure (i.e. no exec pins) even though it was explicitly being set in the autocast logic.
- This meant that any intermediate autocast nodes for interface->self end up being dropped as impure, with no connection to the exec pins, so they would end up being pruned at compile time. (this problem was due to another regression that traced back a long long ways..it was introduced in UE 4.6).
- Fixing that required a change to the way in which Dynamic Cast nodes manage the internal pure/impure state (since it can be toggled by the user, and it also has a default setting for new nodes).
- After fixing that, existing connections now continue to work (including previously-connected interface array outputs), while dragging new connections from interface->self will now add an explicit autocast node.
- An additional fix was made to prevent users from connecting an array of interfaces output to a function call node's Target pin for new connections (existing connections will continue to function per above).
--> Since call nodes support a ForEach-style expansion, the array connection was being allowed to pass, but then it would try to add an autocast node as if it were a scalar type, which doesn't support the expansion, so it could not be connected (broken UX).
#jira UE-157527
#rb Dave.Jones2, Dan.OConnor, Ben.Zeigler, Marc.Audy
#preflight 63dd78f4cc75b137677aaa32
[CL 24067044 by phillip kavan in ue5-main branch]
- Plugins/BlueprintContext
- Editor/GlueprintGraph
- Editor/GraphEditor
- Editor/Kismet
- Editor/KismetCompiler
- Editor/UnrealEd/Private/Kismet2
note: if you're seeing this CL in the perforce history because you're trying to figure out why there's a null check that doesn't make sense, This is why. The goal of this CL is to preserve the behavior before IsChildOf changed rather than analyze whether that behavior makes sense. Use your best judgement
#rb marc.audy
#preflight 6299023a6438e3c731307a69
[CL 20474984 by jordan hoffmann in ue5-main branch]
Change summary:
- Extended FBlueprintActionContext to include a weak ptr to the current IBlueprintEditor context.
- Added ENUM_CLASS_FLAGS() for the FBlueprintActionFilter::EFlags enumeration (for use as bitflags).
- Deprecated the current FBlueprintActionFilter constructor, replaced with a more explicitly-typed EFlags param.
- FBlueprintActionFilter now internally stores its filter flags. Also added FBlueprintActionFilter::HasAnyFlags/HasAllFlags().
- Minor refactor to a few action filter delegates to query the filter flags locally rather than add bool flags to delegate payloads.
- The FBlueprintActionFilter constructor now unsets the non-imported filter flag if Blueprint namespace editor settings are disabled.
- BlueprintActionFilterImpl::IsNonImportedObject() now utilizes the filter context rather than iterate the Blueprints array to find open asset editors.
- Added an override for UBlueprintComponentNodeSpawner::IsTemplateNodeFilteredOut(). This is now used to filter out any loaded or unloaded BP component types from the context menu.
- Cleaned up display inconsistencies in the menu UI spec between loaded vs. unloaded "Add Component" node spawner actions in the context menu.
- Added an FSoftObjectPath variant of IBlueprintEditor::IsNonImportedObject() (to support unloaded non-native component type entries which store the class object path). Implemented as FBlueprintEditor::IsNonImportedObject(FSoftObjectPath).
- Added an override for UK2Node_DynamicCast::IsActionFilteredOut() to exclude cast operator actions for non-native component types if they are not imported into the current editor context.
- Modified SBlueprintActionMenu, SBlueprintFavoritesPalette and SBlueprintLibraryPalette to include the current editor context in applicable action filter context(s).
#jira UE-149760
#rb Ben.Hoffman
#preflight 62753dd9e31cfc52d5bd0539
[CL 20077282 by Phillip Kavan in ue5-main branch]
#rnx
#rb none
#ROBOMERGE-SOURCE: CL 10869241 via CL 10869527 via CL 10869904
#ROBOMERGE-BOT: (v613-10869866)
[CL 10870586 by ryan durand in Main branch]
