Bug 304684 – Add some TZONE_ALLOCATED enforcement.

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Mark Lam]

This is an invariant of TZone allocation as a hardening mechanism: if a class / structure is TZONE_ALLOCATED, its subclasses should also be TZONE_ALLOCATED.  This patch adds some verification in FAST_ALLOCATED to ensure that the class does not inherit from an ancestor class that is TZONE_ALLOCATED.  This verification can also be added in other non-TZone allocation macros, but we're starting with FAST_ALLOCATED for now.

Also fix some classes that should be TZONE_ALLOCATED (found by this verification).
Also fix some incorrect uses of WTF_DEPRECATED_MAKE_FAST_ALLOCATED and WTF_DEPRECATED_MAKE_STRUCT_FAST_ALLOCATED_WITH_HEAP_IDENTIFIER, where the classname argument is wrong.  These were copy paste errors that had gone unnoticed until now.  This issue was found by this verification.

Also introduce WTF_FORBID_NEW_DELETE_OPERATORS which is equivalent to WTF_FORBID_HEAP_ALLOCATION with the !usesTZoneHeap() verification.  Eventually, we should replace all uses of WTF_FORBID_HEAP_ALLOCATION with WTF_FORBID_NEW_DELETE_OPERATORS.  WTF_FORBID_NEW_DELETE_OPERATORS is also a better name because it describes what the macro is actually doing.  In most cases, the intent is to forbid heap allocation, but the macro can't actually guarantee that.  For example, the class may actually be embedded in another class that can be heap allocated.  The macro cannot prevent that.  So, we'll name it WTF_FORBID_NEW_DELETE_OPERATORS to more clearly express what it does guarantee.

Also introduce WTF_FORBID_NEW_DELETE_OPERATORS_IN_ABSTRACT_CLASS which is the equivalent of WTF_FORBID_NEW_DELETE_OPERATORS.  The only reason for this "duplicate" macro is because it documents the reason why we're forbidding new and delete operators i.e. the class is an abstract class.

Also introduce WTF_MAKE_INHERITED_TZONE_ALLOCATED which can be used for subclasses that inherit from a TZONE_ALLOCATED class but does not add any fields.  Hence. it is identical in shape and size as its parent.  Therefore, there's not much added value in declaring its own s_heapRef and set of TZone support functions.  Just use its parent's.

[Radar WebKit Bug Importer]

<rdar://problem/167161285>

[Mark Lam]

Pull request: https://github.com/WebKit/WebKit/pull/55858

[EWS]

Committed 304989@main (61117dc2de25): <https://commits.webkit.org/304989@main>

Reviewed commits have been landed. Closing PR #55858 and removing active labels.