• Seth Brenith's avatar
    [torque] Stricter object field verification, part 2 · 15ea19db
    Seth Brenith authored
    This change removes the special case in the Torque compiler for types
    that descend from JSObject: they will no longer get implicit
    "| Undefined" appended to their types for verification purposes. It
    removes any additional custom verification steps in objects-debug that
    are made redundant by that change.
    
    In order to do so safely, I categorized all cases where we were
    implicitly adding "| Undefined" to the field type, as follows:
    
    1. Classes that aren't using the generated verifier function (we should
       probably revisit these, but for now we at least know they're safe):
       - JSGlobalObject
       - JSFinalizationGroup
       - JSFinalizationGroupCleanupIterator
    
    2. Classes where the existing verifier is already at least as strict as
       what we would get after removing the implicit "| Undefined":
       - JSDate
       - JSPromise
       - JSRegExp
       - JSRegExpStringIterator
       - WasmMemoryObject
       - JSWeakRef
       - JSStringIterator
       - WasmExceptionObject
       - JSListFormat (fixed in part 1)
       - JSPluralRules (fixed in part 1)
       - JSRelativeTimeFormat (fixed in part 1)
       - JSSegmenter (fixed in part 1)
       - JSArrayBufferView (fixed in part 1)
       - JSTypedArray (fixed in part 1)
    
    3. Classes where, to the best of my knowledge based on code inspection,
       we already initialize the object correctly to pass the new stricter
       generated verifier:
       - JSFunction
       - JSArrayIterator
       - JSMessageObject
       - JSBoundFunction
       - JSAsyncFromSyncIterator
       - WasmModuleObject
       - JSAsyncFunctionObject
    
    4. Classes that needed some adjustment to their initialization order to
       avoid exposing uninitialized state to the GC:
       - JSArray (only in Factory::NewJSArray; Runtime_NewArray and
                  CodeStubAssembler::AllocateJSArray already behave fine)
       - WasmTableObject
       - JSDateTimeFormat
       - JSNumberFormat
       - JSCollator
       - JSV8BreakIterator
       - JSLocale
       - JSSegmentIterator
       - JSModuleNamespace
    
    5. Classes that had incorrect type definitions in Torque:
       - WasmGlobalObject (category 4 after correction)
    
    6. Classes that weren't fully initialized due to bugs:
       - JSGeneratorObject
       - JSAsyncGeneratorObject
    
    Bug: v8:9311
    Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980
    Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
    Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
    Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
    Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#62228}
    15ea19db
js-date-time-format.h 5.7 KB