2019-06-04  Michael Catanzaro  <mcatanzaro@igalia.com>

        Fix miscellaneous build warnings
        https://bugs.webkit.org/show_bug.cgi?id=198544

        Reviewed by Don Olmstead.

        Silence -Wclass-memaccess warning in this dangerous code.

        * wasm/WasmInstance.cpp:
        (JSC::Wasm::Instance::Instance):

2019-06-04  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, update exception scope for putByIndexBeyondVectorLength
        https://bugs.webkit.org/show_bug.cgi?id=198477

        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndexBeyondVectorLength):

2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>

        Argument elimination should check transitive dependents for interference
        https://bugs.webkit.org/show_bug.cgi?id=198520
        <rdar://problem/50863343>

        Reviewed by Filip Pizlo.

        Consider the following program:

            a: CreateRest
            -->
                b: CreateRest
            <--
            c: Spread(@a)
            d: Spread(@b)
            e: NewArrayWithSpread(@a, @b)
            f: KillStack(locX)
            g: LoadVarargs(@e)

        Suppose @b reads locX, then we cannot transform @e to PhantomNewArraySpread, since that would
        move the stack access from @b into @g, and that stack location is no longer valid at that point.

        We fix that by computing a set of all inline call frames that any argument elimination candidate
        depends on and checking each of them for interference in `eliminateCandidatesThatInterfere`.

        * dfg/DFGArgumentsEliminationPhase.cpp:

2019-06-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] InferredValue should not be a JSCell
        https://bugs.webkit.org/show_bug.cgi?id=198407

        Reviewed by Filip Pizlo.

        Allocating InferredValue as a JSCell is too costly in terms of memory. Gmail has 90000 FunctionExecutables. And each gets
        InferredValue, which takes 32 bytes. So it takes 2.7 MB memory footprint.

        In this patch, we introduce a new container InferredValue<>. Which is similar to WriteBarrier<> container, but it replaces
        the existing InferredValue cells with one pointer size field. The implementation of InferredValue<> is similar to
        InlineWatchpointSet. But we encode JSCell* too to the pointer data of InlineWatchpointSet. So sizeof(InferredValue<>) is one
        pointer size while it keeps Watchpoint feature and JSCell holder feature.

        InferredValue<> needs validation in GC finalize phase. So this patch also makes SymbolTable Iso-allocated.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/ObjectAllocationProfileInlines.h:
        (JSC::ObjectAllocationProfileBase<Derived>::initializeProfile):
        * bytecode/Watchpoint.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGClobbersExitState.cpp:
        (JSC::DFG::clobbersExitState):
        * dfg/DFGDesiredWatchpoints.cpp:
        (JSC::DFG::SymbolTableAdaptor::add):
        (JSC::DFG::FunctionExecutableAdaptor::add):
        (JSC::DFG::DesiredWatchpoints::addLazily):
        (JSC::DFG::DesiredWatchpoints::reallyAdd):
        (JSC::DFG::DesiredWatchpoints::areStillValid const):
        (JSC::DFG::DesiredWatchpoints::dumpInContext const):
        (JSC::DFG::InferredValueAdaptor::add): Deleted.
        * dfg/DFGDesiredWatchpoints.h:
        (JSC::DFG::SymbolTableAdaptor::hasBeenInvalidated):
        (JSC::DFG::SymbolTableAdaptor::dumpInContext):
        (JSC::DFG::FunctionExecutableAdaptor::hasBeenInvalidated):
        (JSC::DFG::FunctionExecutableAdaptor::dumpInContext):
        (JSC::DFG::DesiredWatchpoints::isWatched):
        (JSC::DFG::InferredValueAdaptor::hasBeenInvalidated): Deleted.
        (JSC::DFG::InferredValueAdaptor::dumpInContext): Deleted.
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        (JSC::DFG::SpeculativeJIT::compileCreateActivation):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::FunctionExecutable::finishCreation):
        (JSC::FunctionExecutable::visitChildren):
        * runtime/FunctionExecutable.h:
        * runtime/FunctionExecutableInlines.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
        (JSC::FunctionExecutable::finalizeUnconditionally):
        * runtime/InferredValue.cpp: Removed.
        * runtime/InferredValue.h:
        (JSC::InferredValue::inferredValue):
        (JSC::InferredValue::InferredValue):
        (JSC::InferredValue::~InferredValue):
        (JSC::InferredValue::stateOnJSThread const):
        (JSC::InferredValue::state const):
        (JSC::InferredValue::hasBeenInvalidated const):
        (JSC::InferredValue::isStillValid const):
        (JSC::InferredValue::invalidate):
        (JSC::InferredValue::isBeingWatched const):
        (JSC::InferredValue::notifyWrite):
        (JSC::InferredValue::isThin):
        (JSC::InferredValue::isFat):
        (JSC::InferredValue::decodeState):
        (JSC::InferredValue::encodeState):
        (JSC::InferredValue::isThin const):
        (JSC::InferredValue::isFat const):
        (JSC::InferredValue::fat):
        (JSC::InferredValue::fat const):
        (JSC::InferredValue::inflate):
        (JSC::InferredValue<JSCellType>::InferredValueWatchpointSet::notifyWriteSlow):
        (JSC::InferredValue<JSCellType>::notifyWriteSlow):
        (JSC::InferredValue<JSCellType>::add):
        (JSC::InferredValue<JSCellType>::inflateSlow):
        (JSC::InferredValue<JSCellType>::freeFat):
        * runtime/InferredValueInlines.h:
        (JSC::InferredValue<JSCellType>::finalizeUnconditionally):
        (JSC::InferredValue::finalizeUnconditionally): Deleted.
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::setSymbolTable):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::finishCreation):
        (JSC::SymbolTable::visitChildren):
        * runtime/SymbolTable.h:
        * runtime/SymbolTableInlines.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
        (JSC::SymbolTable::finalizeUnconditionally):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>

        Argument elimination should check for negative indices in GetByVal
        https://bugs.webkit.org/show_bug.cgi?id=198302
        <rdar://problem/51188095>

        Reviewed by Filip Pizlo.

        In DFG::ArgumentEliminationPhase, the index is treated as unsigned, but there's no check
        for overflow in the addition. In compileGetMyArgumentByVal, there's a check for overflow,
        but the index is treated as signed, resulting in an index lower than numberOfArgumentsToSkip.

        * dfg/DFGArgumentsEliminationPhase.cpp:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):

2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>

        JSScript should not keep bytecode cache in memory
        https://bugs.webkit.org/show_bug.cgi?id=198482

        Reviewed by Saam Barati.

        When JSScript writes to the cache, we keep the in-memory serialized bytecode alive.
        Instead, we should only ever hold the memory mapped bytecode cache to avoid using
        too much memory.

        * API/JSScript.mm:
        (-[JSScript writeCache:]):
        * API/tests/testapi.mm:
        (testBytecodeCacheWithSyntaxError):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * jsc.cpp:
        * parser/SourceProvider.h:
        * runtime/BytecodeCacheError.cpp: Added.
        (JSC::BytecodeCacheError::StandardError::isValid const):
        (JSC::BytecodeCacheError::StandardError::message const):
        (JSC::BytecodeCacheError::WriteError::isValid const):
        (JSC::BytecodeCacheError::WriteError::message const):
        (JSC::BytecodeCacheError::operator=):
        (JSC::BytecodeCacheError::isValid const):
        (JSC::BytecodeCacheError::message const):
        * runtime/BytecodeCacheError.h: Added.
        (JSC::BytecodeCacheError::StandardError::StandardError):
        (JSC::BytecodeCacheError::WriteError::WriteError):
        * runtime/CachedBytecode.h:
        (JSC::CachedBytecode::create):
        * runtime/CachedTypes.cpp:
        (JSC::Encoder::Encoder):
        (JSC::Encoder::release):
        (JSC::Encoder::releaseMapped):
        (JSC::encodeCodeBlock):
        (JSC::encodeFunctionCodeBlock):
        * runtime/CachedTypes.h:
        * runtime/CodeCache.cpp:
        (JSC::serializeBytecode):
        * runtime/CodeCache.h:
        * runtime/Completion.cpp:
        (JSC::generateProgramBytecode):
        (JSC::generateModuleBytecode):
        * runtime/Completion.h:

2019-06-03  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Implement support for "**"
        https://bugs.webkit.org/show_bug.cgi?id=190799

        Reviewed by Saam Barati.

        We are introducing support for BigInt into "**" operator. This Patch
        also includes changes into DFG, introducing a new node "ValuePow" that
        is responsible to handle UntypedUse and BigIntUse.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

        ValuePow(Untyped, Untyped) still can propagate constant if AI proves
        it. We are doing so if AI proves rhs and lhs as numbers.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

        When compiling op_pow, we first verify if rhs and lhs can be any Int
        or number. If this happen, we emit ArithPow, otherwise we fallback to
        ValuePow and rely on fixup to convert it to ArithPow if possible.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

        We only clobberize world if ValuePow is UntypedUse. Otherwise, we can
        properly support CSE.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

        JSBigInt::exponentiate allocates JSBigInts to perform calculation and
        it can trigger GC. ValuePow(UntypedUse) can trigger GC because it can
        execute user code.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupArithPow):
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValuePow):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValuePow):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

        We are adding proper support to BigInt on op_pow. The specification
        defines that we can only apply pow when both operands have the same
        type after calling ToNumeric().

        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::exponentiate):
        * runtime/JSBigInt.h:

2019-06-03  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] JSObject::attemptToInterceptPutByIndexOnHole should use getPrototype instead of getPrototypeDirect
        https://bugs.webkit.org/show_bug.cgi?id=198477
        <rdar://problem/51299504>

        Reviewed by Saam Barati.

        JSObject::attemptToInterceptPutByIndexOnHole uses getPrototypeDirect, but it should use getPrototype to
        handle getPrototype methods in derived JSObject classes correctly.

        * runtime/JSArrayInlines.h:
        (JSC::JSArray::pushInline):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
        (JSC::JSObject::putByIndexBeyondVectorLength):

2019-06-03  Don Olmstead  <don.olmstead@sony.com>

        [CMake] Add WebKit::JavaScriptCore target
        https://bugs.webkit.org/show_bug.cgi?id=198403

        Reviewed by Konstantin Tokarev.

        Create the WebKit::JavaScriptCore target and use that to propagate headers. Use
        WEBKIT_COPY_FILES instead of WEBKIT_MAKE_FORWARDING_HEADERS.

        * CMakeLists.txt:
        * shell/CMakeLists.txt:

2019-06-03  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r246022.
        https://bugs.webkit.org/show_bug.cgi?id=198486

        Causing Internal build failures and JSC test failures
        (Requested by ShawnRoberts on #webkit).

        Reverted changeset:

        "Reenable Gigacage on ARM64."
        https://bugs.webkit.org/show_bug.cgi?id=198453
        https://trac.webkit.org/changeset/246022

2019-06-03  Darin Adler  <darin@apple.com>

        Finish cleanup of String::number for floating point
        https://bugs.webkit.org/show_bug.cgi?id=198471

        Reviewed by Yusuke Suzuki.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode): Use String::number instead of
        String::numberToStringECMAScript, since that's now the default.
        * parser/ParserArena.h:
        (JSC::IdentifierArena::makeNumericIdentifier): Ditto.
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue): Use appendNumber instead of
        builder.appendECMAScriptNumber, since that's now the default.
        * runtime/NumberPrototype.cpp:
        (JSC::toStringWithRadix): Use String::number instead of
        String::numberToStringECMAScript, since that's now the default.
        (JSC::numberProtoFuncToExponential): Ditto.
        (JSC::numberProtoFuncToFixed): Ditto.
        (JSC::numberProtoFuncToPrecision): Ditto.
        (JSC::numberToStringInternal): Ditto.
        * runtime/NumericStrings.h:
        (JSC::NumericStrings::add): Ditto.
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::prepare): Ditto.

2019-06-02  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Crash explicitly if StructureIDs are exhausted
        https://bugs.webkit.org/show_bug.cgi?id=198467

        Reviewed by Sam Weinig.

        When StructureIDTable::m_size reaches to s_maximumNumberOfStructures, newCapacity in resize function is also capped with s_maximumNumberOfStructures.
        So m_size == newCapacity. In that case, the following code in resize function, `makeFreeListFromRange(m_size, m_capacity - 1);` starts executing the
        wrong code.

        Currently, this is safe. We immediately execute the wrong code in makeFreeListFromRange, and crash with zero division. But we should not rely on
        this crash, and instead we should explicitly crash because we exhaust StructureIDs.

        This patch inserts RELEASE_ASSERT for `m_size < newCapacity` status to ensure that resize is always extending the table.

        In practice, this crash does not happen in Safari because Safari has memory footprint limit. To exhaust StructureIDs, we need to allocate massive
        amount of Structures, and it exceeds the memory footprint limit and the process will be killed.

        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::resize):

2019-06-02  Keith Miller  <keith_miller@apple.com>

        Reenable Gigacage on ARM64.
        https://bugs.webkit.org/show_bug.cgi?id=198453

        Reviewed by Filip Pizlo.

        This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
        old Gigacage however, arm64e uses both Gigacaging and PAC. Since
        Gigacaging would otherwise strip a PAC failed authenticate bit we
        force a load of the pointer into some garbage register.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
        (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cageConditionally):
        * llint/LowLevelInterpreter64.asm:

2019-06-02  Tadeu Zagallo  <tzagallo@apple.com>

        CachedMetadataTable::decode leaks empty tables
        https://bugs.webkit.org/show_bug.cgi?id=198465
        <rdar://problem/51307673>

        Reviewed by Yusuke Suzuki.

        CachedMetadataTable::decode creates the metadata and never calls finalize on it.
        This leaks the underlying UnlinkedMetadataTable buffer when m_hasMetadata is false,
        since the buffer would be freed in finalize instead of in the destructor.

        * bytecode/UnlinkedMetadataTable.h:
        (JSC::UnlinkedMetadataTable::empty):
        * bytecode/UnlinkedMetadataTableInlines.h:
        (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
        * runtime/CachedTypes.cpp:
        (JSC::CachedMetadataTable::decode const):

2019-05-31  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, fix setEntryAddressCommon register usage in LLInt ASM Windows 64
        https://bugs.webkit.org/show_bug.cgi?id=197979

        * llint/LowLevelInterpreter.asm:
        * offlineasm/x86.rb:

2019-05-31  Stephan Szabo  <stephan.szabo@sony.com>

        [PlayStation] Support internal test runner for JSC tests
        https://bugs.webkit.org/show_bug.cgi?id=198386

        Reviewed by Alex Christensen.

        Support using our test runner with our wrapper library
        to run multiple tests sequentially in one execution. With
        default arguments, will run as normal, but with special
        arguments will shift into this mode.

        * runtime/Options.h:
        Export the default values of the JSC options similar
        to the values for resetting the values between tests.
        * shell/PlatformPlayStation.cmake:
        * shell/playstation/TestShell.cpp: Added.
        (setupTestRun): Function to set up the system before starting the tests
        (preTest): Function for setting up individual test
        (runTest): Function to run a test execution
        (postTest): Function for shutdown of individual test
        (shutdownTestRun): Function for shutting down the system after test run completes.

2019-05-31  Don Olmstead  <don.olmstead@sony.com>

        [CMake] Add WebKit::WTF target
        https://bugs.webkit.org/show_bug.cgi?id=198400

        Reviewed by Konstantin Tokarev.

        Use the WebKit::WTF target.

        * CMakeLists.txt:
        * shell/CMakeLists.txt:

2019-05-30  Devin Rousso  <drousso@apple.com>

        Web Inspector: Audit: there should be a default test for WebInspectorAudit.Resources functionality
        https://bugs.webkit.org/show_bug.cgi?id=196710
        <rdar://problem/49712348>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Audit.json:
        Increment Audit version.

2019-05-30  Devin Rousso  <drousso@apple.com>

        Web Inspector: Audit: tests are unable to get the current Audit version
        https://bugs.webkit.org/show_bug.cgi?id=198270

        Reviewed by Timothy Hatcher.

        Expose the Audit version number through the `WebInspectorObject` that's injected into tests
        so that they can decide at runtime whether they're supported (e.g. the `unsupported` result).

        * inspector/agents/InspectorAuditAgent.h:
        * inspector/agents/InspectorAuditAgent.cpp:
        (Inspector::InspectorAuditAgent::populateAuditObject):

2019-05-30  Tadeu Zagallo  <tzagallo@apple.com> and Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Implement op_wide16 / op_wide32 and introduce 16bit version bytecode
        https://bugs.webkit.org/show_bug.cgi?id=197979

        Reviewed by Filip Pizlo.

        This patch introduces 16bit bytecode size. Previously, we had two versions of bytecodes, 8bit and 32bit. However,
        in Gmail, we found that a lot of bytecodes get 32bit because they do not fit in 8bit. 8bit is very small and large
        function easily emits a lot of 32bit bytecodes because of large VirtualRegister number etc. But they almost always
        fit in 16bit. If we can have 16bit version of bytecode, we can make most of the current 32bit bytecodes 16bit and
        save memory.

        We rename rename op_wide to op_wide32 and introduce op_wide16. The mechanism is similar to old op_wide. When we
        get op_wide16, the following bytecode data is 16bit, and we execute 16bit version of bytecode in LLInt.

        We also disable this op_wide16 feature in Windows CLoop, which is used in AppleWin port. When the code size of
        CLoop::execute increases, MSVC starts generating CLoop::execute function with very large stack allocation
        requirement. Even before introducing this 16bit bytecode, CLoop::execute in AppleWin takes almost 100KB stack
        height. After introducing this, it becomes 160KB. While the semantics of the function is correctly compiled,
        such a large stack allocation is not essentially necessary, and this leads to stack overflow errors quite easily,
        and tests fail with AppleWin port because it starts throwing stack overflow range error in various places.
        In this patch, for now, we just disable op_wide16 feature for AppleWin so that CLoop::execute takes 100KB
        stack allocation because this patch is not focusing on fixing AppleWin's CLoop issue. We introduce a new backend
        type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16 version of code to reduce the code size of
        CLoop::execute. In the future, we should investigate whether this MSVC issue is fixed in Visual Studio 2019.
        Or we should consider always enabling ASM LLInt for Windows.

        This patch improves Gmail by 7MB at least.

        * CMakeLists.txt:
        * bytecode/BytecodeConventions.h:
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBlock):
        * bytecode/BytecodeList.rb:
        * bytecode/BytecodeRewriter.h:
        (JSC::BytecodeRewriter::Fragment::align):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::metadataTable const):
        * bytecode/Fits.h:
        * bytecode/Instruction.h:
        (JSC::Instruction::opcodeID const):
        (JSC::Instruction::isWide16 const):
        (JSC::Instruction::isWide32 const):
        (JSC::Instruction::hasMetadata const):
        (JSC::Instruction::sizeShiftAmount const):
        (JSC::Instruction::size const):
        (JSC::Instruction::wide16 const):
        (JSC::Instruction::wide32 const):
        (JSC::Instruction::isWide const): Deleted.
        (JSC::Instruction::wide const): Deleted.
        * bytecode/InstructionStream.h:
        (JSC::InstructionStreamWriter::write):
        * bytecode/Opcode.h:
        * bytecode/OpcodeSize.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::alignWideOpcode16):
        (JSC::BytecodeGenerator::alignWideOpcode32):
        (JSC::BytecodeGenerator::emitGetByVal): Previously, we always emit 32bit op_get_by_val for bytecodes in `for-in` context because
        its operand can be replaced to the other VirtualRegister later. But if we know that replacing VirtualRegister can fit in 8bit / 16bit
        a-priori, we should not emit 32bit version. We expose OpXXX::checkWithoutMetadataID to check whether we could potentially compact
        the bytecode for the given operands.

        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::StructureForInContext::finalize):
        (JSC::BytecodeGenerator::alignWideOpcode): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::write):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * generator/Argument.rb:
        * generator/DSL.rb:
        * generator/Metadata.rb:
        * generator/Opcode.rb: A little bit weird but checkImpl's argument must be reference. We are relying on that BoundLabel is once modified in
        this check phase, and the modified BoundLabel will be used when emitting the code. If checkImpl copies the passed BoundLabel, this modification
        will be discarded in this checkImpl function and make the code generation broken.

        * generator/Section.rb:
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        * llint/LLIntData.h:
        (JSC::LLInt::opcodeMapWide16):
        (JSC::LLInt::opcodeMapWide32):
        (JSC::LLInt::getOpcodeWide16):
        (JSC::LLInt::getOpcodeWide32):
        (JSC::LLInt::getWide16CodePtr):
        (JSC::LLInt::getWide32CodePtr):
        (JSC::LLInt::opcodeMapWide): Deleted.
        (JSC::LLInt::getOpcodeWide): Deleted.
        (JSC::LLInt::getWideCodePtr): Deleted.
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm.rb:
        * offlineasm/arm64.rb:
        * offlineasm/asm.rb:
        * offlineasm/backends.rb:
        * offlineasm/cloop.rb:
        * offlineasm/instructions.rb:
        * offlineasm/mips.rb:
        * offlineasm/x86.rb: Load operation with sign extension should also have the extended size information. For example, loadbs should be
        converted to loadbsi for 32bit sign extension (and loadbsq for 64bit sign extension). And use loadbsq / loadhsq for loading VirtualRegister
        information in LowLevelInterpreter64 since they will be used for pointer arithmetic and they are using machine register width.

        * parser/ResultType.h:
        (JSC::OperandTypes::OperandTypes):
        (JSC::OperandTypes::first const):
        (JSC::OperandTypes::second const):
        (JSC::OperandTypes::bits):
        (JSC::OperandTypes::fromBits):
        (): Deleted.
        (JSC::OperandTypes::toInt): Deleted.
        (JSC::OperandTypes::fromInt): Deleted.
        We reduce sizeof(OperandTypes) from unsigned to uint16_t, which guarantees that OperandTypes always fit in 16bit bytecode.

2019-05-30  Justin Michaud  <justin_michaud@apple.com>

        oss-fuzz: jsc: Issue 15016: jsc: Abrt in JSC::Wasm::AirIRGenerator::addLocal (15016)
        https://bugs.webkit.org/show_bug.cgi?id=198355

        Reviewed by Saam Barati.

        Fix missing anyref case in addLocal.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::addLocal):

2019-05-29  Don Olmstead  <don.olmstead@sony.com>

        Remove ENABLE definitions from WebKit config files
        https://bugs.webkit.org/show_bug.cgi?id=197858

        Reviewed by Simon Fraser.

        Sync FeatureDefines.xcconfig.

        * Configurations/FeatureDefines.xcconfig:

2019-05-28  Dean Jackson  <dino@apple.com>

        Implement Promise.allSettled
        https://bugs.webkit.org/show_bug.cgi?id=197600
        <rdar://problem/50483885>

        Reviewed by Keith Miller.

        Implement Promise.allSettled
        https://github.com/tc39/proposal-promise-allSettled/

        Shipping in Firefox since version 68.
        Shipping in V8 since https://chromium.googlesource.com/v8/v8.git/+/1f6d27e8df819b448712dface6ad367fb8de426b

        * builtins/PromiseConstructor.js:
        (allSettled.newResolveRejectElements.resolveElement):
        (allSettled.newResolveRejectElements.rejectElement):
        (allSettled.newResolveRejectElements):
        (allSettled): Added.
        * runtime/JSPromiseConstructor.cpp: Add ref to allSettled.

2019-05-28  Michael Saboff  <msaboff@apple.com>

        [YARR] Properly handle RegExp's that require large ParenContext space
        https://bugs.webkit.org/show_bug.cgi?id=198065

        Reviewed by Keith Miller.

        Changed what happens when we exceed VM::patternContextBufferSize when compiling a RegExp
        that needs ParenCOntextSpace to fail the RegExp JIT compilation and fall back to the YARR
        interpreter.  This can save large amounts of JIT memory for a
        JIT'ed function that cannot ever succeed.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::initParenContextFreeList):
        (JSC::Yarr::YarrGenerator::compile):

2019-05-28  Tadeu Zagallo  <tzagallo@apple.com>

        JITOperations putByVal should mark negative array indices as out-of-bounds
        https://bugs.webkit.org/show_bug.cgi?id=198271

        Reviewed by Saam Barati.

        Similar to what was done to getByVal in r245769, we should also mark put_by_val as out-of-bounds
        when we exit from DFG for putting to a negative index. This avoids the same scenario where we keep
        recompiling a CodeBlock with DFG and exiting at the same bytecode.

        This is a 3.7x improvement in the microbenchmark being added: put-by-val-negative-array-index.js.

        * jit/JITOperations.cpp:

2019-05-28  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, revert r242070 due to Membuster regression
        https://bugs.webkit.org/show_bug.cgi?id=195013

        Membuster shows ~0.3% regression.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::runBeginPhase):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::forEachSlotVisitor):
        (JSC::Heap::numberOfSlotVisitors): Deleted.
        * heap/MarkingConstraintSolver.cpp:
        (JSC::MarkingConstraintSolver::didVisitSomething const):
        * heap/SlotVisitor.h:

2019-05-27  Tadeu Zagallo  <tzagallo@apple.com>

        Fix opensource build of testapi
        https://bugs.webkit.org/show_bug.cgi?id=198256

        Reviewed by Alexey Proskuryakov.

        In r245564, we added custom entitlements to testapi to allow caching
        bytecode in data vaults, but we should only use the entitlements for
        internal builds. Otherwises, testapi gets killed on launch. Also fix the
        formatting for the errors added in the same patch, according to comments
        in the bug after the patch had already landed.

        * API/JSScript.mm:
        (validateBytecodeCachePath):
        * Configurations/ToolExecutable.xcconfig:

2019-05-25  Tadeu Zagallo  <tzagallo@apple.com>

        JITOperations getByVal should mark negative array indices as out-of-bounds
        https://bugs.webkit.org/show_bug.cgi?id=198229

        Reviewed by Saam Barati.

        get_by_val with an array or string as base value and a negative index causes DFG to OSR exit,
        but baseline doesn't mark it as out-of-bounds, since it only considers positive indices. This
        leads to discarding DFG code, recompiling it and exiting at the same bytecode.

        This is observed in the prepack-wtb subtest of JetStream2. In popContext#CdOhFJ, the last item
        of the array popped and the new last value is accessed using `array[array.length - 1]`, which
        is -1 when the array is empty. It shows a ~0.5% progression in JetStream2, but it's within the
        noise.

        * jit/JITOperations.cpp:
        (JSC::getByVal):

2019-05-24  Justin Michaud  <justin_michaud@apple.com>

        [WASM-References] Support Anyref in globals
        https://bugs.webkit.org/show_bug.cgi?id=198102

        Reviewed by Saam Barati.

        Support anyref for globals, imports and exports. This adds code in B3 and Air to emit a write barrier
        on the JSWebAssemblyWrapper whenever an anyref global is set. This also fixes a small bug in emitCCall
        for air where it adds code to the wrong block.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::emitCCall):
        (JSC::Wasm::AirIRGenerator::moveOpForValueType):
        (JSC::Wasm::AirIRGenerator::setGlobal):
        (JSC::Wasm::AirIRGenerator::emitWriteBarrierForJSWrapper):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::setGlobal):
        (JSC::Wasm::B3IRGenerator::emitWriteBarrierForJSWrapper):
        * wasm/WasmInstance.cpp:
        (JSC::Wasm::Instance::Instance):
        (JSC::Wasm::Instance::setGlobal):
        * wasm/WasmInstance.h:
        (JSC::Wasm::Instance::loadI32Global const):
        (JSC::Wasm::Instance::loadI64Global const):
        (JSC::Wasm::Instance::setGlobal):
        (JSC::Wasm::Instance::shouldMarkGlobal):
        (JSC::Wasm::Instance::numGlobals const):
        * wasm/WasmSectionParser.cpp:
        (JSC::Wasm::SectionParser::parseInitExpr):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):

2019-05-23  Devin Rousso  <drousso@apple.com>

        Web Inspector: Overlay: rulers/guides should be shown whenever element selection is enabled
        https://bugs.webkit.org/show_bug.cgi?id=198088

        Reviewed by Timothy Hatcher.

        When trying to "measure" the absolute position (to the viewport) or relative position (to
        another element) of a given element, often the easiest way is to enable Element Selection
        and Show Rulers at the same time.

        This can have the undesired "side-effect" of having the rulers be always present, even when
        not highlighting any nodes.

        The ideal functionality is to allow the rulers/guides to be shown when element selection is
        active and a node is hovered, regardless of whether "Show Rulers" is enabled.

        * inspector/protocol/DOM.json:
        Add an optional `showRulers` parameter to `DOM.setInspectModeEnabled` that supersedes the
        current value of `Page.setShowRulers` as to whether rulers/guides are shown.

2019-05-23  Ross Kirsling  <ross.kirsling@sony.com>

        Socket-based RWI should be able to inspect a JSContext
        https://bugs.webkit.org/show_bug.cgi?id=198197

        Reviewed by Don Olmstead.

        * inspector/remote/socket/RemoteInspectorSocket.cpp:
        (Inspector::RemoteInspector::listingForInspectionTarget const):
        Just use the debuggableType strings that WebInspectorUI ultimately wants.

2019-05-23  Tadeu Zagallo  <tzagallo@apple.com>

        DFG::OSREntry should not perform arity check
        https://bugs.webkit.org/show_bug.cgi?id=198189

        Reviewed by Saam Barati.

        The check prevents OSR entering from hot loops inside functions that were called
        with too few arguments.

        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):

2019-05-23  Ross Kirsling  <ross.kirsling@sony.com>

        Lexer<T>::parseDecimal ought to ASSERT isASCIIDigit
        https://bugs.webkit.org/show_bug.cgi?id=198156

        Reviewed by Keith Miller.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseDecimal):
        Add ASSERT -- apparently the issue with doing so earlier was simply
        that m_current can be anything at all when m_buffer8 is non-empty.

        (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
        Clean up a few things in the vicinity of r245655:
         - fix token enum values in a couple of error cases added in the last patch
         - add UNLIKELY for existing error cases that forgot to use it
         - simplify some control flow

2019-05-23  Adrian Perez de Castro  <aperez@igalia.com>

        Fix a few missing header inclusions often masked by by unified sources
        https://bugs.webkit.org/show_bug.cgi?id=198180

        Reviewed by Eric Carlson.

        * assembler/PerfLog.cpp: Add missing <array> header inclusion.
        * wasm/WasmBinding.cpp: Add missing "WasmCallingConvention.h" inclusion.

2019-05-23  Tadeu Zagallo  <tzagallo@apple.com>

        createListFromArrayLike should throw if value is not an object
        https://bugs.webkit.org/show_bug.cgi?id=198138

        Reviewed by Yusuke Suzuki.

        According to the spec[1], createListFromArrayLike should throw a type error if the array-like value
        passed in is not an object.
        [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-createlistfromarraylike

        * runtime/JSObjectInlines.h:
        (JSC::createListFromArrayLike):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectConstruct):

2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] UnlinkedMetadataTable's offset table should be small
        https://bugs.webkit.org/show_bug.cgi?id=197910

        Reviewed by Saam Barati.

        In Gmail, we found that massive # of UnlinkedMetadataTable (21979 - 24727) exists. Each UnlinkedMetadataTable takes at least 204 bytes
        because of large (unsinged) offset table. This patch reduces the size of offset table by introducing 16bit version offset table.
        Previously our code for looking up Metadata is like this.

            offset = offsetTable32[opcode]
            metadata = (SomeOp::Metadata*)table[offset] + id

        Instead, we introduce uint16_t offset table. The lookup code becomes like this.

            offset = offsetTable16[opcode]
            if (!offset)
                offset = offsetTable32[opcode]
            metadata = (SomeOp::Metadata*)table[offset] + id

        We use 0 offset as a marker to indicate that we have 32bit offset table. This is OK since 0 offset does not appear since all the offsets
        included in this table is larger than s_offset16TableSize.

        32bit offset table is allocated only when the offset exceeds 16bit range. It means that this will be used only when Metadata table is larger
        than almost 64KB. Even in Gmail, such MetadataTable is rare, and additional 32bit offset table size does not matter much in this case since
        MetadataTable is already so large.

        Based on the # of UnlinkedMetadataTables, this optimization should improve Gmail steady state memory by 2MB.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/MetadataTable.cpp:
        (JSC::MetadataTable::~MetadataTable):
        (JSC::MetadataTable::destroy):
        * bytecode/MetadataTable.h:
        (JSC::MetadataTable::ref):
        (JSC::MetadataTable::deref):
        (JSC::MetadataTable::buffer):
        (JSC::MetadataTable::is32Bit const):
        (JSC::MetadataTable::offsetTable16 const):
        (JSC::MetadataTable::offsetTable32 const):
        (JSC::MetadataTable::totalSize const):
        (JSC::MetadataTable::getOffset const):
        (JSC::MetadataTable::getImpl):
        (JSC::MetadataTable::ref const): Deleted.
        (JSC::MetadataTable::deref const): Deleted.
        * bytecode/Opcode.cpp:
        * bytecode/UnlinkedMetadataTable.cpp: Added.
        (JSC::UnlinkedMetadataTable::finalize):
        * bytecode/UnlinkedMetadataTable.h:
        (JSC::UnlinkedMetadataTable::create):
        (JSC::UnlinkedMetadataTable::totalSize const):
        (JSC::UnlinkedMetadataTable::offsetTableSize const):
        (JSC::UnlinkedMetadataTable::preprocessBuffer const):
        (JSC::UnlinkedMetadataTable::buffer const):
        (JSC::UnlinkedMetadataTable::offsetTable16 const):
        (JSC::UnlinkedMetadataTable::offsetTable32 const):
        * bytecode/UnlinkedMetadataTableInlines.h:
        (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
        (JSC::UnlinkedMetadataTable::addEntry):
        (JSC::UnlinkedMetadataTable::sizeInBytes):
        (JSC::UnlinkedMetadataTable::link):
        (JSC::UnlinkedMetadataTable::unlink):
        (JSC::UnlinkedMetadataTable::finalize): Deleted.
        * llint/LowLevelInterpreter.asm:
        * runtime/CachedTypes.cpp:
        (JSC::CachedMetadataTable::encode):
        (JSC::CachedMetadataTable::decode const):

2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] ArrayAllocationProfile should not access to butterfly in concurrent compiler
        https://bugs.webkit.org/show_bug.cgi?id=197809

        Reviewed by Michael Saboff.

        ArrayAllocationProfile assumes that Butterfly can be accessed concurrently. But this is not correct now
        since LargeAllocation Butterfly can be realloced. In this patch, we switch profiling array allocations
        only in the main thread. This allocation profiling is repeatedly called in the main thread's slow path,
        and it is also called when updating the profiles in the main thread.

        We also rename updateAllPredictionsAndCountLiveness to updateAllValueProfilePredictionsAndCountLiveness
        since it only cares ValueProfiles.

        * bytecode/ArrayAllocationProfile.cpp:
        (JSC::ArrayAllocationProfile::updateProfile):
        * bytecode/ArrayAllocationProfile.h:
        (JSC::ArrayAllocationProfile::selectIndexingTypeConcurrently):
        (JSC::ArrayAllocationProfile::selectIndexingType):
        (JSC::ArrayAllocationProfile::vectorLengthHintConcurrently):
        (JSC::ArrayAllocationProfile::vectorLengthHint):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness):
        (JSC::CodeBlock::updateAllValueProfilePredictions):
        (JSC::CodeBlock::shouldOptimizeNow):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): Deleted.
        * bytecode/CodeBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink Metadata
        https://bugs.webkit.org/show_bug.cgi?id=197940

        Reviewed by Michael Saboff.

        We get Metadata related data in Gmail and it turns out the following things.

        1. At peak, MetadataTable eats a lot of bytes (30 MB - 50 MB, sometimes 70 MB while total Gmail footprint is 400 - 500 MB).
        2. After full GC happens, most of Metadata is destroyed while some are kept. Still keeps 1 MB. But after the GC, # of MetadataTable eventually grows again.

        If we shrink Metadata, we can reduce the peak memory footprint in Gmail.

        This patch shrinks Metadata. This patch first focus on low hanging fruits: it does not include the change removing OSR exit JSValue in ValueProfile.
        This patch uses fancy bit juggling & leverages nice data types to reduce Metadata, as follows.

        1. ValueProfile is reduced from 32 to 24. It reduces Metadata using ValueProfile.
        2. ArrayProfile is reduced from 16 to 12. Ditto.
        3. OpCall::Metadata is reduced from 88 to 64.
        4. OpGetById::Metadata is reduced from 56 to 40.
        5. OpToThis::Metadata is reduced from 48 to 32.
        6. OpNewObject::Metadata is reduced from 32 to 16.

        According to the gathered data, it should reduce 1-2MB in steady state in Gmail, much more in peak memory, ~1 MB in the state just after full GC.
        It also improves RAMification by 0.3% (6 runs).

        * bytecode/ArrayProfile.cpp:
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::ArrayProfile):
        (JSC::ArrayProfile::bytecodeOffset const): Deleted.
        (JSC::ArrayProfile::isValid const): Deleted.
        * bytecode/BytecodeList.rb:
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::getArrayProfile):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::dumpValueProfiles):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::valueProfileForArgument):
        * bytecode/CodeBlockInlines.h:
        (JSC::CodeBlock::forEachValueProfile):
        (JSC::CodeBlock::forEachArrayProfile):
        * bytecode/GetByIdMetadata.h:
        We use ProtoLoad's JSObject's high bits to embed hitCountForLLIntCaching and mode, since they
        are always zero for ProtoLoad mode.

        (): Deleted.
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/LLIntCallLinkInfo.h:
        (JSC::LLIntCallLinkInfo::isLinked const):
        (JSC::LLIntCallLinkInfo::link):
        (JSC::LLIntCallLinkInfo::unlink):
        (JSC::LLIntCallLinkInfo::callee const):
        (JSC::LLIntCallLinkInfo::lastSeenCallee const):
        (JSC::LLIntCallLinkInfo::clearLastSeenCallee):
        (JSC::LLIntCallLinkInfo::LLIntCallLinkInfo): Deleted.
        (JSC::LLIntCallLinkInfo::isLinked): Deleted.
        In LLIntCallLinkInfo, we always set the same value to lastSeenCallee and callee. But later, callee can be cleared.
        It means that we can represent them in one value + cleared flag. We encode this flag into the lowest bit of the callee cell so
        that we can make them one pointer. We also use PackedRawSentinelNode to get some space, and embed ArrayProfile into this space
        to get further memory reduction.

        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
        * bytecode/LazyOperandValueProfile.h:
        (JSC::LazyOperandValueProfile::LazyOperandValueProfile):
        (JSC::LazyOperandValueProfile::key const):
        * bytecode/MetadataTable.h:
        (JSC::MetadataTable::buffer):
        * bytecode/ObjectAllocationProfile.h:
        (JSC::ObjectAllocationProfileBase::offsetOfAllocator):
        (JSC::ObjectAllocationProfileBase::offsetOfStructure):
        (JSC::ObjectAllocationProfileBase::clear):
        (JSC::ObjectAllocationProfileBase::visitAggregate):
        (JSC::ObjectAllocationProfile::setPrototype):
        (JSC::ObjectAllocationProfileWithPrototype::prototype):
        (JSC::ObjectAllocationProfileWithPrototype::clear):
        (JSC::ObjectAllocationProfileWithPrototype::visitAggregate):
        (JSC::ObjectAllocationProfileWithPrototype::setPrototype):
        (JSC::ObjectAllocationProfile::offsetOfAllocator): Deleted.
        (JSC::ObjectAllocationProfile::offsetOfStructure): Deleted.
        (JSC::ObjectAllocationProfile::offsetOfInlineCapacity): Deleted.
        (JSC::ObjectAllocationProfile::ObjectAllocationProfile): Deleted.
        (JSC::ObjectAllocationProfile::isNull): Deleted.
        (JSC::ObjectAllocationProfile::structure): Deleted.
        (JSC::ObjectAllocationProfile::prototype): Deleted.
        (JSC::ObjectAllocationProfile::inlineCapacity): Deleted.
        (JSC::ObjectAllocationProfile::clear): Deleted.
        (JSC::ObjectAllocationProfile::visitAggregate): Deleted.
        * bytecode/ObjectAllocationProfileInlines.h:
        (JSC::ObjectAllocationProfileBase<Derived>::initializeProfile):
        (JSC::ObjectAllocationProfileBase<Derived>::possibleDefaultPropertyCount):
        (JSC::ObjectAllocationProfile::initializeProfile): Deleted.
        (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted.
        OpNewObject's ObjectAllocationProfile does not need to hold prototype. So we have two versions now, ObjectAllocationProfile and ObjectAllocationProfileWithPrototype
        to cut one pointer. We also remove inline capacity since this can be retrieved from Structure.

        * bytecode/Opcode.h:
        * bytecode/ValueProfile.h:
        (JSC::ValueProfileBase::ValueProfileBase):
        (JSC::ValueProfileBase::totalNumberOfSamples const):
        (JSC::ValueProfileBase::isSampledBefore const):
        (JSC::ValueProfileBase::dump):
        (JSC::ValueProfileBase::computeUpdatedPrediction):
        (JSC::MinimalValueProfile::MinimalValueProfile):
        (JSC::ValueProfileWithLogNumberOfBuckets::ValueProfileWithLogNumberOfBuckets):
        (JSC::ValueProfile::ValueProfile):
        (JSC::getValueProfileBytecodeOffset): Deleted.
        Bytecode offset is no longer used. And sample count is not used effectively.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCreateThis):
        * ftl/FTLAbstractHeapRepository.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupFrame):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupFrame):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_to_this):
        (JSC::JIT::emit_op_create_this):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_to_this):
        * jit/JITOperations.cpp:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_id):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setUpCall):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/FunctionRareData.h:
        * tools/HeapVerifier.cpp:
        (JSC::HeapVerifier::validateJSCell):

2019-05-22  Ross Kirsling  <ross.kirsling@sony.com>

        [ESNext] Implement support for Numeric Separators
        https://bugs.webkit.org/show_bug.cgi?id=196351

        Reviewed by Keith Miller.

        Implement the following proposal, which is now Stage 3:
          https://github.com/tc39/proposal-numeric-separator

        Specifically, this allows `_` to be used as a separator in numeric literals.
        It may be inserted arbitrarily without semantic effect, but it may not occur:
          - multiple times in a row
          - at the beginning or end of the literal
          - adjacent to `0x`, `0b`, `0o`, `.`, `e`, or `n`
          - after a leading zero (e.g. `0_123`), even in sloppy mode

        * parser/Lexer.cpp:
        (JSC::isASCIIDigitOrSeparator): Added.
        (JSC::isASCIIHexDigitOrSeparator): Added.
        (JSC::isASCIIBinaryDigitOrSeparator): Added.
        (JSC::isASCIIOctalDigitOrSeparator): Added.
        (JSC::Lexer<T>::parseHex):
        (JSC::Lexer<T>::parseBinary):
        (JSC::Lexer<T>::parseOctal):
        (JSC::Lexer<T>::parseDecimal):
        (JSC::Lexer<T>::parseNumberAfterDecimalPoint):
        (JSC::Lexer<T>::parseNumberAfterExponentIndicator):
        (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
        * parser/Lexer.h:

2019-05-22  Tadeu Zagallo  <tzagallo@apple.com>

        llint_slow_path_get_by_id needs to hold the CodeBlock's lock to update the metadata's mode
        https://bugs.webkit.org/show_bug.cgi?id=198120
        <rdar://problem/49668795>

        Reviewed by Michael Saboff.

        There are two places in llint_slow_path_get_by_id where we change the
        metadata's mode without holding the CodeBlock's lock. This is an issue
        when switching to and from ArrayLength mode, since other places can
        either get a pointer to an array profile that will be overwritten or
        an array profile that hasn't yet been initialized.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

2019-05-22  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r245634.
        https://bugs.webkit.org/show_bug.cgi?id=198140

        'This patch makes JSC crash on launch in debug builds'
        (Requested by tadeuzagallo on #webkit).

        Reverted changeset:

        "[ESNext] Implement support for Numeric Separators"
        https://bugs.webkit.org/show_bug.cgi?id=196351
        https://trac.webkit.org/changeset/245634

2019-05-22 Zagallo  <tzagallo@apple.com>

        Fix validateExceptionChecks for CLoop
        https://bugs.webkit.org/show_bug.cgi?id=191253

        Reviewed by Keith Miller.

        validateExceptionChecks relies on the stack position to determine if
        an ExceptionScope was going to be handled by LLInt or JIT, but when
        running with CLoop, it was comparing VM::topEntryFrame, which was an
        address inside the CLoopStack to machine stack. This caused exceptions
        to never be checked on x86 and always fail on ARM.

        * runtime/CatchScope.h:
        * runtime/ExceptionScope.h:
        * runtime/ThrowScope.h:
        * runtime/VM.cpp:
        (JSC::VM::currentCLoopStackPointer const):
        * runtime/VM.h:

2019-05-22  Tadeu Zagallo  <tzagallo@apple.com>

        Stack-buffer-overflow in decodeURIComponent
        https://bugs.webkit.org/show_bug.cgi?id=198109
        <rdar://problem/50397550>

        Reviewed by Michael Saboff.

        Since r244828 we started using U8_MAX_LENGTH to determine the size of the buffer and
        U8_COUNT_TRAIL_BYTES when decoding UTF-8 sequences in JSC::decode. However, U8_MAX_LENGTH
        is defined as 4 and in pre-60 ICU U8_COUNT_TRAIL_BYTES returns 0..5.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::decode):

2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>

        Don't clear PropertyNameArray in Proxy code
        https://bugs.webkit.org/show_bug.cgi?id=197691

        Reviewed by Saam Barati.

        ProxyObject::performGetOwnPropertyNames clears the given PropertyNameArray to filter out non-enumerable keys.
        But this does not assume that PropertyNameArray already contains the keys collected in the different objects.
        We have an assumption that PropertyNameArray is always increasing, and JSPropertyNameEnumerator relies on this.
        Since ProxyObject::performGetOwnPropertyNames clears the passed PropertyNameArray which contained the other
        keys collected at some point of prototype hierarchy, this breaks JSPropertyNameEnumerator. Let's see the example.

        var object = { __proto__: someProxy, someKey: 42 };
        // Here, we first collect "someKey" in object. And using the same PropertyNameArray to add more keys from __proto__.
        // But Proxy accidentally clears the passed PropertyNameArray, so "someKey" becomes missing.
        for (var key in object);

        This patch fixes ProxyObject::performGetOwnPropertyNames. Using separate PropertyNameArray to collect keys, and
        filtering and adding them to the passed PropertyNameArray later. We also remove PropertyNameArray::reset method
        since this breaks JSPropertyNameEnumerator's assumption.

        We also fix the issue by changing seenKeys' HashSet<UniquedStringImpl*> to HashSet<RefPtr<UniquedStringImpl>>.
        They can be deallocated if it is not added to trapResult later and it is toString-ed result from 'toPropertyKey()'.

        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::reset): Deleted.
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):

2019-05-22  Ross Kirsling  <ross.kirsling@sony.com>

        [ESNext] Implement support for Numeric Separators
        https://bugs.webkit.org/show_bug.cgi?id=196351

        Reviewed by Keith Miller.

        Implement the following proposal, which is now Stage 3:
          https://github.com/tc39/proposal-numeric-separator

        Specifically, this allows `_` to be used as a separator in numeric literals.
        It may be inserted arbitrarily without semantic effect, but it may not occur:
          - multiple times in a row
          - at the beginning or end of the literal
          - adjacent to `0x`, `0b`, `0o`, `.`, `e`, or `n`
          - after a leading zero (e.g. `0_123`), even in sloppy mode

        * parser/Lexer.cpp:
        (JSC::isASCIIDigitOrSeparator): Added.
        (JSC::isASCIIHexDigitOrSeparator): Added.
        (JSC::isASCIIBinaryDigitOrSeparator): Added.
        (JSC::isASCIIOctalDigitOrSeparator): Added.
        (JSC::Lexer<T>::parseHex):
        (JSC::Lexer<T>::parseBinary):
        (JSC::Lexer<T>::parseOctal):
        (JSC::Lexer<T>::parseDecimal):
        (JSC::Lexer<T>::parseNumberAfterDecimalPoint):
        (JSC::Lexer<T>::parseNumberAfterExponentIndicator):
        (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
        * parser/Lexer.h:

2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] ArrayBufferContents::tryAllocate signs the pointer with allocation size and authenticates it with sizeInBytes
        https://bugs.webkit.org/show_bug.cgi?id=198101

        Reviewed by Michael Saboff.

        When we allocate 0-length ArrayBuffer, we allocate 1 byte storage instead because we would like to ensure that
        non-neutered ArrayBuffer always have non nullptr. While we allocate a 1 byte storage, this ArrayBuffer says
        sizeInBytes = 0. However, we accidentally configure the vector pointer with this 1 byte size in the constructor.
        In ARM64E device, we sign the vector pointer with modifier = 1 (1 byte size), and later we authenticate this
        pointer with modifier = 0 (sizeInBytes), and fail to authenticate the pointer.

        In this patch, we sign the pointer with sizeInBytes so that we correctly authenticate the 0 bytes vector pointer.

        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBufferContents::tryAllocate):

2019-05-21  Ross Kirsling  <ross.kirsling@sony.com>

        [PlayStation] Don't call fcntl.
        https://bugs.webkit.org/show_bug.cgi?id=197961

        Reviewed by Fujii Hironori.

        * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
        (Inspector::Socket::setup):
        Use WTF::setCloseOnExec and WTF::setNonBlock.

2019-05-21  Stephan Szabo  <stephan.szabo@sony.com>

        [PlayStation] Update initializer for changed port options
        https://bugs.webkit.org/show_bug.cgi?id=198057

        Reviewed by Ross Kirsling.

        * shell/playstation/Initializer.cpp:
        (initializer): Remove loading of shared JavaScriptCore
        library.

2019-05-21  Tadeu Zagallo  <tzagallo@apple.com>

        Fix production build after r245564
        https://bugs.webkit.org/show_bug.cgi?id=197898

        Reviewed by Keith Miller.

        The production configuration should not set CODE_SIGN_IDENTITY.

        * Configurations/ToolExecutable.xcconfig:

2019-05-21  Keith Miller  <keith_miller@apple.com>

        Unreviewed, add mistakenly ommited initializer.

        * runtime/RegExpInlines.h:

2019-05-21  Keith Miller  <keith_miller@apple.com>

        Unreviewed build fix add UNUSED_PARAM.

        * runtime/RegExpInlines.h:
        (JSC::PatternContextBufferHolder::PatternContextBufferHolder):

2019-05-20  Keith Miller  <keith_miller@apple.com>

        Cleanup Yarr regexp code around paren contexts.
        https://bugs.webkit.org/show_bug.cgi?id=198063

        Reviewed by Yusuke Suzuki.

        There are three refactoring changes around paren contexts:
        1. Make EncodedMatchResult the same type as MatchResult on X86_64 and arm64 and uint64_t elsewhere.
        2. All function pointer types for Yarr JIT generated code reserve space for paren contexts.
        3. initParenContextFreeList should bail based on VM::patternContextBufferSize as that's the buffer size anyway.

        * runtime/MatchResult.h:
        (JSC::MatchResult::MatchResult):
        * runtime/RegExpInlines.h:
        (JSC::PatternContextBufferHolder::PatternContextBufferHolder):
        (JSC::PatternContextBufferHolder::~PatternContextBufferHolder):
        (JSC::PatternContextBufferHolder::size):
        (JSC::RegExp::matchInline):
        * runtime/VM.h:
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::initParenContextFreeList):
        * yarr/YarrJIT.h:
        (JSC::Yarr::YarrCodeBlock::execute):

2019-05-20  Tadeu Zagallo  <tzagallo@apple.com>

        Only cache bytecode for API clients in data vaults
        https://bugs.webkit.org/show_bug.cgi?id=197898
        <rdar://problem/45945449>

        Reviewed by Keith Miller.

        Enforce that API clients only store cached bytecode in data vaults. This prevents
        another process from compromising the current one by tampering with the bytecode.

        * API/JSScript.mm:
        (validateBytecodeCachePath):
        (+[JSScript scriptOfType:withSource:andSourceURL:andBytecodeCache:inVirtualMachine:error:]):
        (+[JSScript scriptOfType:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:inVirtualMachine:error:]):
        * API/tests/testapi.mm:
        (cacheFileInDataVault):
        (testModuleBytecodeCache):
        (testProgramBytecodeCache):
        (testBytecodeCacheWithSyntaxError):
        (testBytecodeCacheWithSameCacheFileAndDifferentScript):
        (testCacheFileFailsWhenItsAlreadyCached):
        (testCanCacheManyFilesWithTheSameVM):
        (testIsUsingBytecodeCacheAccessor):
        (testBytecodeCacheValidation):
        (testObjectiveCAPI):
        * Configurations/ToolExecutable.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * testapi.entitlements: Added.

2019-05-20  Tadeu Zagallo  <tzagallo@apple.com>

        Fix 32-bit btyecode cache crashes
        https://bugs.webkit.org/show_bug.cgi?id=198035
        <rdar://problem/49905560>

        Reviewed by Michael Saboff.

        There were 2 32-bit issues with the bytecode cache:
        - UnlinkedFunctionExecutable::m_cachedCodeBlockForConstructOffset was not initialized.
          The code was relying on the other member of the union, `m_unlinkedCodeBlockForConstruct`,
          initializing both m_cachedCodeBlockForCallOffset and m_cachedCodeBlockForConstructOffset.
          This is undefined behavior and is also incorrect in 32-bit. Since m_unlinkedCodeBlockForConstruct
          is 32-bit, it only initializes the first member of the struct.
        - Encoder::Page was not aligned at the end. This lead to unaligned allocations on subsequent
          pages, since the start of the following page would not be aligned.

        * runtime/CachedTypes.cpp:
        (JSC::Encoder::release):
        (JSC::Encoder::Page::alignEnd):
        (JSC::Encoder::allocateNewPage):
        (JSC::VariableLengthObject::buffer const):
        (JSC::VariableLengthObject::allocate):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):

2019-05-20  Ross Kirsling  <ross.kirsling@sony.com>

        [WinCairo] Implement Remote Web Inspector Client.
        https://bugs.webkit.org/show_bug.cgi?id=197434

        Reviewed by Don Olmstead.

        * inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
        (Inspector::RemoteInspectorConnectionClient::didAccept): Deleted.
        * inspector/remote/socket/RemoteInspectorConnectionClient.h:
        (Inspector::RemoteInspectorConnectionClient::didAccept):
        * inspector/remote/socket/RemoteInspectorServer.cpp:
        (Inspector::RemoteInspectorServer::dispatchMap):

2019-05-20  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLIB] Crash when instantiating a js object registered with jsc_context_register_class on window object cleared
        https://bugs.webkit.org/show_bug.cgi?id=198037

        Reviewed by Michael Catanzaro.

        This happens because JSCClass is keeping a pointer to the JSCContext used when the class is registered, and the
        context can be destroyed before the class. We can't a reference to the context, because we don't really want to
        keep it alive. The life of the JSCClass is not attached to the JSCContext, but to its wrapped global context, so
        we can keep a pointer to the JSGlobalContextRef instead and create a new JSCContext wrapping it when
        needed. This patch is also making the context property of JSCClass non-readable, which was always the intention,
        that's why there isn't a public getter in the API.

        * API/glib/JSCCallbackFunction.cpp:
        (JSC::JSCCallbackFunction::construct): Pass the context to jscClassGetOrCreateJSWrapper().
        * API/glib/JSCClass.cpp:
        (jscClassGetProperty): Remove the getter for context property.
        (jscClassSetProperty): Get the JSGlobalContextRef from the given JSCContext.
        (jsc_class_class_init): Make context writable only.
        (jscClassCreate): Use the passed in context instead of the member.
        (jscClassGetOrCreateJSWrapper): It receives now the context as parameter.
        (jscClassCreateContextWithJSWrapper): Ditto.
        (jscClassCreateConstructor): Get or create a JSCContext for our JSGlobalContextRef.
        (jscClassAddMethod): Ditto.
        (jsc_class_add_property): Ditto.
        * API/glib/JSCClassPrivate.h:
        * API/glib/JSCContext.cpp:
        (jsc_context_evaluate_in_object): Pass the context to jscClassCreateContextWithJSWrapper().
        * API/glib/JSCValue.cpp:
        (jsc_value_new_object): Pass the context to jscClassGetOrCreateJSWrapper().

2019-05-19  Tadeu Zagallo  <tzagallo@apple.com>

        Add support for %pid in dumpJITMemoryPath
        https://bugs.webkit.org/show_bug.cgi?id=198026

        Reviewed by Saam Barati.

        This is necessary when using dumpJITMemory with Safari. Otherwise, multiple WebContent
        processes will try to write to the same file at the same time, which will crash since
        the file is open with exclusive locking.

        * jit/ExecutableAllocator.cpp:
        (JSC::dumpJITMemory):

2019-05-18  Tadeu Zagallo  <tzagallo@apple.com>

        Add extra information to dumpJITMemory
        https://bugs.webkit.org/show_bug.cgi?id=197998

        Reviewed by Saam Barati.

        Add ktrace events around the memory dump and mach_absolute_time to link the
        events with the entries in the dump. Additionally, add a background queue
        to flush on a configurable interval, since the atexit callback does not work
        in every situation.

        * jit/ExecutableAllocator.cpp:
        (JSC::dumpJITMemory):
        * runtime/Options.h:

2019-05-17  Justin Michaud  <justin_michaud@apple.com>

        [WASM-References] Add support for Anyref in parameters and return types, Ref.null and Ref.is_null for Anyref values.
        https://bugs.webkit.org/show_bug.cgi?id=197969

        Reviewed by Keith Miller.

        Add a new runtime option for wasm references.
        Add support for Anyref as a value type.
        Add support for Anyref in parameters and return types of Wasm functions. JSValues are marshalled into/out of wasm Anyrefs
                as a black box, except null which becomes a Nullref value. Nullref is not expressible in the bytecode or in the js API.
        Add Ref.null and Ref.is_null for Anyref values. Support for these functions with funcrefs is out of scope.

        * runtime/Options.h:
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::tmpForType):
        (JSC::Wasm::AirIRGenerator::AirIRGenerator):
        (JSC::Wasm::AirIRGenerator::addConstant):
        (JSC::Wasm::AirIRGenerator::addRefIsNull):
        (JSC::Wasm::AirIRGenerator::addReturn):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addRefIsNull):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConventionAir::marshallArgument const):
        (JSC::Wasm::CallingConventionAir::setupCall const):
        * wasm/WasmFormat.h:
        (JSC::Wasm::isValueType):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::FunctionParser):
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::addRefIsNull):
        * wasm/generateWasmOpsHeader.py:
        (bitSet):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::wasmToJS):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
        * wasm/wasm.json:

2019-05-17  Don Olmstead  <don.olmstead@sony.com>

        [CMake] Use builtin FindICU
        https://bugs.webkit.org/show_bug.cgi?id=197934

        Reviewed by Michael Catanzaro.

        Remove uses of ICU_INCLUDE_DIRS and ICU_LIBRARIES.

        * CMakeLists.txt:
        * PlatformWin.cmake:

2019-05-17  Keith Rollin  <krollin@apple.com>

        Re-enable generate-xcfilelists
        https://bugs.webkit.org/show_bug.cgi?id=197933
        <rdar://problem/50831677>

        Reviewed by Jonathan Bedard.

        The following two tasks have been completed, and we can re-enable
        generate-xcfilelists:

        Bug 197619 <rdar://problem/50507392> Temporarily disable generate-xcfilelists (197619)
        Bug 197622 <rdar://problem/50508222> Rewrite generate-xcfilelists in Python (197622)

        * Scripts/check-xcfilelists.sh:

2019-05-16  Keith Miller  <keith_miller@apple.com>

        Wasm should cage the memory base pointers in structs
        https://bugs.webkit.org/show_bug.cgi?id=197620

        Reviewed by Saam Barati.

        Currently, we use cageConditionally; this only matters for API
        users since the web content process cannot disable primitive
        gigacage. This patch also adds a set helper for union/intersection
        of RegisterSets.

        * assembler/CPU.h:
        (JSC::isARM64E):
        * jit/RegisterSet.h:
        (JSC::RegisterSet::set):
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmInstance.h:
        (JSC::Wasm::Instance::cachedMemory const):
        (JSC::Wasm::Instance::updateCachedMemory):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::grow):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::memory const):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):

2019-05-16  David Kilzer  <ddkilzer@apple.com>

        REGRESSION (r15133): Fix leak of JSStringRef in minidom
        <https://webkit.org/b/197968>
        <rdar://problem/50872430>

        Reviewed by Joseph Pecoraro.

        * API/tests/minidom.c:
        (print): Call JSStringRelease() to fix the leak.

2019-05-16  Ross Kirsling  <ross.kirsling@sony.com>

        [JSC] Invalid AssignmentTargetType should be an early error.
        https://bugs.webkit.org/show_bug.cgi?id=197603

        Reviewed by Keith Miller.

        Since ES6, expressions like 0++, ++0, 0 = 0, and 0 += 0 are all specified as early errors:
          https://tc39.github.io/ecma262/#sec-update-expressions-static-semantics-early-errors
          https://tc39.github.io/ecma262/#sec-assignment-operators-static-semantics-early-errors

        We currently throw late ReferenceErrors for these -- let's turn them into early SyntaxErrors.
        (This is based on the expectation that https://github.com/tc39/ecma262/pull/1527 will be accepted;
        if that doesn't come to pass, we can subsequently introduce early ReferenceError and revise these.)

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitBytecode): Add an assert for "function call LHS" case.
        (JSC::PrefixNode::emitBytecode): Add an assert for "function call LHS" case.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::isLocation): Added.
        (JSC::ASTBuilder::isAssignmentLocation): Fix misleading parameter name.
        (JSC::ASTBuilder::isFunctionCall): Added.
        (JSC::ASTBuilder::makeAssignNode): Add an assert for "function call LHS" case.
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::isLocation): Added.
        (JSC::SyntaxChecker::isAssignmentLocation): Fix incorrect definition and align with ASTBuilder.
        (JSC::SyntaxChecker::isFunctionCall): Added.
        * parser/Nodes.h:
        (JSC::ExpressionNode::isFunctionCall const): Added.
        Ensure that the parser can check whether an expression node is a function call.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::isSimpleAssignmentTarget): Added.
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseUnaryExpression): See below.
        * parser/Parser.h:
        Throw SyntaxError whenever an assignment or update expression's target is invalid.
        Unfortunately, it seems that web compatibility obliges us to exempt the "function call LHS" case in sloppy mode.
        (https://github.com/tc39/ecma262/issues/257#issuecomment-195106880)

        Additional cleanup items:
          - Make use of `semanticFailIfTrue` for `isMetaProperty` checks, as it's equivalent.
          - Rename `requiresLExpr` to `hasPrefixUpdateOp` since it's now confusing,
            and get rid of `modifiesExpr` since it refers to the exact same condition.
          - Stop setting `lastOperator` near the end -- one case was incorrect and regardless neither is used.

2019-05-15  Saam Barati  <sbarati@apple.com>

        Bound liveness of SetArgumentMaybe nodes when maximal flush insertion phase is enabled
        https://bugs.webkit.org/show_bug.cgi?id=197855
        <rdar://problem/50236506>

        Reviewed by Michael Saboff.

        Maximal flush insertion phase assumes it can extend the live range of
        variables. However, this is not true with SetArgumentMaybe nodes, because
        they are not guaranteed to demarcate the birth of a variable in the way
        that SetArgumentDefinitely does. This caused things to break in SSA conversion
        when we wanted to use the result of a SetArgumentMaybe node. To obviate this,
        when we're done inlining something with SetArgumentMaybes, we SetLocal(undefined)
        to the same set of locals. This caps the live range of the SetArgumentMaybe
        and makes it so that extending the live range of the SetLocal is valid.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleVarargsInlining):

2019-05-14  Keith Miller  <keith_miller@apple.com>

        Fix issue with byteOffset on ARM64E
        https://bugs.webkit.org/show_bug.cgi?id=197884

        Reviewed by Saam Barati.

        We forgot to remove the tag from the ArrayBuffer's data
        pointer. This corrupted data when computing the offset.  We didn't
        catch this because we didn't run any with a non-zero byteOffset in
        the JITs.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
        (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
        * jit/IntrinsicEmitter.cpp:
        (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):

2019-05-14  Tadeu Zagallo  <tzagallo@apple.com>

        REGRESSION (r245249): ASSERTION FAILED: !m_needExceptionCheck seen with stress/proxy-delete.js and stress/proxy-property-descriptor.js
        https://bugs.webkit.org/show_bug.cgi?id=197885
        <rdar://problem/50770190>

        Reviewed by Yusuke Suzuki.

        In r245249 we added a throw scope to JSObject::getOwnPropertyDescriptor and its
        callers now need to check for exceptions.

        * runtime/ProxyObject.cpp:
        (JSC::performProxyGet):
        (JSC::ProxyObject::performDelete):

2019-05-14  Ross Kirsling  <ross.kirsling@sony.com>

        Unreviewed restoration of non-unified build.

        * dfg/DFGMinifiedID.h:
        * runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp:

2019-05-14  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink sizeof(UnlinkedFunctionExecutable) more
        https://bugs.webkit.org/show_bug.cgi?id=197833

        Reviewed by Darin Adler.

        It turns out that Gmail creates so many JSFunctions, FunctionExecutables, and UnlinkedFunctionExecutables.
        So we should shrink size of them to save memory. As a first step, this patch reduces the sizeof(UnlinkedFunctionExecutable) more by 16 bytes.

        1. We reorder some fields to get 8 bytes. And we use 31 bits for xxx offset things since their maximum size should be within 31 bits due to
           String's length & int32_t representation in our parser.

        2. We drop m_inferredName and prefer m_ecmaName. The inferred name is used to offer better function name when the function expression lacks
           the name, but now ECMAScript has a specified semantics to name those functions with intuitive names. We should use ecmaName consistently,
           and should not eat 8 bytes for inferred names in UnlinkedFunctionExecutable.

        We also fix generator ecma name.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::inferredName const):
        * bytecode/InlineCallFrame.cpp:
        (JSC::InlineCallFrame::inferredName const):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createGeneratorFunctionBody):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createProperty):
        (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
        (JSC::ASTBuilder::makeAssignNode):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::operator== const):
        (JSC::FunctionMetadataNode::dump const):
        * parser/Nodes.h:
        * runtime/CachedTypes.cpp:
        (JSC::CachedFunctionExecutable::ecmaName const):
        (JSC::CachedFunctionExecutable::encode):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::CachedFunctionExecutable::inferredName const): Deleted.
        * runtime/FunctionExecutable.h:
        * runtime/FunctionExecutableDump.cpp:
        (JSC::FunctionExecutableDump::dump const):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::calculatedDisplayName):
        (JSC::getCalculatedDisplayName):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::displayName):
        (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):

2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Compress JIT related data more by using Packed<>
        https://bugs.webkit.org/show_bug.cgi?id=197866

        Reviewed by Saam Barati.

        This patch leverages Packed<> more to reduce JIT related data size. When we measure memory usage on Gmail, we found that a lot of memory is
        consumed in DFG data. This patch attempts to reduce that size by using Packed<> to make various data structure's alignment 1.

        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::shrinkToFit): Add more shrinkToFit.
        * dfg/DFGMinifiedID.h: Make alignment = 1.
        (JSC::DFG::MinifiedID::operator! const):
        (JSC::DFG::MinifiedID::operator== const):
        (JSC::DFG::MinifiedID::operator!= const):
        (JSC::DFG::MinifiedID::operator< const):
        (JSC::DFG::MinifiedID::operator> const):
        (JSC::DFG::MinifiedID::operator<= const):
        (JSC::DFG::MinifiedID::operator>= const):
        (JSC::DFG::MinifiedID::hash const):
        (JSC::DFG::MinifiedID::dump const):
        (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
        (JSC::DFG::MinifiedID::bits const):
        * dfg/DFGMinifiedIDInlines.h:
        (JSC::DFG::MinifiedID::MinifiedID):
        * dfg/DFGMinifiedNode.cpp:
        (JSC::DFG::MinifiedNode::fromNode): Make sizeof(MinifiedNode) from 16 to 13 with alignment = 1.
        * dfg/DFGMinifiedNode.h:
        (JSC::DFG::MinifiedNode::id const):
        (JSC::DFG::MinifiedNode::hasConstant const):
        (JSC::DFG::MinifiedNode::constant const):
        (JSC::DFG::MinifiedNode::isPhantomDirectArguments const):
        (JSC::DFG::MinifiedNode::isPhantomClonedArguments const):
        (JSC::DFG::MinifiedNode::hasInlineCallFrame const):
        (JSC::DFG::MinifiedNode::inlineCallFrame const):
        (JSC::DFG::MinifiedNode::op const): Deleted.
        (JSC::DFG::MinifiedNode::hasInlineCallFrame): Deleted.
        * dfg/DFGVariableEvent.h: Make sizeof(VariableEvent) from 12 to 10 with alignment = 1.
        (JSC::DFG::VariableEvent::fillGPR):
        (JSC::DFG::VariableEvent::fillPair):
        (JSC::DFG::VariableEvent::fillFPR):
        (JSC::DFG::VariableEvent::birth):
        (JSC::DFG::VariableEvent::spill):
        (JSC::DFG::VariableEvent::death):
        (JSC::DFG::VariableEvent::setLocal):
        (JSC::DFG::VariableEvent::movHint):
        (JSC::DFG::VariableEvent::id const):
        (JSC::DFG::VariableEvent::gpr const):
        (JSC::DFG::VariableEvent::tagGPR const):
        (JSC::DFG::VariableEvent::payloadGPR const):
        (JSC::DFG::VariableEvent::fpr const):
        (JSC::DFG::VariableEvent::spillRegister const):
        (JSC::DFG::VariableEvent::bytecodeRegister const):
        (JSC::DFG::VariableEvent::machineRegister const):
        (JSC::DFG::VariableEvent::variableRepresentation const):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::tryToSetConstantRecovery):

2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>

        [WTF] Simplify GCThread and CompilationThread flags by adding them to WTF::Thread
        https://bugs.webkit.org/show_bug.cgi?id=197146

        Reviewed by Saam Barati.

        Rename Heap::Thread to Heap::HeapThread to remove conflict between WTF::Thread.

        * heap/AlignedMemoryAllocator.cpp:
        (JSC::AlignedMemoryAllocator::registerDirectory):
        * heap/Heap.cpp:
        (JSC::Heap::HeapThread::HeapThread):
        (JSC::Heap::Heap):
        (JSC::Heap::runCurrentPhase):
        (JSC::Heap::runBeginPhase):
        (JSC::Heap::resumeThePeriphery):
        (JSC::Heap::requestCollection):
        (JSC::Heap::isCurrentThreadBusy):
        (JSC::Heap::notifyIsSafeToCollect):
        (JSC::Heap::Thread::Thread): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::incrementDeferralDepth):
        (JSC::Heap::decrementDeferralDepth):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::prepareForAllocation):

2019-05-13  Saam Barati  <sbarati@apple.com>

        macro assembler code-pointer tagging has its arguments backwards
        https://bugs.webkit.org/show_bug.cgi?id=197677

        Reviewed by Michael Saboff.

        We had the destination as the leftmost instead of the rightmost argument,
        which goes against the convention of how we order arguments in macro assembler
        methods.

        * assembler/MacroAssemblerARM64E.h:
        (JSC::MacroAssemblerARM64E::tagReturnAddress):
        (JSC::MacroAssemblerARM64E::untagReturnAddress):
        (JSC::MacroAssemblerARM64E::tagPtr):
        (JSC::MacroAssemblerARM64E::untagPtr):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * ftl/FTLThunks.cpp:
        (JSC::FTL::genericGenerationThunkGenerator):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::prepareForTailCall):
        * jit/ThunkGenerators.cpp:
        (JSC::emitPointerValidation):
        (JSC::arityFixupGenerator):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):

2019-05-13  Tadeu Zagallo  <tzagallo@apple.com>

        JSObject::getOwnPropertyDescriptor is missing an exception check
        https://bugs.webkit.org/show_bug.cgi?id=197693
        <rdar://problem/50441784>

        Reviewed by Saam Barati.

        The method table call to getOwnPropertySlot might throw, and JSObject::getOwnPropertyDescriptor
        must handle the exception before calling PropertySlot::getValue, which can also throw.

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):

2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Compress miscelaneous JIT related data structures with Packed<>
        https://bugs.webkit.org/show_bug.cgi?id=197830

        Reviewed by Saam Barati.

        This patch leverages Packed<> to compress miscelaneous data structures related to JIT.

        1. JIT IC data structures

        2. ValueRecovery

            We use Packed<> for EncodedJSValue in ValueRecovery. This means that conservative GC cannot find
            these values. But this is OK anyway since ValueRecovery's constant should be already registered
            in DFG graph. From 16 (alignment 8) to 9 (alignment 1).

        3. FTL::ExitValue

            We use Packed<> for EncodedJSValue in FTL::ExitValue. This is also OK since this constant should
            be already registered by DFG/FTL graph. From 16 (alignment 8) to 9 (alignment 1).

        * assembler/CodeLocation.h:
        * bytecode/ByValInfo.h:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::callReturnLocation):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::nearCallMode const):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::addJITAddIC):
        (JSC::CodeBlock::addJITMulIC):
        (JSC::CodeBlock::addJITSubIC):
        (JSC::CodeBlock::addJITNegIC):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addMathIC):
        * bytecode/InlineCallFrame.h:
        (JSC::InlineCallFrame::InlineCallFrame):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::inGPR):
        (JSC::ValueRecovery::inPair):
        (JSC::ValueRecovery::inFPR):
        (JSC::ValueRecovery::displacedInJSStack):
        (JSC::ValueRecovery::constant):
        (JSC::ValueRecovery::directArgumentsThatWereNotCreated):
        (JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
        (JSC::ValueRecovery::gpr const):
        (JSC::ValueRecovery::tagGPR const):
        (JSC::ValueRecovery::payloadGPR const):
        (JSC::ValueRecovery::fpr const):
        (JSC::ValueRecovery::virtualRegister const):
        (JSC::ValueRecovery::withLocalsOffset const):
        (JSC::ValueRecovery::constant const):
        (JSC::ValueRecovery::nodeID const):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileValueSub):
        (JSC::DFG::SpeculativeJIT::compileValueNegate):
        (JSC::DFG::SpeculativeJIT::compileValueMul):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::materializeNewObject):
        * ftl/FTLExitValue.h:
        (JSC::FTL::ExitValue::inJSStack):
        (JSC::FTL::ExitValue::inJSStackAsInt32):
        (JSC::FTL::ExitValue::inJSStackAsInt52):
        (JSC::FTL::ExitValue::inJSStackAsDouble):
        (JSC::FTL::ExitValue::constant):
        (JSC::FTL::ExitValue::exitArgument):
        (JSC::FTL::ExitValue::exitArgument const):
        (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
        (JSC::FTL::ExitValue::constant const):
        (JSC::FTL::ExitValue::virtualRegister const):
        (JSC::FTL::ExitValue::objectMaterialization const):
        (JSC::FTL::ExitValue::withVirtualRegister const):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
        (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
        * jit/CachedRecovery.h:
        * jit/CallFrameShuffleData.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emit_op_sub):
        * jit/JITMathIC.h:
        (JSC::isProfileEmpty):
        (JSC::JITBinaryMathIC::JITBinaryMathIC):
        (JSC::JITUnaryMathIC::JITUnaryMathIC):
        * jit/PolymorphicCallStubRoutine.h:
        (JSC::PolymorphicCallNode::hasCallLinkInfo):
        * jit/SnippetOperand.h:
        (JSC::SnippetOperand::asRawBits const):
        (JSC::SnippetOperand::asConstInt32 const):
        (JSC::SnippetOperand::asConstDouble const):
        (JSC::SnippetOperand::setConstInt32):
        (JSC::SnippetOperand::setConstDouble):

2019-05-12  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Compress Watchpoint size by using enum type and Packed<> data structure
        https://bugs.webkit.org/show_bug.cgi?id=197730

        Reviewed by Filip Pizlo.

        Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
        reducing each size of Watchpoint reduces memory footprint significantly.

        As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.

        1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
           memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
           the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
           we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
           class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
           does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
           using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
           Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.

        2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
           pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S

        3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
           Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
           GC scan. It is OK for watchpoint since they are allocated in the heap anyway.

        We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
        ARM64 only takes 2 pointers size.

                                                                              ORIGINAL    X86_64   ARM64
            WatchpointSet:                                                    40          32       28
            CodeBlockJettisoningWatchpoint:                                   32          19       15
            StructureStubClearingWatchpoint:                                  56          48       40
            AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24          13       11
            AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint:  24          13       11
            FunctionRareData::AllocationProfileClearingWatchpoint:            32          19       15
            ObjectToStringAdaptiveStructureWatchpoint:                        56          48       40
            LLIntPrototypeLoadAdaptiveStructureWatchpoint:                    64          48       48
            DFG::AdaptiveStructureWatchpoint:                                 56          48       40

        While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
        * bytecode/CodeBlockJettisoningWatchpoint.h:
        * bytecode/CodeOrigin.h:
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::fireInternal):
        * bytecode/StructureStubClearingWatchpoint.h:
        * bytecode/Watchpoint.cpp:
        (JSC::Watchpoint::fire):
        * bytecode/Watchpoint.h:
        (JSC::Watchpoint::Watchpoint):
        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
        (JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
        * dfg/DFGAdaptiveStructureWatchpoint.h:
        * heap/PackedCellPtr.h: Added.
        * runtime/FunctionRareData.h:
        * runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
        * runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::clearObjectToStringValue):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
        * runtime/StructureRareData.h:

2019-05-12  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Compact generator code's bytecode size
        https://bugs.webkit.org/show_bug.cgi?id=197822

        Reviewed by Michael Saboff.

        op_put_to_scope's symbolTableOrScopeDepth is represented as int. This was OK for the old bytecode format since
        VirtualRegister / scope depth can be represented by int anyway. But it is problematic now since only int8_t range
        will be represented in narrow bytecode. When this field is used for symbol table constant index, it is always
        larger than FirstConstantRegisterIndex. So it always exceeds the range of int8_t, and results in wide bytecode.
        It makes all generator's op_put_to_scope wide bytecode.

        In this patch, we introduce a new (logically) union type SymbolTableOrScopeDepth. It holds unsigned value, and we store the
        SymbolTableConstantIndex - FirstConstantRegisterIndex in this unsigned value to make op_put_to_scope narrow bytecode.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::run):
        * bytecode/BytecodeList.rb:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/Fits.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitProfileType):
        (JSC::BytecodeGenerator::emitPutToScope):
        (JSC::BytecodeGenerator::localScopeDepth const):
        * bytecompiler/BytecodeGenerator.h:
        * runtime/SymbolTableOrScopeDepth.h: Added.
        (JSC::SymbolTableOrScopeDepth::symbolTable):
        (JSC::SymbolTableOrScopeDepth::scopeDepth):
        (JSC::SymbolTableOrScopeDepth::raw):
        (JSC::SymbolTableOrScopeDepth::symbolTable const):
        (JSC::SymbolTableOrScopeDepth::scopeDepth const):
        (JSC::SymbolTableOrScopeDepth::raw const):
        (JSC::SymbolTableOrScopeDepth::dump const):
        (JSC::SymbolTableOrScopeDepth::SymbolTableOrScopeDepth):

2019-05-10  Saam barati  <sbarati@apple.com>

        Call to JSToWasmICCallee::createStructure passes in wrong prototype value
        https://bugs.webkit.org/show_bug.cgi?id=197807
        <rdar://problem/50530400>

        Reviewed by Yusuke Suzuki.

        We were passing the empty value instead of null. However, the empty
        value means the Structure is poly proto. That's definitely not the case
        here.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

2019-05-10  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] String substring operation should return ropes consistently
        https://bugs.webkit.org/show_bug.cgi?id=197765
        <rdar://problem/37689944>

        Reviewed by Michael Saboff.

        Currently we have different policies per string substring operation function.

            1. String#slice returns the resolved non-rope string
            2. String#substring returns rope string
            3. String#substr returns rope string in runtime function, non-rope string in DFG and FTL

        Due to (3), we see large memory use in the tested web page[1]. Non rope substring have a problem.
        First of all, that returned string seems not used immediately. It is possible that the resulted
        string is used as a part of the other ropes (like, xxx.substring(...) + "Hello"). To avoid the
        eager materialization of the string, we are using StringImpl::createSubstringSharingImpl for the
        resulted non rope string. StringImpl::createSubstringSharingImpl is StringImpl's substring feature: the
        substring is pointing the owner StringImpl. While this has memory saving benefit, it can retain owner
        StringImpl so long, and it could keep very large owner StringImpl alive.

        The problem we are attempting to solve with StringImpl::createSubstringSharingImpl can be solved by
        the rope string simply. Rope string can share the underlying string. And good feature of the rope
        string is that, when resolving rope string, the rope string always create a new StringImpl instead of
        using StringImpl::createSubstringSharingImpl. So we allow the owner StringImpl to be destroyed. And this
        resolving only happens when we actually want to use the content of the rope string. In addition, we recently
        shrunk the sizeof(JSRopeString) from 48 to 32, so JSRopeString is cheap.

        In this patch, we change (2) and (3) to (1), using rope String as a result of substring operations.

        RAMification and JetStream2 are neutral. The web page[1] shows large memory footprint improvement from 776MB to 681MB.

        [1]: https://beta.observablehq.com/@ldgardner/assignment-4-visualizations-and-multiple-views

        * dfg/DFGOperations.cpp:
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncSlice):
        * runtime/StringPrototypeInlines.h:
        (JSC::stringSlice):

2019-05-10  Robin Morisset  <rmorisset@apple.com>

        testb3 failing with crash in JSC::B3::BasicBlock::appendNonTerminal
        https://bugs.webkit.org/show_bug.cgi?id=197756
        <rdar://problem/50641659>

        Reviewed by Saam Barati.

        When I added https://bugs.webkit.org/show_bug.cgi?id=197265 I assumed that which block is the root does not change in the middle of strength reduction.
        But specializeSelect can use splitForward, which uses a new block for the first half of the given block.
        So if the block being split is the root block I must update m_root and erase the m_valueInConstant cache.
        Erasing the cache cannot cause wrong results: at most it can make us miss some optimization opportunities in this iteration of the fixpoint.

        * b3/B3ReduceStrength.cpp:

2019-05-09  Keith Miller  <keith_miller@apple.com>

        Fix crashes related to pointer authentication for primitive gigacage
        https://bugs.webkit.org/show_bug.cgi?id=197763
        <rdar://problem/50629257>

        Reviewed by Saam Barati.

        This fixes two bugs related to PAC for caging. The first is that
        we didn't clear the high bits of the size register going into the
        patchpoint to tag the new buffer for NewArrayBuffer. The second is
        that the GC needs to strip all stack pointers when considering
        them as a conservative root.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::genericAddPointer):

2019-05-09  Keith Miller  <keith_miller@apple.com>

        parseStatementListItem needs a stack overflow check
        https://bugs.webkit.org/show_bug.cgi?id=197749
        <rdar://problem/50302697>

        Reviewed by Saam Barati.

        There currently exists a path in the parser where you can loop
        arbibrarily many times without a stack overflow check. This patch
        adds a check to parseStatementListItem to break that cycle.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseStatementListItem):

2019-05-09  Keith Miller  <keith_miller@apple.com>

        REGRESSION (r245064): ASSERTION FAILED: m_ptr seen with wasm.yaml/wasm/js-api/test_Data.js.wasm-slow-memory
        https://bugs.webkit.org/show_bug.cgi?id=197740

        Reviewed by Saam Barati.

        If a TypedArray constructor is called with just 0 as the first argument, we don't allocate a backing vector.
        This means we need to handle null when calling vector() in ConstructionContext.

        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::ConstructionContext::vector const):

2019-05-09  Xan López  <xan@igalia.com>

        [CMake] Detect SSE2 at compile time
        https://bugs.webkit.org/show_bug.cgi?id=196488

        Reviewed by Carlos Garcia Campos.

        * assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
        incorrect) static_assert.
        (JSC::MacroAssemblerX86Common::collectCPUFeatures):
        * assembler/MacroAssemblerX86Common.h: Remove SSE2 flags.

2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, build fix after r245064
        https://bugs.webkit.org/show_bug.cgi?id=197110

        * runtime/GenericTypedArrayView.h:

2019-05-08  Saam barati  <sbarati@apple.com>

        AccessGenerationState::emitExplicitExceptionHandler can clobber an in use register
        https://bugs.webkit.org/show_bug.cgi?id=197715
        <rdar://problem/50399252>

        Reviewed by Filip Pizlo.

        AccessGenerationState::emitExplicitExceptionHandler was always clobbering
        x86's r9 without considering if that register was needed to be preserved
        by the IC. This leads to bad things when the DFG/FTL need that register when
        OSR exitting after an exception from a GetById call.

        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::Code):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::emitExplicitExceptionHandler):
        * runtime/Options.h:

2019-05-08  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r245068.

        Caused debug layout tests to exit early due to an assertion
        failure.

        Reverted changeset:

        "All prototypes should call didBecomePrototype()"
        https://bugs.webkit.org/show_bug.cgi?id=196315
        https://trac.webkit.org/changeset/245068

2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>

        Invalid DFG JIT genereation in high CPU usage state
        https://bugs.webkit.org/show_bug.cgi?id=197453

        Reviewed by Saam Barati.

        We have a DFG graph like this.

            a: JSConstant(rope JSString)
            b: CheckStringIdent(Check:StringUse:@a)
            ... AI think this is unreachable ...

        When executing StringUse edge filter onto @a, AbstractValue::filterValueByType clears AbstractValue and makes it None.
        This is because @a constant produces SpecString (SpecStringVar | SpecStringIdent) while StringUse edge filter requires
        SpecStringIdent. AbstractValue::filterValueByType has an assumption that the JS constant always produces the same
        SpeculatedType. So it clears AbstractValue completely.
        But this assumption is wrong. JSString can produce SpecStringIdent later if the string is resolved to AtomicStringImpl.
        AI think that we always fail. But once the string is resolved to AtomicStringImpl, we pass this check. So we execute
        the breakpoint emitted by DFG since DFG think this is unreachable.

        In this patch, we just clear the `m_value` if AbstractValue type filter fails with the held constant, since the constant
        may produce a narrower type which can meet the type filter later.

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::filterValueByType):

2019-05-08  Robin Morisset  <rmorisset@apple.com>

        All prototypes should call didBecomePrototype()
        https://bugs.webkit.org/show_bug.cgi?id=196315

        Reviewed by Saam Barati.

        This changelog already landed, but the commit was missing the actual changes.

        Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.

        I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
        create structures with invalid prototypes.
        It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
        Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.

        * runtime/BigIntPrototype.cpp:
        (JSC::BigIntPrototype::finishCreation):
        * runtime/BooleanPrototype.cpp:
        (JSC::BooleanPrototype::finishCreation):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::finishCreation):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototype::finishCreation):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::finishCreation):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::finishCreation):
        * runtime/IntlPluralRulesPrototype.cpp:
        (JSC::IntlPluralRulesPrototype::finishCreation):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::createConsoleProperty):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::finishCreation):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/Structure.cpp:
        (JSC::Structure::isValidPrototype):
        (JSC::Structure::changePrototypeTransition):
        * runtime/Structure.h:
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
        (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        (JSC::WebAssemblyInstancePrototype::finishCreation):
        * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
        (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::WebAssemblyMemoryPrototype::finishCreation):
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::WebAssemblyModulePrototype::finishCreation):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::WebAssemblyPrototype::finishCreation):
        * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
        (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::WebAssemblyTablePrototype::finishCreation):

2019-05-08  Keith Miller  <keith_miller@apple.com>

        Remove Gigacage from arm64 and use PAC for arm64e instead
        https://bugs.webkit.org/show_bug.cgi?id=197110

        Reviewed by Saam Barati.

        This patch makes a bunch of changes. I'll start with global changes then go over changes to each tier and finish with bug fixes.

        Global Changes:
        Change CagedBarrierPtr to work with PAC so constructors and accessors now expect to receive a length.
        Update assembler helper methods to use do PAC when caging.

        LLInt:
        Add arm64e.rb backend as we missed that when originally open sourcing our arm64e code.
        Add a new optional t6 temporary, which is only used currently on arm64e for GetByVal on a TypedArray.
        Refactor caging into two helper macros for Primitive/JSValue cages.

        Baseline/DFG:
        Add authentication where needed for GetByVal and inline object construction.

        FTL:
        Add a new ValueRep that allows for a late register use. We want this for the authentication patchpoint since we use the length register at the same time as we are defing the authenticated pointer.

        Wasm:
        Use the TaggedArrayStoragePtr class for the memory base pointer. In theory we should be caging those pointers but I don't want to risk introducing a performance regression with the rest of this change. I've filed https://bugs.webkit.org/show_bug.cgi?id=197620 to do this later.
        As we no longer have the Gigacage using most of our VA memory, we can enable fast memories on iOS.
        Using fast memories leads to roughly a 2% JetStream2 speedup.

        * assembler/MacroAssemblerARM64E.h:
        (JSC::MacroAssemblerARM64E::tagArrayPtr):
        (JSC::MacroAssemblerARM64E::untagArrayPtr):
        (JSC::MacroAssemblerARM64E::removeArrayPtrTag):
        * b3/B3LowerToAir.cpp:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::addUsedRegistersTo const):
        (JSC::B3::ValueRep::dump const):
        (WTF::printInternal):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::ValueRep):
        (JSC::B3::ValueRep::isReg const):
        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithSize):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
        (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
        (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
        (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
        (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::cageConditionally):
        * jit/IntrinsicEmitter.cpp:
        (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDirectArgumentsGetByVal):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallNode::clearCallLinkInfo):
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm64.rb:
        * offlineasm/arm64e.rb: Added.
        * offlineasm/ast.rb:
        * offlineasm/instructions.rb:
        * offlineasm/registers.rb:
        * offlineasm/x86.rb:
        * runtime/ArrayBuffer.cpp:
        (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
        (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
        (JSC::ArrayBufferContents::ArrayBufferContents):
        (JSC::ArrayBufferContents::destroy):
        (JSC::ArrayBufferContents::tryAllocate):
        (JSC::ArrayBufferContents::makeShared):
        (JSC::ArrayBufferContents::copyTo):
        * runtime/ArrayBuffer.h:
        (JSC::SharedArrayBufferContents::data const):
        (JSC::ArrayBufferContents::data const):
        (JSC::ArrayBuffer::data):
        (JSC::ArrayBuffer::data const):
        (JSC::ArrayBuffer::byteLength const):
        * runtime/ArrayBufferView.cpp:
        (JSC::ArrayBufferView::ArrayBufferView):
        * runtime/ArrayBufferView.h:
        (JSC::ArrayBufferView::baseAddress const):
        (JSC::ArrayBufferView::byteLength const):
        (JSC::ArrayBufferView::setRangeImpl):
        (JSC::ArrayBufferView::getRangeImpl):
        * runtime/CachedTypes.cpp:
        (JSC::CachedScopedArgumentsTable::encode):
        (JSC::CachedScopedArgumentsTable::decode const):
        * runtime/CagedBarrierPtr.h:
        (JSC::CagedBarrierPtr::CagedBarrierPtr):
        (JSC::CagedBarrierPtr::set):
        (JSC::CagedBarrierPtr::get const):
        (JSC::CagedBarrierPtr::getMayBeNull const):
        (JSC::CagedBarrierPtr::getUnsafe const):
        (JSC::CagedBarrierPtr::at const):
        (JSC::CagedBarrierPtr::operator== const):
        (JSC::CagedBarrierPtr::operator bool const):
        (JSC::CagedBarrierPtr::setWithoutBarrier):
        (JSC::CagedBarrierPtr::operator* const): Deleted.
        (JSC::CagedBarrierPtr::operator-> const): Deleted.
        (JSC::CagedBarrierPtr::operator[] const): Deleted.
        (): Deleted.
        * runtime/DataView.cpp:
        (JSC::DataView::DataView):
        * runtime/DataView.h:
        (JSC::DataView::get):
        (JSC::DataView::set):
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::visitChildren):
        (JSC::DirectArguments::overrideThings):
        (JSC::DirectArguments::unmapArgument):
        * runtime/DirectArguments.h:
        * runtime/GenericArguments.h:
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::visitChildren):
        (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
        (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
        (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
        * runtime/GenericTypedArrayView.h:
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::JSArrayBufferView):
        (JSC::JSArrayBufferView::finalize):
        (JSC::JSArrayBufferView::slowDownAndWasteMemory):
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::ConstructionContext::vector const):
        (JSC::JSArrayBufferView::isNeutered):
        (JSC::JSArrayBufferView::hasVector const):
        (JSC::JSArrayBufferView::vector const):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
        (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
        * runtime/Options.h:
        * runtime/ScopedArgumentsTable.cpp:
        (JSC::ScopedArgumentsTable::clone):
        (JSC::ScopedArgumentsTable::setLength):
        * runtime/ScopedArgumentsTable.h:
        * runtime/SymbolTable.h:
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::complete):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmInstance.h:
        (JSC::Wasm::Instance::cachedMemory const):
        (JSC::Wasm::Instance::updateCachedMemory):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::Memory):
        (JSC::Wasm::Memory::~Memory):
        (JSC::Wasm::Memory::grow):
        (JSC::Wasm::Memory::dump const):
        * wasm/WasmMemory.h:
        (JSC::Wasm::Memory::memory const):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):

2019-05-08  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Add ValueMod into DFG
        https://bugs.webkit.org/show_bug.cgi?id=186174

        Reviewed by Saam Barati.

        This patch is introducing a new DFG node called ValueMod, that is
        responsible to handle BigInt and Untyped specialization of op_mod.
        With the introduction of BigInt, we think that cases with
        ValueMod(Untyped, Untyped) can be more common and we introduced
        support for such kind of node.

        * dfg/DFGAbstractInterpreter.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantDivOp):

        We are abstracting the constant rules of division operations. It
        includes ArithDiv, ValueDiv, ArithMod and ValueMod, since they perform
        the same analysis.

        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        (JSC::DFG::ByteCodeParser::parseBlock):

        Here we check if lhs and rhs have number result to emit ArithMod.
        Otherwise, we need to fallback to ValueMod and let fixup replace this
        operation when possible.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

        ValueMod(BigIntUse) doesn't clobberize world because it only calls
        `operationModBigInt`.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

        ValueMod(BigIntUse) can trigger GC since it allocates intermediate
        JSBigInt to perform calculation. ValueMod(UntypedUse) can trigger GC
        because it can execute arbritary code from user.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupArithDivInt32):

        Function created to simplify readability of ArithDiv/AirthMod fixup
        operation.

        (JSC::DFG::FixupPhase::fixupArithDiv):
        (JSC::DFG::FixupPhase::fixupNode):

        Following the same fixup rules of ArithDiv.

        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::binaryOp):
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:

        ValueMod follows the same prediction propagation rules of ArithMod and
        the same rules for `doDoubleVoting`.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueMod):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueMod):

2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] DFG_ASSERT failed in lowInt52
        https://bugs.webkit.org/show_bug.cgi?id=197569

        Reviewed by Saam Barati.

        GetStack with FlushedInt52 should load the flushed value in Int52 form and put the result in m_int52Values / m_strictInt52Values. Previously,
        we load it in JSValue / Int32 form and lowInt52 fails to get appropriate one since GetStack does not put the result in m_int52Values / m_strictInt52Values.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):

2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] LLIntPrototypeLoadAdaptiveStructureWatchpoint does not require Bag<>
        https://bugs.webkit.org/show_bug.cgi?id=197645

        Reviewed by Saam Barati.

        We are using HashMap<std::tuple<Structure*, const Instruction*>, Bag<LLIntPrototypeLoadAdaptiveStructureWatchpoint>> for LLIntPrototypeLoadAdaptiveStructureWatchpoint,
        but this has several memory inefficiency.

        1. Structure* and Instruction* are too large. We can just use StructureID and bytecodeOffset (unsigned).
        2. While we are using Bag<>, we do not add a new LLIntPrototypeLoadAdaptiveStructureWatchpoint after constructing this Bag first. So we can
           use Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> instead. We ensure that new entry won't be added to this Vector by making Watchpoint
           non-movable.
        3. Instead of having OpGetById::Metadata&, we just hold `unsigned` bytecodeOffset, and get Metadata& from the owner CodeBlock when needed.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/CodeBlock.h:
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
        * bytecode/Watchpoint.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):

2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>

        JSC: A bug in BytecodeGenerator::emitEqualityOpImpl
        https://bugs.webkit.org/show_bug.cgi?id=197479

        Reviewed by Saam Barati.

        Our peephole optimization in BytecodeGenerator is (1) rewinding the previous instruction and (2) emit optimized instruction instead.
        If we have jump target between the previous instruction and the subsequent instruction, this peephole optimization breaks the jump target.
        To prevent it, we had a mechanism disabling peephole optimization, setting m_lastOpcodeID = op_end and checking m_lastOpcodeID when performing
        peephole optimization. However, BytecodeGenerator::emitEqualityOpImpl checks `m_lastInstruction->is<OpTypeof>` instead of `m_lastOpcodeID == op_typeof`,
        and miss `op_end` case.

        This patch makes the following changes.

        1. Add canDoPeepholeOptimization method to clarify the intent of `m_lastInstruction = op_end`.
        2. Check canDoPeepholeOptimization status before performing peephole optimization in emitJumpIfTrue, emitJumpIfFalse, and emitEqualityOpImpl.
        3. Add `ASSERT(canDoPeepholeOptimization())` in fuseCompareAndJump and fuseTestAndJmp to ensure that peephole optimization is allowed.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::fuseCompareAndJump):
        (JSC::BytecodeGenerator::fuseTestAndJmp):
        (JSC::BytecodeGenerator::emitJumpIfTrue):
        (JSC::BytecodeGenerator::emitJumpIfFalse):
        (JSC::BytecodeGenerator::emitEqualityOpImpl):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::canDoPeepholeOptimization const):

2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>

        TemplateObject passed to template literal tags are not always identical for the same source location.
        https://bugs.webkit.org/show_bug.cgi?id=190756

        Reviewed by Saam Barati.

        Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
        when linking CodeBlock and cache it in CodeBlock. But this is wrong because,

        1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
        2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.

        In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
        ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
        But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
        which maps source locations to cached site objects.

        1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
        2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
        3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
        4. TemplateObjectMap is indexed with endOffset of TaggedTemplate.

        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * Scripts/wkbuiltins/builtins_templates.py:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setConstantRegisters):
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addTemplateObjectConstant):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        * bytecompiler/BytecodeGenerator.h:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createTaggedTemplate):
        * runtime/CachedTypes.cpp:
        (JSC::CachedTemplateObjectDescriptor::encode):
        (JSC::CachedTemplateObjectDescriptor::decode const):
        (JSC::CachedJSValue::encode):
        (JSC::CachedJSValue::decode const):
        * runtime/EvalExecutable.cpp:
        (JSC::EvalExecutable::ensureTemplateObjectMap):
        (JSC::EvalExecutable::visitChildren):
        * runtime/EvalExecutable.h:
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::finishCreation):
        (JSC::FunctionExecutable::visitChildren):
        (JSC::FunctionExecutable::fromGlobalCode):
        (JSC::FunctionExecutable::ensureRareDataSlow):
        (JSC::FunctionExecutable::ensureTemplateObjectMap):
        * runtime/FunctionExecutable.h:
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSTemplateObjectDescriptor.cpp:
        (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
        (JSC::JSTemplateObjectDescriptor::create):
        * runtime/JSTemplateObjectDescriptor.h:
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
        (JSC::ModuleProgramExecutable::visitChildren):
        * runtime/ModuleProgramExecutable.h:
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::ensureTemplateObjectMap):
        (JSC::ProgramExecutable::visitChildren):
        * runtime/ProgramExecutable.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::topLevelExecutable):
        (JSC::ScriptExecutable::createTemplateObject):
        (JSC::ScriptExecutable::ensureTemplateObjectMapImpl):
        (JSC::ScriptExecutable::ensureTemplateObjectMap):
        * runtime/ScriptExecutable.h:
        * tools/JSDollarVM.cpp:
        (JSC::functionCreateBuiltin):
        (JSC::functionDeleteAllCodeWhenIdle):
        (JSC::JSDollarVM::finishCreation):

2019-05-07  Robin Morisset  <rmorisset@apple.com>

        [B3] Constants should be hoisted to the root block until moveConstants
        https://bugs.webkit.org/show_bug.cgi?id=197265

        Reviewed by Saam Barati.

        This patch does the following:
        - B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way
        - B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them
        - We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure.
        - I also took the opportunity to fix typos in comments in various parts of the code base.

        Here are a few numbers to justify this patch:
        - In JetStream2, about 27% of values at the beginning of B3 are constants
        - In JetStream2, about 11% of values at the end of B3 are Nops
        - In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller).

        When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression.

        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3MoveConstants.cpp:
        * b3/B3PureCSE.cpp:
        (JSC::B3::PureCSE::process):
        * b3/B3PureCSE.h:
        * b3/B3ReduceStrength.cpp:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGOSRAvailabilityAnalysisPhase.h:
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):

2019-05-07  Robin Morisset  <rmorisset@apple.com>

        All prototypes should call didBecomePrototype()
        https://bugs.webkit.org/show_bug.cgi?id=196315

        Reviewed by Saam Barati.

        Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.

        I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
        create structures with invalid prototypes.
        It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
        Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.

        * runtime/BigIntPrototype.cpp:
        (JSC::BigIntPrototype::finishCreation):
        * runtime/BooleanPrototype.cpp:
        (JSC::BooleanPrototype::finishCreation):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::finishCreation):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototype::finishCreation):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::finishCreation):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::finishCreation):
        * runtime/IntlPluralRulesPrototype.cpp:
        (JSC::IntlPluralRulesPrototype::finishCreation):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::createConsoleProperty):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::finishCreation):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/Structure.cpp:
        (JSC::Structure::isValidPrototype):
        (JSC::Structure::changePrototypeTransition):
        * runtime/Structure.h:
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
        (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        (JSC::WebAssemblyInstancePrototype::finishCreation):
        * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
        (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::WebAssemblyMemoryPrototype::finishCreation):
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::WebAssemblyModulePrototype::finishCreation):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::WebAssemblyPrototype::finishCreation):
        * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
        (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::WebAssemblyTablePrototype::finishCreation):

2019-05-07  Robin Morisset  <rmorisset@apple.com>

        WTF::BitVector should have an isEmpty() method
        https://bugs.webkit.org/show_bug.cgi?id=197637

        Reviewed by Keith Miller.

        Just replaces some comparison of bitCount() to 0 by calls to isEmpty()

        * b3/air/AirAllocateRegistersByGraphColoring.cpp:

2019-05-07  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r244978.
        https://bugs.webkit.org/show_bug.cgi?id=197671

        TemplateObject map should use start/end offsets (Requested by
        yusukesuzuki on #webkit).

        Reverted changeset:

        "TemplateObject passed to template literal tags are not always
        identical for the same source location."
        https://bugs.webkit.org/show_bug.cgi?id=190756
        https://trac.webkit.org/changeset/244978

2019-05-07  Tadeu Zagallo  <tzagallo@apple.com>

        tryCachePutByID should not crash if target offset changes
        https://bugs.webkit.org/show_bug.cgi?id=197311
        <rdar://problem/48033612>

        Reviewed by Filip Pizlo.

        When tryCachePutID is called with a cacheable setter, if the target object where the setter was
        found is still in the prototype chain and there's no poly protos in the chain, we use
        generateConditionsForPrototypePropertyHit to validate that the target object remains the same.
        It checks for the absence of the property in every object in the prototype chain from the base
        down to the target object and checks that the property is still present in the target object. It
        also bails if there are any uncacheable objects, proxies or dictionary objects in the prototype
        chain. However, it does not consider two edge cases:
        - It asserts that the property should still be at the same offset in the target object, but this
        assertion does not hold if the setter deletes properties of the object and causes the structure
        to be flattened after the deletion. Instead of asserting, we just use the updated offset.
        - It does not check whether the new slot is also a setter, which leads to a crash in case it's not.

        * jit/Repatch.cpp:
        (JSC::tryCachePutByID):

2019-05-07  Saam Barati  <sbarati@apple.com>

        Don't OSR enter into an FTL CodeBlock that has been jettisoned
        https://bugs.webkit.org/show_bug.cgi?id=197531
        <rdar://problem/50162379>

        Reviewed by Yusuke Suzuki.

        Sometimes we make silly mistakes. This is one of those times. It's invalid to OSR
        enter into an FTL OSR entry code block that has been jettisoned already.

        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::clearOSREntryBlockAndResetThresholds):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        (JSC::DFG::prepareCatchOSREntry):
        * dfg/DFGOperations.cpp:
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):

2019-05-06  Keith Miller  <keith_miller@apple.com>

        JSWrapperMap should check if existing prototype properties are wrappers when copying exported methods.
        https://bugs.webkit.org/show_bug.cgi?id=197324
        <rdar://problem/50253144>

        Reviewed by Saam Barati.

        The current implementation prevents using JSExport to shadow a
        method from a super class. This was because we would only add a
        method if the prototype didn't already claim to have the
        property. Normally this would only happen if an Objective-C super
        class already exported a ObjCCallbackFunction for the method,
        however, if the user exports a property that is already on
        Object.prototype the overriden method won't be exported.

        This patch fixes the object prototype issue by checking if the
        property on the prototype chain is an ObjCCallbackFunction, if
        it's not then it adds an override.

        * API/JSWrapperMap.mm:
        (copyMethodsToObject):
        * API/tests/testapi.mm:
        (-[ToStringClass toString]):
        (-[ToStringClass other]):
        (-[ToStringSubclass toString]):
        (-[ToStringSubclassNoProtocol toString]):
        (testToString):
        (testObjectiveCAPI):

2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] We should check OOM for description string of Symbol
        https://bugs.webkit.org/show_bug.cgi?id=197634

        Reviewed by Keith Miller.

        When resoling JSString for description of Symbol, we should check OOM error.
        We also change JSValueMakeSymbol(..., nullptr) to returning a symbol value
        without description, (1) to simplify the code and (2) give a way for JSC API
        to create a symbol value without description.

        * API/JSValueRef.cpp:
        (JSValueMakeSymbol):
        * API/tests/testapi.cpp:
        (TestAPI::symbolsTypeof):
        (TestAPI::symbolsDescription):
        (testCAPIViaCpp):
        * dfg/DFGOperations.cpp:
        * runtime/Symbol.cpp:
        (JSC::Symbol::createWithDescription):
        * runtime/Symbol.h:
        * runtime/SymbolConstructor.cpp:
        (JSC::callSymbol):

2019-05-06  Keith Rollin  <krollin@apple.com>

        Temporarily disable generate-xcfilelists
        https://bugs.webkit.org/show_bug.cgi?id=197619
        <rdar://problem/50507392>

        Reviewed by Alex Christensen.

        We need to perform a significant update to the generate-xcfilelist
        scripts. This work involves coordinated work with another facility. If
        the work does not occur in tandem, the build will be broken. To avoid
        this, disable the invoking of the scripts during the transition. The
        checking will be restored once the new scripts are in place.

        * Scripts/check-xcfilelists.sh:

2019-05-06  Basuke Suzuki  <Basuke.Suzuki@sony.com>

        [PlayStation] Fix build break since r244919
        https://bugs.webkit.org/show_bug.cgi?id=197627

        Reviewed by Ross Kirsling.

        Bugfix for POSIX socket implementation and suppress warnings.

        * inspector/remote/socket/RemoteInspectorConnectionClient.h:
        (Inspector::RemoteInspectorConnectionClient::didAccept):
        * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
        (Inspector::Socket::getPort):

2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>

        TemplateObject passed to template literal tags are not always identical for the same source location.
        https://bugs.webkit.org/show_bug.cgi?id=190756

        Reviewed by Saam Barati.

        Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
        when linking CodeBlock and cache it in CodeBlock. But this is wrong because,

        1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
        2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.

        In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
        ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
        But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
        which maps source locations to cached site objects.

        1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
        2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
        3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.

        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * Scripts/wkbuiltins/builtins_templates.py:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setConstantRegisters):
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addTemplateObjectConstant):
        (JSC::BytecodeGenerator::emitGetTemplateObject):
        * bytecompiler/BytecodeGenerator.h:
        * runtime/CachedTypes.cpp:
        (JSC::CachedTemplateObjectDescriptor::encode):
        (JSC::CachedTemplateObjectDescriptor::decode const):
        (JSC::CachedJSValue::encode):
        (JSC::CachedJSValue::decode const):
        * runtime/EvalExecutable.cpp:
        (JSC::EvalExecutable::ensureTemplateObjectMap):
        (JSC::EvalExecutable::visitChildren):
        * runtime/EvalExecutable.h:
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::finishCreation):
        (JSC::FunctionExecutable::visitChildren):
        (JSC::FunctionExecutable::fromGlobalCode):
        (JSC::FunctionExecutable::ensureRareDataSlow):
        (JSC::FunctionExecutable::ensureTemplateObjectMap):
        * runtime/FunctionExecutable.h:
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSTemplateObjectDescriptor.cpp:
        (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
        (JSC::JSTemplateObjectDescriptor::create):
        * runtime/JSTemplateObjectDescriptor.h:
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
        (JSC::ModuleProgramExecutable::visitChildren):
        * runtime/ModuleProgramExecutable.h:
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::ensureTemplateObjectMap):
        (JSC::ProgramExecutable::visitChildren):
        * runtime/ProgramExecutable.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::topLevelExecutable):
        (JSC::ScriptExecutable::createTemplateObject):
        (JSC::ScriptExecutable::ensureTemplateObjectMap):
        * runtime/ScriptExecutable.h:
        * tools/JSDollarVM.cpp:
        (JSC::functionCreateBuiltin):
        (JSC::functionDeleteAllCodeWhenIdle):
        (JSC::JSDollarVM::finishCreation):

2019-05-04  Tadeu Zagallo  <tzagallo@apple.com>

        TypedArrays should not store properties that are canonical numeric indices
        https://bugs.webkit.org/show_bug.cgi?id=197228
        <rdar://problem/49557381>

        Reviewed by Saam Barati.

        According to the spec[1]:
        - TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty if the index is a
        CanonicalNumericIndexString, but invalid according to IntegerIndexedElementGet and similar
        functions. I.e., there are a few properties that should not be set in a TypedArray, like NaN,
        Infinity and -0.
        - On DefineOwnProperty, the out-of-bounds check should be performed before validating the property
        descriptor.
        - On GetOwnProperty, the returned descriptor for numeric properties should have writable set to true.

        [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
        * runtime/PropertyName.h:
        (JSC::isCanonicalNumericIndexString):

2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Need to emit SetLocal if we emit MovHint in DFGByteCodeParser
        https://bugs.webkit.org/show_bug.cgi?id=197584

        Reviewed by Saam Barati.

        In r244864, we emit MovHint for adhocly created GetterCall/SetterCall frame locals in the callee side to make OSR availability analysis's pruning correct.
        However, we just emit MovHint, and we do not emit SetLocal since we ensured that these locals are already flushed in the same place before. However, MovHint
        and SetLocal are needed to be a pair in DFGByteCodeParser because we rely on this assumption in SSA conversion phase. SSA conversion phase always emit KillStack
        just before MovHint's target location even if the MovHint's target is the same to the previously emitted MovHint and SetLocal.
        This patch emits SetLocal too when emitting MovHint for GetterCall/SetterCall frame locals.

        The example is like this.

            a:  SomeValueNode
             :  MovHint(@a, loc10)
            b:  SetLocal(@a, loc10)
                ...
            c:  MovHint(@a, loc10)

        Then, this will be converted to the style in SSA conversion.

            a:  SomeValueNode
             :  KillStack(loc10)
            b:  PutStack(@a, loc10)
                ...
            c:  KillStack(loc10)

        Then, @b will be removed later since @c kills it.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inlineCall):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::MarkedBlock):
        (JSC::MarkedBlock::Handle::stopAllocating):
        (JSC::MarkedBlock::Handle::resumeAllocating):
        (JSC::MarkedBlock::aboutToMarkSlow):
        (JSC::MarkedBlock::Handle::didConsumeFreeList):

2019-05-03  Devin Rousso  <drousso@apple.com>

        Web Inspector: DOM: rename "low power" to "display composited"
        https://bugs.webkit.org/show_bug.cgi?id=197296

        Reviewed by Joseph Pecoraro.

        Removed specific ChangeLog entries since it is almost entirely mechanical changes.

        * inspector/protocol/DOM.json:

2019-05-03  Basuke Suzuki  <Basuke.Suzuki@sony.com>

        [WinCairo] Implement and enable RemoteInspector Server.
        https://bugs.webkit.org/show_bug.cgi?id=197432

        Reviewed by Ross Kirsling.

        Implement Windows implementation for Socket Backend of RemoteInspector and enable it on WinCairo
        for experimental feature.

        Also add listener interface for connection between RemoteInspector and RemoteInspectorServer
        for flexible configuration.

        * PlatformWin.cmake:
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/socket/RemoteInspectorConnectionClient.h:
        (Inspector::RemoteInspectorConnectionClient::didAccept):
        * inspector/remote/socket/RemoteInspectorServer.cpp:
        (Inspector::RemoteInspectorServer::connect):
        (Inspector::RemoteInspectorServer::listenForTargets):
        (Inspector::RemoteInspectorServer::didAccept):
        (Inspector::RemoteInspectorServer::dispatchMap):
        (Inspector::RemoteInspectorServer::start):
        (Inspector::RemoteInspectorServer::addServerConnection): Deleted.
        * inspector/remote/socket/RemoteInspectorServer.h:
        (Inspector::RemoteInspectorServer::RemoteInspectorServer):
        * inspector/remote/socket/RemoteInspectorSocket.cpp:
        (Inspector::RemoteInspector::RemoteInspector):
        (Inspector::RemoteInspector::dispatchMap):
        (Inspector::RemoteInspector::start):
        (Inspector::RemoteInspector::stopInternal):
        (Inspector::RemoteInspector::setServerPort):
        * inspector/remote/socket/RemoteInspectorSocket.h:
        * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
        (Inspector::RemoteInspectorSocketEndpoint::listenInet):
        (Inspector::RemoteInspectorSocketEndpoint::getPort const):
        (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
        * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
        * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
        (Inspector::Socket::init): Added.
        (Inspector::Socket::listen): Signature changed.
        (Inspector::Socket::getPort): Added.
        * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Added.
        (Inspector::Socket::init):
        (Inspector::Socket::Socket::Socket):
        (Inspector::Socket::Socket::~Socket):
        (Inspector::Socket::Socket::close):
        (Inspector::Socket::Socket::operator PlatformSocketType const):
        (Inspector::Socket::Socket::operator bool const):
        (Inspector::Socket::Socket::leak):
        (Inspector::Socket::Socket::create):
        (Inspector::Socket::setOpt):
        (Inspector::Socket::setOptEnabled):
        (Inspector::Socket::enableOpt):
        (Inspector::Socket::connectTo):
        (Inspector::Socket::bindAndListen):
        (Inspector::Socket::connect):
        (Inspector::Socket::listen):
        (Inspector::Socket::accept):
        (Inspector::Socket::createPair):
        (Inspector::Socket::setup):
        (Inspector::Socket::isValid):
        (Inspector::Socket::isListening):
        (Inspector::Socket::getPort):
        (Inspector::Socket::read):
        (Inspector::Socket::write):
        (Inspector::Socket::close):
        (Inspector::Socket::preparePolling):
        (Inspector::Socket::poll):
        (Inspector::Socket::isReadable):
        (Inspector::Socket::isWritable):
        (Inspector::Socket::markWaitingWritable):
        (Inspector::Socket::clearWaitingWritable):

2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Generator CodeBlock generation should be idempotent
        https://bugs.webkit.org/show_bug.cgi?id=197552

        Reviewed by Keith Miller.

        ES6 Generator saves and resumes the current execution state. Since ES6 generator can save the execution state at expression
        granularity (not statement granularity), the saved state involves locals. But if the underlying CodeBlock is jettisoned and
        recompiled with different code generation option (like, debugger, type profiler etc.), the generated instructions can be largely
        different and it does not have the same state previously used. If we resume the previously created generator with the newly
        generator function, resuming is messed up.

            function* gen () { ... }
            var g = gen();
            g.next();

            // CodeBlock is destroyed & Debugger is enabled.

            g.next();

        In this patch,

        1. In generatorification, we use index Identifier (localN => Identifier("N")) instead of private symbols to generate the same
           instructions every time we regenerate the CodeBlock.

        2. We decouple the options which can affect on the generated code (Debugger, TypeProfiler, ControlFlowProfiler) from the BytecodeGenerator,
           and pass them as a parameter, OptionSet<CodeGeneratorMode>.

        3. Generator ScriptExecutable remembers the previous CodeGeneratorMode and reuses this parameter to regenerate CodeBlock. It means that,
           even if the debugger is enabled, previously created generators are not debuggable. But newly created generators are debuggable.

        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
        (JSC::BytecodeGeneratorification::run):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::setConstantRegisters):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes const):
        (JSC::UnlinkedCodeBlock::wasCompiledWithTypeProfilerOpcodes const):
        (JSC::UnlinkedCodeBlock::wasCompiledWithControlFlowProfilerOpcodes const):
        (JSC::UnlinkedCodeBlock::codeGenerationMode const):
        * bytecode/UnlinkedEvalCodeBlock.h:
        * bytecode/UnlinkedFunctionCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecode/UnlinkedGlobalCodeBlock.h:
        (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
        * bytecode/UnlinkedModuleProgramCodeBlock.h:
        * bytecode/UnlinkedProgramCodeBlock.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
        (JSC::BytecodeGenerator::emitProfileType):
        (JSC::BytecodeGenerator::emitProfileControlFlow):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
        (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
        (JSC::BytecodeGenerator::emitDebugHook):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::shouldEmitDebugHooks const):
        (JSC::BytecodeGenerator::shouldEmitTypeProfilerHooks const):
        (JSC::BytecodeGenerator::shouldEmitControlFlowProfilerHooks const):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PrefixNode::emitResolve):
        (JSC::EmptyVarExpression::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * parser/ParserModes.h:
        (): Deleted.
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeFlags::SourceCodeFlags):
        (JSC::SourceCodeKey::SourceCodeKey):
        * runtime/CachedTypes.cpp:
        (JSC::CachedCodeBlock::isClassContext const):
        (JSC::CachedCodeBlock::codeGenerationMode const):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::CachedCodeBlock<CodeBlockType>::encode):
        (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedProgramCodeBlock):
        (JSC::CodeCache::getUnlinkedEvalCodeBlock):
        (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        (JSC::generateUnlinkedCodeBlockForFunctions):
        (JSC::sourceCodeKeyForSerializedBytecode):
        (JSC::sourceCodeKeyForSerializedProgram):
        (JSC::sourceCodeKeyForSerializedModule):
        (JSC::serializeBytecode):
        * runtime/CodeCache.h:
        (JSC::generateUnlinkedCodeBlockImpl):
        (JSC::generateUnlinkedCodeBlock):
        * runtime/Completion.cpp:
        (JSC::generateProgramBytecode):
        (JSC::generateModuleBytecode):
        * runtime/DirectEvalExecutable.cpp:
        (JSC::DirectEvalExecutable::create):
        * runtime/IndirectEvalExecutable.cpp:
        (JSC::IndirectEvalExecutable::create):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::defaultCodeGenerationMode const):
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::create):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/ScriptExecutable.h:
        * tools/JSDollarVM.cpp:
        (JSC::changeDebuggerModeWhenIdle):
        (JSC::functionEnableDebuggerModeWhenIdle):
        (JSC::functionDisableDebuggerModeWhenIdle):

2019-05-03  Devin Rousso  <drousso@apple.com>

        Web Inspector: Record actions performed on WebGL2RenderingContext
        https://bugs.webkit.org/show_bug.cgi?id=176008
        <rdar://problem/34213884>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Recording.json:
        * inspector/scripts/codegen/generator.py:
        Add `canvas-webgl2` as a `Type`.

2019-05-03  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r244881.
        https://bugs.webkit.org/show_bug.cgi?id=197559

        Breaks compilation of jsconly on linux, breaking compilation
        for jsc-i386-ews, jsc-mips-ews and jsc-armv7-ews (Requested by
        guijemont on #webkit).

        Reverted changeset:

        "[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into
        WEBKIT_COPY_FILES"
        https://bugs.webkit.org/show_bug.cgi?id=197174
        https://trac.webkit.org/changeset/244881

2019-05-02  Don Olmstead  <don.olmstead@sony.com>

        [CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into WEBKIT_COPY_FILES
        https://bugs.webkit.org/show_bug.cgi?id=197174

        Reviewed by Alex Christensen.

        Replace WEBKIT_MAKE_FORWARDING_HEADERS with WEBKIT_COPY_FILES and make dependencies
        for framework headers explicit.

        * CMakeLists.txt:

2019-05-02  Michael Saboff  <msaboff@apple.com>

        Unreviewed rollout of r244862.

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):

2019-05-01  Saam barati  <sbarati@apple.com>

        Baseline JIT should do argument value profiling after checking for stack overflow
        https://bugs.webkit.org/show_bug.cgi?id=197052
        <rdar://problem/50009602>

        Reviewed by Yusuke Suzuki.

        Otherwise, we may do value profiling without running a write barrier, which
        is against the rules of how we do value profiling.

        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):

2019-05-01  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Inlining Getter/Setter should care availability of ad-hocly constructed frame
        https://bugs.webkit.org/show_bug.cgi?id=197405

        Reviewed by Saam Barati.

        When inlining getter and setter calls, we setup a stack frame which does not appear in the bytecode.
        Because Inlining can switch on executable, we could have a graph like this.

        BB#0
            ...
            30: GetSetter
            31: MovHint(loc10)
            32: SetLocal(loc10)
            33: MovHint(loc9)
            34: SetLocal(loc9)
            ...
            37: GetExecutable(@30)
            ...
            41: Switch(@37)

        BB#2
            42: GetLocal(loc12, bc#7 of caller)
            ...
            --> callee: loc9 and loc10 are arguments of callee.
              ...
              <HERE, exit to callee, loc9 and loc10 are required in the bytecode>

        When we prune OSR availability at the beginning of BB#2 (bc#7 in the caller), we prune loc9 and loc10's liveness because the caller does not actually have loc9 and loc10.
        However, when we begin executing the callee, we need OSR exit to be aware of where it can recover the arguments to the setter, loc9 and loc10.

        This patch inserts MovHint at the beginning of callee for a getter / setter stack frame to make arguments (loc9 and loc10 in the above example) recoverable from OSR exit.
        We also move arity fixup DFG nodes from the caller to the callee, since moved arguments are not live in the caller too.

        Interestingly, this fix also reveals the existing issue in LiveCatchVariablePreservationPhase. We emitted Flush for |this| of InlineCallFrame blindly if we saw InlineCallFrame
        inside a block which is covered by catch handler. But this is wrong because inlined function can finish its execution within the block, and |this| is completely unrelated to
        the catch handler if the catch handler is in the outer callee. We already collect all the live locals at the catch handler. And this locals must include arguments too if the
        catch handler is in inlined function. So, we should not emit Flush for each |this| of seen InlineCallFrame. This emitted Flush may connect unrelated locals in the catch handler
        to the locals that is only defined and used in the inlined function, and it leads to the results like DFG says the local is live while the bytecode says the local is dead.
        This results in reading and using garbage in OSR entry because DFG OSR entry needs to fill live DFG values from the stack.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):

2019-05-01  Michael Saboff  <msaboff@apple.com>

        ASSERTION FAILED: !m_needExceptionCheck with --validateExceptionChecks=1; ProxyObject.getOwnPropertySlotCommon/JSFunction.callerGetter
        https://bugs.webkit.org/show_bug.cgi?id=197485

        Reviewed by Saam Barati.

        Added an EXCEPTION_ASSERT after call to getOwnPropertySlot().

        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertyDescriptor):

2019-05-01  Ross Kirsling  <ross.kirsling@sony.com>

        RemoteInspector::updateAutomaticInspectionCandidate should have a default implementation.
        https://bugs.webkit.org/show_bug.cgi?id=197439

        Reviewed by Devin Rousso.

        On non-Cocoa platforms, automatic inspection is not currently implemented,
        so updateAutomaticInspectionCandidate falls back to the logic of updateTarget.
        This logic already existed in three places, so refactor it into a common private method
        and allow our websocket-based RWI implementation to make use of it too.

        * inspector/remote/RemoteInspector.cpp:
        (Inspector::RemoteInspector::updateTarget):
        (Inspector::RemoteInspector::updateTargetMap):
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
        * inspector/remote/socket/RemoteInspectorSocket.cpp:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.

2019-05-01  Darin Adler  <darin@apple.com>

        WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
        https://bugs.webkit.org/show_bug.cgi?id=195535

        Reviewed by Alexey Proskuryakov.

        * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.

        * API/JSStringRef.cpp:
        (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
        (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
        Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
        since that is the default. Also updated for changes to CompletionResult.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
        and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
        U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
        equivalents, since these macros from ICU are correct and efficient.

        * wasm/WasmParser.h:
        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
        convertUTF8ToUTF16.

2019-05-01  Shawn Roberts  <sroberts@apple.com>

        Unreviewed, rolling out r244821.

        Causing

        Reverted changeset:

        "WebKit has too much of its own UTF-8 code and should rely
        more on ICU's UTF-8 support"
        https://bugs.webkit.org/show_bug.cgi?id=195535
        https://trac.webkit.org/changeset/244821

2019-04-29  Darin Adler  <darin@apple.com>

        WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
        https://bugs.webkit.org/show_bug.cgi?id=195535

        Reviewed by Alexey Proskuryakov.

        * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.

        * API/JSStringRef.cpp:
        (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
        (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
        Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
        since that is the default. Also updated for changes to CompletionResult.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
        and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
        U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
        equivalents, since these macros from ICU are correct and efficient.

        * wasm/WasmParser.h:
        (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
        convertUTF8ToUTF16.

2019-04-30  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r244806.
        https://bugs.webkit.org/show_bug.cgi?id=197446

        Causing Test262 and JSC test failures on multiple builds
        (Requested by ShawnRoberts on #webkit).

        Reverted changeset:

        "TypeArrays should not store properties that are canonical
        numeric indices"
        https://bugs.webkit.org/show_bug.cgi?id=197228
        https://trac.webkit.org/changeset/244806

2019-04-30  Saam barati  <sbarati@apple.com>

        CodeBlock::m_instructionCount is wrong
        https://bugs.webkit.org/show_bug.cgi?id=197304

        Reviewed by Yusuke Suzuki.

        What we were calling instructionCount() was wrong, as evidenced by
        us using it incorrectly both in the sampling profiler and when we
        dumped bytecode for a given CodeBlock. Prior to the bytecode rewrite,
        instructionCount() was probably valid to do bounds checks against.
        However, this is no longer the case. This patch renames what we called
        instructionCount() to bytecodeCost(). It is now only used to make decisions
        about inlining and tier up heuristics. I've also named options related to
        this appropriately.
        
        This patch also introduces instructionsSize(). The result of this method
        is valid to do bounds checks against.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpAssumingJITType const):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::optimizationThresholdScalingFactor):
        (JSC::CodeBlock::predictedMachineCodeSize):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::instructionsSize const):
        (JSC::CodeBlock::bytecodeCost const):
        (JSC::CodeBlock::instructionCount const): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::getInliningBalance):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::mightCompileEval):
        (JSC::DFG::mightCompileProgram):
        (JSC::DFG::mightCompileFunctionForCall):
        (JSC::DFG::mightCompileFunctionForConstruct):
        (JSC::DFG::mightInlineFunctionForCall):
        (JSC::DFG::mightInlineFunctionForClosureCall):
        (JSC::DFG::mightInlineFunctionForConstruct):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::isSmallEnoughToInlineCodeInto):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dumpHeader):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * jit/JIT.cpp:
        (JSC::JIT::link):
        * jit/JITDisassembler.cpp:
        (JSC::JITDisassembler::dumpHeader):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::shouldJIT):
        * profiler/ProfilerBytecodes.cpp:
        (JSC::Profiler::Bytecodes::Bytecodes):
        * runtime/Options.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::tryGetBytecodeIndex):
        (JSC::SamplingProfiler::processUnverifiedStackTraces):

2019-04-30  Tadeu Zagallo  <tzagallo@apple.com>

        TypeArrays should not store properties that are canonical numeric indices
        https://bugs.webkit.org/show_bug.cgi?id=197228
        <rdar://problem/49557381>

        Reviewed by Darin Adler.

        According to the spec[1], TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty
        if the index is a CanonicalNumericIndexString, but invalid according toIntegerIndexedElementGet
        and similar functions. I.e., there are a few properties that should not be set in a TypedArray,
        like NaN, Infinity and -0.

        [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
        (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
        * runtime/JSTypedArrays.cpp:
        * runtime/PropertyName.h:
        (JSC::canonicalNumericIndexString):

2019-04-30  Brian Burg  <bburg@apple.com>

        Web Automation: use a more informative key to indicate automation availability
        https://bugs.webkit.org/show_bug.cgi?id=197377
        <rdar://problem/50258069>

        Reviewed by Devin Rousso.

        The existing WIRAutomationEnabledKey does not encode uncertainty.
        Add a new key that provides an 'Unknown' state, and prefer to use it.

        Since an application's initial listing is sent from a background dispatch queue
        on Cocoa platforms, this can race with main thread initialization that sets up
        RemoteInspector::Client. Therefore, the initial listing may not properly represent
        the client's capabilites because the client is not yet available. Allowing for
        an "Unknown" state that is later upgraded to Available or Not Available makes it
        possible to work around this potential race.

        * inspector/remote/RemoteInspectorConstants.h:
        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::pushListingsNow):

2019-04-30  Keith Miller  <keith_miller@apple.com>

        Fix failing ARM64E wasm tests
        https://bugs.webkit.org/show_bug.cgi?id=197420

        Reviewed by Saam Barati.

        This patch fixes a bug in the slow path of our JS->Wasm IC bridge
        where we wouldn't untag the link register before tail calling.

        Additionally, this patch fixes a broken assert when using setting
        Options::useTailCalls=false.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):

2019-04-29  Saam Barati  <sbarati@apple.com>

        Make JITType an enum class
        https://bugs.webkit.org/show_bug.cgi?id=197394

        Reviewed by Yusuke Suzuki.

        This makes the code more easily searchable.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpAssumingJITType const):
        (JSC::CodeBlock::specialOSREntryBlockOrNull):
        (JSC::timeToLive):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::baselineAlternative):
        (JSC::CodeBlock::baselineVersion):
        (JSC::CodeBlock::hasOptimizedReplacement):
        (JSC::CodeBlock::noticeIncomingCall):
        (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
        (JSC::CodeBlock::tallyFrequentExitSites):
        (JSC::CodeBlock::frameRegisterCount):
        (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::jitType const):
        (JSC::CodeBlock::hasBaselineJITProfiling const):
        * bytecode/CodeBlockWithJITType.h:
        (JSC::CodeBlockWithJITType::CodeBlockWithJITType):
        * bytecode/DeferredSourceDump.cpp:
        (JSC::DeferredSourceDump::DeferredSourceDump):
        * bytecode/DeferredSourceDump.h:
        * bytecode/ExitingJITType.h:
        (JSC::exitingJITTypeFor):
        * bytecode/InlineCallFrame.h:
        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dumpHeader):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::JITCode):
        (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
        (JSC::DFG::JITCode::optimizeNextInvocation):
        (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
        (JSC::DFG::JITCode::optimizeAfterWarmUp):
        (JSC::DFG::JITCode::optimizeSoon):
        (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
        (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        (JSC::DFG::prepareCatchOSREntry):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::OSRExit::compileOSRExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitCompilerCommon.h:
        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
        * dfg/DFGOperations.cpp:
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct const):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::JITCode):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeCommon):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLThunks.cpp:
        (JSC::FTL::genericGenerationThunkGenerator):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::callSiteBitsAreBytecodeOffset const):
        (JSC::CallFrame::callSiteBitsAreCodeOriginIndex const):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::dump const):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::AssemblyHelpers):
        * jit/JIT.cpp:
        (JSC::JIT::link):
        * jit/JITCode.cpp:
        (JSC::JITCode::typeName):
        (WTF::printInternal):
        * jit/JITCode.h:
        (JSC::JITCode::bottomTierJIT):
        (JSC::JITCode::topTierJIT):
        (JSC::JITCode::nextTierJIT):
        (JSC::JITCode::isExecutableScript):
        (JSC::JITCode::couldBeInterpreted):
        (JSC::JITCode::isJIT):
        (JSC::JITCode::isOptimizingJIT):
        (JSC::JITCode::isBaselineCode):
        (JSC::JITCode::jitTypeFor):
        * jit/JITDisassembler.cpp:
        (JSC::JITDisassembler::dumpHeader):
        * jit/JITOperations.cpp:
        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):
        * jit/JITToDFGDeferredCompilationCallback.cpp:
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::compileLater):
        (JSC::JITWorklist::compileNow):
        * jit/Repatch.cpp:
        (JSC::readPutICCallTarget):
        (JSC::ftlThunkAwareRepatchCall):
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        (JSC::LLInt::setModuleProgramEntrypoint):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):
        * runtime/SamplingProfiler.h:
        * runtime/VM.cpp:
        (JSC::jitCodeForCallTrampoline):
        (JSC::jitCodeForConstructTrampoline):
        * tools/CodeProfile.cpp:
        (JSC::CodeProfile::sample):
        * tools/JSDollarVM.cpp:
        (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
        (JSC::CallerFrameJITTypeFunctor::jitType):
        (JSC::functionLLintTrue):
        (JSC::functionJITTrue):

2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreivewed, fix FTL implementation of r244760
        https://bugs.webkit.org/show_bug.cgi?id=197362

        Reviewed by Saam Barati.

        Looked with Saam. ValueFromBlock from double case block was overridden by NaN thing now.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):

2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>

        normalizeMapKey should normalize NaN to one PureNaN bit pattern to make MapHash same
        https://bugs.webkit.org/show_bug.cgi?id=197362

        Reviewed by Saam Barati.

        Our Map/Set's hash algorithm relies on the bit pattern of JSValue. So our Map/Set has
        normalization of the key, which normalizes Int32 / Double etc. But we did not normalize
        pure NaNs into one canonicalized pure NaN. So we end up having multiple different pure NaNs
        in one Map/Set. This patch normalizes NaN into one jsNaN(), which uses PNaN for the representation.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
        * runtime/HashMapImpl.h:
        (JSC::normalizeMapKey):

2019-04-29  Alex Christensen  <achristensen@webkit.org>

        <rdar://problem/50299396> Fix internal High Sierra build
        https://bugs.webkit.org/show_bug.cgi?id=197388

        * Configurations/Base.xcconfig:

2019-04-29  Yusuke Suzuki  <ysuzuki@apple.com>

        JITStubRoutineSet wastes 180KB of HashTable capacity on can.com
        https://bugs.webkit.org/show_bug.cgi?id=186732

        Reviewed by Saam Barati.

        Our current mechanism of JITStubRoutineSet consumes more memory than needed. Basically we have HashMap<uintptr_t, StubRoutine*> and register
        each executable address by 16 byte to this entry. So if your StubRoutine has 128bytes, it just adds 8 entries to this hash table.
        In Gmail, we see a ~2MB table size.

        Instead, this patch uses Vector<pair<uintptr_t, StubRoutine*>> and performs binary search onto this sorted vector. Before conservative
        scanning, we sort this vector. And doing binary search with the sorted vector to find executing stub routines from the conservative roots.
        This vector includes uintptr_t startAddress to make binary searching fast.

        Large amount of conservative scan should be filtered by range check, so I think binary search here is OK, but we can decide based on what the
        performance bots say.

        * heap/Heap.cpp:
        (JSC::Heap::addCoreConstraints):
        * heap/JITStubRoutineSet.cpp:
        (JSC::JITStubRoutineSet::~JITStubRoutineSet):
        (JSC::JITStubRoutineSet::add):
        (JSC::JITStubRoutineSet::prepareForConservativeScan):
        (JSC::JITStubRoutineSet::clearMarks):
        (JSC::JITStubRoutineSet::markSlow):
        (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
        (JSC::JITStubRoutineSet::traceMarkedStubRoutines):
        * heap/JITStubRoutineSet.h:
        (JSC::JITStubRoutineSet::mark):
        (JSC::JITStubRoutineSet::prepareForConservativeScan):
        (JSC::JITStubRoutineSet::size const): Deleted.
        (JSC::JITStubRoutineSet::at const): Deleted.

2019-04-29  Basuke Suzuki  <Basuke.Suzuki@sony.com>

        [Win] Add flag to enable version information stamping and disable by default.
        https://bugs.webkit.org/show_bug.cgi?id=197249
        <rdar://problem/50224412>

        Reviewed by Ross Kirsling.

        This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
        Then enable it by default on AppleWin.

        * CMakeLists.txt:

2019-04-26  Keith Rollin  <krollin@apple.com>

        Enable new build rule for post-processing headers when using XCBuild
        https://bugs.webkit.org/show_bug.cgi?id=197340
        <rdar://problem/50226685>

        Reviewed by Brent Fulgham.

        In Bug 197116, we conditionally disabled the old method for
        post-processing header files when we are using the new XCBuild build
        system. This check-in conditionally enables the new post-processing
        facility. Note that the old system is disabled and the new system
        enabled only when the USE_NEW_BUILD_SYSTEM environment variable is set
        to YES.

        * Configurations/JavaScriptCore.xcconfig:

2019-04-26  Jessie Berlin  <jberlin@webkit.org>

        Add new mac target numbers
        https://bugs.webkit.org/show_bug.cgi?id=197313

        Reviewed by Alex Christensen.

        * Configurations/Version.xcconfig:
        * Configurations/WebKitTargetConditionals.xcconfig:

2019-04-26  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r244708.
        https://bugs.webkit.org/show_bug.cgi?id=197334

        "Broke the debug build" (Requested by rmorisset on #webkit).

        Reverted changeset:

        "All prototypes should call didBecomePrototype()"
        https://bugs.webkit.org/show_bug.cgi?id=196315
        https://trac.webkit.org/changeset/244708

2019-04-26  Don Olmstead  <don.olmstead@sony.com>

        [CMake] Add WEBKIT_EXECUTABLE macro
        https://bugs.webkit.org/show_bug.cgi?id=197206

        Reviewed by Konstantin Tokarev.

        Migrate to WEBKIT_EXECUTABLE for the jsc and test targets.

        * b3/air/testair.cpp:
        * b3/testb3.cpp:
        * dfg/testdfg.cpp:
        * shell/CMakeLists.txt:
        * shell/PlatformGTK.cmake:
        * shell/PlatformJSCOnly.cmake: Removed.
        * shell/PlatformMac.cmake:
        * shell/PlatformPlayStation.cmake:
        * shell/PlatformWPE.cmake:
        * shell/PlatformWin.cmake:

2019-04-25  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] linkPolymorphicCall now does GC
        https://bugs.webkit.org/show_bug.cgi?id=197306

        Reviewed by Saam Barati.

        Previously, we assumed that linkPolymorphicCall does not perform allocations. So we put CallVariant into a Vector<>.
        But now, WebAssemblyFunction's entrypoint generation can allocate JSToWasmICCallee and cause GC. Since CallLinkInfo
        does not hold these cells, they can be collected, and we will see dead cells in the middle of linkPolymorphicCall.
        We should defer GC for a while in linkPolymorphicCall. We use DeferGCForAWhile instead of DeferGC because the
        caller "operationLinkPolymorphicCall" assumes that this function does not cause GC.

        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):

2019-04-26  Robin Morisset  <rmorisset@apple.com>

        All prototypes should call didBecomePrototype()
        https://bugs.webkit.org/show_bug.cgi?id=196315

        Reviewed by Saam Barati.

        Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.

        I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
        create structures with invalid prototypes.
        It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
        Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.

        * runtime/BigIntPrototype.cpp:
        (JSC::BigIntPrototype::finishCreation):
        * runtime/BooleanPrototype.cpp:
        (JSC::BooleanPrototype::finishCreation):
        * runtime/DatePrototype.cpp:
        (JSC::DatePrototype::finishCreation):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::finishCreation):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototype::finishCreation):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::finishCreation):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::finishCreation):
        * runtime/IntlPluralRulesPrototype.cpp:
        (JSC::IntlPluralRulesPrototype::finishCreation):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::finishCreation):
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::createConsoleProperty):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::finishCreation):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        * runtime/Structure.cpp:
        (JSC::Structure::isValidPrototype):
        (JSC::Structure::changePrototypeTransition):
        * runtime/Structure.h:
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
        (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyInstancePrototype.cpp:
        (JSC::WebAssemblyInstancePrototype::finishCreation):
        * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
        (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyMemoryPrototype.cpp:
        (JSC::WebAssemblyMemoryPrototype::finishCreation):
        * wasm/js/WebAssemblyModulePrototype.cpp:
        (JSC::WebAssemblyModulePrototype::finishCreation):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::WebAssemblyPrototype::finishCreation):
        * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
        (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
        * wasm/js/WebAssemblyTablePrototype.cpp:
        (JSC::WebAssemblyTablePrototype::finishCreation):

2019-04-26  Don Olmstead  <don.olmstead@sony.com>

        Add WTF::findIgnoringASCIICaseWithoutLength to replace strcasestr
        https://bugs.webkit.org/show_bug.cgi?id=197291

        Reviewed by Konstantin Tokarev.

        Replace uses of strcasestr with WTF::findIgnoringASCIICaseWithoutLength.

        * API/tests/testapi.cpp:
        * assembler/testmasm.cpp:
        * b3/air/testair.cpp:
        * b3/testb3.cpp:
        * dfg/testdfg.cpp:
        * dynbench.cpp:

2019-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>

        Unreviewed, rolling out r244669.

        Windows ports can't clean build.

        Reverted changeset:

        "[Win] Add flag to enable version information stamping and
        disable by default."
        https://bugs.webkit.org/show_bug.cgi?id=197249
        https://trac.webkit.org/changeset/244669

2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>

        [Win] Add flag to enable version information stamping and disable by default.
        https://bugs.webkit.org/show_bug.cgi?id=197249

        Reviewed by Ross Kirsling.

        This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
        Then enable it by default on AppleWin.

        * CMakeLists.txt:

2019-04-25  Timothy Hatcher  <timothy@apple.com>

        Disable date and time inputs on iOSMac.
        https://bugs.webkit.org/show_bug.cgi?id=197287
        rdar://problem/46794376

        Reviewed by Wenson Hsieh.

        * Configurations/FeatureDefines.xcconfig:

2019-04-25  Alex Christensen  <achristensen@webkit.org>

        Fix more builds after r244653
        https://bugs.webkit.org/show_bug.cgi?id=197131

        * b3/B3Value.h:
        There is an older system with libc++ headers that don't have std::conjunction.  Just use constexpr and && instead for the one use of it in WebKit.

2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>

        [RemoteInspector] Fix connection and target identifier types.
        https://bugs.webkit.org/show_bug.cgi?id=197243

        Reviewed by Ross Kirsling.

        Give dedicated type for RemoteControllableTarget's identifier as Inspector::TargetID.

        Also rename ClientID type used in Socket backend to ConnectionID because this is the identifier
        socket endpoint assign to the newly created connection. The size was changed to uint32_t.
        Enough size for managing connections.

        * inspector/remote/RemoteConnectionToTarget.cpp:
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::close):
        (Inspector::RemoteConnectionToTarget::targetIdentifier const):
        * inspector/remote/RemoteConnectionToTarget.h:
        * inspector/remote/RemoteControllableTarget.h:
        * inspector/remote/RemoteInspector.cpp:
        (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
        (Inspector::RemoteInspector::registerTarget):
        (Inspector::RemoteInspector::unregisterTarget):
        (Inspector::RemoteInspector::updateTarget):
        (Inspector::RemoteInspector::setupFailed):
        (Inspector::RemoteInspector::setupCompleted):
        (Inspector::RemoteInspector::waitingForAutomaticInspection):
        (Inspector::RemoteInspector::updateTargetListing):
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
        (Inspector::RemoteConnectionToTarget::targetIdentifier const):
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::close):
        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        (Inspector::RemoteInspector::sendMessageToRemote):
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDataMessage):
        (Inspector::RemoteInspector::receivedDidCloseMessage):
        (Inspector::RemoteInspector::receivedIndicateMessage):
        (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        (Inspector::RemoteInspector::sendMessageToRemote):
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDataMessage):
        (Inspector::RemoteInspector::receivedCloseMessage):
        (Inspector::RemoteInspector::setup):
        (Inspector::RemoteInspector::sendMessageToTarget):
        * inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
        (Inspector::RemoteInspectorConnectionClient::didReceiveWebInspectorEvent):
        * inspector/remote/socket/RemoteInspectorConnectionClient.h:
        (Inspector::RemoteInspectorConnectionClient::didAccept):
        * inspector/remote/socket/RemoteInspectorMessageParser.cpp:
        (Inspector::MessageParser::MessageParser):
        (Inspector::MessageParser::parse):
        * inspector/remote/socket/RemoteInspectorMessageParser.h:
        (Inspector::MessageParser::setDidParseMessageListener):
        * inspector/remote/socket/RemoteInspectorServer.cpp:
        (Inspector::RemoteInspectorServer::didAccept):
        (Inspector::RemoteInspectorServer::didClose):
        (Inspector::RemoteInspectorServer::dispatchMap):
        (Inspector::RemoteInspectorServer::sendWebInspectorEvent):
        (Inspector::RemoteInspectorServer::sendCloseEvent):
        (Inspector::RemoteInspectorServer::connectionClosed):
        * inspector/remote/socket/RemoteInspectorServer.h:
        * inspector/remote/socket/RemoteInspectorSocket.cpp:
        (Inspector::RemoteInspector::didClose):
        (Inspector::RemoteInspector::sendMessageToRemote):
        (Inspector::RemoteInspector::setup):
        (Inspector::RemoteInspector::sendMessageToTarget):
        * inspector/remote/socket/RemoteInspectorSocket.h:
        * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
        (Inspector::RemoteInspectorSocketEndpoint::connectInet):
        (Inspector::RemoteInspectorSocketEndpoint::isListening):
        (Inspector::RemoteInspectorSocketEndpoint::workerThread):
        (Inspector::RemoteInspectorSocketEndpoint::createClient):
        (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
        (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
        (Inspector::RemoteInspectorSocketEndpoint::send):
        (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
        * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:

2019-04-25  Alex Christensen  <achristensen@webkit.org>

        Start using C++17
        https://bugs.webkit.org/show_bug.cgi?id=197131

        Reviewed by Darin Alder.

        * Configurations/Base.xcconfig:

2019-04-25  Alex Christensen  <achristensen@webkit.org>

        Remove DeprecatedOptional
        https://bugs.webkit.org/show_bug.cgi?id=197161

        Reviewed by Darin Adler.

        We need to keep a symbol exported from JavaScriptCore for binary compatibility with iOS12.
        We need this symbol to be in a file that doesn't include anything because libcxx's implementation of
        std::optional is actually std::__1::optional, which has a different mangled name.  This change will
        prevent protocol errors from being reported if you are running the iOS12 simulator with a custom build of WebKit
        and using the web inspector with it, but it's necessary to allow us to start using C++17 in WebKit.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/InspectorBackendDispatcher.cpp:
        * inspector/InspectorBackendDispatcher.h:
        * inspector/InspectorBackendDispatcherCompatibility.cpp: Added.
        (Inspector::BackendDispatcher::reportProtocolError):
        * inspector/InspectorBackendDispatcherCompatibility.h: Added.

2019-04-24  Saam Barati  <sbarati@apple.com>

        Add SPI callbacks for before and after module execution
        https://bugs.webkit.org/show_bug.cgi?id=197244
        <rdar://problem/50180511>

        Reviewed by Yusuke Suzuki.

        This is helpful for clients that want to profile execution of modules
        in some way. E.g, if they want to time module execution time.

        * API/JSAPIGlobalObject.h:
        * API/JSAPIGlobalObject.mm:
        (JSC::JSAPIGlobalObject::moduleLoaderEvaluate):
        * API/JSContextPrivate.h:
        * API/tests/testapi.mm:
        (+[JSContextFetchDelegate contextWithBlockForFetch:]):
        (-[JSContextFetchDelegate willEvaluateModule:]):
        (-[JSContextFetchDelegate didEvaluateModule:]):
        (testFetch):
        (testFetchWithTwoCycle):
        (testFetchWithThreeCycle):
        (testLoaderResolvesAbsoluteScriptURL):
        (testLoaderRejectsNilScriptURL):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::evaluate):
        (JSC::JSModuleLoader::evaluateNonVirtual):
        * runtime/JSModuleLoader.h:

2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink DFG::MinifiedNode
        https://bugs.webkit.org/show_bug.cgi?id=197224

        Reviewed by Filip Pizlo.

        Since it is kept alive with compiled DFG code, we should shrink it to save memory.
        If it is effective, we should consider minimizing these OSR exit data more aggressively.

        * dfg/DFGMinifiedNode.h:

2019-04-23  Saam Barati  <sbarati@apple.com>

        LICM incorrectly assumes it'll never insert a node which provably OSR exits
        https://bugs.webkit.org/show_bug.cgi?id=196721
        <rdar://problem/49556479> 

        Reviewed by Filip Pizlo.

        Previously, we assumed LICM could never hoist code that caused us
        to provably OSR exit. This is a bad assumption, as we may very well
        hoist such code. Obviously hoisting such code is not ideal. We shouldn't
        hoist something we provably know will OSR exit. However, this is super rare,
        and the phase is written in such a way where it's easier to gracefully
        handle this case than to prevent us from hoisting such code.
        
        If we wanted to ensure we never hoisted code that would provably exit, we'd
        have to teach the phase to know when it inserted code that provably exits. I
        saw two ways to do that:
        1: Save and restore the AI state before actually hoisting.
        2: Write an analysis that can determine if such a node would exit.
        
        (1) is bad because it costs in memory and compile time. (2) will inevitably
        have bugs as running into this condition is rare.
        
        So instead of (1) or (2), I opted to have LICM gracefully handle when
        it causes a provable exit. When we encounter this, we mark all blocks
        in the loop as !cfaHasVisited and !cfaDidFinish.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):

2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Use node index as DFG::MinifiedID
        https://bugs.webkit.org/show_bug.cgi?id=197186

        Reviewed by Saam Barati.

        DFG Nodes can be identified with index if the graph is given. We should use unsigned index as a DFG::MinifiedID's underlying
        source instead of Node* to reduce the size of VariableEvent from 16 to 12. Vector<VariableEvent> is the main data in DFG's OSR
        tracking. It is kept after DFG compilation is done to make OSR work. We saw that this is allocated with large size in GMail.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/DataFormat.h:
        * bytecode/ValueRecovery.h:
        * dfg/DFGGenerationInfo.h:
        * dfg/DFGMinifiedID.h:
        (JSC::DFG::MinifiedID::MinifiedID):
        (JSC::DFG::MinifiedID::operator! const):
        (JSC::DFG::MinifiedID::operator== const):
        (JSC::DFG::MinifiedID::operator!= const):
        (JSC::DFG::MinifiedID::operator< const):
        (JSC::DFG::MinifiedID::operator> const):
        (JSC::DFG::MinifiedID::operator<= const):
        (JSC::DFG::MinifiedID::operator>= const):
        (JSC::DFG::MinifiedID::hash const):
        (JSC::DFG::MinifiedID::dump const):
        (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
        (JSC::DFG::MinifiedID::fromBits):
        (JSC::DFG::MinifiedID::bits const):
        (JSC::DFG::MinifiedID::invalidIndex):
        (JSC::DFG::MinifiedID::otherInvalidIndex):
        (JSC::DFG::MinifiedID::node const): Deleted.
        (JSC::DFG::MinifiedID::invalidID): Deleted.
        (JSC::DFG::MinifiedID::otherInvalidID): Deleted.
        * dfg/DFGMinifiedIDInlines.h: Copied from Source/JavaScriptCore/dfg/DFGMinifiedNode.cpp.
        (JSC::DFG::MinifiedID::MinifiedID):
        * dfg/DFGMinifiedNode.cpp:
        * dfg/DFGValueSource.h:
        (JSC::DFG::ValueSource::ValueSource):
        * dfg/DFGVariableEvent.h:
        (JSC::DFG::VariableEvent::dataFormat const):

2019-04-23  Keith Rollin  <krollin@apple.com>

        Add Xcode version check for Header post-processing scripts
        https://bugs.webkit.org/show_bug.cgi?id=197116
        <rdar://problem/50058968>

        Reviewed by Brent Fulgham.

        There are several places in our Xcode projects that post-process
        header files after they've been exported. Because of XCBuild, we're
        moving to a model where the post-processing is performed at the same
        time the header files are exported, rather than as a distinct
        post-processing step. This patch disables the distinct step when the
        inline processing is available.

        In practice, this means prefixing appropriate post-processing Custom
        Build phases with:

        if [ "${XCODE_VERSION_MAJOR}" -ge "1100" -a "${USE_NEW_BUILD_SYSTEM}" = "YES" ]; then
            # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.
            exit 0
        fi

        * JavaScriptCore.xcodeproj/project.pbxproj:

2019-04-23  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r244558.
        https://bugs.webkit.org/show_bug.cgi?id=197219

        Causing crashes on iOS Sim Release and Debug (Requested by
        ShawnRoberts on #webkit).

        Reverted changeset:

        "Remove DeprecatedOptional"
        https://bugs.webkit.org/show_bug.cgi?id=197161
        https://trac.webkit.org/changeset/244558

2019-04-23  Devin Rousso  <drousso@apple.com>

        Web Inspector: Uncaught Exception: null is not an object (evaluating 'this.ownerDocument.frameIdentifier')
        https://bugs.webkit.org/show_bug.cgi?id=196420
        <rdar://problem/49444205>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/DOM.json:
        Modify the existing `frameId` to represent the owner frame of the node, rather than the
        frame it holds (in the case of an `<iframe>`).

2019-04-23  Alex Christensen  <achristensen@webkit.org>

        Remove DeprecatedOptional
        https://bugs.webkit.org/show_bug.cgi?id=197161

        Reviewed by Darin Adler.

        * inspector/InspectorBackendDispatcher.cpp:
        * inspector/InspectorBackendDispatcher.h:

2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Use volatile load to populate backing page in MarkedBlock::Footer instead of using holdLock
        https://bugs.webkit.org/show_bug.cgi?id=197152

        Reviewed by Saam Barati.

        Emit volatile load instead of using holdLock to populate backing page in MarkedBlock::Footer.

        * heap/BlockDirectory.cpp:
        (JSC::BlockDirectory::isPagedOut):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::populatePage const):

2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] useJIT should subsume useRegExpJIT
        https://bugs.webkit.org/show_bug.cgi?id=197153

        Reviewed by Alex Christensen.

        useJIT should subsume useRegExpJIT. We should immediately disable JIT feature if useJIT = false,
        even if useRegExpJIT is true.

        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::isSupported):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/RegExp.cpp:
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/VM.cpp:
        (JSC::enableAssembler):
        (JSC::VM::canUseRegExpJIT): Deleted.
        * runtime/VM.h:

2019-04-22  Basuke Suzuki  <basuke.suzuki@sony.com>

        [PlayStation] Restructuring Remote Inspector classes to support multiple platform.
        https://bugs.webkit.org/show_bug.cgi?id=197030

        Reviewed by Don Olmstead.

        Restructuring the PlayStation's RemoteInspector backend which uses native socket for the communication to be ready for WinCairo.

        What we did is basically:
        - Renamed `remote/playstation/` to `remote/socket/`. This directory is now platform independent implementation of socket backend. 
        - Renamed `RemoteInspectorSocket` class to `RemoteInspectorSocketEndpoint`. This class is platform independent and core of the backend.
        - Merged `RemoteInspectorSocket{Client|Server}` classes into `RemoteInspectorSocketEndpoint` class because the differences are little.
        - Defined a new interface functions in `Inspector::Socket` (new) namespace.
        - Moved POSIX socket implementation into `posix\RemoteInspectorSocketPOSIX.{h|cpp}`.

        * PlatformPlayStation.cmake:
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/playstation/RemoteInspectorSocketClient.h: Merged into RemoteInspectorSocketEndpoint.
        * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
        * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Removed.
        * inspector/remote/playstation/RemoteInspectorSocketServer.h: Merged into RemoteInspectorSocketEndpoint.
        * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
        * inspector/remote/socket/RemoteInspectorConnectionClient.cpp: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClientPlayStation.cpp.
        * inspector/remote/socket/RemoteInspectorConnectionClient.h: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClient.h.
        (Inspector::RemoteInspectorConnectionClient::didAccept):
        * inspector/remote/socket/RemoteInspectorMessageParser.cpp: Renamed from inspector\remote\playstation\RemoteInspectorMessageParserPlayStation.cpp.
        * inspector/remote/socket/RemoteInspectorMessageParser.h: Renamed from inspector\remote\playstation\RemoteInspectorMessageParser.h.
        * inspector/remote/socket/RemoteInspectorServer.cpp: Renamed from inspector\remote\playstation\RemoteInspectorServerPlayStation.cpp.
        (Inspector::RemoteInspectorServer::didAccept):
        (Inspector::RemoteInspectorServer::start):
        * inspector/remote/socket/RemoteInspectorServer.h: Renamed from inspector\remote\playstation\RemoteInspectorServer.h.
        * inspector/remote/socket/RemoteInspectorSocket.cpp: Renamed from inspector\remote\playstation\RemoteInspectorPlayStation.cpp.
        (Inspector::RemoteInspector::start):
        * inspector/remote/socket/RemoteInspectorSocket.h: Copied from inspector\remote\playstation\RemoteInspectorSocket.h.
        * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp: Added.
        (Inspector::RemoteInspectorSocketEndpoint::RemoteInspectorSocketEndpoint):
        (Inspector::RemoteInspectorSocketEndpoint::~RemoteInspectorSocketEndpoint):
        (Inspector::RemoteInspectorSocketEndpoint::wakeupWorkerThread):
        (Inspector::RemoteInspectorSocketEndpoint::connectInet):
        (Inspector::RemoteInspectorSocketEndpoint::listenInet):
        (Inspector::RemoteInspectorSocketEndpoint::isListening):
        (Inspector::RemoteInspectorSocketEndpoint::workerThread):
        (Inspector::RemoteInspectorSocketEndpoint::createClient):
        (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
        (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
        (Inspector::RemoteInspectorSocketEndpoint::send):
        (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
        * inspector/remote/socket/RemoteInspectorSocketEndpoint.h: Renamed from inspector\remote\playstation\RemoteInspectorSocket.h.
        * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp: Added.
        (Inspector::Socket::connect):
        (Inspector::Socket::listen):
        (Inspector::Socket::accept):
        (Inspector::Socket::createPair):
        (Inspector::Socket::setup):
        (Inspector::Socket::isValid):
        (Inspector::Socket::isListening):
        (Inspector::Socket::read):
        (Inspector::Socket::write):
        (Inspector::Socket::close):
        (Inspector::Socket::preparePolling):
        (Inspector::Socket::poll):
        (Inspector::Socket::isReadable):
        (Inspector::Socket::isWritable):
        (Inspector::Socket::markWaitingWritable):
        (Inspector::Socket::clearWaitingWritable):

2019-04-20  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, suppress warnings in non Darwin environments

        * jit/ExecutableAllocator.cpp:
        (JSC::dumpJITMemory):

2019-04-19  Saam Barati  <sbarati@apple.com>

        AbstractValue can represent more than int52
        https://bugs.webkit.org/show_bug.cgi?id=197118
        <rdar://problem/49969960>

        Reviewed by Michael Saboff.

        Let's analyze this control flow diamond:
        
        #0
        branch #1, #2
        
        #1:
        PutStack(JSValue, loc42)
        Jump #3
        
        #2:
        PutStack(Int52, loc42)
        Jump #3
        
        #3:
        ...
        
        Our abstract value for loc42 at the head of #3 will contain an abstract
        value that us the union of Int52 with other things. Obviously in the
        above program, a GetStack for loc42 would be inavlid, since it might
        be loading either JSValue or Int52. However, the abstract interpreter
        just tracks what the value could be, and it could be Int52 or JSValue.
        
        When I did the Int52 refactoring, I expected such things to never happen,
        but it turns out it does. We should just allow for this instead of asserting
        against it since it's valid IR to do the above.

        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::checkConsistency const):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):

2019-04-19  Tadeu Zagallo  <tzagallo@apple.com>

        Add option to dump JIT memory
        https://bugs.webkit.org/show_bug.cgi?id=197062
        <rdar://problem/49744332>

        Reviewed by Saam Barati.

        Dump all writes into JIT memory to the specified file. The format is:
        - 64-bit destination address for the write
        - 64-bit size of the content written
        - Copy of the data that was written to JIT memory

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        * jit/ExecutableAllocator.cpp:
        (JSC::dumpJITMemory):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):
        * runtime/Options.h:

2019-04-19  Keith Rollin  <krollin@apple.com>

        Add postprocess-header-rule scripts
        https://bugs.webkit.org/show_bug.cgi?id=197072
        <rdar://problem/50027299>

        Reviewed by Brent Fulgham.

        Several projects have post-processing build phases where exported
        headers are tweaked after they've been copied. This post-processing is
        performed via scripts called postprocess-headers.sh. For reasons
        related to XCBuild, we are now transitioning to a build process where
        the post-processing is performed at the same time as the
        exporting/copying. To support this process, add similar scripts named
        postprocess-header-rule, which are geared towards processing a single
        file at a time rather than all exported files at once. Also add a
        build rule that makes use of these scripts. These scripts and build
        rules are not used at the moment; they will come into use in an
        imminent patch.

        Note that I've named these postprocess-header-rule rather than
        postprocess-header-rule.sh. Scripts in Tools/Scripts do not have
        suffixes indicating how the tool is implemented. Scripts in
        per-project Scripts folders appear to be mixed regarding the use of
        suffixes. I'm opting here to follow the Tools/Scripts convention, with
        the expectation that over time we completely standardize on that.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/postprocess-header-rule: Added.

2019-04-18  Saam barati  <sbarati@apple.com>

        Remove useConcurrentBarriers option
        https://bugs.webkit.org/show_bug.cgi?id=197066

        Reviewed by Michael Saboff.

        This isn't a helpful option as it will lead us to crash when using the
        concurrent GC.

        * dfg/DFGStoreBarrierClusteringPhase.cpp:
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::barrierStoreLoadFence):
        * runtime/Options.h:

2019-04-17  Saam Barati  <sbarati@apple.com>

        Remove deprecated JSScript SPI
        https://bugs.webkit.org/show_bug.cgi?id=194909
        <rdar://problem/48283499>

        Reviewed by Keith Miller.

        * API/JSAPIGlobalObject.mm:
        (JSC::JSAPIGlobalObject::moduleLoaderFetch):
        * API/JSScript.h:
        * API/JSScript.mm:
        (+[JSScript scriptWithSource:inVirtualMachine:]): Deleted.
        (fillBufferWithContentsOfFile): Deleted.
        (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
        (+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
        (-[JSScript setSourceURL:]): Deleted.
        * API/JSScriptInternal.h:
        * API/tests/testapi.mm:
        (testFetch):
        (testFetchWithTwoCycle):
        (testFetchWithThreeCycle):
        (testLoaderResolvesAbsoluteScriptURL):
        (testImportModuleTwice):
        (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):

2019-04-17  Keith Rollin  <krollin@apple.com>

        Remove JSCBuiltins.cpp from Copy Headers phase
        https://bugs.webkit.org/show_bug.cgi?id=196981
        <rdar://problem/49952133>

        Reviewed by Alex Christensen.

        JSCBuiltins.cpp is not a header and so doesn't need to be in the Copy
        Headers phase. Checking its history, it seems to have been added
        accidentally at the same time that JSCBuiltins.h was added.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2019-04-16  Stephan Szabo  <stephan.szabo@sony.com>

        [PlayStation] Update port for system library changes
        https://bugs.webkit.org/show_bug.cgi?id=196978

        Reviewed by Ross Kirsling.

        * shell/playstation/Initializer.cpp:
        Add reference to new posix compatibility library.

2019-04-16  Robin Morisset  <rmorisset@apple.com>

        [WTF] holdLock should be marked WARN_UNUSED_RETURN
        https://bugs.webkit.org/show_bug.cgi?id=196922

        Reviewed by Keith Miller.

        There was one case where holdLock was used and the result ignored.
        From a comment that was deleted in https://bugs.webkit.org/attachment.cgi?id=328438&action=prettypatch, I believe that it is on purpose.
        So I brought back a variant of the comment, and made the ignoring of the return explicit.

        * heap/BlockDirectory.cpp:
        (JSC::BlockDirectory::isPagedOut):

2019-04-16  Caitlin Potter  <caitp@igalia.com>

        [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
        https://bugs.webkit.org/show_bug.cgi?id=176810

        Reviewed by Saam Barati.

        This adds conditional logic following the invariant checks, to perform
        filtering in common uses of getOwnPropertyNames.

        While this would ideally only be done in JSPropertyNameEnumerator, adding
        the filtering to ProxyObject::performGetOwnPropertyNames maintains the
        invariant that the EnumerationMode is properly followed.

        This was originally rolled out in r244020, as DontEnum filtering code
        in ObjectConstructor.cpp's ownPropertyKeys() had not been removed. It's
        now redundant due to being handled in ProxyObject::getOwnPropertyNames().

        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::reset):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):

2019-04-15  Saam barati  <sbarati@apple.com>

        Modify how we do SetArgument when we inline varargs calls
        https://bugs.webkit.org/show_bug.cgi?id=196712
        <rdar://problem/49605012>

        Reviewed by Michael Saboff.

        When we inline varargs calls, we guarantee that the number of arguments that
        go on the stack are somewhere between the "mandatoryMinimum" and the "limit - 1".
        However, we can't statically guarantee that the arguments between these two
        ranges was filled out by Load/ForwardVarargs. This is because in the general
        case we don't know the argument count statically.
        
        However, we used to always emit SetArgumentDefinitely up to "limit - 1" for
        all arguments, even when some arguments aren't guaranteed to be in a valid
        state. Emitting these SetArgumentDefinitely were helpful because they let us
        handle variable liveness and OSR exit metadata. However, when we converted
        to SSA, we ended up emitting a GetStack for each such SetArgumentDefinitely.
        
        This is wrong, as we can't guarantee such SetArgumentDefinitely nodes are
        actually looking at a range of the stack that are guaranteed to be initialized.
        This patch introduces a new form of SetArgument node: SetArgumentMaybe. In terms
        of OSR exit metadata and variable liveness tracking, it behaves like SetArgumentDefinitely.
        
        However, it differs in a couple key ways:
        1. In ThreadedCPS, GetLocal(@SetArgumentMaybe) is invalid IR, as this implies
        you might be loading uninitialized stack. (This same rule applies when you do
        the full data flow reachability analysis over CPS Phis.) If someone logically
        wanted to emit code like this, the correct node to emit would be GetArgument,
        not GetLocal. For similar reasons, PhantomLocal(@SetArgumentMaybe) is also
        invalid IR.
        2. To track liveness, Flush(@SetArgumentMaybe) is valid, and is the main user
        of SetArgumentMaybe.
        3. In SSA conversion, we don't lower SetArgumentMaybe to GetStack, as there
        should be no data flow user of SetArgumentMaybe.
        
        SetArgumentDefinitely guarantees that the stack slot is initialized.
        SetArgumentMaybe makes no such guarantee.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleVarargsInlining):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        (JSC::DFG::CPSRethreadingPhase::propagatePhis):
        (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCommon.h:
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::hasVariableAccessData):
        * dfg/DFGNodeType.h:
        * dfg/DFGPhantomInsertionPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):

2019-04-15  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r243672.
        https://bugs.webkit.org/show_bug.cgi?id=196952

        [JSValue release] should be thread-safe (Requested by
        yusukesuzuki on #webkit).

        Reverted changeset:

        "[JSC] JSWrapperMap should not use Objective-C Weak map
        (NSMapTable with NSPointerFunctionsWeakMemory) for
        m_cachedObjCWrappers"
        https://bugs.webkit.org/show_bug.cgi?id=196392
        https://trac.webkit.org/changeset/243672

2019-04-15  Saam barati  <sbarati@apple.com>

        SafeToExecute for GetByOffset/GetGetterByOffset/PutByOffset is using the wrong child for the base
        https://bugs.webkit.org/show_bug.cgi?id=196945
        <rdar://problem/49802750>

        Reviewed by Filip Pizlo.

        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):

2019-04-15  Robin Morisset  <rmorisset@apple.com>

        DFG should be able to constant fold Object.create() with a constant prototype operand
        https://bugs.webkit.org/show_bug.cgi?id=196886

        Reviewed by Yusuke Suzuki.


        It is a fairly simple and limited patch, as it only works when the DFG can prove the exact object used as prototype.
        But when it applies it can be a significant win:
                                                        Baseline                   Optim                                       
        object-create-constant-prototype              3.6082+-0.0979     ^      1.6947+-0.0756        ^ definitely 2.1292x faster
        object-create-null                           11.4492+-0.2510     ?     11.5030+-0.2402        ?
        object-create-unknown-object-prototype       15.6067+-0.1851     ?     15.7500+-0.2322        ?
        object-create-untyped-prototype               8.8873+-0.1240     ?      8.9806+-0.1202        ? might be 1.0105x slower
        <geometric>                                   8.6967+-0.1208     ^      7.2408+-0.1367        ^ definitely 1.2011x faster

        The only subtlety is that we need to to access the StructureCache concurrently from the compiler thread (see https://bugs.webkit.org/show_bug.cgi?id=186199)
        I solved this with a simple lock, taken when the compiler thread tries to read it, and when the main thread tries to modify it.
        I expect it to be extremely low contention, but will watch the bots just in case.
        The lock is taken neither when the main thread is only reading the cache (it has no-one to race with), nor when the GC purges it of dead entries (it does not free anything while a compiler thread is in the middle of a phase).

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * runtime/StructureCache.cpp:
        (JSC::StructureCache::createEmptyStructure):
        (JSC::StructureCache::tryEmptyObjectStructureForPrototypeFromCompilerThread):
        * runtime/StructureCache.h:

2019-04-15  Devin Rousso  <drousso@apple.com>

        Web Inspector: fake value descriptors for promises add a catch handler, preventing "rejectionhandled" events from being fired
        https://bugs.webkit.org/show_bug.cgi?id=196484
        <rdar://problem/49114725>

        Reviewed by Joseph Pecoraro.

        Only add a catch handler when the promise is reachable via a native getter and is known to
        have rejected. A non-rejected promise doesn't need a catch handler, and any promise that
        isn't reachable via a getter won't actually be reached, as `InjectedScript` doesn't call any
        functions, instead only getting the function object itself.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._propertyDescriptors.createFakeValueDescriptor):

        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::isPromiseRejectedWithNativeGetterTypeError): Added.
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionIsPromiseRejectedWithNativeGetterTypeError): Added.

        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::setNativeGetterTypeError): Added.
        (JSC::ErrorInstance::isNativeGetterTypeError const): Added.

        * runtime/Error.h:
        (JSC::throwVMGetterTypeError): Added.
        * runtime/Error.cpp:
        (JSC::createGetterTypeError): Added.
        (JSC::throwGetterTypeError): Added.
        (JSC::throwDOMAttributeGetterTypeError):

2019-04-15  Robin Morisset  <rmorisset@apple.com>

        B3::Value should have different kinds of adjacency lists
        https://bugs.webkit.org/show_bug.cgi?id=196091

        Reviewed by Filip Pizlo.

        The key idea of this optimization is to replace the Vector<Value*, 3> m_children in B3::Value (40 bytes on 64-bits platform) by one of the following:
        - Nothing (0 bytes)
        - 1 Value* (8 bytes)
        - 2 Value* (16 bytes)
        - 3 Value* (24 bytes)
        - A Vector<Value*, 3>
        after the end of the Value object, depending on the kind of the Value.
        So for example, when allocating an Add, we would allocate an extra 16 bytes into which to store 2 Values.
        This would halve the memory consumption of Const64/Const32/Nop/Identity and a bunch more kinds of values, and reduce by a more moderate amount the memory consumption of the rest of non-varargs values (e.g. Add would go from 72 to 48 bytes).

        A few implementation points:
        - Even if there is no children, we must remember to allocate at least enough space for replaceWithIdentity to work later. It needs sizeof(Value) (for the object itself) + sizeof(Value*) (for the pointer to its child)
        - We must make sure to destroy the vector whenever we destroy a Value which is VarArgs
        - We must remember how many elements there are in the case where we did not allocate a Vector. We cannot do it purely by relying on the kind, both for speed reasons and because Return can have either 0 or 1 argument in B3
          Thankfully, we have an extra byte of padding to use in the middle of B3::Value
        - In order to support clone(), we must have a separate version of allocate, which extracts the opcode from the to-be-cloned object instead of from the call to the constructor
        - Speaking of which, we need a special templated function opcodeFromConstructor, because some of the constructors of subclasses of Value don't take an explicit Opcode as argument, typically because they match a single one.
        - To maximize performance, we provide specialized versions of child/lastChild/numChildren/children in the subclasses of Value, skipping checks when the actual type of the Value is already known.
          This is done through the B3_SPECIALIZE_VALUE_FOR_... defined at the bottom of B3Value.h
        - In the constructors of Value, we convert all extra children arguments to Value* eagerly. It is not required for correctness (they will be converted when put into a Vector<Value*> or a Value* in the end), but it helps limit an explosion in the number of template instantiations.
        - I moved DeepValueDump::dump from the .h to the .cpp, as there is no good reason to inline it, and recompiling JSC is already slow enough

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3ArgumentRegValue.cpp:
        (JSC::B3::ArgumentRegValue::cloneImpl const): Deleted.
        * b3/B3ArgumentRegValue.h:
        * b3/B3AtomicValue.cpp:
        (JSC::B3::AtomicValue::AtomicValue):
        (JSC::B3::AtomicValue::cloneImpl const): Deleted.
        * b3/B3AtomicValue.h:
        * b3/B3BasicBlock.h:
        * b3/B3BasicBlockInlines.h:
        (JSC::B3::BasicBlock::appendNewNonTerminal): Deleted.
        * b3/B3CCallValue.cpp:
        (JSC::B3::CCallValue::appendArgs):
        (JSC::B3::CCallValue::cloneImpl const): Deleted.
        * b3/B3CCallValue.h:
        * b3/B3CheckValue.cpp:
        (JSC::B3::CheckValue::cloneImpl const): Deleted.
        * b3/B3CheckValue.h:
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::cloneImpl const): Deleted.
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::cloneImpl const): Deleted.
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::cloneImpl const): Deleted.
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstFloatValue.cpp:
        (JSC::B3::ConstFloatValue::cloneImpl const): Deleted.
        * b3/B3ConstFloatValue.h:
        * b3/B3ConstPtrValue.h:
        (JSC::B3::ConstPtrValue::opcodeFromConstructor):
        * b3/B3FenceValue.cpp:
        (JSC::B3::FenceValue::FenceValue):
        (JSC::B3::FenceValue::cloneImpl const): Deleted.
        * b3/B3FenceValue.h:
        * b3/B3MemoryValue.cpp:
        (JSC::B3::MemoryValue::MemoryValue):
        (JSC::B3::MemoryValue::cloneImpl const): Deleted.
        * b3/B3MemoryValue.h:
        * b3/B3MoveConstants.cpp:
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::cloneImpl const): Deleted.
        * b3/B3PatchpointValue.h:
        (JSC::B3::PatchpointValue::opcodeFromConstructor):
        * b3/B3Procedure.cpp:
        * b3/B3Procedure.h:
        * b3/B3ProcedureInlines.h:
        (JSC::B3::Procedure::add):
        * b3/B3SlotBaseValue.cpp:
        (JSC::B3::SlotBaseValue::cloneImpl const): Deleted.
        * b3/B3SlotBaseValue.h:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isValidImpl):
        * b3/B3StackmapValue.cpp:
        (JSC::B3::StackmapValue::append):
        (JSC::B3::StackmapValue::StackmapValue):
        * b3/B3StackmapValue.h:
        * b3/B3SwitchValue.cpp:
        (JSC::B3::SwitchValue::SwitchValue):
        (JSC::B3::SwitchValue::cloneImpl const): Deleted.
        * b3/B3SwitchValue.h:
        (JSC::B3::SwitchValue::opcodeFromConstructor):
        * b3/B3UpsilonValue.cpp:
        (JSC::B3::UpsilonValue::cloneImpl const): Deleted.
        * b3/B3UpsilonValue.h:
        * b3/B3Value.cpp:
        (JSC::B3::DeepValueDump::dump const):
        (JSC::B3::Value::~Value):
        (JSC::B3::Value::replaceWithIdentity):
        (JSC::B3::Value::replaceWithNopIgnoringType):
        (JSC::B3::Value::replaceWithPhi):
        (JSC::B3::Value::replaceWithJump):
        (JSC::B3::Value::replaceWithOops):
        (JSC::B3::Value::replaceWith):
        (JSC::B3::Value::invertedCompare const):
        (JSC::B3::Value::returnsBool const):
        (JSC::B3::Value::cloneImpl const): Deleted.
        * b3/B3Value.h:
        (JSC::B3::DeepValueDump::dump const): Deleted.
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::adjacencyListOffset const):
        (JSC::B3::Value::cloneImpl const):
        * b3/B3VariableValue.cpp:
        (JSC::B3::VariableValue::VariableValue):
        (JSC::B3::VariableValue::cloneImpl const): Deleted.
        * b3/B3VariableValue.h:
        * b3/B3WasmAddressValue.cpp:
        (JSC::B3::WasmAddressValue::WasmAddressValue):
        (JSC::B3::WasmAddressValue::cloneImpl const): Deleted.
        * b3/B3WasmAddressValue.h:
        * b3/B3WasmBoundsCheckValue.cpp:
        (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
        (JSC::B3::WasmBoundsCheckValue::cloneImpl const): Deleted.
        * b3/B3WasmBoundsCheckValue.h:
        (JSC::B3::WasmBoundsCheckValue::accepts):
        (JSC::B3::WasmBoundsCheckValue::opcodeFromConstructor):
        * b3/testb3.cpp:
        (JSC::B3::testCallFunctionWithHellaArguments):
        (JSC::B3::testCallFunctionWithHellaArguments2):
        (JSC::B3::testCallFunctionWithHellaArguments3):
        (JSC::B3::testCallFunctionWithHellaDoubleArguments):
        (JSC::B3::testCallFunctionWithHellaFloatArguments):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::call):

2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>

        Bytecode cache should not encode the SourceProvider for UnlinkedFunctionExecutable's classSource
        https://bugs.webkit.org/show_bug.cgi?id=196878

        Reviewed by Saam Barati.

        Every time we encode an (Unlinked)SourceCode, we encode its SourceProvider,
        including the full source if it's a StringSourceProvider. This wasn't an issue,
        since the SourceCode contains a RefPtr to the SourceProvider, and the Encoder
        would avoid encoding the provider multiple times. With the addition of the
        incremental cache, each UnlinkedFunctionCodeBlock is encoded in isolation, which
        means we can no longer deduplicate it and the full program text was being encoded
        multiple times in the cache.
        As a work around, this patch adds a custom cached type for encoding the SourceCode
        without its provider, and later injects the SourceProvider through the Decoder.

        * parser/SourceCode.h:
        * parser/UnlinkedSourceCode.h:
        (JSC::UnlinkedSourceCode::provider const):
        * runtime/CachedTypes.cpp:
        (JSC::Decoder::Decoder):
        (JSC::Decoder::create):
        (JSC::Decoder::provider const):
        (JSC::CachedSourceCodeWithoutProvider::encode):
        (JSC::CachedSourceCodeWithoutProvider::decode const):
        (JSC::decodeCodeBlockImpl):
        * runtime/CachedTypes.h:

2019-04-15  Robin Morisset  <rmorisset@apple.com>

        MarkedSpace.cpp is not in the Xcode workspace
        https://bugs.webkit.org/show_bug.cgi?id=196928

        Reviewed by Saam Barati.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>

        Incremental bytecode cache should not append function updates when loaded from memory
        https://bugs.webkit.org/show_bug.cgi?id=196865

        Reviewed by Filip Pizlo.

        Function updates hold the assumption that a function can only be executed/cached
        after its containing code block has already been cached. This assumptions does
        not hold if the UnlinkedCodeBlock is loaded from memory by the CodeCache, since
        we might have two independent SourceProviders executing different paths of the
        code and causing the same UnlinkedCodeBlock to be modified in memory.
        Use a RefPtr instead of Ref for m_cachedBytecode in ShellSourceProvider to distinguish
        between a new, empty cache and a cache that was not loaded and therefore cannot be updated.

        * jsc.cpp:
        (ShellSourceProvider::ShellSourceProvider):

2019-04-15  Saam barati  <sbarati@apple.com>

        mergeOSREntryValue is wrong when the incoming value does not match up with the flush format
        https://bugs.webkit.org/show_bug.cgi?id=196918

        Reviewed by Yusuke Suzuki.

        r244238 lead to some debug failures because we were calling checkConsistency()
        before doing fixTypeForRepresentation when merging in must handle values in
        CFA. This patch fixes that.
        
        However, as I was reading over mergeOSREntryValue, I realized it was wrong. It
        was possible it could merge in a value/type outside of the variable's flushed type.
        Once the flush format types are locked in, we can't introduce a type out of
        that range. This probably never lead to any crashes as our profiling injection
        and speculation decision code is solid. However, what we were doing is clearly
        wrong, and something a fuzzer could have found if we fuzzed the must handle
        values inside prediction injection. We should do that fuzzing:
        https://bugs.webkit.org/show_bug.cgi?id=196924

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::mergeOSREntryValue):
        * dfg/DFGAbstractValue.h:
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::injectOSR):

2019-04-15  Robin Morisset  <rmorisset@apple.com>

        Several structures and enums in the Yarr interpreter can be shrunk
        https://bugs.webkit.org/show_bug.cgi?id=196923

        Reviewed by Saam Barati.

        YarrOp: 88 -> 80
        RegularExpression: 40 -> 32
        ByteTerm: 56 -> 48
        PatternTerm: 56 -> 48

        * yarr/RegularExpression.cpp:
        * yarr/YarrInterpreter.h:
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::YarrOp::YarrOp):
        * yarr/YarrParser.h:
        * yarr/YarrPattern.h:

2019-04-15  Devin Rousso  <drousso@apple.com>

        Web Inspector: REGRESSION(r244172): crash when trying to add extra domain while inspecting JSContext
        https://bugs.webkit.org/show_bug.cgi?id=196925
        <rdar://problem/49873994>

        Reviewed by Joseph Pecoraro.

        Move the logic for creating the `InspectorAgent` and `InspectorDebuggerAgent` into separate
        functions so that callers can be guaranteed to have a valid instance of the agent.

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
        (Inspector::JSGlobalObjectInspectorController::ensureInspectorAgent): Added.
        (Inspector::JSGlobalObjectInspectorController::ensureDebuggerAgent): Added.
        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):

2019-04-14  Don Olmstead  <don.olmstead@sony.com>

        [CMake] JavaScriptCore derived sources should only be referenced inside JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=196742

        Reviewed by Konstantin Tokarev.

        Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
        to support moving the JavaScriptCore derived sources outside of a shared directory.

        Also use JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOUCES_DIR.

        * CMakeLists.txt:

2019-04-13  Tadeu Zagallo  <tzagallo@apple.com>

        CodeCache should check that the UnlinkedCodeBlock was successfully created before caching it
        https://bugs.webkit.org/show_bug.cgi?id=196880

        Reviewed by Yusuke Suzuki.

        CodeCache should not tell the SourceProvider to cache the bytecode if it failed
        to create the UnlinkedCodeBlock.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):

2019-04-12  Saam barati  <sbarati@apple.com>

        r244079 logically broke shouldSpeculateInt52
        https://bugs.webkit.org/show_bug.cgi?id=196884

        Reviewed by Yusuke Suzuki.

        In r244079, I changed shouldSpeculateInt52 to only return true
        when the prediction is isAnyInt52Speculation(). However, it was
        wrong to not to include SpecInt32 in this for two reasons:

        1. We diligently write code that first checks if we should speculate Int32.
        For example:
        if (shouldSpeculateInt32()) ... 
        else if (shouldSpeculateInt52()) ...

        It would be wrong not to fall back to Int52 if we're dealing with the union of
        Int32 and Int52.

        It would be a performance mistake to not include Int32 here because
        data flow can easily tell us that we have variables that are the union
        of Int32 and Int52 values. It's better to speculate Int52 than Double
        in that situation.

        2. We also write code where we ask if the inputs can be Int52, e.g, if
        we know via profiling that an Add overflows, we may not emit an Int32 add.
        However, we only emit such an add if both inputs can be Int52, and Int32
        can trivially become Int52.

       This patch recovers the 0.5-1% regression r244079 caused on JetStream 2.

        * bytecode/SpeculatedType.h:
        (JSC::isInt32SpeculationForArithmetic):
        (JSC::isInt32OrBooleanSpeculationForArithmetic):
        (JSC::isInt32OrInt52Speculation):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::observeUseKindOnNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateInt52):
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGVariableAccessData.cpp:
        (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):

2019-04-12  Saam barati  <sbarati@apple.com>

        Unreviewed. Build fix after r244233.

        * assembler/CPU.cpp:

2019-04-12  Saam barati  <sbarati@apple.com>

        Sometimes we need to user fewer CPUs in our threading calculations
        https://bugs.webkit.org/show_bug.cgi?id=196794
        <rdar://problem/49389497>

        Reviewed by Yusuke Suzuki.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/CPU.cpp: Added.
        (JSC::isKernTCSMAvailable):
        (JSC::enableKernTCSM):
        (JSC::kernTCSMAwareNumberOfProcessorCores):
        * assembler/CPU.h:
        (JSC::isKernTCSMAvailable):
        (JSC::enableKernTCSM):
        (JSC::kernTCSMAwareNumberOfProcessorCores):
        * heap/MachineStackMarker.h:
        (JSC::MachineThreads::addCurrentThread):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/Options.cpp:
        (JSC::computeNumberOfWorkerThreads):
        (JSC::computePriorityDeltaOfWorkerThreads):
        * wasm/WasmWorklist.cpp:
        (JSC::Wasm::Worklist::Worklist):

2019-04-12  Robin Morisset  <rmorisset@apple.com>

        Use padding at end of ArrayBuffer
        https://bugs.webkit.org/show_bug.cgi?id=196823

        Reviewed by Filip Pizlo.

        * runtime/ArrayBuffer.h:

2019-04-11  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] op_has_indexed_property should not assume subscript part is Uint32
        https://bugs.webkit.org/show_bug.cgi?id=196850

        Reviewed by Saam Barati.

        op_has_indexed_property assumed that subscript part is always Uint32. However, this is just a load from non-constant RegisterID,
        DFG can store it in double format and can perform OSR exit. op_has_indexed_property should not assume that.
        In this patch, instead, we check it with isAnyInt and get uint32_t from AnyInt.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_has_indexed_property):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_has_indexed_property):
        * jit/JITOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2019-04-11  Saam barati  <sbarati@apple.com>

        Remove invalid assertion in operationInstanceOfCustom
        https://bugs.webkit.org/show_bug.cgi?id=196842
        <rdar://problem/49725493>

        Reviewed by Michael Saboff.

        In the generated JIT code, we go to the slow path when the incoming function
        isn't the Node's CodeOrigin's functionProtoHasInstanceSymbolFunction. However,
        in the JIT operation, we were asserting against exec->lexicalGlobalObject()'s
        functionProtoHasInstanceSymbolFunction. That assertion might be wrong when
        inlining across global objects as exec->lexicalGlobalObject() uses the machine
        frame for procuring the global object. There is no harm when this assertion fails
        as we just execute the slow path. This patch removes the assertion. (However, this
        does shed light on the deficiency in our exec->lexicalGlobalObject() function with
        respect to inlining. However, this isn't new -- we've known about this for a while.)

        * jit/JITOperations.cpp:

2019-04-11  Michael Saboff  <msaboff@apple.com>

        Improve the Inline Cache Stats code
        https://bugs.webkit.org/show_bug.cgi?id=196836

        Reviewed by Saam Barati.

        Needed to handle the case where the Identifier could be null, for example with InstanceOfAddAccessCase
        and InstanceOfReplaceWithJump.

        Added the ability to log the location of a GetBy and PutBy property as either on self or up the
        protocol chain.

        * jit/ICStats.cpp:
        (JSC::ICEvent::operator< const):
        (JSC::ICEvent::dump const):
        * jit/ICStats.h:
        (JSC::ICEvent::ICEvent):
        (JSC::ICEvent::hash const):
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryCacheInByID):

2019-04-11  Devin Rousso  <drousso@apple.com>

        Web Inspector: Timelines: can't reliably stop/start a recording
        https://bugs.webkit.org/show_bug.cgi?id=196778
        <rdar://problem/47606798>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/ScriptProfiler.json:
        * inspector/protocol/Timeline.json:
        It is possible to determine when programmatic capturing starts/stops in the frontend based
        on the state when the backend causes the state to change, such as if the state is "inactive"
        when the frontend is told that the backend has started capturing.

        * inspector/protocol/CPUProfiler.json:
        * inspector/protocol/Memory.json:
        Send an end timestamp to match other instruments.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):

        * inspector/agents/InspectorScriptProfilerAgent.h:
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.

2019-04-11  Saam barati  <sbarati@apple.com>

        Rename SetArgument to SetArgumentDefinitely
        https://bugs.webkit.org/show_bug.cgi?id=196828

        Reviewed by Yusuke Suzuki.

        This is in preparation for https://bugs.webkit.org/show_bug.cgi?id=196712
        where we will introduce a node named SetArgumentMaybe. Doing this refactoring
        first will make reviewing that other patch easier.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleVarargsInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
        (JSC::DFG::CPSRethreadingPhase::propagatePhis):
        (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCommon.h:
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGGraph.h:
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
        * dfg/DFGMaximalFlushInsertionPhase.cpp:
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::hasVariableAccessData):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertPhantomToPhantomLocal):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGPhantomInsertionPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):

2019-04-11  Truitt Savell  <tsavell@apple.com>

        Unreviewed, rolling out r244158.

        Casued 8 inspector/timeline/ test failures.

        Reverted changeset:

        "Web Inspector: Timelines: can't reliably stop/start a
        recording"
        https://bugs.webkit.org/show_bug.cgi?id=196778
        https://trac.webkit.org/changeset/244158

2019-04-10  Saam Barati  <sbarati@apple.com>

        AbstractValue::validateOSREntryValue is wrong for Int52 constants
        https://bugs.webkit.org/show_bug.cgi?id=196801
        <rdar://problem/49771122>

        Reviewed by Yusuke Suzuki.

        validateOSREntryValue should not care about the format of the incoming
        value for Int52s. This patch normalizes the format of m_value and
        the incoming value when comparing them.

        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::validateOSREntryValue const):

2019-04-10  Saam Barati  <sbarati@apple.com>

        ArithSub over Int52 has shouldCheckOverflow as always true
        https://bugs.webkit.org/show_bug.cgi?id=196796

        Reviewed by Yusuke Suzuki.

        AI was checking for ArithSub over Int52 if !shouldCheckOverflow. However,
        shouldCheckOverflow is always true, so !shouldCheckOverflow is always
        false. We shouldn't check something we assert against.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2019-04-10  Basuke Suzuki  <basuke.suzuki@sony.com>

        [PlayStation] Specify byte order clearly on Remote Inspector Protocol
        https://bugs.webkit.org/show_bug.cgi?id=196790

        Reviewed by Ross Kirsling.

        Original implementation lacks byte order specification. Network byte order is the
        good candidate if there's no strong reason to choose other.
        Currently no client exists for PlayStation remote inspector protocol, so we can
        change the byte order without care.

        * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp:
        (Inspector::MessageParser::createMessage):
        (Inspector::MessageParser::parse):

2019-04-10  Devin Rousso  <drousso@apple.com>

       Web Inspector: Inspector: lazily create the agent
       https://bugs.webkit.org/show_bug.cgi?id=195971
       <rdar://problem/49039645>

       Reviewed by Joseph Pecoraro.

       * inspector/JSGlobalObjectInspectorController.cpp:
       (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
       (Inspector::JSGlobalObjectInspectorController::connectFrontend):
       (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
       (Inspector::JSGlobalObjectInspectorController::createLazyAgents):

       * inspector/agents/InspectorAgent.h:
       * inspector/agents/InspectorAgent.cpp:

2019-04-10  Saam Barati  <sbarati@apple.com>

        Work around an arm64_32 LLVM miscompile bug
        https://bugs.webkit.org/show_bug.cgi?id=196788

        Reviewed by Yusuke Suzuki.

        * runtime/CachedTypes.cpp:

2019-04-10  Devin Rousso  <drousso@apple.com>

        Web Inspector: Timelines: can't reliably stop/start a recording
        https://bugs.webkit.org/show_bug.cgi?id=196778
        <rdar://problem/47606798>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/ScriptProfiler.json:
        * inspector/protocol/Timeline.json:
        It is possible to determine when programmatic capturing starts/stops in the frontend based
        on the state when the backend causes the state to change, such as if the state is "inactive"
        when the frontend is told that the backend has started capturing.

        * inspector/protocol/CPUProfiler.json:
        * inspector/protocol/Memory.json:
        Send an end timestamp to match other instruments.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):

        * inspector/agents/InspectorScriptProfilerAgent.h:
        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
        (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.

2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>

        Unreviewed, fix watch build after r244143
        https://bugs.webkit.org/show_bug.cgi?id=195000

        The result of `lseek` should be `off_t` rather than `int`.

        * jsc.cpp:

2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>

        Add support for incremental bytecode cache updates
        https://bugs.webkit.org/show_bug.cgi?id=195000

        Reviewed by Filip Pizlo.

        Add support for incremental updates to the bytecode cache. The cache
        is constructed as follows:
        - When the cache is empty, the initial payload can be added to the BytecodeCache
        by calling BytecodeCache::addGlobalUpdate. This represents the encoded
        top-level UnlinkedCodeBlock.
        - Afterwards, updates can be added by calling BytecodeCache::addFunctionUpdate.
        The update is applied by appending the encoded UnlinkedFunctionCodeBlock
        to the existing cache and updating the CachedFunctionExecutableMetadata
        and the offset of the new CachedFunctionCodeBlock in the owner CachedFunctionExecutable.

        * API/JSScript.mm:
        (-[JSScript readCache]):
        (-[JSScript isUsingBytecodeCache]):
        (-[JSScript init]):
        (-[JSScript cachedBytecode]):
        (-[JSScript writeCache:]):
        * API/JSScriptInternal.h:
        * API/JSScriptSourceProvider.h:
        * API/JSScriptSourceProvider.mm:
        (JSScriptSourceProvider::cachedBytecode const):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        * jsc.cpp:
        (ShellSourceProvider::~ShellSourceProvider):
        (ShellSourceProvider::cachePath const):
        (ShellSourceProvider::loadBytecode const):
        (ShellSourceProvider::ShellSourceProvider):
        (ShellSourceProvider::cacheEnabled):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::cachedBytecode const):
        (JSC::SourceProvider::updateCache const):
        (JSC::SourceProvider::commitCachedBytecode const):
        * runtime/CachePayload.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
        (JSC::CachePayload::makeMappedPayload):
        (JSC::CachePayload::makeMallocPayload):
        (JSC::CachePayload::makeEmptyPayload):
        (JSC::CachePayload::CachePayload):
        (JSC::CachePayload::~CachePayload):
        (JSC::CachePayload::operator=):
        (JSC::CachePayload::freeData):
        * runtime/CachePayload.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
        (JSC::CachePayload::data const):
        (JSC::CachePayload::size const):
        (JSC::CachePayload::CachePayload):
        * runtime/CacheUpdate.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
        (JSC::CacheUpdate::CacheUpdate):
        (JSC::CacheUpdate::operator=):
        (JSC::CacheUpdate::isGlobal const):
        (JSC::CacheUpdate::asGlobal const):
        (JSC::CacheUpdate::asFunction const):
        * runtime/CacheUpdate.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
        * runtime/CachedBytecode.cpp: Added.
        (JSC::CachedBytecode::addGlobalUpdate):
        (JSC::CachedBytecode::addFunctionUpdate):
        (JSC::CachedBytecode::copyLeafExecutables):
        (JSC::CachedBytecode::commitUpdates const):
        * runtime/CachedBytecode.h: Added.
        (JSC::CachedBytecode::create):
        (JSC::CachedBytecode::leafExecutables):
        (JSC::CachedBytecode::data const):
        (JSC::CachedBytecode::size const):
        (JSC::CachedBytecode::hasUpdates const):
        (JSC::CachedBytecode::sizeForUpdate const):
        (JSC::CachedBytecode::CachedBytecode):
        * runtime/CachedTypes.cpp:
        (JSC::Encoder::addLeafExecutable):
        (JSC::Encoder::release):
        (JSC::Decoder::Decoder):
        (JSC::Decoder::create):
        (JSC::Decoder::size const):
        (JSC::Decoder::offsetOf):
        (JSC::Decoder::ptrForOffsetFromBase):
        (JSC::Decoder::addLeafExecutable):
        (JSC::VariableLengthObject::VariableLengthObject):
        (JSC::VariableLengthObject::buffer const):
        (JSC::CachedPtrOffsets::offsetOffset):
        (JSC::CachedWriteBarrierOffsets::ptrOffset):
        (JSC::CachedFunctionExecutable::features const):
        (JSC::CachedFunctionExecutable::hasCapturedVariables const):
        (JSC::CachedFunctionExecutableOffsets::codeBlockForCallOffset):
        (JSC::CachedFunctionExecutableOffsets::codeBlockForConstructOffset):
        (JSC::CachedFunctionExecutableOffsets::metadataOffset):
        (JSC::CachedFunctionExecutable::encode):
        (JSC::CachedFunctionExecutable::decode const):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::encodeCodeBlock):
        (JSC::encodeFunctionCodeBlock):
        (JSC::decodeCodeBlockImpl):
        (JSC::isCachedBytecodeStillValid):
        * runtime/CachedTypes.h:
        (JSC::VariableLengthObjectBase::VariableLengthObjectBase):
        (JSC::decodeCodeBlock):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::updateCache):
        (JSC::CodeCache::write):
        (JSC::writeCodeBlock):
        (JSC::serializeBytecode):
        * runtime/CodeCache.h:
        (JSC::SourceCodeValue::SourceCodeValue):
        (JSC::CodeCacheMap::findCacheAndUpdateAge):
        (JSC::CodeCacheMap::fetchFromDiskImpl):
        * runtime/Completion.cpp:
        (JSC::generateProgramBytecode):
        (JSC::generateModuleBytecode):
        * runtime/Completion.h:
        * runtime/LeafExecutable.cpp: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
        (JSC::LeafExecutable::operator+ const):
        * runtime/LeafExecutable.h: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
        (JSC::LeafExecutable::LeafExecutable):
        (JSC::LeafExecutable::base const):

2019-04-10  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, rolling out r243989.

        Broke i686 builds

        Reverted changeset:

        "[CMake] Detect SSE2 at compile time"
        https://bugs.webkit.org/show_bug.cgi?id=196488
        https://trac.webkit.org/changeset/243989

2019-04-10  Robin Morisset  <rmorisset@apple.com>

        We should clear m_needsOverflowCheck when hitting an exception in defineProperties in ObjectConstructor.cpp
        https://bugs.webkit.org/show_bug.cgi?id=196746

        Reviewed by Yusuke Suzuki..

        It should be safe as in that case we are not completing the operation, and so not going to have any buffer overflow.

        * runtime/ObjectConstructor.cpp:
        (JSC::defineProperties):

2019-04-10  Antoine Quint  <graouts@apple.com>

        Enable Pointer Events on watchOS
        https://bugs.webkit.org/show_bug.cgi?id=196771
        <rdar://problem/49040909>

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig:

2019-04-09  Keith Rollin  <krollin@apple.com>

        Unreviewed build maintenance -- update .xcfilelists.

        * DerivedSources-input.xcfilelist:

2019-04-09  Ross Kirsling  <ross.kirsling@sony.com>

        JSC should build successfully even with -DENABLE_UNIFIED_BUILDS=OFF
        https://bugs.webkit.org/show_bug.cgi?id=193073

        Reviewed by Keith Miller.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEqualityOpImpl):
        (JSC::BytecodeGenerator::emitEqualityOp): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitEqualityOp):
        Factor out the logic that uses the template parameter and keep it in the header.

        * jit/JITPropertyAccess.cpp:
        List off the template specializations needed by JITOperations.cpp.
        This is unfortunate but at least there are only two (x2) by definition?
        Trying to do away with this incurs a severe domino effect...

        * API/JSValueRef.cpp:
        * b3/B3OptimizeAssociativeExpressionTrees.cpp:
        * b3/air/AirHandleCalleeSaves.cpp:
        * builtins/BuiltinNames.cpp:
        * bytecode/AccessCase.cpp:
        * bytecode/BytecodeIntrinsicRegistry.cpp:
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeRewriter.cpp:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CodeBlock.cpp:
        * bytecode/InstanceOfAccessCase.cpp:
        * bytecode/MetadataTable.cpp:
        * bytecode/PolyProtoAccessChain.cpp:
        * bytecode/StructureSet.cpp:
        * bytecompiler/NodesCodegen.cpp:
        * dfg/DFGCFAPhase.cpp:
        * dfg/DFGPureValue.cpp:
        * heap/GCSegmentedArray.h:
        * heap/HeapInlines.h:
        * heap/IsoSubspace.cpp:
        * heap/LocalAllocator.cpp:
        * heap/LocalAllocator.h:
        * heap/LocalAllocatorInlines.h:
        * heap/MarkingConstraintSolver.cpp:
        * inspector/ScriptArguments.cpp:
        (Inspector::ScriptArguments::isEqual const):
        * inspector/ScriptCallStackFactory.cpp:
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        * interpreter/StackVisitor.cpp:
        * llint/LLIntEntrypoint.cpp:
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/BigIntPrototype.cpp:
        * runtime/CachedTypes.cpp:
        * runtime/ErrorType.cpp:
        * runtime/IndexingType.cpp:
        * runtime/JSCellInlines.h:
        * runtime/JSImmutableButterfly.h:
        * runtime/Operations.h:
        * runtime/RegExpCachedResult.cpp:
        * runtime/RegExpConstructor.cpp:
        * runtime/RegExpGlobalData.cpp:
        * runtime/StackFrame.h:
        * wasm/WasmSignature.cpp:
        * wasm/js/JSToWasm.cpp:
        * wasm/js/JSToWasmICCallee.cpp:
        * wasm/js/WebAssemblyFunction.h:
        Fix includes / forward declarations (and a couple of nearby clang warnings).

2019-04-09  Don Olmstead  <don.olmstead@sony.com>

        [CMake] Apple builds should use ICU_INCLUDE_DIRS
        https://bugs.webkit.org/show_bug.cgi?id=196720

        Reviewed by Konstantin Tokarev.

        * PlatformMac.cmake:

2019-04-09  Saam barati  <sbarati@apple.com>

        Clean up Int52 code and some bugs in it
        https://bugs.webkit.org/show_bug.cgi?id=196639
        <rdar://problem/49515757>

        Reviewed by Yusuke Suzuki.

        This patch fixes bugs in our Int52 code. The primary change in this patch is
        adopting a segregated type lattice for Int52. Previously, for Int52 values,
        we represented them with SpecInt32Only and SpecInt52Only. For an Int52,
        SpecInt32Only meant that the value is in int32 range. And SpecInt52Only meant
        that the is outside of the int32 range.
        
        However, this got confusing because we reused SpecInt32Only both for JSValue
        representations and Int52 representations. This actually lead to some bugs.
        
        1. It's possible that roundtripping through Int52 representation would say
        it produces the wrong type. For example, consider this program and how we
        used to annotate types in AI:
        a: JSConstant(10.0) => m_type is SpecAnyIntAsDouble
        b: Int52Rep(@a) => m_type is SpecInt52Only
        c: ValueRep(@b) => m_type is SpecAnyIntAsDouble
        
        In AI, for the above program, we'd say that @c produces SpecAnyIntAsDouble.
        However, the execution semantics are such that it'd actually produce a boxed
        Int32. This patch fixes the bug where we'd say that Int52Rep over SpecAnyIntAsDouble
        would produce SpecInt52Only. This is clearly wrong, as SpecAnyIntAsDouble can
        mean an int value in either int32 or int52 range.
        
        2. AsbstractValue::validateTypeAcceptingBoxedInt52 was wrong in how it
        accepted Int52 values. It was wrong in two different ways:
        a: If the AbstractValue's type was SpecInt52Only, and the incoming value
        was a boxed double, but represented a value in int32 range, the incoming
        value would incorrectly validate as being acceptable. However, we should
        have rejected this value.
        b: If the AbstractValue's type was SpecInt32Only, and the incoming value
        was an Int32 boxed in a double, this would not validate, even though
        it should have validated.
        
        Solving 2 was easiest if we segregated out the Int52 type into its own
        lattice. This patch makes a new Int52 lattice, which is composed of
        SpecInt32AsInt52 and SpecNonInt32AsInt52.
        
        The conversion rules are now really simple.
        
        Int52 rep => JSValue rep
        SpecInt32AsInt52 => SpecInt32Only
        SpecNonInt32AsInt52 => SpecAnyIntAsDouble
        
        JSValue rep => Int52 rep
        SpecInt32Only => SpecInt32AsInt52
        SpecAnyIntAsDouble => SpecInt52Any
        
        With these rules, the program in (1) will now correctly report that @c
        returns SpecInt32Only | SpecAnyIntAsDouble.

        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::int52AwareSpeculationFromValue):
        (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
        (JSC::speculationFromString):
        * bytecode/SpeculatedType.h:
        (JSC::isInt32SpeculationForArithmetic):
        (JSC::isInt32OrBooleanSpeculationForArithmetic):
        (JSC::isAnyInt52Speculation):
        (JSC::isIntAnyFormat):
        (JSC::isInt52Speculation): Deleted.
        (JSC::isAnyIntSpeculation): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::fixTypeForRepresentation):
        (JSC::DFG::AbstractValue::checkConsistency const):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::isInt52Any const):
        (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupArithMul):
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
        (JSC::DFG::FixupPhase::fixupToThis):
        (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
        (JSC::DFG::FixupPhase::observeUseKindOnNode):
        (JSC::DFG::FixupPhase::fixIntConvertingEdge):
        (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
        (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
        (JSC::DFG::FixupPhase::fixupChecksInBlock):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateInt52):
        (JSC::DFG::Graph::binaryArithShouldSpeculateInt52):
        (JSC::DFG::Graph::unaryArithShouldSpeculateInt52):
        (JSC::DFG::Graph::addShouldSpeculateAnyInt): Deleted.
        (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt): Deleted.
        (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateInt52):
        (JSC::DFG::Node::shouldSpeculateAnyInt): Deleted.
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        (JSC::DFG::SpeculativeJIT::compileArithNegate):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        * dfg/DFGVariableAccessData.cpp:
        (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
        (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
        (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):

2019-04-09  Tadeu Zagallo  <tzagallo@apple.com>

        ASSERTION FAILED: !scope.exception() || !hasProperty in JSObject::get
        https://bugs.webkit.org/show_bug.cgi?id=196708
        <rdar://problem/49556803>

        Reviewed by Yusuke Suzuki.

        `operationPutToScope` needs to return early if an exception is thrown while
        checking if `hasProperty`.

        * jit/JITOperations.cpp:

2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] DFG should respect node's strict flag
        https://bugs.webkit.org/show_bug.cgi?id=196617

        Reviewed by Saam Barati.

        We accidentally use codeBlock->isStrictMode() directly in DFG and FTL. But this is wrong since this CodeBlock is the top level DFG/FTL CodeBlock,
        and this code does not respect the isStrictMode flag for the inlined CodeBlocks. In this patch, we start using isStrictModeFor(CodeOrigin) consistently
        in DFG and FTL to get the right isStrictMode flag for the DFG node.
        And we also split compilePutDynamicVar into compilePutDynamicVarStrict and compilePutDynamicVarNonStrict since (1) it is cleaner than accessing inlined
        callframe in the operation function, and (2) it is aligned to the other functions like operationPutByValDirectNonStrict etc.
        This bug is discovered by RandomizingFuzzerAgent by expanding the DFG coverage.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupToThis):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
        (JSC::DFG::SpeculativeJIT::compileToThis):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):

2019-04-08  Don Olmstead  <don.olmstead@sony.com>

        [CMake][WinCairo] Separate copied headers into different directories
        https://bugs.webkit.org/show_bug.cgi?id=196655

        Reviewed by Michael Catanzaro.

        * CMakeLists.txt:
        * shell/PlatformWin.cmake:

2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] isRope jump in StringSlice should not jump over register allocations
        https://bugs.webkit.org/show_bug.cgi?id=196716

        Reviewed by Saam Barati.

        Jumping over the register allocation code in DFG (like the following) is wrong.

            auto jump = m_jit.branchXXX();
            {
                GPRTemporary reg(this);
                GPRReg regGPR = reg.gpr();
                ...
            }
            jump.link(&m_jit);

        When GPRTemporary::gpr allocates a new register, it can flush the previous register value into the stack and make the register usable.
        Jumping over this register allocation code skips the flushing code, and makes the DFG's stack and register content tracking inconsistent:
        DFG thinks that the content is flushed and stored in particular stack slot even while this flushing code is skipped.
        In this patch, we perform register allocations before jumping to the slow path based on `isRope` condition in StringSlice.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStringSlice):

2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] to_index_string should not assume incoming value is Uint32
        https://bugs.webkit.org/show_bug.cgi?id=196713

        Reviewed by Saam Barati.

        The slow path of to_index_string assumes that incoming value is Uint32. But we should not have
        this assumption since DFG may decide we should have it double format. This patch removes this
        assumption, and instead, we should assume that incoming value is AnyInt and the range of this
        is within Uint32.

        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2019-04-08  Justin Fan  <justin_fan@apple.com>

        [Web GPU] Fix Web GPU experimental feature on iOS
        https://bugs.webkit.org/show_bug.cgi?id=196632

        Reviewed by Myles C. Maxfield.

        Properly make Web GPU available on iOS 11+.

        * Configurations/FeatureDefines.xcconfig:
        * Configurations/WebKitTargetConditionals.xcconfig:

2019-04-08  Ross Kirsling  <ross.kirsling@sony.com>

        -f[no-]var-tracking-assignments is GCC-only
        https://bugs.webkit.org/show_bug.cgi?id=196699

        Reviewed by Don Olmstead.

        * CMakeLists.txt:
        Just remove the build flag altogether -- it supposedly doesn't solve the problem it was meant to
        and said problem evidently no longer occurs as of GCC 9.

2019-04-08  Saam Barati  <sbarati@apple.com>

        WebAssembly.RuntimeError missing exception check
        https://bugs.webkit.org/show_bug.cgi?id=196700
        <rdar://problem/49693932>

        Reviewed by Yusuke Suzuki.

        * wasm/js/JSWebAssemblyRuntimeError.h:
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyRuntimeError):

2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, rolling in r243948 with test fix
        https://bugs.webkit.org/show_bug.cgi?id=196486

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createString):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseMultilineComment):
        (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
        (JSC::Lexer<T>::lex): Deleted.
        * parser/Lexer.h:
        (JSC::Lexer::hasLineTerminatorBeforeToken const):
        (JSC::Lexer::setHasLineTerminatorBeforeToken):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer::prevTerminator const): Deleted.
        (JSC::Lexer::setTerminator): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::allowAutomaticSemicolon):
        (JSC::Parser<LexerType>::parseSingleFunction):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseYieldExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Parser::nextWithoutClearingLineTerminator):
        (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
        (JSC::Parser::internalSaveLexerState):
        (JSC::Parser::restoreLexerState):

2019-04-08  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r243948.

        Caused inspector/runtime/parse.html to fail

        Reverted changeset:

        "SIGSEGV in JSC::BytecodeGenerator::addStringConstant"
        https://bugs.webkit.org/show_bug.cgi?id=196486
        https://trac.webkit.org/changeset/243948

2019-04-08  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r243943.

        Caused test262 failures.

        Reverted changeset:

        "[JSC] Filter DontEnum properties in
        ProxyObject::getOwnPropertyNames()"
        https://bugs.webkit.org/show_bug.cgi?id=176810
        https://trac.webkit.org/changeset/243943

2019-04-08  Claudio Saavedra  <csaavedra@igalia.com>

        [JSC] Partially fix the build with unified builds disabled
        https://bugs.webkit.org/show_bug.cgi?id=196647

        Reviewed by Konstantin Tokarev.

        If you disable unified builds you find all kind of build
        errors. This partially tries to fix them but there's a lot
        more.

        * API/JSBaseInternal.h:
        * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp:
        * b3/air/AirHandleCalleeSaves.h:
        * bytecode/ExecutableToCodeBlockEdge.cpp:
        * bytecode/ExitFlag.h:
        * bytecode/ICStatusUtils.h:
        * bytecode/UnlinkedMetadataTable.h:
        * dfg/DFGPureValue.h:
        * heap/IsoAlignedMemoryAllocator.cpp:
        * heap/IsoAlignedMemoryAllocator.h:

2019-04-08  Guillaume Emont  <guijemont@igalia.com>

        Enable DFG on MIPS
        https://bugs.webkit.org/show_bug.cgi?id=196689

        Reviewed by Žan Doberšek.

        Since the bytecode change, we enabled the baseline JIT on mips in
        r240432, but DFG is still missing. With this change, all tests are
        passing on a ci20 board.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::calleeSaveRegisters):
        Added s0, which is used in llint.

2019-04-08  Xan Lopez  <xan@igalia.com>

        [CMake] Detect SSE2 at compile time
        https://bugs.webkit.org/show_bug.cgi?id=196488

        Reviewed by Carlos Garcia Campos.

        * assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
        incorrect) static_assert.

2019-04-07  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r243642): Crash in reddit.com page
        https://bugs.webkit.org/show_bug.cgi?id=196684

        Reviewed by Geoffrey Garen.

        In r243642, the code that saves and restores the count for non-greedy character classes
        was inadvertently put inside an if statement.  This code should be generated for all
        non-greedy character classes.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):

2019-04-07  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] CallLinkInfo should clear Callee or CodeBlock even if it is unlinked by jettison
        https://bugs.webkit.org/show_bug.cgi?id=196683

        Reviewed by Saam Barati.

        In r243626, we stop repatching CallLinkInfo when the CallLinkInfo is held by jettisoned CodeBlock.
        But we still need to clear the Callee or CodeBlock since they are now dead. Otherwise, CodeBlock's
        visitWeak eventually accesses this dead cells and crashes because the owner CodeBlock of CallLinkInfo
        can be still live.

        We also move all repatching operations from CallLinkInfo.cpp to Repatch.cpp for consistency because the
        other repatching operations in CallLinkInfo are implemented in Repatch.cpp side.

        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::setCallee):
        (JSC::CallLinkInfo::clearCallee):
        * jit/Repatch.cpp:
        (JSC::linkFor):
        (JSC::revertCall):

2019-04-05  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] OSRExit recovery for SpeculativeAdd does not consier "A = A + A" pattern
        https://bugs.webkit.org/show_bug.cgi?id=196582

        Reviewed by Saam Barati.

        In DFG, our ArithAdd with overflow is executed speculatively, and we recover the value when overflow flag is set.
        The recovery is subtracting the operand from the destination to get the original two operands. Our recovery code
        handles A + B = A, A + B = B cases. But it misses A + A = A case (here, A and B are GPRReg). Our recovery code
        attempts to produce the original operand by performing A - A, and it always produces zero accidentally.

        This patch adds the recovery code for A + A = A case. Because we know that this ArithAdd overflows, and operands were
        same values, we can calculate the original operand from the destination value by `((int32_t)value >> 1) ^ 0x80000000`.

        We also found that FTL recovery code is dead. We remove them in this patch.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        (JSC::DFG::OSRExit::compileExit):
        * dfg/DFGOSRExit.h:
        (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::dataFormat const):
        (JSC::FTL::ExitValue::dumpInContext const):
        * ftl/FTLExitValue.h:
        (JSC::FTL::ExitValue::isArgument const):
        (JSC::FTL::ExitValue::hasIndexInStackmapLocations const):
        (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
        (JSC::FTL::ExitValue::recovery): Deleted.
        (JSC::FTL::ExitValue::isRecovery const): Deleted.
        (JSC::FTL::ExitValue::leftRecoveryArgument const): Deleted.
        (JSC::FTL::ExitValue::rightRecoveryArgument const): Deleted.
        (JSC::FTL::ExitValue::recoveryFormat const): Deleted.
        (JSC::FTL::ExitValue::recoveryOpcode const): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::preparePatchpointForExceptions):
        (JSC::FTL::DFG::LowerDFGToB3::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToB3::exitValueForNode):
        (JSC::FTL::DFG::LowerDFGToB3::addAvailableRecovery): Deleted.
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileRecovery):

2019-04-05  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r243665.

        Caused iOS JSC tests to exit with an exception.

        Reverted changeset:

        "Assertion failed in JSC::createError"
        https://bugs.webkit.org/show_bug.cgi?id=196305
        https://trac.webkit.org/changeset/243665

2019-04-05  Yusuke Suzuki  <ysuzuki@apple.com>

        SIGSEGV in JSC::BytecodeGenerator::addStringConstant
        https://bugs.webkit.org/show_bug.cgi?id=196486

        Reviewed by Saam Barati.

        When parsing a FunctionExpression / FunctionDeclaration etc., we use SyntaxChecker for the body of the function because we do not have any interest on the nodes of the body at that time.
        The nodes will be parsed with the ASTBuilder when the function itself is parsed for code generation. This works well previously because all the function ends with "}" previously.
        SyntaxChecker lexes this "}" token, and parser restores the context back to ASTBuilder and continues parsing.

        But now, we have ArrowFunctionExpression without braces `arrow => expr`. Let's consider the following code.

                arrow => expr
                "string!"

        We parse arrow function's body with SyntaxChecker. At that time, we lex "string!" token under the SyntaxChecker context. But this means that we may not build string content for this token
        since SyntaxChecker may not have interest on string content itself in certain case. After the parser is back to ASTBuilder, we parse "string!" as ExpressionStatement with string constant,
        generate StringNode with non-built identifier (nullptr), and we accidentally create StringNode with nullptr.

        This patch fixes this problem. The root cause of this problem is that the last token lexed in the previous context is used. We add lexCurrentTokenAgainUnderCurrentContext which will re-lex
        the current token under the current context (may be ASTBuilder). This should be done only when the caller's context is different from SyntaxChecker, which avoids unnecessary lexing.
        We leverage existing SavePoint mechanism to implement lexCurrentTokenAgainUnderCurrentContext cleanly.

        And we also fix the bug in the existing SavePoint mechanism, which is shown in the attached test script. When we save LexerState, we do not save line terminator status. This patch also introduces
        lexWithoutClearingLineTerminator, which lex the token without clearing line terminator status.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createString):
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseMultilineComment):
        (JSC::Lexer<T>::lexWithoutClearingLineTerminator): EOF token also should record offset information. This offset information is correctly handled in Lexer::setOffset too.
        (JSC::Lexer<T>::lex): Deleted.
        * parser/Lexer.h:
        (JSC::Lexer::hasLineTerminatorBeforeToken const):
        (JSC::Lexer::setHasLineTerminatorBeforeToken):
        (JSC::Lexer<T>::lex):
        (JSC::Lexer::prevTerminator const): Deleted.
        (JSC::Lexer::setTerminator): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::allowAutomaticSemicolon):
        (JSC::Parser<LexerType>::parseSingleFunction):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseYieldExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Parser::nextWithoutClearingLineTerminator):
        (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
        (JSC::Parser::internalSaveLexerState):
        (JSC::Parser::restoreLexerState):

2019-04-05  Caitlin Potter  <caitp@igalia.com>

        [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
        https://bugs.webkit.org/show_bug.cgi?id=176810

        Reviewed by Saam Barati.

        This adds conditional logic following the invariant checks, to perform
        filtering in common uses of getOwnPropertyNames.

        While this would ideally only be done in JSPropertyNameEnumerator, adding
        the filtering to ProxyObject::performGetOwnPropertyNames maintains the
        invariant that the EnumerationMode is properly followed.

        * runtime/PropertyNameArray.h:
        (JSC::PropertyNameArray::reset):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):

2019-04-05  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r243833.
        https://bugs.webkit.org/show_bug.cgi?id=196645

        This change breaks build of WPE and GTK ports (Requested by
        annulen on #webkit).

        Reverted changeset:

        "[CMake][WTF] Mirror XCode header directories"
        https://bugs.webkit.org/show_bug.cgi?id=191662
        https://trac.webkit.org/changeset/243833

2019-04-05  Caitlin Potter  <caitp@igalia.com>

        [JSC] throw if ownKeys Proxy trap result contains duplicate keys
        https://bugs.webkit.org/show_bug.cgi?id=185211

        Reviewed by Saam Barati.

        Implements the normative spec change in https://github.com/tc39/ecma262/pull/833

        This involves tracking duplicate keys returned from the ownKeys trap in yet
        another HashTable, and may incur a minor performance penalty in some cases. This
        is not expected to significantly affect web performance.

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::performGetOwnPropertyNames):

2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] makeBoundFunction should not assume incoming "length" value is Int32 because it performs some calculation in bytecode
        https://bugs.webkit.org/show_bug.cgi?id=196631

        Reviewed by Saam Barati.

        makeBoundFunction assumes that "length" argument is always Int32. But this should not be done since this "length" value is calculated in builtin JS code.
        DFG may store this value in Double format so that we should not rely on that this value is Int32. This patch fixes makeBoundFunction function to perform
        toInt32 operation. We also insert a missing exception check for `JSString::value(ExecState*)` in makeBoundFunction.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * interpreter/CallFrameInlines.h:
        * runtime/DoublePredictionFuzzerAgent.cpp: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
        (JSC::DoublePredictionFuzzerAgent::DoublePredictionFuzzerAgent):
        (JSC::DoublePredictionFuzzerAgent::getPrediction):
        * runtime/DoublePredictionFuzzerAgent.h: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
        * runtime/JSGlobalObject.cpp:
        (JSC::makeBoundFunction):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):

2019-04-04  Robin Morisset  <rmorisset@apple.com>

        B3ReduceStrength should know that Mul distributes over Add and Sub
        https://bugs.webkit.org/show_bug.cgi?id=196325
        <rdar://problem/49441650>

        Reviewed by Saam Barati.

        Fix some obviously wrong code that was due to an accidental copy-paste.
        It made the entire optimization dead code that never ran.

        * b3/B3ReduceStrength.cpp:

2019-04-04  Saam Barati  <sbarati@apple.com>

        Unreviewed, build fix for CLoop after r243886

        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
        * interpreter/StackVisitor.h:

2019-04-04  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r243898.
        https://bugs.webkit.org/show_bug.cgi?id=196624

        `#if !ENABLE(C_LOOP) && NUMBER_OF_CALLEE_SAVES_REGISTERS > 0`
        does not work well (Requested by yusukesuzuki on #webkit).

        Reverted changeset:

        "Unreviewed, build fix for CLoop and Windows after r243886"
        https://bugs.webkit.org/show_bug.cgi?id=196387
        https://trac.webkit.org/changeset/243898

2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, build fix for CLoop and Windows after r243886
        https://bugs.webkit.org/show_bug.cgi?id=196387

        RegisterAtOffsetList does not exist if ENABLE(ASSEMBLER) is false.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
        * interpreter/StackVisitor.h:

2019-04-04  Saam barati  <sbarati@apple.com>

        Teach Call ICs how to call Wasm
        https://bugs.webkit.org/show_bug.cgi?id=196387

        Reviewed by Filip Pizlo.

        This patch teaches JS to call Wasm without going through the native thunk.
        Currently, we emit a JIT "JS" callee stub which marshals arguments from
        JS to Wasm. Like the native version of this, this thunk is responsible
        for saving and restoring the VM's current Wasm context. Instead of emitting
        an exception handler, we also teach the unwinder how to read the previous
        wasm context to restore it as it unwindws past this frame.
        
        This patch is straight forward, and leaves some areas for perf improvement:
        - We can teach the DFG/FTL to directly use the Wasm calling convention when
          it knows it's calling a single Wasm function. This way we don't shuffle
          registers to the stack and then back into registers.
        - We bail out to the slow path for mismatched arity. I opened a bug to fix
          optimize arity check failures: https://bugs.webkit.org/show_bug.cgi?id=196564
        - We bail out to the slow path Double JSValues flowing into i32 arguments.
          We should teach this thunk how to do that conversion directly.
        
        This patch also refactors the code to explicitly have a single pinned size register.
        We used pretend in some places that we could have more than one pinned size register.
        However, there was other code that just asserted the size was one. This patch just rips
        out this code since we never moved to having more than one pinned size register. Doing
        this refactoring cleans up the various places where we set up the size register.
        
        This patch is a 50-60% progression on JetStream 2's richards-wasm.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodeRef::operator=):
        (JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator() const):
        (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
        (JSC::StackVisitor::Frame::calleeSaveRegisters): Deleted.
        * interpreter/StackVisitor.h:
        * jit/JITOperations.cpp:
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::runtimeTagRegisters):
        (JSC::RegisterSet::specialRegisters):
        (JSC::RegisterSet::runtimeRegisters): Deleted.
        * jit/RegisterSet.h:
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * runtime/JSFunction.cpp:
        (JSC::getCalculatedDisplayName):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::jsToWasmICCalleeStructure const):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::AirIRGenerator):
        (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::B3IRGenerator):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):
        * wasm/WasmContext.h:
        (JSC::Wasm::Context::pointerToInstance):
        * wasm/WasmContextInlines.h:
        (JSC::Wasm::Context::store):
        * wasm/WasmMemoryInformation.cpp:
        (JSC::Wasm::getPinnedRegisters):
        (JSC::Wasm::PinnedRegisterInfo::get):
        (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
        * wasm/WasmMemoryInformation.h:
        (JSC::Wasm::PinnedRegisterInfo::toSave const):
        * wasm/WasmOMGPlan.cpp:
        (JSC::Wasm::OMGPlan::work):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/JSToWasmICCallee.cpp: Added.
        (JSC::JSToWasmICCallee::create):
        (JSC::JSToWasmICCallee::createStructure):
        (JSC::JSToWasmICCallee::visitChildren):
        * wasm/js/JSToWasmICCallee.h: Added.
        (JSC::JSToWasmICCallee::function):
        (JSC::JSToWasmICCallee::JSToWasmICCallee):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::useTagRegisters const):
        (JSC::WebAssemblyFunction::calleeSaves const):
        (JSC::WebAssemblyFunction::usedCalleeSaveRegisters const):
        (JSC::WebAssemblyFunction::previousInstanceOffset const):
        (JSC::WebAssemblyFunction::previousInstance):
        (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
        (JSC::WebAssemblyFunction::visitChildren):
        (JSC::WebAssemblyFunction::destroy):
        * wasm/js/WebAssemblyFunction.h:
        * wasm/js/WebAssemblyFunctionHeapCellType.cpp: Added.
        (JSC::WebAssemblyFunctionDestroyFunc::operator() const):
        (JSC::WebAssemblyFunctionHeapCellType::WebAssemblyFunctionHeapCellType):
        (JSC::WebAssemblyFunctionHeapCellType::~WebAssemblyFunctionHeapCellType):
        (JSC::WebAssemblyFunctionHeapCellType::finishSweep):
        (JSC::WebAssemblyFunctionHeapCellType::destroy):
        * wasm/js/WebAssemblyFunctionHeapCellType.h: Added.
        * wasm/js/WebAssemblyPrototype.h:

2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Pass CodeOrigin to FuzzerAgent
        https://bugs.webkit.org/show_bug.cgi?id=196590

        Reviewed by Saam Barati.

        Pass CodeOrigin instead of bytecodeIndex. CodeOrigin includes richer information (InlineCallFrame*).
        We also mask prediction with SpecBytecodeTop in DFGByteCodeParser. The fuzzer can produce any SpeculatedTypes,
        but DFGByteCodeParser should only see predictions that can be actually produced from the bytecode execution.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        * runtime/FuzzerAgent.cpp:
        (JSC::FuzzerAgent::getPrediction):
        * runtime/FuzzerAgent.h:
        * runtime/RandomizingFuzzerAgent.cpp:
        (JSC::RandomizingFuzzerAgent::getPrediction):
        * runtime/RandomizingFuzzerAgent.h:

2019-04-04  Caio Lima  <ticaiolima@gmail.com>

        [JSC] We should consider moving UnlinkedFunctionExecutable::m_parentScopeTDZVariables to RareData
        https://bugs.webkit.org/show_bug.cgi?id=194944

        Reviewed by Keith Miller.

        Based on profile data collected on JetStream2, Speedometer 2 and
        other benchmarks, it is very rare having non-empty
        UnlinkedFunctionExecutable::m_parentScopeTDZVariables.

        - Data collected from Speedometer2
            Total number of UnlinkedFunctionExecutable: 39463
            Total number of non-empty parentScopeTDZVars: 428 (~1%)

        - Data collected from JetStream2
            Total number of UnlinkedFunctionExecutable: 83715
            Total number of non-empty parentScopeTDZVars: 5285 (~6%)

        We also collected numbers on 6 of top 10 Alexia sites.

        - Data collected from youtube.com
            Total number of UnlinkedFunctionExecutable: 29599
            Total number of non-empty parentScopeTDZVars: 97 (~0.3%)

        - Data collected from twitter.com
            Total number of UnlinkedFunctionExecutable: 23774
            Total number of non-empty parentScopeTDZVars: 172 (~0.7%)

        - Data collected from google.com
            Total number of UnlinkedFunctionExecutable: 33209
            Total number of non-empty parentScopeTDZVars: 174 (~0.5%)

        - Data collected from amazon.com:
            Total number of UnlinkedFunctionExecutable: 15182
            Total number of non-empty parentScopeTDZVars: 166 (~1%)

        - Data collected from facebook.com:
            Total number of UnlinkedFunctionExecutable: 54443
            Total number of non-empty parentScopeTDZVars: 269 (~0.4%)

        - Data collected from netflix.com:
            Total number of UnlinkedFunctionExecutable: 39266
            Total number of non-empty parentScopeTDZVars: 97 (~0.2%)

        Considering such numbers, this patch is moving `m_parentScopeTDZVariables`
        to RareData. This decreases sizeof(UnlinkedFunctionExecutable) by
        16 bytes. With this change, now UnlinkedFunctionExecutable constructors
        receives an `Optional<VariableEnvironmentMap::Handle>` and only stores
        it when `value != WTF::nullopt`. We also changed
        UnlinkedFunctionExecutable::parentScopeTDZVariables() and it returns
        `VariableEnvironment()` whenever the Executable doesn't have RareData,
        or VariableEnvironmentMap::Handle is unitialized. This is required
        because RareData is instantiated when any of its field is stored and
        we can have an unitialized `Handle` even on cases when parentScopeTDZVariables
        is `WTF::nullopt`.

        Results on memory usage on JetStrem2 is neutral.

            Mean of memory peak on ToT: 4258633728 bytes (confidence interval: 249720072.95)
            Mean of memory peak on Changes: 4367325184 bytes (confidence interval: 321285583.61)

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):

        BytecodeGenerator::getVariablesUnderTDZ now also caches if m_cachedVariablesUnderTDZ
        is empty, so we can properly return `WTF::nullopt` without the
        reconstruction of a VariableEnvironment to check if it is empty.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        * parser/VariableEnvironment.h:
        (JSC::VariableEnvironment::isEmpty const):
        * runtime/CachedTypes.cpp:
        (JSC::CachedCompactVariableMapHandle::decode const):

        It returns an unitialized Handle when there is no
        CompactVariableEnvironment. This can happen when RareData is ensured
        because of another field.

        (JSC::CachedFunctionExecutableRareData::encode):
        (JSC::CachedFunctionExecutableRareData::decode const):
        (JSC::CachedFunctionExecutable::encode):
        (JSC::CachedFunctionExecutable::decode const):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * runtime/CodeCache.cpp:

        Instead of creating a dummyVariablesUnderTDZ, we simply pass
        WTF::nullopt.

        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):

2019-04-04  Tadeu Zagallo  <tzagallo@apple.com>

        Cache bytecode for jsc.cpp helpers and fix CachedStringImpl
        https://bugs.webkit.org/show_bug.cgi?id=196409

        Reviewed by Saam Barati.

        Some of the helpers in jsc.cpp, such as `functionRunString`, were stll using
        using `makeSource` instead of `jscSource`, which does not use the ShellSourceProvider
        and therefore does not write the bytecode cache to disk.

        Changing that revealed a bug in bytecode cache. The Encoder keeps a mapping
        of pointers to offsets of already cached objects, in order to avoid caching
        the same object twice. Similarly, the Decoder keeps a mapping from offsets
        to pointers, in order to avoid creating multiple objects in memory for the
        same cached object. The following was happening:
        1) A StringImpl* S was cached as CachedPtr<CachedStringImpl> at offset O. We add
        an entry in the Encoder mapping that S has already been encoded at O.
        2) We cache StringImpl* S again, but now as CachedPtr<CachedUniquedStringImpl>.
        We find an entry in the Encoder mapping for S, and return the offset O. However,
        the object cached at O is a CachedPtr<CachedStringImpl> (i.e. not Uniqued).

        3) When decoding, there are 2 possibilities:
        3.1) We find S for the first time through a CachedPtr<CachedStringImpl>. In
        this case, everything works as expected since we add an entry in the decoder
        mapping from the offset O to the decoded StringImpl* S. The next time we find
        S through the uniqued version, we'll return the already decoded S.
        3.2) We find S through a CachedPtr<CachedUniquedStringImpl>. Now we have a
        problem, since the CachedPtr has the offset of a CachedStringImpl (not uniqued),
        which has a different shape and we crash.

        We fix this by making CachedStringImpl and CachedUniquedStringImpl share the
        same implementation. Since it doesn't matter whether a string is uniqued for
        encoding, and we always decode strings as uniqued either way, they can be used
        interchangeably.

        * jsc.cpp:
        (functionRunString):
        (functionLoadString):
        (functionDollarAgentStart):
        (functionCheckModuleSyntax):
        (runInteractive):
        * runtime/CachedTypes.cpp:
        (JSC::CachedUniquedStringImplBase::decode const):
        (JSC::CachedFunctionExecutable::rareData const):
        (JSC::CachedCodeBlock::rareData const):
        (JSC::CachedFunctionExecutable::encode):
        (JSC::CachedCodeBlock<CodeBlockType>::encode):
        (JSC::CachedUniquedStringImpl::encode): Deleted.
        (JSC::CachedUniquedStringImpl::decode const): Deleted.
        (JSC::CachedStringImpl::encode): Deleted.
        (JSC::CachedStringImpl::decode const): Deleted.

2019-04-04  Tadeu Zagallo  <tzagallo@apple.com>

        UnlinkedCodeBlock constructor from cache should initialize m_didOptimize
        https://bugs.webkit.org/show_bug.cgi?id=196396

        Reviewed by Saam Barati.

        The UnlinkedCodeBlock constructor in CachedTypes was missing the initialization
        for m_didOptimize, which leads to crashes in CodeBlock::thresholdForJIT.

        * runtime/CachedTypes.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):

2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, rolling in r243843 with the build fix
        https://bugs.webkit.org/show_bug.cgi?id=196586

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:
        * runtime/RandomizingFuzzerAgent.cpp:
        (JSC::RandomizingFuzzerAgent::getPrediction):

2019-04-03  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r243843.

        Broke CLoop and Windows builds.

        Reverted changeset:

        "[JSC] Add dump feature for RandomizingFuzzerAgent"
        https://bugs.webkit.org/show_bug.cgi?id=196586
        https://trac.webkit.org/changeset/243843

2019-04-03  Robin Morisset  <rmorisset@apple.com>

        B3 should use associativity to optimize expression trees
        https://bugs.webkit.org/show_bug.cgi?id=194081

        Reviewed by Filip Pizlo.

        This patch adds a new B3 pass, that tries to find and optimize expression trees made purely of any one associative and commutative operator (Add/Mul/BitOr/BitAnd/BitXor).
        The pass only runs in O2, and runs once, after lowerMacros and just before a run of B3ReduceStrength (which helps clean up the dead code it tends to leave behind).
        I had to separate killDeadCode out of B3ReduceStrength (as a new B3EliminateDeadCode pass) to run it before B3OptimizeAssociativeExpressionTrees, as otherwise it is stopped by high use counts
        inherited from CSE.
        This extra run of DCE is by itself a win, most notably on microbenchmarks/instanceof-always-hit-two (1.5x faster), and on microbenchmarks/licm-dragons(-out-of-bounds) (both get 1.16x speedup).
        I suspect it is because it runs between CSE and tail-dedup, and as a result allows a lot more tail-dedup to occur.

        The pass is currently extremely conservative, not trying anything if it would cause _any_ code duplication.
        For this purpose, it starts by computing use counts for the potentially interesting nodes (those with the right opcodes), and segregate them into expression trees.
        The root of an expression tree is a node that is either used in multiple places, or is used by a value with a different opcode.
        The leaves of an expression tree are nodes that are either used in multiple places, or have a different opcode.
        All constant leaves of a tree are combined, as well as all leaves that are identical. What remains is then laid out into a balanced binary tree, hopefully maximizing ILP.

        This optimization was implemented as a stand-alone pass and not as part of B3ReduceStrength mostly because it needs use counts to avoid code duplication.
        It also benefits from finding all tree roots first, and not trying to repeatedly optimize subtrees.

        I added several tests to testB3 with varying patterns of trees. It is also tested in a less focused way by lots of older tests.

        In the future this pass could be expanded to allow some bounded amount of code duplication, and merging more leaves (e.g. Mul(a, 3) and a in an Add tree, into Mul(a, 4))
        The latter will need exposing the peephole optimizations out of B3ReduceStrength to avoid duplicating code.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * b3/B3Common.cpp:
        (JSC::B3::shouldDumpIR):
        (JSC::B3::shouldDumpIRAtEachPhase):
        * b3/B3Common.h:
        * b3/B3EliminateDeadCode.cpp: Added.
        (JSC::B3::EliminateDeadCode::run):
        (JSC::B3::eliminateDeadCode):
        * b3/B3EliminateDeadCode.h: Added.
        (JSC::B3::EliminateDeadCode::EliminateDeadCode):
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3OptimizeAssociativeExpressionTrees.cpp: Added.
        (JSC::B3::OptimizeAssociativeExpressionTrees::OptimizeAssociativeExpressionTrees):
        (JSC::B3::OptimizeAssociativeExpressionTrees::neutralElement):
        (JSC::B3::OptimizeAssociativeExpressionTrees::isAbsorbingElement):
        (JSC::B3::OptimizeAssociativeExpressionTrees::combineConstants):
        (JSC::B3::OptimizeAssociativeExpressionTrees::emitValue):
        (JSC::B3::OptimizeAssociativeExpressionTrees::optimizeRootedTree):
        (JSC::B3::OptimizeAssociativeExpressionTrees::run):
        (JSC::B3::optimizeAssociativeExpressionTrees):
        * b3/B3OptimizeAssociativeExpressionTrees.h: Added.
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::replaceWithIdentity):
        * b3/testb3.cpp:
        (JSC::B3::testBitXorTreeArgs):
        (JSC::B3::testBitXorTreeArgsEven):
        (JSC::B3::testBitXorTreeArgImm):
        (JSC::B3::testAddTreeArg32):
        (JSC::B3::testMulTreeArg32):
        (JSC::B3::testBitAndTreeArg32):
        (JSC::B3::testBitOrTreeArg32):
        (JSC::B3::run):

2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Add dump feature for RandomizingFuzzerAgent
        https://bugs.webkit.org/show_bug.cgi?id=196586

        Reviewed by Saam Barati.

        Towards deterministic tests for the results from randomizing fuzzer agent, this patch adds Options::dumpRandomizingFuzzerAgentPredictions, which dumps the generated types.
        The results is like this.

            getPrediction name:(#C2q9xD),bytecodeIndex:(22),original:(Array),generated:(OtherObj|Array|Float64Array|BigInt|NonIntAsDouble)
            getPrediction name:(makeUnwriteableUnconfigurableObject#AiEJv1),bytecodeIndex:(14),original:(OtherObj),generated:(Final|Uint8Array|Float64Array|SetObject|WeakSetObject|BigInt|NonIntAsDouble)

        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:
        * runtime/RandomizingFuzzerAgent.cpp:
        (JSC::RandomizingFuzzerAgent::getPrediction):

2019-04-03  Myles C. Maxfield  <mmaxfield@apple.com>

        -apple-trailing-word is needed for browser detection
        https://bugs.webkit.org/show_bug.cgi?id=196575

        Unreviewed.

        * Configurations/FeatureDefines.xcconfig:

2019-04-03  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r243642): com.apple.JavaScriptCore crash in JSC::RegExpObject::execInline
        https://bugs.webkit.org/show_bug.cgi?id=196477

        Reviewed by Keith Miller.

        The problem here is that when we advance the index by 2 for a character class that only
        has non-BMP characters, we might go past the end of the string.  This can happen for
        greedy counted character classes that are part of a alternative where there is one
        character to match after the greedy non-BMP character class.

        The "do we have string left to match" check at the top of the JIT loop for the counted
        character class checks to see if index is not equal to the string length.  For non-BMP
        character classes, we need to check to see if there are at least 2 characters left.
        Therefore we now temporarily add 1 to the current index before comparing.  This checks
        to see if there are iat least 2 characters left to match, instead of 1.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):

2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Exception verification crash on operationArrayIndexOfValueInt32OrContiguous
        https://bugs.webkit.org/show_bug.cgi?id=196574

        Reviewed by Saam Barati.

        This patch adds missing exception check in operationArrayIndexOfValueInt32OrContiguous.

        * dfg/DFGOperations.cpp:

2019-04-03  Don Olmstead  <don.olmstead@sony.com>

        [CMake][WTF] Mirror XCode header directories
        https://bugs.webkit.org/show_bug.cgi?id=191662

        Reviewed by Konstantin Tokarev.

        Use WTFFramework as a dependency and include frameworks/WTF.cmake for AppleWin internal
        builds.

        * CMakeLists.txt:
        * shell/CMakeLists.txt:

2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Add FuzzerAgent, which has a hooks to get feedback & inject fuzz data into JSC
        https://bugs.webkit.org/show_bug.cgi?id=196530

        Reviewed by Saam Barati.

        This patch adds FuzzerAgent interface and simple RandomizingFuzzerAgent to JSC.
        This RandomizingFuzzerAgent returns random SpeculatedType for value profiling to find
        the issues in JSC. The seed for randomization can be specified by seedOfRandomizingFuzzerAgent.

        I ran this with seedOfRandomizingFuzzerAgent=1 last night and it finds 3 failures in the current JSC tests,
        they should be fixed in subsequent patches.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        * runtime/FuzzerAgent.cpp: Added.
        (JSC::FuzzerAgent::~FuzzerAgent):
        (JSC::FuzzerAgent::getPrediction):
        * runtime/FuzzerAgent.h: Added.
        * runtime/JSGlobalObjectFunctions.cpp:
        * runtime/Options.h:
        * runtime/RandomizingFuzzerAgent.cpp: Added.
        (JSC::RandomizingFuzzerAgent::RandomizingFuzzerAgent):
        (JSC::RandomizingFuzzerAgent::getPrediction):
        * runtime/RandomizingFuzzerAgent.h: Added.
        * runtime/RegExpCachedResult.h:
        * runtime/RegExpGlobalData.cpp:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::fuzzerAgent const):
        (JSC::VM::setFuzzerAgent):

2019-04-03  Myles C. Maxfield  <mmaxfield@apple.com>

        Remove support for -apple-trailing-word
        https://bugs.webkit.org/show_bug.cgi?id=196525

        Reviewed by Zalan Bujtas.

        This CSS property is nonstandard and not used.

        * Configurations/FeatureDefines.xcconfig:

2019-04-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remote Inspector indicate callback should always happen on the main thread
        https://bugs.webkit.org/show_bug.cgi?id=196513
        <rdar://problem/49498284>

        Reviewed by Devin Rousso.

        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        (Inspector::RemoteInspector::receivedIndicateMessage):
        When we have a WebThread, don't just run on the WebThread,
        run on the MainThread with the WebThreadLock.

2019-04-02  Michael Saboff  <msaboff@apple.com>

        Crash in Options::setOptions() using --configFile option and libgmalloc
        https://bugs.webkit.org/show_bug.cgi?id=196506

        Reviewed by Keith Miller.

        Changed to call CString::data() while making the call to Options::setOptions().  This keeps
        the implicit CString temporary alive until after setOptions() returns.

        * runtime/ConfigFile.cpp:
        (JSC::ConfigFile::parse):

2019-04-02  Fujii Hironori  <Hironori.Fujii@sony.com>

        [CMake] WEBKIT_MAKE_FORWARDING_HEADERS shouldn't use POST_BUILD to copy generated headers
        https://bugs.webkit.org/show_bug.cgi?id=182757

        Reviewed by Don Olmstead.

        * CMakeLists.txt: Do not use DERIVED_SOURCE_DIRECTORIES parameter
        of WEBKIT_MAKE_FORWARDING_HEADERS. Added generated headers to
        JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS.

2019-04-02  Saam barati  <sbarati@apple.com>

        Add a ValueRepReduction phase
        https://bugs.webkit.org/show_bug.cgi?id=196234

        Reviewed by Filip Pizlo.

        This patch adds a ValueRepReduction phase. The main idea here is
        to try to reduce DoubleRep(RealNumberUse:ValueRep(DoubleRepUse:@x))
        to just be @x. This patch handles such above strengh reduction rules
        as long as we prove that all users of the ValueRep can be converted
        to using the incoming double value. That way we prevent introducing
        a parallel live range for the double value.
        
        This patch tracks the uses of the ValueRep through Phi variables,
        so we can convert entire Phi variables to being Double instead
        of JSValue if the Phi also has only double uses.
        
        This is implemented through a simple escape analysis. DoubleRep(RealNumberUse:)
        and OSR exit hints are not counted as escapes. All other uses are counted
        as escapes. Connected Phi graphs are converted to being Double only if the
        entire graph is ok with the result being Double.
        
        Some ways we could extend this phase in the future:
        - There are a lot of DoubleRep(NumberUse:@ValueRep(@x)) uses. This ensures
          that the result of the DoubleRep of @x is not impure NaN. We could
          handle this case if we introduced a PurifyNaN node and replace the DoubleRep
          with PurifyNaN(@x). Alternatively, we could see if certain users of this
          DoubleRep are okay with impure NaN flowing into them and we'd need to ensure
          their output type is always treated as if the input is impure NaN.
        - We could do sinking of ValueRep where we think it's profitable. So instead
          of an escape making it so we never represent the variable as a Double, we
          could make the escape reconstruct the JSValueRep where profitable.
        - We can extend this phase to handle Int52Rep if it's profitable.
        - We can opt other nodes into accepting incoming Doubles so we no longer
          treat them as escapes.
        
        This patch is somewhere between neutral and a 1% progression on JetStream 2.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGValueRepReductionPhase.cpp: Added.
        (JSC::DFG::ValueRepReductionPhase::ValueRepReductionPhase):
        (JSC::DFG::ValueRepReductionPhase::run):
        (JSC::DFG::ValueRepReductionPhase::convertValueRepsToDouble):
        (JSC::DFG::performValueRepReduction):
        * dfg/DFGValueRepReductionPhase.h: Added.
        * runtime/Options.h:

2019-04-01  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] JSRunLoopTimer::Manager should be small
        https://bugs.webkit.org/show_bug.cgi?id=196425

        Reviewed by Darin Adler.

        Using very large Key or Value in HashMap potentially bloats memory since HashMap pre-allocates large size of
        memory ((sizeof(Key) + sizeof(Value)) * N) for its backing storage's array. Using std::unique_ptr<> for JSRunLoopTimer's
        PerVMData to keep HashMap's backing store size small.

        * runtime/JSRunLoopTimer.cpp:
        (JSC::JSRunLoopTimer::Manager::timerDidFire):
        (JSC::JSRunLoopTimer::Manager::registerVM):
        (JSC::JSRunLoopTimer::Manager::scheduleTimer):
        (JSC::JSRunLoopTimer::Manager::cancelTimer):
        (JSC::JSRunLoopTimer::Manager::timeUntilFire):
        (JSC::JSRunLoopTimer::Manager::didChangeRunLoop):
        * runtime/JSRunLoopTimer.h:

2019-04-01  Stephan Szabo  <stephan.szabo@sony.com>

        [PlayStation] Add initialization for JSC shell for PlayStation port
        https://bugs.webkit.org/show_bug.cgi?id=195411

        Reviewed by Ross Kirsling.

        Add ps options

        * shell/PlatformPlayStation.cmake: Added.
        * shell/playstation/Initializer.cpp: Added.
        (initializer):

2019-04-01  Michael Catanzaro  <mcatanzaro@igalia.com>

        Stop trying to support building JSC with clang 3.8
        https://bugs.webkit.org/show_bug.cgi?id=195947
        <rdar://problem/49069219>

        Reviewed by Darin Adler.

        It seems WebKit hasn't built with clang 3.8 in a while, no devs are using this compiler, we
        don't know how much effort it would be to make JSC work again, and it's making the code
        worse. Remove my hacks to support clang 3.8 from JSC.

        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::create):
        (JSC::GetterSetterAccessCase::clone const):
        * bytecode/InstanceOfAccessCase.cpp:
        (JSC::InstanceOfAccessCase::clone const):
        * bytecode/IntrinsicGetterAccessCase.cpp:
        (JSC::IntrinsicGetterAccessCase::clone const):
        * bytecode/ModuleNamespaceAccessCase.cpp:
        (JSC::ModuleNamespaceAccessCase::clone const):
        * bytecode/ProxyableAccessCase.cpp:
        (JSC::ProxyableAccessCase::clone const):

2019-03-31  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Butterfly allocation from LargeAllocation should try "realloc" behavior if collector thread is not active
        https://bugs.webkit.org/show_bug.cgi?id=196160

        Reviewed by Saam Barati.

        "realloc" can be effective in terms of peak/current memory footprint when realloc succeeds because,

        1. It does not allocate additional memory while expanding a vector
        2. It does not deallocate an old memory, just reusing the current memory by expanding, so that memory footprint is tight even before scavenging

        We found that we can "realloc" large butterflies in certain conditions are met because,

        1. If it goes to LargeAllocation, this memory region is never reused until GC sweeps it.
        2. Butterflies are owned by owner JSObjects, so we know the lifetime of Butterflies.

        This patch attempts to use "realloc" onto butterflies if,

        1. Butterflies are allocated in LargeAllocation kind
        2. Concurrent collector is not active
        3. Butterflies do not have property storage

        The condition (2) is required to avoid deallocating butterflies while the concurrent collector looks into it. The condition (3) is
        also required to avoid deallocating butterflies while the concurrent compiler looks into it.

        We also change LargeAllocation mechanism to using "malloc" and "free" instead of "posix_memalign". This allows us to use "realloc"
        safely in all the platforms. Since LargeAllocation uses alignment to distinguish LargeAllocation and MarkedBlock, we manually adjust
        16B alignment by allocating 8B more memory in "malloc".

        Speedometer2 and JetStream2 are neutral. RAMification shows about 1% progression (even in some of JIT tests).

        * heap/AlignedMemoryAllocator.h:
        * heap/CompleteSubspace.cpp:
        (JSC::CompleteSubspace::tryAllocateSlow):
        (JSC::CompleteSubspace::reallocateLargeAllocationNonVirtual):
        * heap/CompleteSubspace.h:
        * heap/FastMallocAlignedMemoryAllocator.cpp:
        (JSC::FastMallocAlignedMemoryAllocator::tryAllocateMemory):
        (JSC::FastMallocAlignedMemoryAllocator::freeMemory):
        (JSC::FastMallocAlignedMemoryAllocator::tryReallocateMemory):
        * heap/FastMallocAlignedMemoryAllocator.h:
        * heap/GigacageAlignedMemoryAllocator.cpp:
        (JSC::GigacageAlignedMemoryAllocator::tryAllocateMemory):
        (JSC::GigacageAlignedMemoryAllocator::freeMemory):
        (JSC::GigacageAlignedMemoryAllocator::tryReallocateMemory):
        * heap/GigacageAlignedMemoryAllocator.h:
        * heap/IsoAlignedMemoryAllocator.cpp:
        (JSC::IsoAlignedMemoryAllocator::tryAllocateMemory):
        (JSC::IsoAlignedMemoryAllocator::freeMemory):
        (JSC::IsoAlignedMemoryAllocator::tryReallocateMemory):
        * heap/IsoAlignedMemoryAllocator.h:
        * heap/LargeAllocation.cpp:
        (JSC::isAlignedForLargeAllocation):
        (JSC::LargeAllocation::tryCreate):
        (JSC::LargeAllocation::tryReallocate):
        (JSC::LargeAllocation::LargeAllocation):
        (JSC::LargeAllocation::destroy):
        * heap/LargeAllocation.h:
        (JSC::LargeAllocation::indexInSpace):
        (JSC::LargeAllocation::setIndexInSpace):
        (JSC::LargeAllocation::basePointer const):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::sweepLargeAllocations):
        (JSC::MarkedSpace::prepareForConservativeScan):
        * heap/WeakSet.h:
        (JSC::WeakSet::isTriviallyDestructible const):
        * runtime/Butterfly.h:
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::reallocArrayRightIfPossible):
        * runtime/JSObject.cpp:
        (JSC::JSObject::ensureLengthSlow):

2019-03-31  Sam Weinig  <weinig@apple.com>

        Remove more i386 specific configurations
        https://bugs.webkit.org/show_bug.cgi?id=196430

        Reviewed by Alexey Proskuryakov.

        * Configurations/FeatureDefines.xcconfig:
        ENABLE_WEB_AUTHN_macosx can now be enabled unconditionally on macOS.

        * Configurations/ToolExecutable.xcconfig:
        ARC can be enabled unconditionally now.

2019-03-29  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] JSWrapperMap should not use Objective-C Weak map (NSMapTable with NSPointerFunctionsWeakMemory) for m_cachedObjCWrappers
        https://bugs.webkit.org/show_bug.cgi?id=196392

        Reviewed by Saam Barati.

        Weak representation in Objective-C is surprisingly costly in terms of memory. We can see that very easy program shows 10KB memory consumption due to
        this weak wrapper map in JavaScriptCore.framework. But we do not need this weak map since Objective-C JSValue has a dealloc. We can unregister itself
        from the map when it is deallocated without using Objective-C weak mechanism. And since Objective-C JSValue is tightly coupled to a specific JSContext,
        and wrapper map is created per JSContext, JSValue wrapper and actual JavaScriptCore value is one-on-one, and [JSValue dealloc] knows which JSContext's
        wrapper map holds itself.

        1. We do not use Objective-C weak mechanism. We use WTF::HashSet instead. When JSValue is allocated, we register it to JSWrapperMap's HashSet. And unregister
           JSValue from this map when JSValue is deallocated.
        2. We use HashSet<JSValue> (logically) instead of HashMap<JSValueRef, JSValue> to keep JSValueRef and JSValue relationship. We can achieve it because JSValue
           holds JSValueRef inside it.

        * API/JSContext.mm:
        (-[JSContext removeWrapper:]):
        * API/JSContextInternal.h:
        * API/JSValue.mm:
        (-[JSValue dealloc]):
        (-[JSValue initWithValue:inContext:]):
        * API/JSWrapperMap.h:
        * API/JSWrapperMap.mm:
        (WrapperKey::hashTableDeletedValue):
        (WrapperKey::WrapperKey):
        (WrapperKey::isHashTableDeletedValue const):
        (WrapperKey::Hash::hash):
        (WrapperKey::Hash::equal):
        (WrapperKey::Traits::isEmptyValue):
        (WrapperKey::Translator::hash):
        (WrapperKey::Translator::equal):
        (WrapperKey::Translator::translate):
        (-[JSWrapperMap initWithGlobalContextRef:]):
        (-[JSWrapperMap dealloc]):
        (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
        (-[JSWrapperMap removeWrapper:]):
        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):

2019-03-29  Robin Morisset  <rmorisset@apple.com>

        B3ReduceStrength should know that Mul distributes over Add and Sub
        https://bugs.webkit.org/show_bug.cgi?id=196325

        Reviewed by Michael Saboff.

        In this patch I add the following patterns to B3ReduceStrength:
        - Turn this: Integer Neg(Mul(value, c))
          Into this: Mul(value, -c), as long as -c does not overflow
        - Turn these: Integer Mul(value, Neg(otherValue)) and Integer Mul(Neg(value), otherValue)
          Into this: Neg(Mul(value, otherValue))
        - For Op==Add or Sub, turn any of these:
             Op(Mul(x1, x2), Mul(x1, x3))
             Op(Mul(x2, x1), Mul(x1, x3))
             Op(Mul(x1, x2), Mul(x3, x1))
             Op(Mul(x2, x1), Mul(x3, x1))
          Into this: Mul(x1, Op(x2, x3))

        Also includes a trivial change: a similar reduction for the distributivity of BitAnd over BitOr/BitXor now
        emits the arguments to BitAnd in the other order, to minimize the probability that we'll spend a full fixpoint step just to flip them.

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testAddMulMulArgs):
        (JSC::B3::testMulArgNegArg):
        (JSC::B3::testMulNegArgArg):
        (JSC::B3::testNegMulArgImm):
        (JSC::B3::testSubMulMulArgs):
        (JSC::B3::run):

2019-03-29  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Remove distancing for LargeAllocation
        https://bugs.webkit.org/show_bug.cgi?id=196335

        Reviewed by Saam Barati.

        In r230226, we removed distancing feature from our GC. This patch removes remaining distancing thing in LargeAllocation.

        * heap/HeapCell.h:
        * heap/LargeAllocation.cpp:
        (JSC::LargeAllocation::tryCreate):
        * heap/MarkedBlock.h:

2019-03-29  Myles C. Maxfield  <mmaxfield@apple.com>

        Delete WebMetal implementation in favor of WebGPU
        https://bugs.webkit.org/show_bug.cgi?id=195418

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig:
        * inspector/protocol/Canvas.json:
        * inspector/scripts/codegen/generator.py:

2019-03-29  Tadeu Zagallo  <tzagallo@apple.com>

        Assertion failed in JSC::createError
        https://bugs.webkit.org/show_bug.cgi?id=196305
        <rdar://problem/49387382>

        Reviewed by Saam Barati.

        JSC::createError assumes that `errorDescriptionForValue` will either
        throw an exception or return a valid description string. However, that
        is not true if the value is a rope string and we successfully resolve it,
        but later fail to wrap the string in quotes with `tryMakeString`.

        * runtime/ExceptionHelpers.cpp:
        (JSC::createError):

2019-03-29  Devin Rousso  <drousso@apple.com>

        Web Inspector: add fast returns for instrumentation hooks that have no affect before a frontend is connected
        https://bugs.webkit.org/show_bug.cgi?id=196382
        <rdar://problem/49403417>

        Reviewed by Joseph Pecoraro.

        Ensure that all instrumentation hooks use `FAST_RETURN_IF_NO_FRONTENDS` or check that
        `developerExtrasEnabled`. There should be no activity to/from any inspector objects until
        developer extras are enabled.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::startTiming):
        (Inspector::InspectorConsoleAgent::stopTiming):
        (Inspector::InspectorConsoleAgent::count):
        (Inspector::InspectorConsoleAgent::addConsoleMessage):

2019-03-29  Cathie Chen  <cathiechen@igalia.com>

        Implement ResizeObserver.
        https://bugs.webkit.org/show_bug.cgi?id=157743

        Reviewed by Simon Fraser.

        Add ENABLE_RESIZE_OBSERVER.

        * Configurations/FeatureDefines.xcconfig:

2019-03-28  Michael Saboff  <msaboff@apple.com>

        [YARR] Precompute BMP / non-BMP status when constructing character classes
        https://bugs.webkit.org/show_bug.cgi?id=196296

        Reviewed by Keith Miller.

        Changed CharacterClass::m_hasNonBMPCharacters into a character width bit field which
        indicateis if the class includes characters from either BMP, non-BMP or both ranges.
        This allows the recognizing code to eliminate checks for the width of a matched
        characters when the class has only one width.  The character width is needed to
        determine if we advance 1 or 2 character.  Also, the pre-computed width of character
        classes that contains either all BMP or all non-BMP characters allows the parser to
        use fixed widths for terms using those character classes.  Changed both the code gen
        scripts and Yarr compiler to compute this bit field during the construction of
        character classes.

        For JIT'ed code of character classes that contain either all BMP or all non-BMP
        characters, we can eliminate the generic check we were doing do compute how much
        to advance after sucessfully matching a character in the class.

                Generic isBMP check      BMP only            non-BMP only
                --------------           --------------      --------------
                inc %r9d                 inc %r9d            add $0x2, %r9d
                cmp $0x10000, %eax
                jl isBMP
                cmp %edx, %esi
                jz atEndOfString
                inc %r9d
                inc %esi
         isBMP:

        For character classes that contained non-BMP characters, we were always generating
        the code in the left column.  The middle column is the code we generate for character
        classes that contain only BMP characters.  The right column is the code we now
        generate if the character class has only non-BMP characters.  In the fix width cases,
        we can eliminate both the isBMP check as well as the atEndOfString check.  The
        atEndOfstring check is eliminated since we know how many characters this character
        class requires and that check can be factored out to the beginning of the current
        alternative.  For character classes that contain both BMP and non-BMP characters,
        we still generate the generic left column.

        This change is a ~8% perf progression on UniPoker and a ~2% improvement on RexBench
        as a whole.

        * runtime/RegExp.cpp:
        (JSC::RegExp::matchCompareWithInterpreter):
        * runtime/RegExpInlines.h:
        (JSC::RegExp::matchInline):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::checkCharacterClassDontAdvanceInputForNonBMP):
        (JSC::Yarr::Interpreter::matchCharacterClass):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::optimizeAlternative):
        (JSC::Yarr::YarrGenerator::matchCharacterClass):
        (JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch):
        (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy):
        (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::YarrGenerator):
        (JSC::Yarr::YarrGenerator::compile):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
        (JSC::Yarr::CharacterClassConstructor::reset):
        (JSC::Yarr::CharacterClassConstructor::charClass):
        (JSC::Yarr::CharacterClassConstructor::addSorted):
        (JSC::Yarr::CharacterClassConstructor::addSortedRange):
        (JSC::Yarr::CharacterClassConstructor::hasNonBMPCharacters):
        (JSC::Yarr::CharacterClassConstructor::characterWidths):
        (JSC::Yarr::PatternTerm::dump):
        (JSC::Yarr::anycharCreate):
        * yarr/YarrPattern.h:
        (JSC::Yarr::operator|):
        (JSC::Yarr::operator&):
        (JSC::Yarr::operator|=):
        (JSC::Yarr::CharacterClass::CharacterClass):
        (JSC::Yarr::CharacterClass::hasNonBMPCharacters):
        (JSC::Yarr::CharacterClass::hasOneCharacterSize):
        (JSC::Yarr::CharacterClass::hasOnlyNonBMPCharacters):
        (JSC::Yarr::PatternTerm::invert const):
        (JSC::Yarr::PatternTerm::invert): Deleted.
        * yarr/create_regex_tables:
        * yarr/generateYarrUnicodePropertyTables.py:

2019-03-28  Saam Barati  <sbarati@apple.com>

        BackwardsGraph needs to consider back edges as the backward's root successor
        https://bugs.webkit.org/show_bug.cgi?id=195991

        Reviewed by Filip Pizlo.

        * b3/testb3.cpp:
        (JSC::B3::testInfiniteLoopDoesntCauseBadHoisting):
        (JSC::B3::run):

2019-03-28  Fujii Hironori  <Hironori.Fujii@sony.com>

        Opcode.h(159,27): warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int]
        https://bugs.webkit.org/show_bug.cgi?id=196343

        Reviewed by Saam Barati.

        Clang reports a compilation warning and recommend '&PADDING_STRING[PADDING_STRING_LENGTH]'
        instead of 'PADDING_STRING + PADDING_STRING_LENGTH'.

        * bytecode/Opcode.cpp:
        (JSC::padOpcodeName): Moved padOpcodeName from Opcode.h because
        this function is used only in Opcode.cpp. Changed macros
        PADDING_STRING and PADDING_STRING_LENGTH to simple variables.
        (JSC::compareOpcodePairIndices): Replaced pair with std::pair.
        * bytecode/Opcode.h:
        (JSC::padOpcodeName): Moved.

2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>

        CodeBlock::jettison() should disallow repatching its own calls
        https://bugs.webkit.org/show_bug.cgi?id=196359
        <rdar://problem/48973663>

        Reviewed by Saam Barati.

        CodeBlock::jettison() calls CommonData::invalidate, which replaces the `hlt`
        instruction with the jump to OSR exit. However, if the `hlt` was immediately
        followed by a call to the CodeBlock being jettisoned, we would write over the
        OSR exit address while unlinking all the incoming CallLinkInfos later in
        CodeBlock::jettison().

        Change it so that we set a flag, `clearedByJettison`, in all the CallLinkInfos
        owned by the CodeBlock being jettisoned. If the flag is set, we will avoid
        repatching the call during unlinking. This is safe because this call will never
        be reachable again after the CodeBlock is jettisoned.

        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::setCallee):
        (JSC::CallLinkInfo::clearCallee):
        (JSC::CallLinkInfo::setCodeBlock):
        (JSC::CallLinkInfo::clearCodeBlock):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::clearedByJettison):
        (JSC::CallLinkInfo::setClearedByJettison):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):
        * jit/Repatch.cpp:
        (JSC::revertCall):

2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Drop VM and Context cache map in JavaScriptCore.framework
        https://bugs.webkit.org/show_bug.cgi?id=196341

        Reviewed by Saam Barati.

        Previously, we created Objective-C weak map to maintain JSVirtualMachine and JSContext wrappers corresponding to VM and JSGlobalObject.
        But Objective-C weak map is really memory costly. Even if the entry is only one, it consumes 2.5KB per weak map. Since we can modify
        JSC intrusively for JavaScriptCore.framework (and we already did it, like, holding JSWrapperMap in JSGlobalObject), we can just hold
        a pointer to a wrapper in VM and JSGlobalObject.

        This patch adds void* members to VM and JSGlobalObject, which holds a non-strong reference to a wrapper. When a wrapper is gone, we
        clear this pointer too. This removes unnecessary two Objective-C weak maps, and save 5KB.

        * API/JSContext.mm:
        (-[JSContext initWithVirtualMachine:]):
        (-[JSContext dealloc]):
        (-[JSContext initWithGlobalContextRef:]):
        (-[JSContext wrapperMap]):
        (+[JSContext contextWithJSGlobalContextRef:]):
        * API/JSVirtualMachine.mm:
        (-[JSVirtualMachine initWithContextGroupRef:]):
        (-[JSVirtualMachine dealloc]):
        (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
        (scanExternalObjectGraph):
        (scanExternalRememberedSet):
        (initWrapperCache): Deleted.
        (wrapperCache): Deleted.
        (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): Deleted.
        (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): Deleted.
        (-[JSVirtualMachine contextForGlobalContextRef:]): Deleted.
        (-[JSVirtualMachine addContext:forGlobalContextRef:]): Deleted.
        * API/JSVirtualMachineInternal.h:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::setAPIWrapper):
        (JSC::JSGlobalObject::apiWrapper const):
        * runtime/VM.h:

2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>

        In-memory code cache should not share bytecode across domains
        https://bugs.webkit.org/show_bug.cgi?id=196321

        Reviewed by Geoffrey Garen.

        Use the SourceProvider's URL to make sure that the hosts match for the
        two SourceCodeKeys in operator==.

        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::host const):
        (JSC::SourceCodeKey::operator== const):

2019-03-28  Víctor Manuel Jáquez Leal  <vjaquez@igalia.com>

        Silence lot of warnings when compiling with clang
        https://bugs.webkit.org/show_bug.cgi?id=196310

        Reviewed by Michael Catanzaro.

        Initialize variable with default constructor.

        * API/glib/JSCOptions.cpp:
        (jsc_options_foreach):

2019-03-27  Saam Barati  <sbarati@apple.com>

        validateOSREntryValue with Int52 should box the value being checked into double format
        https://bugs.webkit.org/show_bug.cgi?id=196313
        <rdar://problem/49306703>

        Reviewed by Yusuke Suzuki.

        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::validateAIState):

2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Owner of watchpoints should validate at GC finalizing phase
        https://bugs.webkit.org/show_bug.cgi?id=195827

        Reviewed by Filip Pizlo.

        This patch fixes JSC's watchpoint liveness issue by the following two policies.

        1. Watchpoint should have owner cell, and "fire" operation should be gaurded with owner cell's isLive check.

        Watchpoints should hold its owner cell, and fire procedure should be guarded by `owner->isLive()`.
        When the owner cell is destroyed, these watchpoints are destroyed too. But this destruction can
        be delayed due to incremental sweeper. So the following condition can happen.

        When we have a watchpoint like the following.

            class XXXWatchpoint {
                ObjectPropertyCondition m_key;
                JSCell* m_owner;
            };

        Both m_key's cell and m_owner is now unreachable from the root. So eventually, m_owner cell's destructor
        is called and this watchpoint will be destroyed. But before that, m_key's cell can be destroyed. And this
        watchpoint's fire procedure can be called since m_owner's destructor is not called yet. In this situation,
        we encounter the destroyed cell held in m_key. This problem can be avoided if we guard fire procedure with
        `m_owner->isLive()`. Until the owner cell is destroyed, this guard avoids "fire" procedure execution. And
        once the destructor of m_owner is called, this watchpoint will be destroyed too.

        2. Watchpoint liveness should be maintained by owner cell's unconditional finalizer

        Watchpoints often hold weak references to the other cell (like, m_key in the above example). If we do not
        delete watchpoints with dead cells when these weak cells become dead, these watchpoints continue holding dead cells,
        and watchpoint's fire operation can use these dead cells accidentally. isLive / isStillLive check for these weak cells
        in fire operation is not useful. Because these dead cells can be reused to the other live cells eventually, and this
        isLive / isStillLive checks fail to see these cells are live if they are reused. Appropriate way is deleting watchpoints
        with dead cells when finalizing GC. In this patch, we do this in unconditional finalizers in owner cells of watchpoints.
        We already did this in CodeBlock etc. We add the same thing to StructureRareData which owns watchpoints for toString operations.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint): Deleted.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint): Deleted.
        * bytecode/CodeBlockJettisoningWatchpoint.h:
        (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): Deleted.
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::key const): Deleted.
        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::fireInternal):
        (JSC::WatchpointsOnStructureStubInfo::isValid const):
        * bytecode/StructureStubClearingWatchpoint.h:
        (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): Deleted.
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::isValid const):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
        * dfg/DFGAdaptiveStructureWatchpoint.h:
        (JSC::DFG::AdaptiveStructureWatchpoint::key const): Deleted.
        * dfg/DFGDesiredWatchpoints.cpp:
        (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setupGetByIdPrototypeCache):
        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
        * runtime/ArrayBufferNeuteringWatchpointSet.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.cpp.
        (JSC::ArrayBufferNeuteringWatchpointSet::ArrayBufferNeuteringWatchpointSet):
        (JSC::ArrayBufferNeuteringWatchpointSet::destroy):
        (JSC::ArrayBufferNeuteringWatchpointSet::create):
        (JSC::ArrayBufferNeuteringWatchpointSet::createStructure):
        (JSC::ArrayBufferNeuteringWatchpointSet::fireAll):
        * runtime/ArrayBufferNeuteringWatchpointSet.h: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.h.
        * runtime/FunctionRareData.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
        * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h:
        (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): Deleted.
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::finalizeUnconditionally):
        * runtime/StructureRareData.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):

2019-03-26  Saam Barati  <sbarati@apple.com>

        FTL: Emit code to validate AI's state when running the compiled code
        https://bugs.webkit.org/show_bug.cgi?id=195924
        <rdar://problem/49003422>

        Reviewed by Filip Pizlo.

        This patch adds code that between the execution of each node that validates
        the types that AI proves. This option is too expensive to turn on for our
        regression testing, but we think it will be valuable in other types of running
        modes, such as when running with a fuzzer.
        
        This patch also adds options to only probabilistically run this validation
        after the execution of each node. As the probability is lowered, there is
        less of a perf hit.
        
        This patch just adds this validation in the FTL. A follow-up patch will land
        it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
        (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
        (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
        * runtime/Options.h:

2019-03-26  Tadeu Zagallo  <tzagallo@apple.com>

        WebAssembly: Fix f32.min, f64.min and f64.max operations on NaN
        https://bugs.webkit.org/show_bug.cgi?id=196217

        Reviewed by Saam Barati.

        Generalize the fix for f32.max to properly handle NaN by doing an extra GreatherThan
        comparison in r243446 to all min and max float operations.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
        (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
        * wasm/wasm.json:

2019-03-26  Andy VanWagoner  <andy@vanwagoner.family>

        Intl.DateTimeFormat should obey 2-digit hour
        https://bugs.webkit.org/show_bug.cgi?id=195974

        Reviewed by Keith Miller.

        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat):

2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>

        Heap::isMarked and friends should be instance methods
        https://bugs.webkit.org/show_bug.cgi?id=179988

        Reviewed by Saam Barati.

        Almost all the callers of Heap::isMarked have VM& reference. We should make Heap::isMarked instance function instead of static function
        so that we do not need to look up Heap from the cell.

        * API/JSAPIWrapperObject.mm:
        (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
        * API/JSMarkingConstraintPrivate.cpp:
        (JSC::isMarked):
        * API/glib/JSAPIWrapperObjectGLib.cpp:
        (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::finalizeUnconditionally):
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::visitWeak const):
        (JSC::AccessCase::propagateTransitions const):
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::visitWeak):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::finalize):
        * bytecode/CallLinkStatus.h:
        * bytecode/CallVariant.cpp:
        (JSC::CallVariant::finalize):
        * bytecode/CallVariant.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shouldJettisonDueToWeakReference):
        (JSC::CodeBlock::shouldJettisonDueToOldAge):
        (JSC::shouldMarkTransition):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::determineLiveness):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::jettison):
        * bytecode/CodeBlock.h:
        * bytecode/ExecutableToCodeBlockEdge.cpp:
        (JSC::ExecutableToCodeBlockEdge::visitChildren):
        (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
        (JSC::ExecutableToCodeBlockEdge::runConstraint):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::finalize):
        * bytecode/GetByIdStatus.h:
        * bytecode/GetByIdVariant.cpp:
        (JSC::GetByIdVariant::finalize):
        * bytecode/GetByIdVariant.h:
        * bytecode/InByIdStatus.cpp:
        (JSC::InByIdStatus::finalize):
        * bytecode/InByIdStatus.h:
        * bytecode/InByIdVariant.cpp:
        (JSC::InByIdVariant::finalize):
        * bytecode/InByIdVariant.h:
        * bytecode/ObjectPropertyCondition.cpp:
        (JSC::ObjectPropertyCondition::isStillLive const):
        * bytecode/ObjectPropertyCondition.h:
        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::ObjectPropertyConditionSet::areStillLive const):
        * bytecode/ObjectPropertyConditionSet.h:
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::visitWeak const):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillLive const):
        * bytecode/PropertyCondition.h:
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::finalize):
        * bytecode/PutByIdStatus.h:
        * bytecode/PutByIdVariant.cpp:
        (JSC::PutByIdVariant::finalize):
        * bytecode/PutByIdVariant.h:
        * bytecode/RecordedStatuses.cpp:
        (JSC::RecordedStatuses::finalizeWithoutDeleting):
        (JSC::RecordedStatuses::finalize):
        * bytecode/RecordedStatuses.h:
        * bytecode/StructureSet.cpp:
        (JSC::StructureSet::isStillAlive const):
        * bytecode/StructureSet.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::visitWeakReferences):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::finalizeInGC):
        (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
        * heap/GCIncomingRefCounted.h:
        * heap/GCIncomingRefCountedInlines.h:
        (JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
        * heap/GCIncomingRefCountedSet.h:
        * heap/GCIncomingRefCountedSetInlines.h:
        (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
        (JSC::GCIncomingRefCountedSet<T>::sweep):
        (JSC::GCIncomingRefCountedSet<T>::removeAll): Deleted.
        (JSC::GCIncomingRefCountedSet<T>::removeDead): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::runEndPhase):
        (JSC::Heap::sweepArrayBuffers):
        (JSC::Heap::addCoreConstraints):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::isMarked):
        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::appendNode):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendToMarkStack):
        (JSC::SlotVisitor::visitChildren):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallStubRoutine::visitWeak):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finalizeUnconditionally):
        * runtime/InferredValueInlines.h:
        (JSC::InferredValue::finalizeUnconditionally):
        * runtime/StackFrame.h:
        (JSC::StackFrame::isMarked const):
        * runtime/Structure.cpp:
        (JSC::Structure::isCheapDuringGC):
        (JSC::Structure::markIfCheap):
        * runtime/Structure.h:
        * runtime/TypeProfiler.cpp:
        (JSC::TypeProfiler::invalidateTypeSetCache):
        * runtime/TypeProfiler.h:
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::invalidateCache):
        * runtime/TypeSet.h:
        * runtime/WeakMapImpl.cpp:
        (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitOutputConstraints):
        * runtime/WeakMapImplInlines.h:
        (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):

2019-03-25  Keith Miller  <keith_miller@apple.com>

        ASSERTION FAILED: m_op == CompareStrictEq in JSC::DFG::Node::convertToCompareEqPtr(JSC::DFG::FrozenValue *, JSC::DFG::Edge)
        https://bugs.webkit.org/show_bug.cgi?id=196176

        Reviewed by Saam Barati.

        convertToCompareEqPtr should allow for either CompareStrictEq or
        the SameValue DFG node. This fixes the old assertion that only
        allowed CompareStrictEq.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToCompareEqPtr):

2019-03-25  Tadeu Zagallo  <tzagallo@apple.com>

        WebAssembly: f32.max with NaN generates incorrect result
        https://bugs.webkit.org/show_bug.cgi?id=175691
        <rdar://problem/33952228>

        Reviewed by Saam Barati.

        Fix the B3 and Air compilation for f32.max. In order to handle the NaN
        case, we need an extra GreaterThan comparison on top of the existing
        Equal and LessThan ones.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
        * wasm/wasm.json:

2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, speculative fix for CLoop build on CPU(UNKNOWN)
        https://bugs.webkit.org/show_bug.cgi?id=195982

        * jit/ExecutableAllocator.h:
        (JSC::ExecutableAllocator::initializeUnderlyingAllocator):

2019-03-25  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        Remove NavigatorContentUtils in WebCore/Modules
        https://bugs.webkit.org/show_bug.cgi?id=196070

        Reviewed by Alex Christensen.

        NavigatorContentUtils was to support the custom scheme spec [1].
        However, in WebKit side, no port has supported the feature in
        WebKit layer after EFL port was removed. So there has been the
        only IDL implementation of the NavigatorContentUtils in WebCore.
        So we don't need to keep the implementation in WebCore anymore.

        [1] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers

        * Configurations/FeatureDefines.xcconfig:

2019-03-23  Mark Lam  <mark.lam@apple.com>

        Rolling out r243032 and r243071 because the fix is incorrect.
        https://bugs.webkit.org/show_bug.cgi?id=195892
        <rdar://problem/48981239>

        Not reviewed.

        The fix is incorrect: it relies on being able to determine liveness of an object
        in an ObjectPropertyCondition based on the state of the object's MarkedBit.
        However, there's no guarantee that GC has run and that the MarkedBit is already
        set even if the object is live.  As a result, we may not re-install adaptive
        watchpoints based on presumed dead objects which are actually live.

        I'm rolling this out, and will implement a more comprehensive fix to handle
        watchpoint liveness later.

        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/ObjectPropertyCondition.cpp:
        (JSC::ObjectPropertyCondition::dumpInContext const):
        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::fireInternal):
        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
        * runtime/StructureRareData.cpp:
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):

2019-03-23  Keith Miller  <keith_miller@apple.com>

        Refactor clz/ctz and fix getLSBSet.
        https://bugs.webkit.org/show_bug.cgi?id=196162

        Reviewed by Saam Barati.

        Refactor references of clz32/64 and ctz32 to use clz and ctz,
        respectively.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGOperations.cpp:
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::digitDiv):
        (JSC::JSBigInt::absoluteDivWithBigIntDivisor):
        (JSC::JSBigInt::calculateMaximumCharactersRequired):
        (JSC::JSBigInt::toStringBasePowerOfTwo):
        (JSC::JSBigInt::compareToDouble):
        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncClz32):

2019-03-23  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink sizeof(RegExp)
        https://bugs.webkit.org/show_bug.cgi?id=196133

        Reviewed by Mark Lam.

        Some applications have many RegExp cells. But RegExp cells are very large (144B).
        This patch reduces the size from 144B to 48B by,

        1. Allocate Yarr::YarrCodeBlock in non-GC heap. We can avoid this allocation if JIT is disabled.
        2. m_captureGroupNames and m_namedGroupToParenIndex are moved to RareData. They are only used when RegExp has named capture groups.

        * runtime/RegExp.cpp:
        (JSC::RegExp::finishCreation):
        (JSC::RegExp::estimatedSize):
        (JSC::RegExp::compile):
        (JSC::RegExp::matchConcurrently):
        (JSC::RegExp::compileMatchOnly):
        (JSC::RegExp::deleteCode):
        (JSC::RegExp::printTraceData):
        * runtime/RegExp.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::hasCodeFor):
        (JSC::RegExp::matchInline):
        (JSC::RegExp::hasMatchOnlyCodeFor):

2019-03-22  Keith Rollin  <krollin@apple.com>

        Enable ThinLTO support in Production builds
        https://bugs.webkit.org/show_bug.cgi?id=190758
        <rdar://problem/45413233>

        Reviewed by Daniel Bates.

        Tweak JavaScriptCore's Base.xcconfig to be more in-line with other
        .xcconfig files with regards to LTO settings. However, don't actually
        enable LTO for JavaScriptCore. LTO is not enabled for JavaScriptCore
        due to <rdar://problem/24543547>.

        * Configurations/Base.xcconfig:

2019-03-22  Mark Lam  <mark.lam@apple.com>

        Placate exception check validation in genericTypedArrayViewProtoFuncLastIndexOf().
        https://bugs.webkit.org/show_bug.cgi?id=196154
        <rdar://problem/49145307>

        Reviewed by Filip Pizlo.

        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):

2019-03-22  Mark Lam  <mark.lam@apple.com>

        Placate exception check validation in constructJSWebAssemblyLinkError().
        https://bugs.webkit.org/show_bug.cgi?id=196152
        <rdar://problem/49145257>

        Reviewed by Michael Saboff.

        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyLinkError):

2019-03-22  Timothy Hatcher  <timothy@apple.com>

        Change macosx() to macos() in WK_API... and JSC_API... macros.
        https://bugs.webkit.org/show_bug.cgi?id=196106

        Reviewed by Brian Burg.

        * API/JSBasePrivate.h:
        * API/JSContext.h:
        * API/JSContextPrivate.h:
        * API/JSContextRef.h:
        * API/JSContextRefInternal.h:
        * API/JSContextRefPrivate.h:
        * API/JSManagedValue.h:
        * API/JSObjectRef.h:
        * API/JSObjectRefPrivate.h:
        * API/JSRemoteInspector.h:
        * API/JSScript.h:
        * API/JSTypedArray.h:
        * API/JSValue.h:
        * API/JSValuePrivate.h:
        * API/JSValueRef.h:
        * API/JSVirtualMachinePrivate.h:

2019-03-22  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, build fix for Windows
        https://bugs.webkit.org/show_bug.cgi?id=196122

        * runtime/FunctionExecutable.cpp:

2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink sizeof(FunctionExecutable) by 16bytes
        https://bugs.webkit.org/show_bug.cgi?id=196122

        Reviewed by Saam Barati.

        This patch reduces sizeof(FunctionExecutable) by 16 bytes.

        1. ScriptExecutable::m_numParametersForCall and ScriptExecutable::m_numParametersForConstruct are not used in a meaningful way. Removed them.
        2. ScriptExecutable::m_lastLine and ScriptExecutable::m_endColumn can be calculated from UnlinkedFunctionExecutable. So FunctionExecutable does not need to hold it.
           This patch adds GlobalExecutable, which are non-function ScriptExecutables, and move m_lastLine and m_endColumn to this class.
        3. FunctionExecutable still needs to have the feature overriding m_lastLine and m_endColumn. We move overridden data in FunctionExecutable::RareData.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::link):
        * runtime/EvalExecutable.cpp:
        (JSC::EvalExecutable::EvalExecutable):
        * runtime/EvalExecutable.h:
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::FunctionExecutable::ensureRareDataSlow):
        (JSC::FunctionExecutable::overrideInfo):
        * runtime/FunctionExecutable.h:
        * runtime/GlobalExecutable.cpp: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
        * runtime/GlobalExecutable.h: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
        (JSC::GlobalExecutable::lastLine const):
        (JSC::GlobalExecutable::endColumn const):
        (JSC::GlobalExecutable::recordParse):
        (JSC::GlobalExecutable::GlobalExecutable):
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        * runtime/ModuleProgramExecutable.h:
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::ProgramExecutable):
        * runtime/ProgramExecutable.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::clearCode):
        (JSC::ScriptExecutable::installCode):
        (JSC::ScriptExecutable::hasClearableCode const):
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::typeProfilingEndOffset const):
        (JSC::ScriptExecutable::recordParse):
        (JSC::ScriptExecutable::lastLine const):
        (JSC::ScriptExecutable::endColumn const):
        * runtime/ScriptExecutable.h:
        (JSC::ScriptExecutable::hasJITCodeForCall const):
        (JSC::ScriptExecutable::hasJITCodeForConstruct const):
        (JSC::ScriptExecutable::recordParse):
        (JSC::ScriptExecutable::lastLine const): Deleted.
        (JSC::ScriptExecutable::endColumn const): Deleted.
        * tools/FunctionOverrides.h:

2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink sizeof(RegExpObject)
        https://bugs.webkit.org/show_bug.cgi?id=196130

        Reviewed by Saam Barati.

        sizeof(RegExpObject) is 48B due to one bool flag. We should compress this flag into lower bit of RegExp* field so that we can make RegExpObject 32B.
        It saves memory footprint 1.3% in RAMification's regexp.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewRegexp):
        (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::RegExpObject):
        (JSC::RegExpObject::visitChildren):
        (JSC::RegExpObject::getOwnPropertySlot):
        (JSC::RegExpObject::defineOwnProperty):
        * runtime/RegExpObject.h:

2019-03-21  Tomas Popela  <tpopela@redhat.com>

        [JSC] Fix build after r243232 on unsupported 64bit architectures
        https://bugs.webkit.org/show_bug.cgi?id=196072

        Reviewed by Keith Miller.

        As Keith suggested we already expect 16 free bits at the top of any
        pointer for JSValue even for the unsupported 64 bit arches.

        * bytecode/CodeOrigin.h:

2019-03-21  Mark Lam  <mark.lam@apple.com>

        Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
        https://bugs.webkit.org/show_bug.cgi?id=196116
        <rdar://problem/48976951>

        Reviewed by Filip Pizlo.

        The DFG backend should not make assumptions about what optimizations the front end
        will or will not do.  The assertion asserts that the operand cannot be known to be
        a cell.  However, it is not guaranteed that the front end will fold away this case.
        Also, the DFG backend is perfectly capable of generating code to handle the case
        where the operand is a cell.

        The attached test case demonstrates a case where the operand can be a known cell.
        The test needs to be run with the concurrent JIT and GC, and is racy.  It used to
        trip up this assertion about once every 10 runs or so.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):

2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>

        JSC::createError should clear exception thrown by errorDescriptionForValue
        https://bugs.webkit.org/show_bug.cgi?id=196089

        Reviewed by Mark Lam.

        errorDescriptionForValue returns a nullString in case of failure, but it
        might also throw an OOM exception when resolving a rope string. We need
        to clear any potential exceptions thrown by errorDescriptionForValue
        before returning the OOM from JSC::createError.

        * runtime/ExceptionHelpers.cpp:
        (JSC::createError):

2019-03-21  Robin Morisset  <rmorisset@apple.com>

        B3::Opcode can fit in a single byte, shrinking B3Value by 8 bytes
        https://bugs.webkit.org/show_bug.cgi?id=196014

        Reviewed by Keith Miller.

        B3::Opcode has less than one hundred cases, so it can easily fit in one byte (from two currently)
        This shrinks B3::Kind from 4 bytes to 2 (by removing the byte of padding at the end).
        This in turns eliminate padding from B3::Value, shrinking it by 8 bytes (out of 80).

        * b3/B3Opcode.h:

2019-03-21  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, more clang 3.8 build fixes
        https://bugs.webkit.org/show_bug.cgi?id=195947
        <rdar://problem/49069219>

        In the spirit of making our code worse to please old compilers....

        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::create):
        (JSC::GetterSetterAccessCase::clone const):
        * bytecode/InstanceOfAccessCase.cpp:
        (JSC::InstanceOfAccessCase::clone const):
        * bytecode/IntrinsicGetterAccessCase.cpp:
        (JSC::IntrinsicGetterAccessCase::clone const):
        * bytecode/ModuleNamespaceAccessCase.cpp:
        (JSC::ModuleNamespaceAccessCase::clone const):
        * bytecode/ProxyableAccessCase.cpp:
        (JSC::ProxyableAccessCase::clone const):

2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Do not create JIT related data under non-JIT mode
        https://bugs.webkit.org/show_bug.cgi?id=195982

        Reviewed by Mark Lam.

        We avoid creations of JIT related data structures under non-JIT mode.
        This patch removes the following allocations.

        1. JITThunks
        2. FTLThunks
        3. FixedVMPoolExecutableAllocator
        4. noJITValueProfileSingleton since it is no longer used
        5. ARM disassembler should be initialized when it is used
        6. Wasm related data structures are accidentally allocated if VM::canUseJIT() == false &&
           Options::useWebAssembly() == true. Add Wasm::isSupported() function to check the both conditions.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::runEndPhase):
        * jit/ExecutableAllocator.cpp:
        (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
        (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
        (JSC::ExecutableAllocator::isValid const):
        (JSC::ExecutableAllocator::underMemoryPressure):
        (JSC::ExecutableAllocator::memoryPressureMultiplier):
        (JSC::ExecutableAllocator::allocate):
        (JSC::ExecutableAllocator::isValidExecutableMemory):
        (JSC::ExecutableAllocator::getLock const):
        (JSC::ExecutableAllocator::committedByteCount):
        (JSC::ExecutableAllocator::dumpProfile):
        (JSC::startOfFixedExecutableMemoryPoolImpl):
        (JSC::endOfFixedExecutableMemoryPoolImpl):
        (JSC::ExecutableAllocator::initialize):
        (JSC::ExecutableAllocator::initializeAllocator): Deleted.
        (JSC::ExecutableAllocator::ExecutableAllocator): Deleted.
        (JSC::ExecutableAllocator::~ExecutableAllocator): Deleted.
        * jit/ExecutableAllocator.h:
        (JSC::ExecutableAllocatorBase::isValid const):
        (JSC::ExecutableAllocatorBase::underMemoryPressure):
        (JSC::ExecutableAllocatorBase::memoryPressureMultiplier):
        (JSC::ExecutableAllocatorBase::dumpProfile):
        (JSC::ExecutableAllocatorBase::allocate):
        (JSC::ExecutableAllocatorBase::setJITEnabled):
        (JSC::ExecutableAllocatorBase::isValidExecutableMemory):
        (JSC::ExecutableAllocatorBase::committedByteCount):
        (JSC::ExecutableAllocatorBase::getLock const):
        (JSC::ExecutableAllocator::isValid const): Deleted.
        (JSC::ExecutableAllocator::underMemoryPressure): Deleted.
        (JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted.
        (JSC::ExecutableAllocator::allocate): Deleted.
        (JSC::ExecutableAllocator::setJITEnabled): Deleted.
        (JSC::ExecutableAllocator::isValidExecutableMemory): Deleted.
        (JSC::ExecutableAllocator::committedByteCount): Deleted.
        (JSC::ExecutableAllocator::getLock const): Deleted.
        * jsc.cpp:
        (functionWebAssemblyMemoryMode):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/VM.cpp:
        (JSC::enableAssembler):
        (JSC::VM::canUseAssembler):
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/WasmCapabilities.h: Added.
        (JSC::Wasm::isSupported):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::enableFastMemory):

2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Fix JSC build with newer ICU
        https://bugs.webkit.org/show_bug.cgi?id=196098

        Reviewed by Keith Miller.

        IntlDateTimeFormat and IntlNumberFormat have switch statement over ICU's enums. However it lacks "default" clause so that
        the compile error occurs when a new enum value is added in ICU side. We should have "default" clause which just fallbacks
        "unknown"_s case. The behavior is not changed since we already have `return "unknown"_s;` statement anyway after the
        switch statement. This patch just suppresses a compile error.

        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::partTypeString):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::partTypeString):

2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>

        JSObject::putDirectIndexSlowOrBeyondVectorLength should check if indexIsSufficientlyBeyondLengthForSparseMap
        https://bugs.webkit.org/show_bug.cgi?id=196078
        <rdar://problem/35925380>

        Reviewed by Mark Lam.

        Unlike the other variations of putByIndex, it only checked if the index
        was larger than MIN_SPARSE_ARRAY_INDEX when the indexingType was
        ALL_BLANK_INDEXING_TYPES. This resulted in a huge butterfly being
        allocated for object literals (e.g. `{[9e4]: ...}`) and objects parsed
        from JSON.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):

2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>

        CachedUnlinkedSourceCodeShape::m_provider should be a CachedRefPtr
        https://bugs.webkit.org/show_bug.cgi?id=196079

        Reviewed by Saam Barati.

        It was mistakenly cached as CachedPtr, which was leaking the decoded SourceProvider.

        * runtime/CachedTypes.cpp:
        (JSC::CachedUnlinkedSourceCodeShape::encode):

2019-03-21  Mark Lam  <mark.lam@apple.com>

        Placate exception check validation in operationArrayIndexOfString().
        https://bugs.webkit.org/show_bug.cgi?id=196067
        <rdar://problem/49056572>

        Reviewed by Michael Saboff.

        * dfg/DFGOperations.cpp:

2019-03-21  Xan Lopez  <xan@igalia.com>

        [JSC][x86] Drop support for x87 floating point
        https://bugs.webkit.org/show_bug.cgi?id=194853

        Reviewed by Don Olmstead.

        Require SSE2 throughout the codebase, and remove x87 support where
        it was optionally available. SSE2 detection happens at compile
        time through a static_assert.

        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::storeDouble):
        (JSC::MacroAssemblerX86::moveDoubleToInts):
        (JSC::MacroAssemblerX86::supportsFloatingPoint):
        (JSC::MacroAssemblerX86::supportsFloatingPointTruncate):
        (JSC::MacroAssemblerX86::supportsFloatingPointSqrt):
        (JSC::MacroAssemblerX86::supportsFloatingPointAbs):
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::moveDouble):
        (JSC::MacroAssemblerX86Common::loadDouble):
        (JSC::MacroAssemblerX86Common::loadFloat):
        (JSC::MacroAssemblerX86Common::storeDouble):
        (JSC::MacroAssemblerX86Common::storeFloat):
        (JSC::MacroAssemblerX86Common::convertDoubleToFloat):
        (JSC::MacroAssemblerX86Common::convertFloatToDouble):
        (JSC::MacroAssemblerX86Common::addDouble):
        (JSC::MacroAssemblerX86Common::addFloat):
        (JSC::MacroAssemblerX86Common::divDouble):
        (JSC::MacroAssemblerX86Common::divFloat):
        (JSC::MacroAssemblerX86Common::subDouble):
        (JSC::MacroAssemblerX86Common::subFloat):
        (JSC::MacroAssemblerX86Common::mulDouble):
        (JSC::MacroAssemblerX86Common::mulFloat):
        (JSC::MacroAssemblerX86Common::convertInt32ToDouble):
        (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
        (JSC::MacroAssemblerX86Common::branchDouble):
        (JSC::MacroAssemblerX86Common::branchFloat):
        (JSC::MacroAssemblerX86Common::compareDouble):
        (JSC::MacroAssemblerX86Common::compareFloat):
        (JSC::MacroAssemblerX86Common::branchTruncateDoubleToInt32):
        (JSC::MacroAssemblerX86Common::truncateDoubleToInt32):
        (JSC::MacroAssemblerX86Common::truncateFloatToInt32):
        (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
        (JSC::MacroAssemblerX86Common::branchDoubleNonZero):
        (JSC::MacroAssemblerX86Common::branchDoubleZeroOrNaN):
        (JSC::MacroAssemblerX86Common::lshiftPacked):
        (JSC::MacroAssemblerX86Common::rshiftPacked):
        (JSC::MacroAssemblerX86Common::orPacked):
        (JSC::MacroAssemblerX86Common::move32ToFloat):
        (JSC::MacroAssemblerX86Common::moveFloatTo32):
        (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
        (JSC::MacroAssemblerX86Common::moveConditionallyFloat):
        * offlineasm/x86.rb:
        * runtime/MathCommon.cpp:
        (JSC::operationMathPow):

2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLIB] User data not correctly passed to callback of functions and constructors with no parameters
        https://bugs.webkit.org/show_bug.cgi?id=196073

        Reviewed by Michael Catanzaro.

        This is because GClosure always expects a first parameter as instance. In case of functions or constructors with
        no parameters we insert a fake instance which is just a null pointer that is ignored by the callback. But
        if the function/constructor has user data the callback will expect one parameter for the user data. In that case
        we can simply swap instance/user data so that the fake instance will be the second argument and user data the
        first one.

        * API/glib/JSCClass.cpp:
        (jscClassCreateConstructor): Use g_cclosure_new_swap() if parameters is empty and user data was provided.
        * API/glib/JSCValue.cpp:
        (jscValueFunctionCreate): Ditto.

2019-03-21  Pablo Saavedra  <psaavedra@igalia.com>

        [JSC][32-bit] Build failure after r243232
        https://bugs.webkit.org/show_bug.cgi?id=196068

        Reviewed by Mark Lam.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):

2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLib] Returning G_TYPE_OBJECT from a method does not work
        https://bugs.webkit.org/show_bug.cgi?id=195574

        Reviewed by Michael Catanzaro.

        Add more documentation to clarify the ownership of wrapped objects when created and when returned by functions.

        * API/glib/JSCCallbackFunction.cpp:
        (JSC::JSCCallbackFunction::construct): Also allow to return boxed types from a constructor.
        * API/glib/JSCClass.cpp:
        * API/glib/JSCValue.cpp:

2019-03-21  Mark Lam  <mark.lam@apple.com>

        Cap length of an array with spread to MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH.
        https://bugs.webkit.org/show_bug.cgi?id=196055
        <rdar://problem/49067448>

        Reviewed by Yusuke Suzuki.

        We are doing this because:
        1. We expect the array to be densely packed.
        2. SpeculativeJIT::compileAllocateNewArrayWithSize() (and the FTL equivalent)
           expects the array length to be less than MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH
           if we don't want to use an ArrayStorage shape.
        3. There's no reason why an array with spread needs to be that large anyway.
           MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH is plenty.

        In this patch, we also add a debug assert in compileAllocateNewArrayWithSize() and
        emitAllocateButterfly() to check for overflows.

        * assembler/AbortReason.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCreateRest):
        (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
        (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
        (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
        * runtime/ArrayConventions.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2019-03-20  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Use finalizer in JSGlobalLexicalEnvironment and JSGlobalObject
        https://bugs.webkit.org/show_bug.cgi?id=195992

        Reviewed by Keith Miller and Mark Lam.

        JSGlobalLexicalEnvironment and JSGlobalObject have their own CompleteSubspace to call destructors while they are not inheriting JSDestructibleObject.
        But it is too costly since (1) it requires CompleteSubspace in VM, (2) both objects allocate MarkedBlocks while # of them are really small.

        Instead of using CompleteSubspace, we just set finalizers for them. Since these objects are rarely allocated, setting finalizers does not show
        memory / performance problems (actually, previously we used finalizer for ArrayPrototype due to the same reason, and it does not show any problems).

        And we also add following two changes to JSSegmentedVariableObject.

        1. Remove one boolean used for debugging in Release build. It enlarges sizeof(JSSegmentedVariableObject) and allocates one more MarkedBlock.
        2. Use cellLock() instead.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::findVariableIndex):
        (JSC::JSSegmentedVariableObject::addVariables):
        (JSC::JSSegmentedVariableObject::visitChildren):
        (JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
        (JSC::JSSegmentedVariableObject::finishCreation):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::subspaceFor): Deleted.
        * runtime/JSSegmentedVariableObjectHeapCellType.cpp: Removed.
        * runtime/JSSegmentedVariableObjectHeapCellType.h: Removed.
        * runtime/StringIteratorPrototype.cpp:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-03-20  Saam Barati  <sbarati@apple.com>

        DFG::AbstractValue::validateOSREntry is wrong when isHeapTop and the incoming value is Empty
        https://bugs.webkit.org/show_bug.cgi?id=195721

        Reviewed by Filip Pizlo.

        There was a check in AbstractValue::validateOSREntry where it checked
        if isHeapTop(), and if so, just returned true. However, this is wrong
        if the value we're checking against is the empty value, since HeapTop
        does not include the Empty value. Instead, this check should be
        isBytecodeTop(), which does account for the empty value.
        
        This patch also does a couple of other things:
        - For our OSR entry AbstractValues, we were using HeapTop to mark
         a dead value. That is now changed to BytecodeTop. (The idea here
         is just to have validateOSREntry return early.)
        - It wasn't obvious to me how I could make this fail in JS code.
         The symptom we'd end up seeing is something like a nullptr derefernece
         from forgetting to do a TDZ check. Instead, I've added a unit test.
         This unit test lives in a new test file: testdfg. testdfg is similar
         to testb3/testair/testapi.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/SpeculatedType.h:
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::isBytecodeTop const):
        (JSC::DFG::AbstractValue::validateOSREntryValue const):
        * dfg/testdfg.cpp: Added.
        (hiddenTruthBecauseNoReturnIsStupid):
        (usage):
        (JSC::DFG::testEmptyValueDoesNotValidateWithHeapTop):
        (JSC::DFG::run):
        (run):
        (main):
        * shell/CMakeLists.txt:

2019-03-20  Saam Barati  <sbarati@apple.com>

        typeOfDoubleSum is wrong for when NaN can be produced
        https://bugs.webkit.org/show_bug.cgi?id=196030

        Reviewed by Filip Pizlo.

        We were using typeOfDoubleSum(SpeculatedType, SpeculatedType) for add/sub/mul.
        It assumed that the only way the resulting type could be NaN is if one of
        the inputs were NaN. However, this is wrong. NaN can be produced in at least
        these cases:
          Infinity - Infinity
          Infinity + (-Infinity)
          Infinity * 0

        * bytecode/SpeculatedType.cpp:
        (JSC::typeOfDoubleSumOrDifferenceOrProduct):
        (JSC::typeOfDoubleSum):
        (JSC::typeOfDoubleDifference):
        (JSC::typeOfDoubleProduct):

2019-03-20  Simon Fraser  <simon.fraser@apple.com>

        Rename ENABLE_ACCELERATED_OVERFLOW_SCROLLING macro to ENABLE_OVERFLOW_SCROLLING_TOUCH
        https://bugs.webkit.org/show_bug.cgi?id=196049

        Reviewed by Tim Horton.

        This macro is about the -webkit-overflow-scrolling CSS property, not accelerated
        overflow scrolling in general, so rename it.

        * Configurations/FeatureDefines.xcconfig:

2019-03-20  Saam Barati  <sbarati@apple.com>

        GetCallee does not report the correct type in AI
        https://bugs.webkit.org/show_bug.cgi?id=195981

        Reviewed by Yusuke Suzuki.

        I found this as part of my work in:
        https://bugs.webkit.org/show_bug.cgi?id=195924
        
        I'm not sure how to write a test for it.
        
        GetCallee was always reporting that the result is SpecFunction. However,
        for eval, it may result in just a JSCallee object, which is not a JSFunction.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2019-03-20  Mark Lam  <mark.lam@apple.com>

        Open source arm64e code.
        https://bugs.webkit.org/show_bug.cgi?id=196012
        <rdar://problem/49066237>

        Reviewed by Keith Miller.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/ARM64EAssembler.h: Added.
        (JSC::ARM64EAssembler::encodeGroup1):
        (JSC::ARM64EAssembler::encodeGroup2):
        (JSC::ARM64EAssembler::encodeGroup4):
        (JSC::ARM64EAssembler::pacia1716):
        (JSC::ARM64EAssembler::pacib1716):
        (JSC::ARM64EAssembler::autia1716):
        (JSC::ARM64EAssembler::autib1716):
        (JSC::ARM64EAssembler::paciaz):
        (JSC::ARM64EAssembler::paciasp):
        (JSC::ARM64EAssembler::pacibz):
        (JSC::ARM64EAssembler::pacibsp):
        (JSC::ARM64EAssembler::autiaz):
        (JSC::ARM64EAssembler::autiasp):
        (JSC::ARM64EAssembler::autibz):
        (JSC::ARM64EAssembler::autibsp):
        (JSC::ARM64EAssembler::xpaclri):
        (JSC::ARM64EAssembler::pacia):
        (JSC::ARM64EAssembler::pacib):
        (JSC::ARM64EAssembler::pacda):
        (JSC::ARM64EAssembler::pacdb):
        (JSC::ARM64EAssembler::autia):
        (JSC::ARM64EAssembler::autib):
        (JSC::ARM64EAssembler::autda):
        (JSC::ARM64EAssembler::autdb):
        (JSC::ARM64EAssembler::paciza):
        (JSC::ARM64EAssembler::pacizb):
        (JSC::ARM64EAssembler::pacdza):
        (JSC::ARM64EAssembler::pacdzb):
        (JSC::ARM64EAssembler::autiza):
        (JSC::ARM64EAssembler::autizb):
        (JSC::ARM64EAssembler::autdza):
        (JSC::ARM64EAssembler::autdzb):
        (JSC::ARM64EAssembler::xpaci):
        (JSC::ARM64EAssembler::xpacd):
        (JSC::ARM64EAssembler::pacga):
        (JSC::ARM64EAssembler::braa):
        (JSC::ARM64EAssembler::brab):
        (JSC::ARM64EAssembler::blraa):
        (JSC::ARM64EAssembler::blrab):
        (JSC::ARM64EAssembler::braaz):
        (JSC::ARM64EAssembler::brabz):
        (JSC::ARM64EAssembler::blraaz):
        (JSC::ARM64EAssembler::blrabz):
        (JSC::ARM64EAssembler::retaa):
        (JSC::ARM64EAssembler::retab):
        (JSC::ARM64EAssembler::eretaa):
        (JSC::ARM64EAssembler::eretab):
        (JSC::ARM64EAssembler::linkPointer):
        (JSC::ARM64EAssembler::repatchPointer):
        (JSC::ARM64EAssembler::setPointer):
        (JSC::ARM64EAssembler::readPointer):
        (JSC::ARM64EAssembler::readCallTarget):
        (JSC::ARM64EAssembler::ret):
        * assembler/MacroAssembler.cpp:
        * assembler/MacroAssembler.h:
        * assembler/MacroAssemblerARM64.cpp:
        * assembler/MacroAssemblerARM64E.h: Added.
        (JSC::MacroAssemblerARM64E::tagReturnAddress):
        (JSC::MacroAssemblerARM64E::untagReturnAddress):
        (JSC::MacroAssemblerARM64E::tagPtr):
        (JSC::MacroAssemblerARM64E::untagPtr):
        (JSC::MacroAssemblerARM64E::removePtrTag):
        (JSC::MacroAssemblerARM64E::callTrustedPtr):
        (JSC::MacroAssemblerARM64E::call):
        (JSC::MacroAssemblerARM64E::callRegister):
        (JSC::MacroAssemblerARM64E::jump):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * ftl/FTLThunks.cpp:
        (JSC::FTL::genericGenerationThunkGenerator):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::prepareForTailCall):
        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::allocate):
        * jit/ThunkGenerators.cpp:
        (JSC::arityFixupGenerator):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ClassInfo.h:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSCPtrTag.cpp: Added.
        (JSC::tagForPtr):
        (JSC::ptrTagName):
        (JSC::initializePtrTagLookup):
        * runtime/JSCPtrTag.h:
        (JSC::initializePtrTagLookup):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2019-03-20  Tadeu Zagallo  <tzagallo@apple.com>

        JSC::createError needs to check for OOM in errorDescriptionForValue
        https://bugs.webkit.org/show_bug.cgi?id=196032
        <rdar://problem/46842740>

        Reviewed by Mark Lam.

        We were missing exceptions checks at two levels:
        - In errorDescriptionForValue, when the value is a string, we should
          check that JSString::value returns a valid string, since we might run
          out of memory if it is a rope and we need to resolve it.
        - In createError, we should check for the result of errorDescriptionForValue
          before concatenating it with the message provided by the caller.

        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue):
        (JSC::createError):
        * runtime/ExceptionHelpers.h:

2019-03-20  Devin Rousso  <drousso@apple.com>

        Web Inspector: DOM: include window as part of any event listener chain
        https://bugs.webkit.org/show_bug.cgi?id=195730
        <rdar://problem/48916872>

        Reviewed by Timothy Hatcher.

        * inspector/protocol/DOM.json:
        Modify `DOM.getEventListenersForNode` to not save the handler object, as that was never
        used by the frontend. Add an `onWindow` optional property to `DOM.EventListener` that is set
        when the event listener was retrieved from the `window` object.

2019-03-20  Devin Rousso  <drousso@apple.com>

        Web Inspector: Runtime: lazily create the agent
        https://bugs.webkit.org/show_bug.cgi?id=195972
        <rdar://problem/49039655>

        Reviewed by Timothy Hatcher.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):

        * inspector/agents/InspectorRuntimeAgent.h:
        (Inspector::InspectorRuntimeAgent::enabled): Deleted.
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::didCreateFrontendAndBackend): Added.
        (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):

        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
        (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): Deleted.

2019-03-20  Michael Saboff  <msaboff@apple.com>

        JSC test crash: stress/dont-strength-reduce-regexp-with-compile-error.js.default
        https://bugs.webkit.org/show_bug.cgi?id=195906

        Reviewed by Mark Lam.

        The problem here as that we may successfully parsed a RegExp without running out of stack,
        but later run out of stack when trying to JIT compile the same expression.

        Added a check for available stack space when we call into one of the parenthesis compilation
        functions that recurse.  When we don't have enough stack space to recurse, we fail the JIT
        compilation and let the interpreter handle the expression.

        From code inspection of the YARR interpreter it has the same issue, but I couldn't cause a failure.
        Filed a new bug and added a FIXME comment for the Interpreter to have similar checks.
        Given that we can reproduce a failure, this is sufficient for now.

        This change is covered by the previously added failing test,
        JSTests/stress/dont-strength-reduce-regexp-with-compile-error.js.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::interpret):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
        (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
        (JSC::Yarr::YarrGenerator::opCompileBody):
        (JSC::Yarr::dumpCompileFailure):
        * yarr/YarrJIT.h:

2019-03-20  Robin Morisset  <rmorisset@apple.com>

        DFGNodeAllocator.h is dead code
        https://bugs.webkit.org/show_bug.cgi?id=196019

        Reviewed by Yusuke Suzuki.

        As explained by Yusuke on IRC, the comment on DFG::Node saying that it cannot have a destructor is obsolete since https://trac.webkit.org/changeset/216815/webkit.
        This patch removes both the comment and DFGNodeAllocator.h that that patch forgot to remove.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::dumpChildren):
        * dfg/DFGNodeAllocator.h: Removed.

2019-03-20  Robin Morisset  <rmorisset@apple.com>

        Compress CodeOrigin into a single word in the common case
        https://bugs.webkit.org/show_bug.cgi?id=195928

        Reviewed by Saam Barati.

        The trick is that pointers only take 48 bits on x86_64 in practice (and we can even use the bottom three bits of that thanks to alignment), and even less on ARM64.
        So we can shove the bytecode index in the top bits almost all the time.
        If the bytecodeIndex is too ginormous (1<<16 in practice on x86_64), we just set one bit at the bottom and store a pointer to some out-of-line storage instead.
        Finally we represent an invalid bytecodeIndex (which used to be represented by UINT_MAX) by setting the second least signifcant bit.

        The patch looks very long, but most of it is just replacing direct accesses to inlineCallFrame and bytecodeIndex by the relevant getters.

        End result: CodeOrigin in the common case moves from 16 bytes (8 for InlineCallFrame*, 4 for unsigned bytecodeIndex, 4 of padding) to 8.
        As a reference, during running JetStream2 we allocate more than 35M CodeOrigins. While they won't all be alive at the same time, it is still quite a lot of objects, so I am hoping for some small
        improvement to RAMification from this work.

        The one slightly tricky part is that we must implement copy and move assignment operators and constructors to make sure that any out-of-line storage belongs to a single CodeOrigin and is destroyed exactly once.

        * bytecode/ByValInfo.h:
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::globalObjectFor):
        (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
        (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
        * bytecode/CodeOrigin.cpp:
        (JSC::CodeOrigin::inlineDepth const):
        (JSC::CodeOrigin::isApproximatelyEqualTo const):
        (JSC::CodeOrigin::approximateHash const):
        (JSC::CodeOrigin::inlineStack const):
        (JSC::CodeOrigin::codeOriginOwner const):
        (JSC::CodeOrigin::stackOffset const):
        (JSC::CodeOrigin::dump const):
        (JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
        * bytecode/CodeOrigin.h:
        (JSC::OutOfLineCodeOrigin::OutOfLineCodeOrigin):
        (JSC::CodeOrigin::CodeOrigin):
        (JSC::CodeOrigin::~CodeOrigin):
        (JSC::CodeOrigin::isSet const):
        (JSC::CodeOrigin::isHashTableDeletedValue const):
        (JSC::CodeOrigin::bytecodeIndex const):
        (JSC::CodeOrigin::inlineCallFrame const):
        (JSC::CodeOrigin::buildCompositeValue):
        (JSC::CodeOrigin::hash const):
        (JSC::CodeOrigin::operator== const):
        (JSC::CodeOrigin::exitingInlineKind const): Deleted.
        * bytecode/DeferredSourceDump.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfo):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/ICStatusMap.cpp:
        (JSC::ICStatusContext::isInlined const):
        * bytecode/InByIdStatus.cpp:
        (JSC::InByIdStatus::computeFor):
        (JSC::InByIdStatus::computeForStubInfo):
        * bytecode/InlineCallFrame.cpp:
        (JSC::InlineCallFrame::dumpInContext const):
        * bytecode/InlineCallFrame.h:
        (JSC::InlineCallFrame::computeCallerSkippingTailCalls):
        (JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
        (JSC::CodeOrigin::walkUpInlineStack):
        * bytecode/InstanceOfStatus.h:
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        (JSC::PutByIdStatus::computeFor):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGArgumentsUtilities.cpp:
        (JSC::DFG::argumentsInvolveStackSlot):
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGArrayMode.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::flushForTerminalImpl):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        (JSC::DFG::ByteCodeParser::handlePutByVal):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dumpCodeOrigin):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::isLiveInBytecode):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::executableFor):
        (JSC::DFG::Graph::isStrictModeFor):
        (JSC::DFG::Graph::hasExitSite):
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
        * dfg/DFGMinifiedNode.cpp:
        (JSC::DFG::MinifiedNode::fromNode):
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        (JSC::DFG::printOSRExit):
        (JSC::DFG::OSRExit::compileExit):
        * dfg/DFGOSRExitBase.cpp:
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGOperations.cpp:
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitGetLength):
        (JSC::DFG::SpeculativeJIT::emitGetCallee):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileValueSub):
        (JSC::DFG::SpeculativeJIT::compileValueNegate):
        (JSC::DFG::SpeculativeJIT::compileValueMul):
        (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
        (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct const):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
        (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
        (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
        (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
        (JSC::FTL::DFG::LowerDFGToB3::codeOriginDescriptionOfCallSite const):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::bytecodeOffset):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
        (JSC::StackVisitor::readFrame):
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::inlinedFrameOffset):
        (JSC::StackVisitor::readInlinedFrame):
        * interpreter/StackVisitor.h:
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::executableFor):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::isStrictModeFor):
        (JSC::AssemblyHelpers::argumentsStart):
        (JSC::AssemblyHelpers::argumentCount):
        * jit/PCToCodeOriginMap.cpp:
        (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
        (JSC::PCToCodeOriginMap::findPC const):
        * profiler/ProfilerOriginStack.cpp:
        (JSC::Profiler::OriginStack::OriginStack):
        * profiler/ProfilerOriginStack.h:
        * runtime/ErrorInstance.cpp:
        (JSC::appendSourceToError):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):

2019-03-20  Devin Rousso  <drousso@apple.com>

        Web Inspector: Search: allow DOM searches to be case sensitive
        https://bugs.webkit.org/show_bug.cgi?id=194673
        <rdar://problem/48087577>

        Reviewed by Timothy Hatcher.

        Since `DOM.performSearch` also searches by selector and XPath, some results may appear
        as unexpected. As an example, searching for "BoDy" will still return the <body> as a result,
        as although the literal node name ("BODY") didn't match, it did match via selector/XPath.

        * inspector/protocol/DOM.json:
        Allow `DOM.performSearch` to be case sensitive.

2019-03-20  Saam Barati  <sbarati@apple.com>

        AI rule for ValueBitNot/ValueBitXor/ValueBitAnd/ValueBitOr is wrong
        https://bugs.webkit.org/show_bug.cgi?id=195980

        Reviewed by Yusuke Suzuki.

        They were all saying they could be type: (SpecBoolInt32, SpecBigInt)
        However, they should have been type: (SpecInt32Only, SpecBigInt)

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2019-03-20  Michael Catanzaro  <mcatanzaro@igalia.com>

        Remove copyRef() calls added in r243163
        https://bugs.webkit.org/show_bug.cgi?id=195962

        Reviewed by Chris Dumez.

        As best I can tell, may be a GCC 9 bug. It shouldn't warn about this case because the return
        value is noncopyable and the WTFMove() is absolutely required. We can avoid the warning
        without refcount churn by introducing an intermediate variable.

        * inspector/scripts/codegen/cpp_generator_templates.py:

2019-03-20  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLIB] Optimize jsc_value_object_define_property_data|accessor
        https://bugs.webkit.org/show_bug.cgi?id=195679

        Reviewed by Saam Barati.

        Use direct C++ call instead of using the JSC GLib API to create the descriptor object and invoke Object.defineProperty().

        * API/glib/JSCValue.cpp:
        (jsc_value_object_define_property_data):
        (jsc_value_object_define_property_accessor):

2019-03-19  Devin Rousso  <drousso@apple.com>

        Web Inspector: Debugger: lazily create the agent
        https://bugs.webkit.org/show_bug.cgi?id=195973
        <rdar://problem/49039674>

        Reviewed by Joseph Pecoraro.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):

        * inspector/JSGlobalObjectConsoleClient.h:
        (Inspector::JSGlobalObjectConsoleClient::setInspectorDebuggerAgent): Added.
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):

        * inspector/agents/InspectorDebuggerAgent.h:
        (Inspector::InspectorDebuggerAgent::addListener): Added.
        (Inspector::InspectorDebuggerAgent::removeListener): Added.
        (Inspector::InspectorDebuggerAgent::setListener): Deleted.
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
        (Inspector::InspectorDebuggerAgent::enable):
        (Inspector::InspectorDebuggerAgent::disable):
        (Inspector::InspectorDebuggerAgent::getScriptSource):
        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::didPause):
        (Inspector::InspectorDebuggerAgent::breakProgram):
        (Inspector::InspectorDebuggerAgent::clearBreakDetails):
        Drive-by: reorder some member variables for better sizing.
        Drive-by: rename some member variables for clarity.

2019-03-19  Saam barati  <sbarati@apple.com>

        Prune code after ForceOSRExit
        https://bugs.webkit.org/show_bug.cgi?id=195913

        Reviewed by Keith Miller.

        I removed our original implementation of this in r242989 because
        it was not sound. It broke backwards propagation because it removed
        uses of a node that backwards propagation relied on to be sound.
        Essentially, backwards propagation relies on being able to see uses
        that would exist in bytecode to be sound.
        
        The rollout in r242989 was a 1% Speedometer2 regression. This patch
        rolls back in the optimization in a sound way.
        
        This patch augments the code we had prior to r242989 to be sound. In
        addition to preserving liveness, we now also convert all uses after
        the ForceOSRExit to be Phantom. This may pessimize the optimizations
        we do in backwards propagation, but it will prevent that phase from
        making unsound optimizations.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        (JSC::DFG::ByteCodeParser::parse):

2019-03-19  Michael Catanzaro  <mcatanzaro@igalia.com>

        Build cleanly with GCC 9
        https://bugs.webkit.org/show_bug.cgi?id=195920

        Reviewed by Chris Dumez.

        WebKit triggers three new GCC 9 warnings:

        """
        -Wdeprecated-copy, implied by -Wextra, warns about the C++11 deprecation of implicitly
        declared copy constructor and assignment operator if one of them is user-provided.
        """

        Solution is to either add a copy constructor or copy assignment operator, if required, or
        else remove one if it is redundant.

        """
        -Wredundant-move, implied by -Wextra, warns about redundant calls to std::move.
        -Wpessimizing-move, implied by -Wall, warns when a call to std::move prevents copy elision.
        """

        These account for most of this patch. Solution is to just remove the bad WTFMove().

        Additionally, -Wclass-memaccess has been enhanced to catch a few cases that GCC 8 didn't.
        These are solved by casting nontrivial types to void* before using memcpy. (Of course, it
        would be safer to not use memcpy on nontrivial types, but that's too complex for this
        patch. Searching for memcpy used with static_cast<void*> will reveal other cases to fix.)

        * b3/B3ValueRep.h:
        * bindings/ScriptValue.cpp:
        (Inspector::jsToInspectorValue):
        * bytecode/GetterSetterAccessCase.cpp:
        (JSC::GetterSetterAccessCase::create):
        (JSC::GetterSetterAccessCase::clone const):
        * bytecode/InstanceOfAccessCase.cpp:
        (JSC::InstanceOfAccessCase::clone const):
        * bytecode/IntrinsicGetterAccessCase.cpp:
        (JSC::IntrinsicGetterAccessCase::clone const):
        * bytecode/ModuleNamespaceAccessCase.cpp:
        (JSC::ModuleNamespaceAccessCase::clone const):
        * bytecode/ProxyableAccessCase.cpp:
        (JSC::ProxyableAccessCase::clone const):
        * bytecode/StructureSet.h:
        * debugger/Breakpoint.h:
        * dfg/DFGRegisteredStructureSet.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::buildDebuggerLocation):
        * inspector/scripts/codegen/cpp_generator_templates.py:
        * parser/UnlinkedSourceCode.h:
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::parseAndCompileAir):
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::parseAndCompile):
        * wasm/WasmNameSectionParser.cpp:
        (JSC::Wasm::NameSectionParser::parse):
        * wasm/WasmStreamingParser.cpp:
        (JSC::Wasm::StreamingParser::consume):

2019-03-19  Saam Barati  <sbarati@apple.com>

        Style fix: remove C style cast in Instruction.h
        https://bugs.webkit.org/show_bug.cgi?id=195917

        Reviewed by Filip Pizlo.

        * bytecode/Instruction.h:
        (JSC::Instruction::wide const):

2019-03-19  Devin Rousso  <drousso@apple.com>

        Web Inspector: Provide $event in the console when paused on an event listener
        https://bugs.webkit.org/show_bug.cgi?id=188672

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScript.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::setEventValue): Added.
        (Inspector::InjectedScript::clearEventValue): Added.

        * inspector/InjectedScriptManager.h:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::clearEventValue): Added.

        * inspector/InjectedScriptSource.js:
        (WI.InjectedScript.prototype.setEventValue): Added.
        (WI.InjectedScript.prototype.clearEventValue): Added.
        (BasicCommandLineAPI):

2019-03-19  Devin Rousso  <drousso@apple.com>

        Web Inspector: ScriptProfiler: lazily create the agent
        https://bugs.webkit.org/show_bug.cgi?id=195591
        <rdar://problem/48791756>

        Reviewed by Joseph Pecoraro.

        * inspector/JSGlobalObjectConsoleClient.h:
        (Inspector::JSGlobalObjectConsoleClient::setInspectorScriptProfilerAgent): Added.
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
        (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
        (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):

2019-03-19  Devin Rousso  <drousso@apple.com>

        Web Inspector: Heap: lazily create the agent
        https://bugs.webkit.org/show_bug.cgi?id=195590
        <rdar://problem/48791750>

        Reviewed by Joseph Pecoraro.

        * inspector/agents/InspectorHeapAgent.h:
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent): Deleted.

        * inspector/agents/InspectorConsoleAgent.h:
        (Inspector::InspectorConsoleAgent::setInspectorHeapAgent): Added.
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
        (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
        (Inspector::InspectorConsoleAgent::~InspectorConsoleAgent): Deleted.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):

2019-03-19  Caio Lima  <ticaiolima@gmail.com>

        [JSC] LLIntEntryPoint creates same DirectJITCode for all functions
        https://bugs.webkit.org/show_bug.cgi?id=194648

        Reviewed by Keith Miller.

        1. Making LLIntThunks singleton. 

        Motivation: Former implementation has one LLIntThunk per type per VM.
        However, the generated code for every kind of thunk is essentially the
        same and we end up wasting memory (right now jitAllocationGranule = 32 bytes)
        when we have 2 or more VM instantiated. Turn these thunks into
        singleton will avoid such wasting.

        Tradeoff: This change comes with a price, because we will keep thunks
        allocated even when there is no VM instantiated. Considering WebCore use case,
        the situation of having no VM instantiated is uncommon, since once a
        VM is created through `commomVM()`, it will never be destroyed. Given
        that, this change does not impact the overall memory comsumption of
        WebCore/JSC. It also doesn't impact memory footprint, since thunks are
        generated lazily (see results below).

        Since we are keeping a static `MacroAssemblerCodeRef<JITThunkPtrTag>`,
        we have the assurance that JITed code will never be deallocated,
        given it is being pointed by `RefPtr<ExecutableMemoryHandle> m_executableMemory`.
        To understand why we decided to make LLIntThunks singleton instead of
        removing them, please see the comment on `llint/LLIntThunks.cpp`.

        2. Making all LLIntEntrypoints singleton

        Motivation: With singleton LLIntThunks, we also can have singleton
        DirectJITCodes and NativeJITCodes for each LLIntEntrypoint type and
        avoid multiple allocations of objects with the same content.

        Tradeoff: As explained before, once we allocate an entrypoint, it
        will be alive until the program exits. However, the gains we can
        achieve in some use cases justifies such allocations.

        As DirectJITCode and NativeJITCode are ThreadSafeRefCounted and we are using
        `codeBlock->setJITCode(makeRef(*jitCode))`, their reference counter
        will never be less than 1.

        3. Memory usage analysis

        This change reduces memory usage on stress/generate-multiple-llint-entrypoints.js
        by 2% and is neutral on JetStream 2. Following results were generated
        running each benchmark 6 times and using 95% Student's t distribution
        confidence interval.

        microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory): 
            Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
            Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)

        JetStream2 (Neutral):
            Mean of memory peak on ToT: 5442742272 bytes (confidence interval: 134381565.9117)
            Mean of memory peak on Changes: 5384949760 bytes (confidence interval: 158413904.8352)

        4. Performance Analysis

        This change is performance neutral on JetStream 2 and Speedometer 2.
        See results below.:

        JetStream 2 (Neutral):
            Mean of score on ToT: 139.58 (confidence interval: 2.44)
            Mean of score on Changes: 141.46 (confidence interval: 4.24)

        Speedometer run #1
           ToT: 110 +- 2.9
           Changes: 110 +- 1.8

        Speedometer run #2
           ToT: 110 +- 1.6
           Changes: 108 +- 2.3

        Speedometer run #3
           ToT: 110 +- 3.0
           Changes: 110 +- 1.4

        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::JSInterfaceJIT):
        * llint/LLIntEntrypoint.cpp:

        Here we are changing the usage or DirectJITCode by NativeJITCode on cases
        where there is no difference from address of calls with and without
        ArithCheck.

        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        (JSC::LLInt::setModuleProgramEntrypoint):
        (JSC::LLInt::setEntrypoint):
        * llint/LLIntEntrypoint.h:
        * llint/LLIntThunks.cpp:
        (JSC::LLInt::generateThunkWithJumpTo):
        (JSC::LLInt::functionForCallEntryThunk):
        (JSC::LLInt::functionForConstructEntryThunk):
        (JSC::LLInt::functionForCallArityCheckThunk):
        (JSC::LLInt::functionForConstructArityCheckThunk):
        (JSC::LLInt::evalEntryThunk):
        (JSC::LLInt::programEntryThunk):
        (JSC::LLInt::moduleProgramEntryThunk):
        (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
        (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
        (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
        (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
        (JSC::LLInt::evalEntryThunkGenerator): Deleted.
        (JSC::LLInt::programEntryThunkGenerator): Deleted.
        (JSC::LLInt::moduleProgramEntryThunkGenerator): Deleted.
        * llint/LLIntThunks.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::setupLLInt):
        (JSC::ScriptExecutable::prepareForExecutionImpl):

2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Add missing exception checks revealed by newly added exception checks, follow-up after r243081
        https://bugs.webkit.org/show_bug.cgi?id=195927

        Reviewed by Mark Lam.

        r243081 adds more exception checks which are previously missing, and it reveals missing exception checks in the caller.
        This patch is a follow-up patch after r243081, adding missing exception checks more to fix debug test failures.

        * runtime/RegExpConstructor.cpp:
        (JSC::setRegExpConstructorInput):
        (JSC::setRegExpConstructorMultiline):
        * runtime/RegExpGlobalData.cpp:
        (JSC::RegExpGlobalData::getBackref):
        (JSC::RegExpGlobalData::getLastParen):

2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Generator should not create JSLexicalEnvironment if it is not necessary
        https://bugs.webkit.org/show_bug.cgi?id=195901

        Reviewed by Saam Barati.

        It is not rare that generators do not need to have any registers to be suspended and resumed.
        Since currently we always emit op_create_lexical_environment for generator code, we sometimes
        create empty JSLexicalEnvironment while it is not required. We can see that a lot of empty JSLexicalEnvironment
        are allocated in RAMification's Basic test.

        This patch removes this unnecessary allocation. We introduce op_create_generator_frame_environment, which is
        a marker, similar to op_yield. And generatorification phase decides whether we should actually emit op_create_lexical_environment,
        based on the result of the analysis in generatorification. This can remove unnecessary JSLexicalEnvironment allocations.

        We run RAMification in 6 times, use average of them.
        RAMification's Basic in JIT mode shows 1.4% improvement.
        ToT
            Current: 55076864.00, Peak: 55080960.00
        Patched
            Current: 54325930.67, Peak: 54329344.00

        RAMification's Basic in non-JIT mode shows 5.0% improvement.
        ToT
            Current: 12485290.67, Peak: 12485290.67
        Patched
            Current: 11894101.33, Peak: 11894101.33

        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
        (JSC::BytecodeGeneratorification::generatorFrameData const):
        (JSC::BytecodeGeneratorification::run):
        * bytecode/BytecodeList.rb:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * llint/LowLevelInterpreter.asm:

2019-03-18  Robin Morisset  <rmorisset@apple.com>

        Remove the inline capacity of Operands
        https://bugs.webkit.org/show_bug.cgi?id=195898

        Reviewed by Yusuke Suzuki.

        Operands currently has a vector with an inline capacity of 24.
        I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
        This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
        Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
        
        So I removed the inline capacity of the vector in Operands, and here are the results:
        Baseline Jetstream2:
        159.741
        159.746
        159.989
        Baseline RAMification on grouped and jit tests: (end/peak/score)
        89.288/89.763/89.526
        90.166/90.761/90.418
        89.560/90.014/89.787
        After optimization Jetstream2:
        159.342
        161.812
        162.037
        After optimization RAMification:
        89.147/89.644/89.395
        89.102.89.585/89.343
        88.953/89.536/89.2444
        
        So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
        I hope to land this, and get more accurate results from the bots.

        * bytecode/Operands.h:

2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
        https://bugs.webkit.org/show_bug.cgi?id=195897

        Reviewed by Keith Miller.

        It is useful if we have an option logging the status of all the existing MarkedBlocks and their objects at VM destruction.
        I used this feature to find wasting memory, and successfully removed many wasted MarkedBlocks and JS cells like r243081.
        This patch adds,

        1. --destroy-vm option to JSC shell to destroy main thread JSC::VM
        2. dumpHeapStatisticsAtVMDestruction to dump MarkedBlocks at VM destruction

        While the current option name is "dumpHeapStatisticsAtVMDestruction", we just dump the status of MarkedBlocks and cells. But eventually,
        we would like to collect heap statistics and dump them to investigate Heap status more.

        This patch also removes logHeapStatisticsAtExit option since it is no longer used in JSC.

        * heap/Heap.cpp:
        (JSC::Heap::dumpHeapStatisticsAtVMDestruction):
        (JSC::Heap::lastChanceToFinalize):
        * heap/Heap.h:
        * jsc.cpp:
        (printUsageStatement):
        (CommandLine::parseArguments):
        (runJSC):
        * runtime/Options.h:

2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] jsSubstring should resolve rope before calling JSRopeString::create
        https://bugs.webkit.org/show_bug.cgi?id=195840

        Reviewed by Geoffrey Garen.

        jsSubstring always ends up resolving rope of the base string because substring JSRopeString only accepts non-rope JSString
        as its base. Instead of resolving ropes in finishCreationSubstring, we should resolve before passing it to JSRopeString.
        So that, we can access string data before creating JSRopeString, and we can introduce optimizations like avoiding creation
        of single character substrings.

        We can find that a lot of substrings for length = 1 are allocated in RAMification regexp tests. This patch avoids creation of these
        strings to save memory.

        This patch also strengthen error checks caused by rope resolution for base of substrings. Previously we sometimes miss this checks.

        * dfg/DFGOperations.cpp:
        * runtime/JSString.cpp:
        (JSC::JSString::dumpToStream):
        * runtime/JSString.h:
        (JSC::jsSubstring):
        (JSC::jsSubstringOfResolved):
        (JSC::jsSingleCharacterString):
        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::lastResult): We no longer need to have length = 0 path since jsSubstring returns an empty string if length == 0.
        (JSC::RegExpCachedResult::leftContext):
        (JSC::RegExpCachedResult::rightContext):
        (JSC::RegExpCachedResult::setInput):
        * runtime/RegExpGlobalData.cpp:
        (JSC::RegExpGlobalData::getBackref):
        (JSC::RegExpGlobalData::getLastParen):
        * runtime/StringObject.h:
        (JSC::jsStringWithReuse):
        (JSC::jsSubstring):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingRegExpSearch):
        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
        (JSC::replaceUsingStringSearch):
        (JSC::stringProtoFuncSlice):
        (JSC::splitStringByOneCharacterImpl):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncSubstr):
        (JSC::stringProtoFuncSubstring):
        (JSC::stringProtoFuncToLowerCase):
        (JSC::stringProtoFuncToUpperCase):
        Some `const String& value = string->value(exec)` is dangerous if GC happens later. Changed to getting `String` instead of `const String&` here.

        * runtime/StringPrototypeInlines.h:
        (JSC::stringSlice):

2019-03-18  Mark Lam  <mark.lam@apple.com>

        Missing a ThrowScope release in JSObject::toString().
        https://bugs.webkit.org/show_bug.cgi?id=195893
        <rdar://problem/48970986>

        Reviewed by Michael Saboff.

        Placate the validator with a RELEASE_AND_RETURN().

        * runtime/JSObject.cpp:
        (JSC::JSObject::toString const):

2019-03-18  Mark Lam  <mark.lam@apple.com>

        Structure::flattenDictionary() should clear unused property slots.
        https://bugs.webkit.org/show_bug.cgi?id=195871
        <rdar://problem/48959497>

        Reviewed by Michael Saboff.

        It currently attempts to do this but fails because it's actually clearing up the
        preCapacity region instead.  The fix is simply to account for the preCapacity
        when computing the start address of the property slots.

        * runtime/Structure.cpp:
        (JSC::Structure::flattenDictionaryStructure):

2019-03-18  Robin Morisset  <rmorisset@apple.com>

        B3 should reduce Shl(<S|Z>Shr(@x, @const), @const) to BitAnd(@x, -(1<<@const))
        https://bugs.webkit.org/show_bug.cgi?id=152164

        Reviewed by Filip Pizlo.

        Turn this: Shl(<S|Z>Shr(@x, @const), @const)
        Into this: BitAnd(@x, -(1<<@const))

        I added two tests: one for ZShr/32 bits, and one for SShr/64 bits, I think it is enough coverage (no reason for any interaction between the signedness of the shift and the bitwidth).
        I also modified a few adjacent tests to remove undefined behaviours.

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testShlImms):
        (JSC::B3::testShlArgImm):
        (JSC::B3::testShlSShrArgImm):
        (JSC::B3::testShlImms32):
        (JSC::B3::testShlArgImm32):
        (JSC::B3::testShlZShrArgImm32):
        (JSC::B3::run):

2019-03-17  Robin Morisset  <rmorisset@apple.com>

        ParserError can be shrunk by 8 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195496

        Reviewed by Mark Lam.

        * parser/ParserError.h:

2019-03-17  Diego Pino Garcia  <dpino@igalia.com>

        Fix WPE and GTK Debug builds after r243049
        https://bugs.webkit.org/show_bug.cgi?id=195860

        Unreviewed, build fix after r243049.

        * runtime/StringPrototype.cpp:
        (JSC::normalizationAffects8Bit):

2019-03-17  Yusuke Suzuki  <ysuzuki@apple.com>

        REGRESSION: !vm.isInitializingObject() void* JSC::tryAllocateCellHelper<JSC::Structure> JSC::Structure::create
        https://bugs.webkit.org/show_bug.cgi?id=195858

        Reviewed by Mark Lam.

        r243011 changed WebAssembly related structures lazily-allocated. It means that this lazy allocation must not be done in the middle of
        the other object allocations. This patch changes the signature of wasm related objects' ::create functions to taking Structure*.
        This prevents us from materializing lazily-allocated structures while allocating wasm related objects, and this style is used in the
        other places to fix the same problem. This bug is caught by existing debug tests for wasm.

        * runtime/JSGlobalObject.h:
        * wasm/js/JSWebAssemblyCompileError.cpp:
        (JSC::createJSWebAssemblyCompileError):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finalizeCreation):
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyLinkError.cpp:
        (JSC::createJSWebAssemblyLinkError):
        * wasm/js/JSWebAssemblyModule.cpp:
        (JSC::JSWebAssemblyModule::createStub):
        (JSC::JSWebAssemblyModule::finishCreation):
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::wasmToJSException):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyCompileError):
        (JSC::callJSWebAssemblyCompileError):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::WebAssemblyFunction::create):
        * wasm/js/WebAssemblyFunction.h:
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::constructJSWebAssemblyInstance):
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyLinkError):
        (JSC::callJSWebAssemblyLinkError):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyModuleValidateAsyncInternal):
        (JSC::instantiate):
        (JSC::compileAndInstantiate):
        (JSC::webAssemblyModuleInstantinateAsyncInternal):
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyRuntimeError):
        (JSC::callJSWebAssemblyRuntimeError):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        * wasm/js/WebAssemblyToJSCallee.cpp:
        (JSC::WebAssemblyToJSCallee::create):
        * wasm/js/WebAssemblyToJSCallee.h:
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::WebAssemblyWrapperFunction::create):
        * wasm/js/WebAssemblyWrapperFunction.h:

2019-03-16  Darin Adler  <darin@apple.com>

        Improve normalization code, including moving from unorm.h to unorm2.h
        https://bugs.webkit.org/show_bug.cgi?id=195330

        Reviewed by Michael Catanzaro.

        * runtime/JSString.h: Move StringViewWithUnderlyingString to StringView.h.

        * runtime/StringPrototype.cpp: Include unorm2.h instead of unorm.h.
        (JSC::normalizer): Added. Function to create normalizer object given
        enumeration value indicating which is selected. Simplified because we
        know the function will not fail and so we don't need error handling code.
        (JSC::normalize): Changed this function to take a JSString* so we can
        optimize the case where no normalization is needed. Added an early exit
        if the string is stored as 8-bit and another if the string is already
        normalized, using unorm2_isNormalized. Changed error handling to only
        check cases that can actually fail in practice. Also did other small
        optimizations like passing VM rather than ExecState.
        (JSC::stringProtoFuncNormalize): Used smaller enumeration names that are
        identical to the names used in the API and normalization parlance rather
        than longer ones that expand the acronyms. Updated to pass JSString* to
        the normalize function, so we can optimize 8-bit and already-normalized
        cases, rather than callling the expensive String::upconvertedCharacters
        function. Use throwVMRangeError.

2019-03-15  Mark Lam  <mark.lam@apple.com>

        Need to check ObjectPropertyCondition liveness before accessing it when firing watchpoints.
        https://bugs.webkit.org/show_bug.cgi?id=195827
        <rdar://problem/48845513>

        Reviewed by Filip Pizlo.

        m_object in ObjectPropertyCondition may no longer be live by the time the watchpoint fires.

        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        * bytecode/ObjectPropertyCondition.cpp:
        (JSC::ObjectPropertyCondition::dumpInContext const):
        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::fireInternal):
        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
        * runtime/StructureRareData.cpp:
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):

2019-03-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Make more properties lazily-allocated in JSGlobalObject, including properties only used in JIT mode
        https://bugs.webkit.org/show_bug.cgi?id=195816

        Reviewed by Michael Saboff.

        This patch makes more properties lazily-allocated in JSGlobalObject. This patch makes the following lazily-allocated.

        1. iteratorResultObjectStructure
        2. WebAssembly related objects except for JSWebAssembly top-level object.

        * CMakeLists.txt:
        * DerivedSources-input.xcfilelist:
        * DerivedSources-output.xcfilelist:
        * DerivedSources.make:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::iteratorResultObjectStructure const):
        (JSC::JSGlobalObject::webAssemblyModuleRecordStructure const):
        (JSC::JSGlobalObject::webAssemblyFunctionStructure const):
        (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const):
        (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const):
        * wasm/js/JSWebAssembly.cpp:
        * wasm/js/JSWebAssembly.h:

2019-03-15  Dominik Infuehr  <dinfuehr@igalia.com>

        [CMake] Move test .js files into testapiScripts
        https://bugs.webkit.org/show_bug.cgi?id=195565

        Reviewed by Yusuke Suzuki.

        testapi expect .js file in the testapiScripts-directory.

        * shell/CMakeLists.txt:

2019-03-15  Mark Lam  <mark.lam@apple.com>

        Gardening: add a missing exception check after r242991.
        https://bugs.webkit.org/show_bug.cgi?id=195791

        Unreviewed.

        * tools/JSDollarVM.cpp:
        (JSC::functionGetGetterSetter):

2019-03-15  Devin Rousso  <drousso@apple.com>

        Web Inspector: provide a way to capture a screenshot of a node from within the page
        https://bugs.webkit.org/show_bug.cgi?id=194279
        <rdar://problem/10731573>

        Reviewed by Joseph Pecoraro.

        Add `console.screenshot` functionality, which displays a screenshot of a given object (if
        able) within Web Inspector's Console tab. From there, it can be viewed and saved.

        Currently, `console.screenshot` will
         - capture an image of a `Node` (if provided)
         - capture an image of the viewport if nothing is provided

        * inspector/protocol/Console.json:
        Add `Image` enum value to `ConsoleMessage` type.
        * runtime/ConsoleTypes.h:
        * inspector/ConsoleMessage.h:
        * inspector/ConsoleMessage.cpp:
        (Inspector::messageTypeValue):

        * runtime/ConsoleClient.h:
        * runtime/ConsoleObject.cpp:
        (JSC::ConsoleObject::finishCreation):
        (JSC::consoleProtoFuncScreenshot): Added.

        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::screenshot): Added.

2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Retain PrivateName of Symbol before passing it to operations potentially incurring GC
        https://bugs.webkit.org/show_bug.cgi?id=195791
        <rdar://problem/48806130>

        Reviewed by Mark Lam.

        Consider the following example:

            void putByVal(JSObject*, PropertyName propertyName, ...);

            putByVal(object, symbol->privateName(), ...);

        PropertyName does not retain the passed UniquedStringImpl*. It just holds the pointer to UniquedStringImpl*.
        It means that since `Symbol::privateName()` returns `const PrivateName&` instead of `PrivateName`, putByVal
        and its caller does not retain UniquedStringImpl* held in PropertyName. The problem happens when the putByVal
        incurs GC, and when the `symbol` is missing in the conservative GC scan. The underlying UniquedStringImpl* of
        PropertyName can be accidentally destroyed in the middle of the putByVal operation. We should retain PrivateName
        before passing it to operations which takes it as PropertyName.

        1. We use the code pattern like this.

            auto propertyName = symbol->privateName();
            someOperation(..., propertyName);

        This pattern is well aligned to existing `JSValue::toPropertyKey(exec)` and `JSString::toIdentifier(exec)` code patterns.

            auto propertyName = value.toPropertyKey(exec);
            RETURN_IF_EXCEPTION(scope, { });
            someOperation(..., propertyName);

        2. We change `Symbol::privateName()` to returning `PrivateName` instead of `const PrivateName&` to avoid
           potential dangerous use cases. This is OK because the code using `Symbol::privateName()` is not a critical path,
           and they typically need to retain PrivateName.

        3. We audit similar functions `toPropertyKey(exec)` and `toIdentifier(exec)` for needed but missing exception checks.
           BTW, these functions are safe to the problem fixed in this patch since they return `Identifier` instead
           of `const Identifier&`.

        Mark and Robin investigated and offered important data to understand what went wrong. And figured out the reason behind
        the mysterious behavior shown in the data, and now, we confirm that this is the right fix for this bug.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:
        (JSC::tryGetByValOptimize):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::setFunctionName):
        * runtime/JSModuleLoader.cpp:
        (JSC::printableModuleKey):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Stringifier):
        * runtime/Symbol.cpp:
        (JSC::Symbol::descriptiveString const):
        (JSC::Symbol::description const):
        * runtime/Symbol.h:
        * runtime/SymbolConstructor.cpp:
        (JSC::symbolConstructorKeyFor):
        * tools/JSDollarVM.cpp:
        (JSC::functionGetGetterSetter):

2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>

        REGRESSION(r242841): Fix conservative DFG OSR entry validation to accept values which will be stored in AnyInt / Double flush formats
        https://bugs.webkit.org/show_bug.cgi?id=195752

        Reviewed by Saam Barati.

        We fixed the bug skipping AbstractValue validations when the flush format is Double or AnyInt. But it
        was too conservative. While validating inputs with AbstractValue is mandatory (without it, whole CFA
        falls into wrong condition), our validation does not care AnyInt and Double representations in lower
        tiers. For example, if a value is stored in Double flush format in DFG, its AbstractValue becomes
        SpecFullDouble. However, it does not include Int32 and OSR entry is rejected if Int32 comes for DoubleRep
        OSR entry value. This is wrong since we later convert these numbers into DoubleRep representation
        before entering DFG code.

        This patch performs AbstractValue validation onto the correctly converted value with flush format hint.

        And it still does not fix OSR entry failures in navier-stokes. This is because AbstractValue representation
        in navier-stokes's lin_solve was too strict. Then, this patch reverts r242627. Instead of removing must handle
        value handling in CFA, DFG OSR entry now correctly validates inputs with AbstractValues even if the flush format
        is Double or AnyInt. As long as DFG OSR entry validates inputs, merging must handle values as proven constants is OK.

        We can see that # of OSR entry failures in navier-stokes.js becomes the same to the previous count. And we can see
        AnyInt OSR entry actually works in microbenchmarks/large-int.js. However, AnyInt effect is hard to observe because this
        is super rare. Since we inject type prediction based on must handle value, the flush format tends to be SpecAnyIntAsDouble
        and it accepts JSValues simply.

        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::filterValueByType):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::validateOSREntryValue const):
        (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
        (JSC::DFG::AbstractValue::validate const): Deleted.
        (JSC::DFG::AbstractValue::validateType const): Deleted.
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::run):
        (JSC::DFG::CFAPhase::injectOSR):
        (JSC::DFG::CFAPhase::performBlockCFA):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):

2019-03-14  Saam barati  <sbarati@apple.com>

        We can't remove code after ForceOSRExit until after FixupPhase
        https://bugs.webkit.org/show_bug.cgi?id=186916
        <rdar://problem/41396612>

        Reviewed by Yusuke Suzuki.

        There was an optimization in the bytecode parser I added in r232742 that converted blocks
        with ForceOSRExit in them to remove all IR after the ForceOSRExit. However,
        this is incorrect because it breaks backwards propagation. For example, it
        could incorrectly lead us to think it's safe to not check for overflow in
        an Add because such Add has no non-int uses. Backwards propagation relies on
        having a view over bytecode uses, and this optimization broke that. This patch
        rolls out that optimization, as initial perf data shows it may no longer be
        needed.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addToGraph):
        (JSC::DFG::ByteCodeParser::parse):

2019-03-14  Saam barati  <sbarati@apple.com>

        JSScript should have an accessor saying if it's cached or not
        https://bugs.webkit.org/show_bug.cgi?id=195783

        Reviewed by Michael Saboff.

        * API/JSScript.h:
        * API/JSScript.mm:
        (-[JSScript isUsingBytecodeCache]):
        * API/tests/testapi.mm:
        (testIsUsingBytecodeCacheAccessor):
        (testObjectiveCAPI):

2019-03-14  Saam barati  <sbarati@apple.com>

        Remove retain cycle from JSScript and also don't keep the cache file descriptor open so many JSScripts can be cached in a loop
        https://bugs.webkit.org/show_bug.cgi?id=195782
        <rdar://problem/48880625>

        Reviewed by Michael Saboff.

        This patch fixes two issues with JSScript API:
        
        1. There was a retain cycle causing us to never destroy a JSScript once it
        created a JSSourceCode. The reason for this is that JSScript had a 
        Strong<JSSourceCode> field. And JSSourceCode transitively had RetainPtr<JSScript>.
        
        This patch fixes this issue by making the "jsSourceCode" accessor return a transient object.
        
        2. r242585 made it so that JSScript would keep the cache file descriptor open
        (and locked) for the duration of the lifetime of the JSScript itself. Our
        anticipation here is that it would make implementing iterative cache updates
        easier. However, this made using the API super limiting in other ways. For
        example, if a program had a loop that cached 3000 different JSScripts, it's
        likely that such a program would exhaust the open file count limit. This patch
        reverts to the behavior prior to r242585 where we just keep open the file descriptor
        while we read or write it.

        * API/JSAPIGlobalObject.mm:
        (JSC::JSAPIGlobalObject::moduleLoaderFetch):
        * API/JSContext.mm:
        (-[JSContext evaluateJSScript:]):
        * API/JSScript.mm:
        (-[JSScript dealloc]):
        (-[JSScript readCache]):
        (-[JSScript init]):
        (-[JSScript sourceCode]):
        (-[JSScript jsSourceCode]):
        (-[JSScript writeCache:]):
        (-[JSScript forceRecreateJSSourceCode]): Deleted.
        * API/JSScriptInternal.h:
        * API/tests/testapi.mm:
        (testCanCacheManyFilesWithTheSameVM):
        (testObjectiveCAPI):
        (testCacheFileIsExclusive): Deleted.

2019-03-14  Michael Saboff  <msaboff@apple.com>

        ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread()
        https://bugs.webkit.org/show_bug.cgi?id=195735

        Reviewed by Mark Lam.

        There are two bug fixes here.

        The first bug happens due to a race condition when we are compiling on a separate thread while the
        main thread is compiling the RegExp at a place where it can run out of stack.  When that happens,
        the RegExp becomes invalid due to the out of stack error.  If we check the ASSERT condition in the DFG
        compilation thread, we crash.  After the main thread throws an exception, it resets the RegExp as
        it might compile successfully the next time we try to execute it on a shallower stack.
        The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling
        or any slow path we call out to.  Therefore ASSERTs like this in compilation code can be eliminated.

        The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase.
        The current check for "do we have code to run the RegExp?" only checks that the RegExp's state
        is != NotCompiled.  We also can't run the RegExp if there the state is ParseError.
        Changing hasCode() to take this into account fixes the second issue.

        (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
        * runtime/RegExp.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewRegexp):
        * runtime/RegExp.h:

2019-03-14  Saam barati  <sbarati@apple.com>

        Fixup uses KnownInt32 incorrectly in some nodes
        https://bugs.webkit.org/show_bug.cgi?id=195279
        <rdar://problem/47915654>

        Reviewed by Yusuke Suzuki.

        Fixup was sometimes using KnownInt32 edges when it knew some
        incoming value is an Int32 based on what the bytecode would return.
        However, because bytecode may result in Int32 for some node does
        not mean we'll pick Int32 as the value format for that local. For example,
        we may choose for a value to be represented as a double. This patch
        corrects such uses of KnownInt32.

        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArrayPush):
        (JSC::DFG::SpeculativeJIT::compileGetDirectPname):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):

2019-03-14  Keith Miller  <keith_miller@apple.com>

        DFG liveness can't skip tail caller inline frames
        https://bugs.webkit.org/show_bug.cgi?id=195715
        <rdar://problem/46221598>

        Reviewed by Saam Barati.

        In order to simplify OSR exit/DFG bytecode parsing our bytecode
        generator always emits an op_ret after any tail call. However, the
        DFG when computing the liveness of locals, would skip any tail
        caller inline frames. This mean that if we ended up inserting a
        Check that would OSR to the op_ret we wouldn't have kept
        availability data around for it.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):

2019-03-14  Robin Morisset  <rmorisset@apple.com>

        DFG::Worklist can be shrunk by 16 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195490

        Reviewed by Darin Adler.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::Worklist):
        * dfg/DFGWorklist.h:

2019-03-14  Devin Rousso  <drousso@apple.com>

        Web Inspector: Audit: provide a way to get the contents of resources
        https://bugs.webkit.org/show_bug.cgi?id=195266
        <rdar://problem/48550911>

        Reviewed by Joseph Pecoraro.

        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeAsyncCall):
        Drive-by: fix missing `else`.

2019-03-14  Devin Rousso  <drousso@apple.com>

        Web Inspector: Styles: `::-webkit-scrollbar*` rules aren't shown
        https://bugs.webkit.org/show_bug.cgi?id=195123
        <rdar://problem/48450148>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/CSS.json:
        Add `CSS.PseudoId` enum, rather than send a number, so that we have more knowledge about
        which pseudo type the rule corresponds to (e.g. a string is more descriptive than a number).

2019-03-13  Caio Lima  <ticaiolima@gmail.com>

        [JSC] CodeBlock::visitChildren is reporting extra memory even when its JITCode is singleton
        https://bugs.webkit.org/show_bug.cgi?id=195638

        Reviewed by Mark Lam.

        This patch introduces a m_isShared flag to track whether the
        JITCode is shared between many CodeBlocks. This flag is used in
        `CodeBlock::setJITCode` and `CodeBlock::visitChildren` to avoid
        reporting duplicated extra memory for singleton JITCodes.
        With those changes, we now stop counting singleton LLIntEntrypoints
        as extra memory, since they are declared as static variables. This
        change can potentially avoid unecessary GC pressure, because
        extra memory is used by Heap::updateAllocationLimits() to update Heap
        limits.
        Even though it is hard to show performance difference for this change
        (see results below), it is important to keep extra memory usage
        correct. Otherwise, it can be a source of a complicated bug on
        GC in the future.

        Results from last run of Speedometer 2 comparing ToT and changes. We
        collected those numbers running Minibrowser on a MacBook Pro 15-inch
        with 2,6 GHz Intel Core i7. Both versions are with JIT disabled,
        since these singleton JITCode are only used by this configuration:

        Speedometer2 Run #1
            ToT: 58.2 +- 1.1
            changes: 57.9 +- 0.99

        Speedometer2 Run #2
            ToT: 58.5 +- 1.7
            changes: 58.0 +- 1.5

        Speedometer2 Run #2
            ToT: 58.5 +- 0.99
            changes: 57.1 +- 1.5

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::estimatedSize):
        (JSC::CodeBlock::visitChildren):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        * jit/JITCode.cpp:
        (JSC::JITCode::JITCode):
        (JSC::JITCodeWithCodeRef::JITCodeWithCodeRef):
        (JSC::DirectJITCode::DirectJITCode):
        (JSC::NativeJITCode::NativeJITCode):
        * jit/JITCode.h:
        (JSC::JITCode::isShared const):
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        (JSC::LLInt::setModuleProgramEntrypoint):

2019-03-13  Keith Rollin  <krollin@apple.com>

        Add support for new StagedFrameworks layout
        https://bugs.webkit.org/show_bug.cgi?id=195543

        Reviewed by Alexey Proskuryakov.

        When creating the WebKit layout for out-of-band Safari/WebKit updates,
        use an optional path prefix when called for.

        * Configurations/Base.xcconfig:

2019-03-13  Mark Lam  <mark.lam@apple.com>

        Remove unneeded --tradeDestructorBlocks option.
        https://bugs.webkit.org/show_bug.cgi?id=195698
        <rdar://problem/39681388>

        Reviewed by Yusuke Suzuki.

        There's no reason why we would ever want --tradeDestructorBlocks to be false.

        Also, there was an assertion in BlockDirectory::endMarking() for when
        (!Options::tradeDestructorBlocks() && needsDestruction()).  This assertion is
        outdated because the BlockDirectory's m_empty set used to mean the set of all
        blocks that have no live (as in not reachable by GC) objects and dead objects
        also do not require destructors to be called on them.  The current meaning of
        m_empty is that it is the set of all blocks that have no live objects,
        independent of whether they needs destructors to be called on them or not.
        The assertion is no longer valid for the new meaning of m_empty as m_empty may
        now contain destructible blocks.  This assertion is now removed as part of this
        patch.

        * heap/BlockDirectory.cpp:
        (JSC::BlockDirectory::endMarking):
        * heap/LocalAllocator.cpp:
        (JSC::LocalAllocator::tryAllocateWithoutCollecting):
        * runtime/Options.h:

2019-03-13  Dominik Infuehr  <dinfuehr@igalia.com>

        String overflow when using StringBuilder in JSC::createError
        https://bugs.webkit.org/show_bug.cgi?id=194957

        Reviewed by Mark Lam.

        StringBuilder in notAFunctionSourceAppender didn't check
        for overflows but just failed.

        * runtime/ExceptionHelpers.cpp:
        (JSC::notAFunctionSourceAppender):

2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Move species watchpoint installation from ArrayPrototype to JSGlobalObject
        https://bugs.webkit.org/show_bug.cgi?id=195593

        Reviewed by Keith Miller.

        This patch moves watchpoints installation and watchpoints themselves from ArrayPrototype to JSGlobalObject because of the following two reasons.

        1. ArrayPrototype configures finalizer because of std::unique_ptr<> for watchpoints. If we move them from ArrayPrototype to JSGlobalObject, we do
           not need to set finalizer. And we can avoid unnecessary WeakBlock allocation.

        2. This code lazily configures watchpoints instead of setting watchpoints eagerly in JSGlobalObject::init. We would like to expand this mechanism
           to other watchpoints which are eagerly configured in JSGlobalObject::init. Putting these code in JSGlobalObject instead of scattering them in
           each XXXPrototype / XXXConstructor can encourage the reuse of the code.

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::create):
        (JSC::speciesWatchpointIsValid):
        (JSC::ArrayPrototype::destroy): Deleted.
        (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): Deleted.
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint): Deleted.
        (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): Deleted.
        * runtime/ArrayPrototype.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint): Instead of using ArrayPrototypeAdaptiveInferredPropertyWatchpoint,
        we use ObjectPropertyChangeAdaptiveWatchpoint. We create watchpoints after touching WatchpointSet since ObjectPropertyChangeAdaptiveWatchpoint
        requires WatchpointSet is IsWatched state.
        * runtime/JSGlobalObject.h:

2019-03-12  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] OSR entry should respect abstract values in addition to flush formats
        https://bugs.webkit.org/show_bug.cgi?id=195653

        Reviewed by Mark Lam.

        Let's consider the following graph.

        Block #0
            ...
            27:< 2:loc13> JSConstant(JS|UseAsOther, StringIdent, Strong:String (atomic) (identifier): , StructureID: 42679, bc#10, ExitValid)
            ...
            28:< 2:loc13> ArithPow(DoubleRep:@437<Double>, Int32:@27, Double|UseAsOther, BytecodeDouble, Exits, bc#10, ExitValid)
            29:<!0:->     MovHint(DoubleRep:@28<Double>, MustGen, loc7, W:SideState, ClobbersExit, bc#10, ExitValid)
            30:< 1:->     SetLocal(DoubleRep:@28<Double>, loc7(M<Double>/FlushedDouble), machine:loc6, W:Stack(-8), bc#10, exit: bc#14, ExitValid)  predicting BytecodeDouble
            ...
            73:<!0:->     Jump(MustGen, T:#1, W:SideState, bc#71, ExitValid)

        Block #1 (bc#71): (OSR target) pred, #0
            ...
           102:<!2:loc15> GetLocal(Check:Untyped:@400, Double|MustGen|PureInt, BytecodeDouble, loc7(M<Double>/FlushedDouble), machine:loc6, R:Stack(-8), bc#120, ExitValid)  predicting BytecodeDouble
            ...

        CFA at @28 says it is invalid since there are type contradiction (Int32:@27 v.s. StringIdent). So, of course, we do not propagate #0's type information to #1 since we become invalid state.
        However, #1 is still reachable since it is an OSR target. Since #0 was only the predecessor of #1, loc7's type information becomes None at the head of #1.
        Since loc7's AbstractValue is None, @102 GetLocal emits breakpoint. It is OK as long as OSR entry fails because AbstractValue validation requires the given value is None type.

        The issue here is that we skipped AbstractValue validation when we have FlushFormat information. Since loc7 has FlushedDouble format, DFG OSR entry code does not validate it against AbstractValue,
        which is None. Then, we hit the breakpoint emitted by @102.

        This patch performs AbstractValue validation against values even if we have FlushFormat. We should correctly configure AbstractValue for OSR entry's locals too to avoid unnecessary OSR entry
        failures in the future but anyway validating locals with AbstractValue is correct behavior here since DFGSpeculativeJIT relies on that.

        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):

2019-03-12  Michael Saboff  <msaboff@apple.com>

        REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes
        https://bugs.webkit.org/show_bug.cgi?id=195613

        Reviewed by Mark Lam.

        The bug here is in Yarr JIT backreference matching code.  We are incorrectly
        using a checkedOffset / inputPosition correction when checking for the available
        length left in a string.  It is improper to do these corrections as a backreference's
        match length is based on what was matched in the referenced capture group and not
        part of the checkedOffset and inputPosition computed when we compiled the RegExp.
        In some cases, the resulting incorrect calculation would allow us to go past
        the subject string's length.  Removed these adjustments.

        After writing tests for the first bug, found another bug where the non-greedy
        backreference backtracking code didn't do an "are we at the end of the input?" check.
        This caused an infinite loop as we'd jump from the backtracking code back to
        try matching one more backreference, fail and then backtrack.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateBackReference):
        (JSC::Yarr::YarrGenerator::backtrackBackReference):

2019-03-12  Robin Morisset  <rmorisset@apple.com>

        A lot more classes have padding that can be reduced by reordering their fields
        https://bugs.webkit.org/show_bug.cgi?id=195579

        Reviewed by Mark Lam.

        * assembler/LinkBuffer.h:
        * dfg/DFGArrayifySlowPathGenerator.h:
        (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        * dfg/DFGGraph.h:
        * dfg/DFGNode.h:
        (JSC::DFG::SwitchData::SwitchData):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        * dfg/DFGPlan.h:
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        * dfg/DFGSpeculativeJIT.h:
        * domjit/DOMJITSignature.h:
        (JSC::DOMJIT::Signature::Signature):
        (JSC::DOMJIT::Signature::effect):
        (JSC::DOMJIT::Signature::argumentCount): Deleted.
        * heap/MarkingConstraintSolver.h:
        * heap/SlotVisitor.h:
        * jit/CallFrameShuffleData.h:
        * jit/JITDivGenerator.h:
        * jit/SpillRegistersMode.h:
        * parser/Nodes.h:
        * profiler/ProfilerOSRExit.cpp:
        (JSC::Profiler::OSRExit::OSRExit):
        * profiler/ProfilerOSRExit.h:
        * runtime/ArrayBufferView.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::SamplingProfiler):
        * runtime/SamplingProfiler.h:
        * runtime/TypeSet.cpp:
        (JSC::StructureShape::StructureShape):
        * runtime/TypeSet.h:
        * runtime/Watchdog.h:

2019-03-12  Mark Lam  <mark.lam@apple.com>

        The HasIndexedProperty node does GC.
        https://bugs.webkit.org/show_bug.cgi?id=195559
        <rdar://problem/48767923>

        Reviewed by Yusuke Suzuki.

        HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(),
        which can eventually call JSString::getIndex(), which can resolve a rope.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-03-12  Devin Rousso  <drousso@apple.com>

        Web Inspector: Audit: there should be a centralized place for reusable code
        https://bugs.webkit.org/show_bug.cgi?id=195265
        <rdar://problem/47040673>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Audit.json:
        Increment version.

2019-03-12  Robin Morisset  <rmorisset@apple.com>

        blocksInPreOrder and blocksInPostOrder should reserve the right capacity for their result vector
        https://bugs.webkit.org/show_bug.cgi?id=195595

        Reviewed by Saam Barati.

        Also change BlockList from being Vector<BasicBlock*, 5> to Vector<BasicBlock*>

        * dfg/DFGBasicBlock.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::blocksInPreOrder):
        (JSC::DFG::Graph::blocksInPostOrder):

2019-03-11  Ross Kirsling  <ross.kirsling@sony.com>

        Add Optional to Forward.h.
        https://bugs.webkit.org/show_bug.cgi?id=195586

        Reviewed by Darin Adler.

        * b3/B3Common.cpp:
        * b3/B3Common.h:
        * debugger/DebuggerParseData.cpp:
        * debugger/DebuggerParseData.h:
        * heap/HeapSnapshot.cpp:
        * heap/HeapSnapshot.h:
        * jit/PCToCodeOriginMap.cpp:
        * jit/PCToCodeOriginMap.h:
        * runtime/AbstractModuleRecord.cpp:
        * runtime/AbstractModuleRecord.h:
        * wasm/WasmInstance.h:
        * wasm/WasmModuleParser.h:
        * wasm/WasmSectionParser.cpp:
        * wasm/WasmSectionParser.h:
        * wasm/WasmStreamingParser.cpp:
        * wasm/WasmStreamingParser.h:
        * yarr/YarrFlags.cpp:
        * yarr/YarrFlags.h:
        * yarr/YarrUnicodeProperties.cpp:
        * yarr/YarrUnicodeProperties.h:
        Remove unnecessary includes from headers.

2019-03-11  Justin Fan  <justin_fan@apple.com>

        [Web GPU] Update GPUSwapChainDescriptor, GPUSwapChain and implement GPUCanvasContext
        https://bugs.webkit.org/show_bug.cgi?id=194406
        <rdar://problem/47892466>

        Reviewed by Myles C. Maxfield.

        Added WebGPU to inspector context types.

        * inspector/protocol/Canvas.json:
        * inspector/scripts/codegen/generator.py:

2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Reduce # of structures in JSGlobalObject initialization
        https://bugs.webkit.org/show_bug.cgi?id=195498

        Reviewed by Darin Adler.

        This patch reduces # of structure allocations in JSGlobalObject initialization. Now it becomes 141, it fits in one
        MarkedBlock and this patch drops one MarkedBlock used for Structure previously.

        * CMakeLists.txt:
        * DerivedSources-output.xcfilelist:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation): ArrayIteratorPrototype, MapIteratorPrototype, and StringIteratorPrototype's
        "next" properties are referenced by JSGlobalObject::init, and it causes reification of the lazy "next" property and structure
        transition anyway. So we should put it eagerly "without-transition" configuration to avoid one structure transition.

        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation): @@unscopable object's structure should be dictionary because (1) it is used as a dictionary
        in with-scope-resolution and (2) since with-scope-resolution is C++ runtime function anyway, non-dictionary structure does not add
        any performance benefit. This change saves several structures that are not useful.

        * runtime/ClonedArguments.cpp:
        (JSC::ClonedArguments::createStructure): Bake CloneArguments's structure with 'without-transition' manner.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Previously we are always call resetProtoype at the end of JSGlobalObject::init. But it is not necessary
        since we do not change [[Prototype]] of JSGlobalObject. All we want is (1) fixupPrototypeChainWithObjectPrototype's operation and (2) setGlobalThis
        operation. Since setGlobalThis part is done in JSGlobalObject::finishCreation, fixupPrototypeChainWithObjectPrototype is only the thing
        we should do here.

        (JSC::JSGlobalObject::fixupPrototypeChainWithObjectPrototype):
        (JSC::JSGlobalObject::resetPrototype): If the [[Prototype]] is the same to the current [[Prototype]], we can skip the operation.

        * runtime/JSGlobalObject.h:
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        * runtime/NullGetterFunction.h:
        * runtime/NullSetterFunction.h: Since structures of them are allocated per JSGlobalObject and they are per-JSGlobalObject,
        we can use without-transition property addition.

        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::setIteratorStructureSlow):
        (JSC::VM::mapIteratorStructureSlow): These structures are only used in WebCore's main thread.
        * runtime/VM.h:
        (JSC::VM::setIteratorStructure):
        (JSC::VM::mapIteratorStructure):

2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] BuiltinExecutables should behave like a WeakSet instead of generic WeakHandleOwner for memory footprint
        https://bugs.webkit.org/show_bug.cgi?id=195508

        Reviewed by Darin Adler.

        Weak<> is not cheap in terms of memory footprint. We allocate WeakBlock (256 bytes) for book-keeping Weak<>.
        Currently BuiltinExecutables has 203 Weak<> members and many WeakBlocks are actually allocated because
        many UnlinkedFunctionExecutables in BuiltinExecutables are allocated during JSGlobalObject initialization process.

        This patch changes two things in BuiltinExecutables.

        1. Previously we have m_xxxSourceCode fields too. But we do not need to keep it since we know how to produce it when it is required.
           We generate SourceCode in xxxSourceCode() method instead of just returning m_xxxSourceCode. This reduces sizeof(BuiltinExecutables) 24 x 203 = 4KB.

        2. Instead of using Weak<>, BuiltinExecutables holds raw array of UnlinkedFunctionExecutable*. And Heap::finalizeUnconditionalFinalizers() correctly clears dead executables.
           This is similar to JSWeakSet implementation. And it saves WeakBlock allocations.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::BuiltinExecutables):
        (JSC::BuiltinExecutables::finalizeUnconditionally):
        (JSC::JSC_FOREACH_BUILTIN_CODE): Deleted.
        (JSC::BuiltinExecutables::finalize): Deleted.
        * builtins/BuiltinExecutables.h:
        (JSC::BuiltinExecutables::static_cast<unsigned>):
        (): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):

2019-03-11  Robin Morisset  <rmorisset@apple.com>

        IntlDateTimeFormat can be shrunk by 32 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195504

        Reviewed by Darin Adler.

        * runtime/IntlDateTimeFormat.h:

2019-03-11  Robin Morisset  <rmorisset@apple.com>

        IntlCollator can be shrunk by 16 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195503

        Reviewed by Darin Adler.

        * runtime/IntlCollator.h:

2019-03-11  Robin Morisset  <rmorisset@apple.com>

        IntlNumberFormat can be shrunk by 16 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195505

        Reviewed by Darin Adler.

        * runtime/IntlNumberFormat.h:

2019-03-11  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Implement "~" unary operation
        https://bugs.webkit.org/show_bug.cgi?id=182216

        Reviewed by Keith Miller.

        This patch is adding support of BigInt into op_bitnot operations. In
        addition, we are changing ArithBitNot to handle only Number operands,
        while introducing a new node named ValueBitNot to handle Untyped and
        BigInt. This node follows the same approach we are doing into other
        arithimetic operations into DFG.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

        It is possible that fixup and prediction propagation don't convert a
        ValueBitNot(ConstInt32) into ArithBitNot(ConstInt32) because these
        analysis are conservative. In such case, we are adding constant
        folding rules to ValueBitNot AI.

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):

        ValueBitNot has same rules as ArithBitNot on backwards propagation.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

        We can emit ArithBitNot if we know that operand of op_bitnot is a
        Number or any int. Otherwise we fallback to ValueBitNot and rely on
        fixup to convert the node to ArithBitNot when it is possible.
        ValueBitNot uses heap prediction on prediction propagation and we
        collect its type from op_bitnot's value profiler.

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

        When we have the case with ValueBitNot(BigInt), we don't clobberize
        world.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

        ValueBitNot can GC on BigIntUse because, right now, all bitNot
        operation allocates temporary BigInts to perform calculations and it
        can potentially trigger GC.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

        ValueBitNot is responsible do handle BigIntUse and UntypedUse. To all
        other uses, we fallback to ArithBitNot.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::bitwiseBinaryOp):

        This template function is abstracting the new semantics of numeric
        values operations on bitwise operations. These operations usually
        folow these steps:

            1. rhsNumeric = GetInt32OrBigInt(rhs)
            2. lhsNumeric = GetInt32OrBigInt(lhs)
            3. trhow error if TypeOf(rhsNumeric) != TypeOf(lhsNumeric)
            4. return BigInt::bitwiseOp(bitOp, rhs, lhs) if TypeOf(lhsNumeric) == BigInt
            5. return rhs <int32BitOp> lhs

        Since we have almost the same code for every bitwise op,
        we use such template to avoid code duplication. The template receives
        Int32 and BigInt operations as parameter. Error message is received as
        `const char*` instead of `String&` to avoid String allocation even when
        there is no error to throw.

        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueBitNot):

        ValueBitNot generates speculative code for BigIntUse and this code is a
        call to `operationBitNotBigInt`. This operation is faster than
        `operationValueBitNot` because there is no need to check types of
        operands and execute properly operation. We still need to check
        exceptions after `operationBitNotBigInt` because it can throw OOM.

        (JSC::DFG::SpeculativeJIT::compileBitwiseNot):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::bitwiseNot):
        * runtime/JSBigInt.h:

2019-03-11  Darin Adler  <darin@apple.com>

        Specify fixed precision explicitly to prepare to change String::number and StringBuilder::appendNumber floating point behavior
        https://bugs.webkit.org/show_bug.cgi?id=195533

        Reviewed by Brent Fulgham.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testExecutionTimeLimit): Use appendFixedPrecisionNumber.
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToPrecision): Use numberToStringFixedPrecision.
        * runtime/Options.cpp:
        (JSC::Option::dump const): Use appendFixedPrecisionNumber.

2019-03-10  Ross Kirsling  <ross.kirsling@sony.com>

        Invalid flags in a RegExp literal should be an early SyntaxError
        https://bugs.webkit.org/show_bug.cgi?id=195514

        Reviewed by Darin Adler.

        Currently we're throwing a *runtime* SyntaxError; this should occur at parse time. 

          12.2.8.1 Static Semantics: Early Errors
            PrimaryExpression : RegularExpressionLiteral
              - It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized
                using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
              - It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points
                other than "g", "i", "m",  "s", "u", or "y", or if it contains the same code point more than once.

        In fixing this, let's also move flag handling from runtime/ to yarr/.

        * yarr/YarrSyntaxChecker.cpp:
        (JSC::Yarr::checkSyntax):
        Check flags before checking pattern.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::RegExpNode::emitBytecode):
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        * runtime/CachedTypes.cpp:
        * runtime/RegExp.cpp:
        (JSC::RegExp::RegExp):
        (JSC::RegExp::createWithoutCaching):
        (JSC::RegExp::create):
        (JSC::regExpFlags): Deleted.
        * runtime/RegExp.h:
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::lookupOrCreate):
        (JSC::RegExpCache::ensureEmptyRegExpSlow):
        * runtime/RegExpCache.h:
        * runtime/RegExpConstructor.cpp:
        (JSC::toFlags):
        (JSC::regExpCreate):
        (JSC::constructRegExp):
        * runtime/RegExpKey.h:
        (JSC::RegExpKey::RegExpKey):
        (WTF::HashTraits<JSC::RegExpKey>::constructDeletedValue):
        (WTF::HashTraits<JSC::RegExpKey>::isDeletedValue):
        (): Deleted.
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        * testRegExp.cpp:
        (parseRegExpLine):
        * yarr/RegularExpression.cpp:
        (JSC::Yarr::RegularExpression::Private::compile):
        * yarr/YarrFlags.cpp: Added.
        (JSC::Yarr::parseFlags):
        * yarr/YarrFlags.h: Added.
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::ignoreCase const):
        (JSC::Yarr::BytecodePattern::multiline const):
        (JSC::Yarr::BytecodePattern::sticky const):
        (JSC::Yarr::BytecodePattern::unicode const):
        (JSC::Yarr::BytecodePattern::dotAll const):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPattern::compile):
        (JSC::Yarr::YarrPattern::YarrPattern):
        (JSC::Yarr::YarrPattern::dumpPattern):
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::global const):
        (JSC::Yarr::YarrPattern::ignoreCase const):
        (JSC::Yarr::YarrPattern::multiline const):
        (JSC::Yarr::YarrPattern::sticky const):
        (JSC::Yarr::YarrPattern::unicode const):
        (JSC::Yarr::YarrPattern::dotAll const):
        Move flag handling to Yarr and modernize API.

2019-03-09  Robin Morisset  <rmorisset@apple.com>

        Compilation can be shrunk by 8 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195500

        Reviewed by Mark Lam.

        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::Compilation):
        * profiler/ProfilerCompilation.h:

2019-03-09  Robin Morisset  <rmorisset@apple.com>

        BinarySwitch can be shrunk by 8 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195493

        Reviewed by Mark Lam.

        * jit/BinarySwitch.cpp:
        (JSC::BinarySwitch::BinarySwitch):
        * jit/BinarySwitch.h:

2019-03-09  Robin Morisset  <rmorisset@apple.com>

        AsyncStackTrace can be shrunk by 8 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195491

        Reviewed by Mark Lam.

        * inspector/AsyncStackTrace.h:

2019-03-08  Mark Lam  <mark.lam@apple.com>

        Stack overflow crash in JSC::JSObject::hasInstance.
        https://bugs.webkit.org/show_bug.cgi?id=195458
        <rdar://problem/48710195>

        Reviewed by Yusuke Suzuki.

        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):

2019-03-08  Robin Morisset  <rmorisset@apple.com>

        IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195487

        Reviewed by Saam Barati.

        * dfg/DFGIntegerCheckCombiningPhase.cpp:

2019-03-08  Robin Morisset  <rmorisset@apple.com>

        TypeLocation can be shrunk by 8 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195483

        Reviewed by Mark Lam.

        * bytecode/TypeLocation.h:
        (JSC::TypeLocation::TypeLocation):

2019-03-08  Robin Morisset  <rmorisset@apple.com>

        GetByIdStatus can be shrunk by 16 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195480

        Reviewed by Saam Barati.

        8 bytes from reordering fields
        8 more bytes by making the enum State only use 1 byte.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::GetByIdStatus):
        * bytecode/GetByIdStatus.h:

2019-03-08  Robin Morisset  <rmorisset@apple.com>

        PutByIdVariant can be shrunk by 8 bytes
        https://bugs.webkit.org/show_bug.cgi?id=195482

        Reviewed by Mark Lam.

        * bytecode/PutByIdVariant.h:
        (JSC::PutByIdVariant::PutByIdVariant):

2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, follow-up after r242568

        Robin pointed that calculation of `numberOfChildren` and `nonEmptyIndex` is unnecessary.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
        https://bugs.webkit.org/show_bug.cgi?id=195447

        Reviewed by Filip Pizlo.

        This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
        caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
        To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
        to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
        to use `putDirectWithoutTransition` instead of `putDirect`.

        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
        * runtime/ArrayConstructor.cpp:
        (JSC::ArrayConstructor::finishCreation):
        * runtime/AsyncFunctionConstructor.cpp:
        (JSC::AsyncFunctionConstructor::finishCreation):
        * runtime/AsyncGeneratorFunctionConstructor.cpp:
        (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
        * runtime/BigIntConstructor.cpp:
        (JSC::BigIntConstructor::finishCreation):
        * runtime/BooleanConstructor.cpp:
        (JSC::BooleanConstructor::finishCreation):
        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::finishCreation):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::finishCreation):
        * runtime/FunctionConstructor.cpp:
        (JSC::FunctionConstructor::finishCreation):
        * runtime/FunctionPrototype.cpp:
        (JSC::FunctionPrototype::finishCreation):
        (JSC::FunctionPrototype::addFunctionProperties):
        (JSC::FunctionPrototype::initRestrictedProperties):
        * runtime/FunctionPrototype.h:
        * runtime/GeneratorFunctionConstructor.cpp:
        (JSC::GeneratorFunctionConstructor::finishCreation):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::finishCreation):
        * runtime/InternalFunction.h:
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructor::finishCreation):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructor::finishCreation):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructor::finishCreation):
        * runtime/IntlPluralRulesConstructor.cpp:
        (JSC::IntlPluralRulesConstructor::finishCreation):
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
        (JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):
        * runtime/JSObject.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::finishCreation):
        * runtime/JSTypedArrayViewConstructor.cpp:
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/MapConstructor.cpp:
        (JSC::MapConstructor::finishCreation):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructorBase::finishCreation):
        * runtime/NullGetterFunction.h:
        * runtime/NullSetterFunction.h:
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        * runtime/ProxyConstructor.cpp:
        (JSC::ProxyConstructor::finishCreation):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        * runtime/SetConstructor.cpp:
        (JSC::SetConstructor::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/StringConstructor.cpp:
        (JSC::StringConstructor::finishCreation):
        * runtime/SymbolConstructor.cpp:
        (JSC::SymbolConstructor::finishCreation):
        * runtime/WeakMapConstructor.cpp:
        (JSC::WeakMapConstructor::finishCreation):
        * runtime/WeakSetConstructor.cpp:
        (JSC::WeakSetConstructor::finishCreation):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyInstanceConstructor.cpp:
        (JSC::WebAssemblyInstanceConstructor::finishCreation):
        * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
        (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::WebAssemblyMemoryConstructor::finishCreation):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::WebAssemblyModuleConstructor::finishCreation):
        * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
        (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::WebAssemblyTableConstructor::finishCreation):

2019-03-08  Tadeu Zagallo  <tzagallo@apple.com>

        op_check_tdz does not def its argument
        https://bugs.webkit.org/show_bug.cgi?id=192880
        <rdar://problem/46221598>

        Reviewed by Saam Barati.

        This prevented the for-in loop optimization in the bytecode generator, since
        the analysis sees a redefinition of the loop variable.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeDefsForBytecodeOffset):

2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Make more fields lazy in JSGlobalObject
        https://bugs.webkit.org/show_bug.cgi?id=195449

        Reviewed by Mark Lam.

        This patch makes more fields lazy-allocated in JSGlobalObject to save memory.

        1. Some minor structures like moduleRecordStructure.
        2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
        3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * runtime/JSArrayBufferPrototype.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::parseIntFunction const):
        (JSC::JSGlobalObject::parseFloatFunction const):
        (JSC::JSGlobalObject::evalFunction const):
        (JSC::JSGlobalObject::strictEvalActivationStructure const):
        (JSC::JSGlobalObject::moduleRecordStructure const):
        (JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
        (JSC::JSGlobalObject::proxyObjectStructure const):
        (JSC::JSGlobalObject::callableProxyObjectStructure const):
        (JSC::JSGlobalObject::proxyRevokeStructure const):
        (JSC::JSGlobalObject::arrayBufferConstructor const):
        (JSC::JSGlobalObject::arrayBufferPrototype const):
        (JSC::JSGlobalObject::arrayBufferStructure const):
        * runtime/ProxyObject.h:
        * runtime/StrictEvalActivation.cpp:
        (JSC::StrictEvalActivation::StrictEvalActivation):
        * runtime/StrictEvalActivation.h:
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::buffer):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::webAssemblyModuleCustomSections):

2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Remove merging must handle values into proven types in CFA
        https://bugs.webkit.org/show_bug.cgi?id=195444

        Reviewed by Saam Barati.

        Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
        from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.

            Block #2 (loop header) succ #3, #4
            ...
            1: ForceOSRExit
            ...
            2: JSConstant(0)
            3: SetLocal(@2, loc6)
            ...
            4: Branch(#3, #4)

            Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
            ...
            5: GetLocal(loc6)
            6: StringFromCharCode(@5)
            ...

        Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
        If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
        as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
        we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
        we should not merge it in CFA.

        Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
        progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.

        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::run):
        (JSC::DFG::CFAPhase::performBlockCFA):
        (JSC::DFG::CFAPhase::injectOSR): Deleted.

2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
        https://bugs.webkit.org/show_bug.cgi?id=195429

        Reviewed by Saam Barati.

        We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
        for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
        this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
        Note that ThunkGenerators's StringFromCharCode thunk was correct.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileFromCharCode):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):

2019-03-07  Mark Lam  <mark.lam@apple.com>

        Follow up refactoring in try-finally code after r242591.
        https://bugs.webkit.org/show_bug.cgi?id=195428

        Reviewed by Saam Barati.

        1. Added some comments in emitFinallyCompletion() to describe each completion case.
        2. Converted CatchEntry into a struct.
        3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
           to be more clear about its purpose.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        * bytecompiler/BytecodeGenerator.h:

2019-03-07  Saam Barati  <sbarati@apple.com>

        CompactVariableMap::Handle's copy operator= leaks the previous data
        https://bugs.webkit.org/show_bug.cgi?id=195398

        Reviewed by Yusuke Suzuki.

        The copy constructor was just assigning |this| to the new value,
        forgetting to decrement the ref count of the thing pointed to by
        the |this| handle. Based on Yusuke's suggestion, this patch refactors
        the move constructor, move operator=, and copy operator= to use the
        swap() primitive and the copy constructor primitive.

        * parser/VariableEnvironment.cpp:
        (JSC::CompactVariableMap::Handle::Handle):
        (JSC::CompactVariableMap::Handle::swap):
        (JSC::CompactVariableMap::Handle::operator=): Deleted.
        * parser/VariableEnvironment.h:
        (JSC::CompactVariableMap::Handle::Handle):
        (JSC::CompactVariableMap::Handle::operator=):

2019-03-07  Tadeu Zagallo  <tzagallo@apple.com>

        Lazily decode cached bytecode
        https://bugs.webkit.org/show_bug.cgi?id=194810

        Reviewed by Saam Barati.

        Like lazy parsing, we should pause at code block boundaries. Instead
        of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
        we store their offsets in the executable and lazily decode them on the next
        call to `unlinkedCodeBlockFor`.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::visitChildren):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
        * bytecode/UnlinkedFunctionExecutable.h:
        * runtime/CachedTypes.cpp:
        (JSC::Decoder::Decoder):
        (JSC::Decoder::~Decoder):
        (JSC::Decoder::create):
        (JSC::Decoder::offsetOf):
        (JSC::Decoder::cacheOffset):
        (JSC::Decoder::ptrForOffsetFromBase):
        (JSC::Decoder::handleForEnvironment const):
        (JSC::Decoder::setHandleForEnvironment):
        (JSC::Decoder::addFinalizer):
        (JSC::VariableLengthObject::isEmpty const):
        (JSC::CachedWriteBarrier::isEmpty const):
        (JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
        (JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
        (JSC::CachedFunctionExecutable::decode const):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::decodeCodeBlockImpl):
        (JSC::isCachedBytecodeStillValid):
        (JSC::decodeFunctionCodeBlock):
        * runtime/CachedTypes.h:
        (JSC::Decoder::vm):

2019-03-06  Mark Lam  <mark.lam@apple.com>

        Exception is a JSCell, not a JSObject.
        https://bugs.webkit.org/show_bug.cgi?id=195392

        Reviewed by Saam Barati.

        Exception is a VM implementation construct to carry a stack trace for the point
        where it is thrown from.  As a reminder, an Exception is needed because:
        1. JS code can throw primitives as well that are non-cells.
        2. Error objects capture the stack trace at the point where they are constructed,
           which is not always the same as the point where they are thrown (if they are
           thrown).

        Hence, Exception should not be visible to JS code, and therefore should not be a
        JSObject.  Hence, it should not inherit from JSDestructibleObject.

        This patch changes the following:

        1. Exception now inherits directly from JSCell instead.

        2. Places where we return an Exception masquerading as a JSObject* are now
           updated to return a nullptr when we encounter an exception.

        3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
           exception in functions that return JSValue or EncodedJSValue.  This is because
           the number that implements the following pattern is too numerous:

                return throw<Some Error>(...)

           We'll leave these as is for now.

        * bytecode/CodeBlock.h:
        (JSC::ScriptExecutable::prepareForExecution):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeModuleProgram):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/Error.cpp:
        (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
        (JSC::throwTypeError):
        (JSC::throwSyntaxError):
        * runtime/Error.h:
        (JSC::throwRangeError):
        * runtime/Exception.cpp:
        (JSC::Exception::createStructure):
        * runtime/Exception.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::throwOutOfMemoryError):
        (JSC::throwStackOverflowError):
        (JSC::throwTerminatedExecutionException):
        * runtime/ExceptionHelpers.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/IntlPluralRules.cpp:
        (JSC::IntlPluralRules::resolvedOptions):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        * runtime/JSObject.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/RegExpConstructor.cpp:
        (JSC::regExpCreate):
        (JSC::constructRegExp):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        * runtime/ScriptExecutable.h:
        * runtime/ThrowScope.cpp:
        (JSC::ThrowScope::throwException):
        * runtime/ThrowScope.h:
        (JSC::ThrowScope::throwException):
        (JSC::throwException):
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/VM.h:

2019-03-06  Ross Kirsling  <ross.kirsling@sony.com>

        [Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
        https://bugs.webkit.org/show_bug.cgi?id=195346

        Reviewed by Fujii Hironori.

        * jsc.cpp:
        (currentWorkingDirectory):
        (fetchModuleFromLocalFileSystem):
        * runtime/DateConversion.cpp:
        (JSC::formatDateTime):
        Use wchar helpers as needed.

2019-03-06  Mark Lam  <mark.lam@apple.com>

        Fix incorrect handling of try-finally completion values.
        https://bugs.webkit.org/show_bug.cgi?id=195131
        <rdar://problem/46222079>

        Reviewed by Saam Barati and Yusuke Suzuki.

        Consider the following:

            function foo() {                        // line 1
                try {
                    return 42;                      // line 3
                } finally {
                    for (var j = 0; j < 1; j++) {   // line 5
                        try {
                            throw '';               // line 7
                        } finally {
                            continue;               // line 9
                        }
                    }
                }                                   // line 11
            }
            var result = foo();

        With the current (before fix) code base, result will be the exception object thrown
        at line 7.  The expected result should be 42, returned at line 3.

        The bug is that we were previously only using one set of completion type and
        value registers for the entire function.  This is inadequate because the outer
        try-finally needs to preserve its own completion type and value ({ Return, 42 }
        in this case) in order to be able to complete correctly.

        One might be deceived into thinking that the above example should complete with
        the exception thrown at line 7.  However, according to Section 13.15.8 of the
        ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
        completion.  As a result, it overrides the throw from line 7.  After the continue,
        execution resumes at the top of the loop at line 5, followed by a normal completion
        at line 11.

        Also according to Section 13.15.8, given that the completion type of the outer
        finally is normal, the resultant completion of the outer try-finally should be
        the completion of the outer try block i.e. { Return, 42 }.

        This patch makes the following changes:
        
        1. Fix handling of finally completion to use a unique set of completion
           type and value registers for each FinallyContext.

        2. Move the setting of Throw completion type to the out of line exception handler.
           This makes the mainline code slightly less branchy.

        3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
           emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
           bytecode inline.  Also, these make it clearer when we're emitting a handler
           for a catch vs a finally.

        4. Allocate the FinallyContext on the stack instead of as a member of the
           heap allocated ControlFlowScope.  This simplifies its life-cycle management
           and reduces the amount of needed copying.

        5. Update emitFinallyCompletion() to propagate the completion type and value to
           the outer FinallyContext when needed.

        6. Fix emitJumpIf() to use the right order of operands.  Previously, we were
           only using it to do op_stricteq and op_nstricteq comparisons.  So, the order
           wasn't important.  We now use it to also do op_beloweq comparisons.  Hence,
           the order needs to be corrected.

        7. Remove the unused CompletionType::Break and Continue.  These are encoded with
           the jumpIDs of the jump targets instead.

        Relevant specifications:
        Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
        Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::FinallyContext::FinallyContext):
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
        (JSC::BytecodeGenerator::popFinallyControlFlowScope):
        (JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
        (JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
        (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        (JSC::BytecodeGenerator::emitJumpIf):
        (JSC::BytecodeGenerator::emitCatch): Deleted.
        (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
        (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::FinallyContext::completionTypeRegister const):
        (JSC::FinallyContext::completionValueRegister const):
        (JSC::ControlFlowScope::ControlFlowScope):
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
        (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
        (JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
        (JSC::BytecodeGenerator::completionValueRegister const): Deleted.
        (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
        (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::TryNode::emitBytecode):

2019-03-06  Saam Barati  <sbarati@apple.com>

        JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
        https://bugs.webkit.org/show_bug.cgi?id=195186

        Reviewed by Keith Miller.

        This patch makes it so that JSScript will keep its bytecode cache file
        locked as long as the JSScript is alive. This makes it obvious that it's
        safe to update that file, as it will only be used in a single VM, across
        all processes, at a single time. We may be able to extend this in the future
        if we can atomically update it across VMs/processes. However, we're choosing
        more restricted semantics now as it's always easier to extend these semantics
        in the future opposed to having to support the more flexible behavior
        up front.
        
        This patch also:
        - Adds error messages if writing the cache fails. We don't expect this to
          fail, but previously we would say we cached it even if write() fails.
        - Removes the unused m_moduleKey field.
        - Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
          In the future, we should extend this to just fill in the parts of the cache
          that are not present. But we don't have the ability to do that yet, so we
          just result in an error for now.

        * API/JSScript.mm:
        (-[JSScript dealloc]):
        (-[JSScript readCache]):
        (-[JSScript init]):
        (-[JSScript writeCache:]):
        * API/JSScriptInternal.h:
        * API/tests/testapi.mm:
        (testCacheFileIsExclusive):
        (testCacheFileFailsWhenItsAlreadyCached):
        (testObjectiveCAPI):

2019-03-06  Christopher Reid  <chris.reid@sony.com>

        Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
        https://bugs.webkit.org/show_bug.cgi?id=195381

        Reviewed by Mark Lam.

        Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
        Also using `= { }` for struct initialization instead of memeset.

        * inspector/remote/RemoteConnectionToTarget.cpp:
        * inspector/remote/RemoteInspector.cpp:
        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
        * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
        * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        * inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
        * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
        * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
        * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:

2019-03-06  Saam Barati  <sbarati@apple.com>

        Air::reportUsedRegisters must padInterference
        https://bugs.webkit.org/show_bug.cgi?id=195303
        <rdar://problem/48270343>

        Reviewed by Keith Miller.

        reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
        registers. However, liveness can report incorrect results in certain 
        scenarios when considering liveness at instruction boundaries. For example,
        it can go wrong when an Inst has a LateUse of a register and the following
        Inst has an EarlyDef of that same register. Such a scenario could lead us
        to incorrectly say the register is not live-in to the first Inst. Pad
        interference inserts Nops between such instruction boundaries that cause
        this issue.
        
        The test with this patch fixes the issue in reportUsedRegisters. This patch
        also conservatively makes it so that lowerAfterRegAlloc calls padInterference
        since it also reasons about liveness.

        * b3/air/AirLowerAfterRegAlloc.cpp:
        (JSC::B3::Air::lowerAfterRegAlloc):
        * b3/air/AirPadInterference.h:
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters):
        * b3/testb3.cpp:
        (JSC::B3::testReportUsedRegistersLateUseNotDead):
        (JSC::B3::run):

2019-03-06  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] AI should not propagate AbstractValue relying on constant folding phase
        https://bugs.webkit.org/show_bug.cgi?id=195375

        Reviewed by Saam Barati.

        MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
        This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
        and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
        proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
        at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
        relying on constant folding phase.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2019-03-05  Saam barati  <sbarati@apple.com>

        op_switch_char broken for rope strings after JSRopeString layout rewrite
        https://bugs.webkit.org/show_bug.cgi?id=195339
        <rdar://problem/48592545>

        Reviewed by Yusuke Suzuki.

        When we did the JSString rewrite, we accidentally broke LLInt's switch_char
        for rope strings. That change made it so that we always go to the slow path
        for ropes. That's wrong. The slow path should only be taken when the rope
        is of length 1. For lengths other than 1, we need to fall through to the
        default case. This patch fixes this.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSString.h:

2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Should check exception for JSString::toExistingAtomicString
        https://bugs.webkit.org/show_bug.cgi?id=195337

        Reviewed by Keith Miller, Saam Barati, and Mark Lam.

        We missed the exception check for JSString::toExistingAtomicString while it can resolve
        a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
        fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getByVal):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, build fix for debug builds after r242397

        * runtime/JSString.h:

2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Store bits for JSRopeString in 3 stores
        https://bugs.webkit.org/show_bug.cgi?id=195234

        Reviewed by Saam Barati.

        This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
        Previously, we store some part of data separately. Instead, this patch calculates
        the data first by bit operations and store calculated data with fewer stores.

        This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
        of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
        we can put them into the lower 3 bits, they are always empty due to alignment.

        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::canBeRope):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
        (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
        * runtime/JSString.cpp:
        (JSC::JSString::visitChildren):
        * runtime/JSString.h:
        (JSC::JSString::is8Bit const):
        (JSC::JSString::isSubstring const):
        * tools/JSDollarVM.cpp:
        (JSC::functionCreateNullRopeString):
        (JSC::JSDollarVM::finishCreation):

2019-03-04  Joseph Pecoraro  <pecoraro@apple.com>

        ITMLKit Inspector: Data Bindings / Associated Data for nodes
        https://bugs.webkit.org/show_bug.cgi?id=195290
        <rdar://problem/48304019>

        Reviewed by Devin Rousso.

        * inspector/protocol/DOM.json:

2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS
        https://bugs.webkit.org/show_bug.cgi?id=195250

        Reviewed by Saam Barati.

        By removing @Reflect from builtin JS, we can make Reflect object allocation lazy.
        We move @ownKeys function from @Reflect to @Object to remove @Reflect reference.

        We also remove m_intlObject field from JSGlobalObject since we no longer use it.

        * builtins/BuiltinNames.h:
        * builtins/GlobalOperations.js:
        (globalPrivate.copyDataProperties):
        (globalPrivate.copyDataPropertiesNoExclusions):
        * runtime/JSGlobalObject.cpp:
        (JSC::createReflectProperty):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructor::finishCreation):
        (JSC::objectConstructorOwnKeys):
        * runtime/ReflectObject.cpp:
        (JSC::ReflectObject::finishCreation):

2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Offer @makeTypeError instead of exposing @TypeError
        https://bugs.webkit.org/show_bug.cgi?id=193858

        Reviewed by Mark Lam.

        Instead of exposing @TypeError, we expose @makeTypeError function.
        And we make TypeError and Error lazily-allocated objects in non JIT environment.
        In JIT environment, only TypeError becomes lazily-allocated since WebAssembly errors
        touch Error prototype anyway. But we can make them lazy in a subsequent patch.

        * builtins/AsyncFromSyncIteratorPrototype.js:
        * builtins/AsyncGeneratorPrototype.js:
        (globalPrivate.asyncGeneratorEnqueue):
        * builtins/BuiltinNames.h:
        * builtins/PromiseOperations.js:
        (globalPrivate.createResolvingFunctions.resolve):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::initializeErrorConstructor):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::errorPrototype const):
        (JSC::JSGlobalObject::errorStructure const):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncMakeTypeError):
        * runtime/JSGlobalObjectFunctions.h:

2019-03-04  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLib] Returning G_TYPE_OBJECT from a constructor does not work
        https://bugs.webkit.org/show_bug.cgi?id=195206

        Reviewed by Žan Doberšek.

        We are freeing the newly created object before returning from the constructor.

        * API/glib/JSCCallbackFunction.cpp:
        (JSC::JSCCallbackFunction::construct):

2019-03-02  Darin Adler  <darin@apple.com>

        Retire legacy dtoa function and DecimalNumber class
        https://bugs.webkit.org/show_bug.cgi?id=195253

        Reviewed by Daniel Bates.

        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToExponential): Removed dependency on NumberToStringBufferLength,
        using NumberToStringBuffer instead. Also tweaked style of implementation a bit.

2019-03-01  Darin Adler  <darin@apple.com>

        Finish removing String::format
        https://bugs.webkit.org/show_bug.cgi?id=194893

        Reviewed by Daniel Bates.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
        using the new "pad" function.

2019-03-01  Christopher Reid  <chris.reid@sony.com>

        [PlayStation] Upstream playstation's remote inspector server
        https://bugs.webkit.org/show_bug.cgi?id=193806

        Reviewed by Joseph Pecoraro.

        Upstreaming PlayStation's Remote Inspector implementation.
        It is using a JSON RPC protocol over TCP sockets.
        This inspector implementation is planned to also support running on a WinCairo Client and Server.

        * PlatformPlayStation.cmake:
        * SourcesGTK.txt:
        * SourcesWPE.txt:
        * inspector/remote/RemoteConnectionToTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/glib/RemoteConnectionToTargetGlib.cpp.
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/playstation/RemoteInspectorConnectionClient.h: Added.
        * inspector/remote/playstation/RemoteInspectorConnectionClientPlayStation.cpp: Added.
        * inspector/remote/playstation/RemoteInspectorMessageParser.h: Added.
        * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp: Added.
        * inspector/remote/playstation/RemoteInspectorPlayStation.cpp: Added.
        * inspector/remote/playstation/RemoteInspectorServer.h: Added.
        * inspector/remote/playstation/RemoteInspectorServerPlayStation.cpp: Added.
        * inspector/remote/playstation/RemoteInspectorSocket.h: Added.
        * inspector/remote/playstation/RemoteInspectorSocketClient.h: Added.
        * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Added.
        * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Added.
        * inspector/remote/playstation/RemoteInspectorSocketServer.h: Added.
        * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Added.

2019-03-01  Saam Barati  <sbarati@apple.com>

        Create SPI to crash if a JSC VM is created
        https://bugs.webkit.org/show_bug.cgi?id=195231
        <rdar://problem/47717990>

        Reviewed by Mark Lam.

        * API/JSVirtualMachine.mm:
        (+[JSVirtualMachine setCrashOnVMCreation:]):
        * API/JSVirtualMachinePrivate.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::setCrashOnVMCreation):
        * runtime/VM.h:

2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Fix FTL build on ARM32_64 by adding stubs for JSRopeString::offsetOfXXX
        https://bugs.webkit.org/show_bug.cgi?id=195235

        Reviewed by Saam Barati.

        This is a workaround until https://bugs.webkit.org/show_bug.cgi?id=195234 is done.

        * runtime/JSString.h:

2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Use runtime calls for DFG MakeRope if !CPU(ADDRESS64)
        https://bugs.webkit.org/show_bug.cgi?id=195221

        Reviewed by Mark Lam.

        ARM32_64 builds DFG 64bit, but the size of address is 32bit. Make DFG MakeRope a runtime call not only for DFG 32_64,
        but also DFG 64 with !CPU(ADDRESS64). This patch unifies compileMakeRope again, and use a runtime call for !CPU(ADDRESS64).

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.

2019-03-01  Justin Fan  <justin_fan@apple.com>

        [Web GPU] 32-bit builds broken by attempt to disable WebGPU on 32-bit
        https://bugs.webkit.org/show_bug.cgi?id=195191

        Rubber-stamped by Dean Jackson.

        Dropping support for 32-bit entirely, so I'm intentionally leaving 32-bit broken.

        * Configurations/FeatureDefines.xcconfig:

2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>

        Fix debug builds with GCC
        https://bugs.webkit.org/show_bug.cgi?id=195205

        Unreviewed. Fix debug builds in GCC by removing
        the constexpr-keyword for this function.

        * runtime/CachedTypes.cpp:
        (JSC::tagFromSourceCodeType):

2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>

        [ARM] Fix assembler warnings in ctiMasmProbeTrampoline
        https://bugs.webkit.org/show_bug.cgi?id=195164

        Reviewed by Mark Lam.

        Short branches in IT blocks are deprecated in AArch32. In addition the
        the conditional branch was the only instruction in the IT block. Short
        branches are able to encode the condition code themselves, the additional
        IT instruction is not needed.

        The assembler was also warning that writing into APSR without a bitmask
        was deprecated. Therefore use APSR_nzcvq instead, this generates the same
        instruction encoding.

        * assembler/MacroAssemblerARMv7.cpp:

2019-02-28  Tadeu Zagallo  <tzagallo@apple.com>

        Remove CachedPtr::m_isEmpty and CachedOptional::m_isEmpty fields
        https://bugs.webkit.org/show_bug.cgi?id=194999

        Reviewed by Saam Barati.

        These fields are unnecessary, since we can just check that m_offset
        has not been initialized (I added VariableLengthObject::isEmpty for
        that). They also add 7-byte padding to these classes, which is pretty
        bad given how frequently CachedPtr is used.

        * runtime/CachedTypes.cpp:
        (JSC::CachedObject::operator new[]):
        (JSC::VariableLengthObject::allocate):
        (JSC::VariableLengthObject::isEmpty const):
        (JSC::CachedPtr::encode):
        (JSC::CachedPtr::decode const):
        (JSC::CachedPtr::get const):
        (JSC::CachedOptional::encode):
        (JSC::CachedOptional::decode const):
        (JSC::CachedOptional::decodeAsPtr const):

2019-02-28  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] sizeof(JSString) should be 16
        https://bugs.webkit.org/show_bug.cgi?id=194375

        Reviewed by Saam Barati.

        This patch reduces sizeof(JSString) from 24 to 16 to fit it into GC heap cell atom. And it also reduces sizeof(JSRopeString) from 48 to 32.
        Both classes cut 16 bytes per instance in GC allocation. This new layout is used in 64bit architectures which has little endianess.

        JSString no longer has length and flags directly. JSString has String, and we query information to this String instead of holding duplicate
        information in JSString. We embed isRope bit into this String's pointer so that we can convert JSRopeString to JSString in an atomic manner.
        We emit store-store fence before we put String pointer. This should exist even before this patch, so this patch also fixes one concurrency issue.

        The old JSRopeString separately had JSString* fibers along with String. In this patch, we merge the first JSString* fiber and String pointer
        storage into one to reduce the size of JSRopeString. JSRopeString has three pointer width storage. We pick 48bit effective address of JSString*
        fibers to compress three fibers + length + flags into three pointer width storage.

        In 64bit architecture, JSString and JSRopeString have the following memory layout to make sizeof(JSString) == 16 and sizeof(JSRopeString) == 32.
        JSString has only one pointer. We use it for String. length() and is8Bit() queries go to StringImpl. In JSRopeString, we reuse the above pointer
        place for the 1st fiber. JSRopeString has three fibers so its size is 48. To keep length and is8Bit flag information in JSRopeString, JSRopeString
        encodes these information into the fiber pointers. is8Bit flag is encoded in the 1st fiber pointer. length is embedded directly, and two fibers
        are compressed into 12bytes. isRope information is encoded in the first fiber's LSB.

        Since length of JSRopeString should be frequently accessed compared to each fiber, we put length in contiguous 32byte field, and compress 2nd
        and 3rd fibers into the following 80byte fields. One problem is that now 2nd and 3rd fibers are split. Storing and loading 2nd and 3rd fibers
        are not one pointer load operation. To make concurrent collector work correctly, we must initialize 2nd and 3rd fibers at JSRopeString creation
        and we must not modify these part later.

                     0                        8        10               16                       32                                     48
        JSString     [   ID      ][  header  ][   String pointer      0]
        JSRopeString [   ID      ][  header  ][ flags ][ 1st fiber    1][  length  ][2nd lower32][2nd upper16][3rd lower16][3rd upper32]
                                                                      ^
                                                                   isRope bit

        Since fibers in JSRopeString are not initialized in atomic pointer store manner, we must initialize all the fiber fields at JSRopeString creation.
        To achieve this, we modify our JSRopeString::RopeBuilder implementation not to create half-baked JSRopeString.

        This patch also makes an empty JSString singleton per VM. This makes evaluation of JSString in boolean context one pointer comparison. This is
        critical in this change since this patch enlarges the code necessary to get length from JSString in JIT. Without this guarantee, our code of boolean
        context evaluation is bloated. This patch hides all the JSString::create and JSRopeString::create in the private permission. JSString and JSRopeString
        creation is only allowed from jsString and related helper functions and they return a singleton empty JSString if the length is zero. We also change
        JSRopeString::RopeBuilder not to construct an empty JSRopeString.

        This patch is performance neutral in Speedometer2 and JetStream2. And it improves RAMification by 2.7%.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::storeZero16):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::storeZero16):
        (JSC::MacroAssemblerX86Common::store16):
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/InlineAccess.cpp:
        (JSC::InlineAccess::dumpCacheSizesAndCrash):
        (JSC::linkCodeInline):
        (JSC::InlineAccess::isCacheableStringLength):
        (JSC::InlineAccess::generateStringLength):
        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStringSlice):
        (JSC::DFG::SpeculativeJIT::compileToLowerCase):
        (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileStringEquality):
        (JSC::DFG::SpeculativeJIT::compileStringZeroLength):
        (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
        (JSC::DFG::SpeculativeJIT::emitStringBranch):
        (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
        (JSC::DFG::SpeculativeJIT::compileArraySlice):
        (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
        (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
        (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
        (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
        (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringToUntypedStrictEquality):
        (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
        (JSC::FTL::DFG::LowerDFGToB3::mapHashString):
        (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
        (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
        (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::switchString):
        (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
        (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitConvertValueToBoolean):
        (JSC::AssemblyHelpers::branchIfValue):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfRopeStringImpl):
        (JSC::AssemblyHelpers::branchIfNotRopeStringImpl):
        * jit/JITInlines.h:
        (JSC::JIT::emitLoadCharacterString):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * jit/ThunkGenerators.cpp:
        (JSC::stringGetByValGenerator):
        (JSC::stringCharLoad):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSString.cpp:
        (JSC::JSString::createEmptyString):
        (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
        (JSC::JSString::dumpToStream):
        (JSC::JSString::estimatedSize):
        (JSC::JSString::visitChildren):
        (JSC::JSRopeString::resolveRopeInternal8 const):
        (JSC::JSRopeString::resolveRopeInternal8NoSubstring const):
        (JSC::JSRopeString::resolveRopeInternal16 const):
        (JSC::JSRopeString::resolveRopeInternal16NoSubstring const):
        (JSC::JSRopeString::resolveRopeToAtomicString const):
        (JSC::JSRopeString::convertToNonRope const):
        (JSC::JSRopeString::resolveRopeToExistingAtomicString const):
        (JSC::JSRopeString::resolveRopeWithFunction const):
        (JSC::JSRopeString::resolveRope const):
        (JSC::JSRopeString::resolveRopeSlowCase8 const):
        (JSC::JSRopeString::resolveRopeSlowCase const):
        (JSC::JSRopeString::outOfMemory const):
        (JSC::JSRopeString::visitFibers): Deleted.
        (JSC::JSRopeString::clearFibers const): Deleted.
        * runtime/JSString.h:
        (JSC::JSString::uninitializedValueInternal const):
        (JSC::JSString::valueInternal const):
        (JSC::JSString::JSString):
        (JSC::JSString::finishCreation):
        (JSC::JSString::create):
        (JSC::JSString::offsetOfValue):
        (JSC::JSString::isRope const):
        (JSC::JSString::is8Bit const):
        (JSC::JSString::length const):
        (JSC::JSString::tryGetValueImpl const):
        (JSC::JSString::toAtomicString const):
        (JSC::JSString::toExistingAtomicString const):
        (JSC::JSString::value const):
        (JSC::JSString::tryGetValue const):
        (JSC::JSRopeString::unsafeView const):
        (JSC::JSRopeString::viewWithUnderlyingString const):
        (JSC::JSString::unsafeView const):
        (JSC::JSString::viewWithUnderlyingString const):
        (JSC::JSString::offsetOfLength): Deleted.
        (JSC::JSString::offsetOfFlags): Deleted.
        (JSC::JSString::setIs8Bit const): Deleted.
        (JSC::JSString::setLength): Deleted.
        (JSC::JSString::string): Deleted.
        (JSC::jsStringBuilder): Deleted.
        * runtime/JSStringInlines.h:
        (JSC::JSString::~JSString):
        (JSC::JSString::equal const):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):
        * runtime/RegExpObjectInlines.h:
        (JSC::collectMatches):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncSplitFast):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::initializeCommonStrings):
        (JSC::SmallStrings::createEmptyString): Deleted.
        * runtime/SmallStrings.h:
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncSlice):
        * runtime/StringPrototypeInlines.h: Added.
        (JSC::stringSlice):

2019-02-28  Saam barati  <sbarati@apple.com>

        Unreviewed. Attempt windows build fix after r242239.

        * runtime/CachedTypes.cpp:
        (JSC::tagFromSourceCodeType):

2019-02-28  Mark Lam  <mark.lam@apple.com>

        In cloop.rb, rename :int and :uint to :intptr and :uintptr.
        https://bugs.webkit.org/show_bug.cgi?id=195183

        Reviewed by Yusuke Suzuki.

        Also changed intMemRef and uintMemRef to intptrMemRef and uintptrMemRef respectively.

        * offlineasm/cloop.rb:

2019-02-28  Saam barati  <sbarati@apple.com>

        Make JSScript:cacheBytecodeWithError update the cache when the script changes
        https://bugs.webkit.org/show_bug.cgi?id=194912

        Reviewed by Mark Lam.

        Prior to this patch, the JSScript SPI would never check if its cached
        bytecode were still valid. This would lead the cacheBytecodeWithError
        succeeding even if the underlying cache were stale. This patch fixes
        that by making JSScript check if the cache is still valid. If it's not,
        we will cache bytecode when cacheBytecodeWithError is invoked.

        * API/JSScript.mm:
        (-[JSScript readCache]):
        (-[JSScript writeCache:]):
        * API/tests/testapi.mm:
        (testBytecodeCacheWithSameCacheFileAndDifferentScript):
        (testObjectiveCAPI):
        * runtime/CachedTypes.cpp:
        (JSC::Decoder::Decoder):
        (JSC::VariableLengthObject::buffer const):
        (JSC::CachedPtr::decode const):
        (JSC::tagFromSourceCodeType):
        (JSC::GenericCacheEntry::isUpToDate const):
        (JSC::CacheEntry::isStillValid const):
        (JSC::GenericCacheEntry::decode const):
        (JSC::GenericCacheEntry::isStillValid const):
        (JSC::encodeCodeBlock):
        (JSC::decodeCodeBlockImpl):
        (JSC::isCachedBytecodeStillValid):
        * runtime/CachedTypes.h:
        * runtime/CodeCache.cpp:
        (JSC::sourceCodeKeyForSerializedBytecode):
        (JSC::sourceCodeKeyForSerializedProgram):
        (JSC::sourceCodeKeyForSerializedModule):
        (JSC::serializeBytecode):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::fetchFromDiskImpl):
        * runtime/Completion.cpp:
        (JSC::generateProgramBytecode):
        (JSC::generateBytecode): Deleted.
        * runtime/Completion.h:

2019-02-28  Mark Lam  <mark.lam@apple.com>

        cloop.rb shift mask should depend on the word size being shifted.
        https://bugs.webkit.org/show_bug.cgi?id=195181
        <rdar://problem/48484164>

        Reviewed by Yusuke Suzuki.

        Previously, we're always masking the shift amount with 0x1f.  This is only correct
        for 32-bit words.  For 64-bit words, the mask should be 0x3f.  For pointer sized
        shifts, the mask depends on sizeof(uintptr_t).

        * offlineasm/cloop.rb:

2019-02-28  Justin Fan  <justin_fan@apple.com>

        [Web GPU] Enable Web GPU only on 64-bit
        https://bugs.webkit.org/show_bug.cgi?id=195139

        Because Metal is only supported on 64 bit apps.

        Unreviewed build fix.

        * Configurations/FeatureDefines.xcconfig:

2019-02-27  Mark Lam  <mark.lam@apple.com>

        The parser is failing to record the token location of new in new.target.
        https://bugs.webkit.org/show_bug.cgi?id=195127
        <rdar://problem/39645578>

        Reviewed by Yusuke Suzuki.

        Also adjust the token location for the following to be as shown:

            new.target
            ^
            super
            ^
            import.meta
            ^

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):

2019-02-27  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] mustHandleValues for dead bytecode locals should be ignored in DFG phases
        https://bugs.webkit.org/show_bug.cgi?id=195144
        <rdar://problem/47595961>

        Reviewed by Mark Lam.

        DFGMaximalFlushInsertionPhase inserts Flush for all the locals at the end of basic blocks. This enlarges the live ranges of
        locals in DFG, and it sometimes makes DFG value live while it is dead in bytecode. The issue happens when we use mustHandleValues
        to widen AbstractValue in CFAPhase. At that time, DFG tells "this value is live in DFG", but it may be dead in the bytecode level.
        At that time, we attempt to merge AbstractValue with dead mustHandleValue, which is cleared as jsUndefined() in
        DFG::Plan::cleanMustHandleValuesIfNecessary before start compilation, and crash because jsUndefined() may be irrelevant to the FlushFormat
        in VariableAccessData.

        This patch makes the type of mustHandleValues Operands<Optional<JSValue>>. We clear dead JSValues in DFG::Plan::cleanMustHandleValuesIfNecessary.
        And we skip handling dead mustHandleValue in DFG phases.

        * bytecode/Operands.h:
        (JSC::Operands::isLocal const):
        (JSC::Operands::isVariable const): Deleted.
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::injectOSR):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        (JSC::DFG::compile):
        * dfg/DFGDriver.h:
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::reconstruct):
        * dfg/DFGJITCode.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::checkLivenessAndVisitChildren):
        (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::mustHandleValues const):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * jit/JITOperations.cpp:

2019-02-27  Simon Fraser  <simon.fraser@apple.com>

        Roll out r242014; it caused crashes in compositing logging (webkit.org/b/195141)

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::nameForRegister):

2019-02-27  Robin Morisset  <rmorisset@apple.com>

        DFG: Loop-invariant code motion (LICM) should not hoist dead code
        https://bugs.webkit.org/show_bug.cgi?id=194945
        <rdar://problem/48311657>

        Reviewed by Saam Barati.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):

2019-02-27  Antoine Quint  <graouts@apple.com>

        Support Pointer Events on macOS
        https://bugs.webkit.org/show_bug.cgi?id=195008
        <rdar://problem/47454419>

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig:

2019-02-26  Mark Lam  <mark.lam@apple.com>

        Remove poisons in JSCPoison and uses of them.
        https://bugs.webkit.org/show_bug.cgi?id=195082

        Reviewed by Yusuke Suzuki.

        Also removed unused poisoning code in WriteBarrier, AssemblyHelpers,
        DFG::SpeculativeJIT, FTLLowerDFGToB3, and FTL::Output.

        * API/JSAPIWrapperObject.h:
        (JSC::JSAPIWrapperObject::wrappedObject):
        * API/JSCallbackFunction.h:
        * API/JSCallbackObject.h:
        * API/glib/JSAPIWrapperGlobalObject.h:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateWithGuard):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
        (JSC::DFG::SpeculativeJIT::compileGetExecutable):
        (JSC::DFG::SpeculativeJIT::compileCreateThis):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPoisonedPointer): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
        (JSC::FTL::DFG::LowerDFGToB3::dynamicPoison): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnLoadedType): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::dynamicPoisonOnType): Deleted.
        (JSC::FTL::DFG::LowerDFGToB3::weakPoisonedPointer): Deleted.
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::weakPoisonedPointer): Deleted.
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitDynamicPoison): Deleted.
        (JSC::AssemblyHelpers::emitDynamicPoisonOnLoadedType): Deleted.
        (JSC::AssemblyHelpers::emitDynamicPoisonOnType): Deleted.
        * jit/AssemblyHelpers.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_this):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitScopedArgumentsGetByVal):
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::nativeForGenerator):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * parser/UnlinkedSourceCode.h:
        * runtime/ArrayPrototype.h:
        * runtime/CustomGetterSetter.h:
        (JSC::CustomGetterSetter::getter const):
        (JSC::CustomGetterSetter::setter const):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::getCallData):
        (JSC::InternalFunction::getConstructData):
        * runtime/InternalFunction.h:
        (JSC::InternalFunction::nativeFunctionFor):
        * runtime/JSArrayBuffer.h:
        * runtime/JSBoundFunction.h:
        * runtime/JSCPoison.cpp: Removed.
        * runtime/JSCPoison.h: Removed.
        * runtime/JSFunction.h:
        * runtime/JSGlobalObject.h:
        * runtime/JSScriptFetchParameters.h:
        * runtime/JSScriptFetcher.h:
        * runtime/JSString.h:
        * runtime/NativeExecutable.cpp:
        (JSC::NativeExecutable::hashFor const):
        * runtime/NativeExecutable.h:
        * runtime/Options.h:
        * runtime/ScopedArguments.h:
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::setSingleTransition):
        * runtime/StructureTransitionTable.h:
        (JSC::StructureTransitionTable::map const):
        (JSC::StructureTransitionTable::weakImpl const):
        (JSC::StructureTransitionTable::setMap):
        * runtime/WriteBarrier.h:
        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmInstance.h:
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
        (JSC::JSWebAssemblyInstance::visitChildren):
        * wasm/js/JSWebAssemblyInstance.h:
        * wasm/js/JSWebAssemblyMemory.h:
        * wasm/js/JSWebAssemblyModule.h:
        * wasm/js/JSWebAssemblyTable.cpp:
        (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
        (JSC::JSWebAssemblyTable::grow):
        (JSC::JSWebAssemblyTable::clearFunction):
        * wasm/js/JSWebAssemblyTable.h:
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::materializeImportJSCell):
        (JSC::Wasm::handleBadI64Use):
        (JSC::Wasm::wasmToJS):
        * wasm/js/WebAssemblyFunctionBase.h:
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        (JSC::WebAssemblyModuleRecord::evaluate):
        * wasm/js/WebAssemblyModuleRecord.h:
        * wasm/js/WebAssemblyToJSCallee.h:
        * wasm/js/WebAssemblyWrapperFunction.h:

2019-02-26  Mark Lam  <mark.lam@apple.com>

        wasmToJS() should purify incoming NaNs.
        https://bugs.webkit.org/show_bug.cgi?id=194807
        <rdar://problem/48189132>

        Reviewed by Saam Barati.

        * runtime/JSCJSValue.h:
        (JSC::jsNumber):
        * runtime/TypedArrayAdaptors.h:
        (JSC::IntegralTypedArrayAdaptor::toJSValue):
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::wasmToJS):

2019-02-26  Dominik Infuehr  <dinfuehr@igalia.com>

        Fix warnings on ARM and MIPS
        https://bugs.webkit.org/show_bug.cgi?id=195049

        Reviewed by Mark Lam.

        Fix all warnings on ARM and MIPS.

        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printMemory):
        * assembler/testmasm.cpp:
        (JSC::testProbeModifiesStackValues):
        * bytecode/InByIdStatus.cpp:
        (JSC::InByIdStatus::computeFor):
        * runtime/CachedTypes.cpp:
        (JSC::VariableLengthObject::buffer const):
        * runtime/JSBigInt.h:
        * tools/JSDollarVM.cpp:
        (JSC::codeBlockFromArg):

2019-02-26  Mark Lam  <mark.lam@apple.com>

        Misc cleanup in StructureIDTable after r242096.
        https://bugs.webkit.org/show_bug.cgi?id=195063

        Reviewed by Saam Barati.

        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::allocateID):
        - RELEASE_ASSERT that the StructureID allocation will succeed.

        * runtime/StructureIDTable.h:
        (JSC::StructureIDTable::decode):
        (JSC::StructureIDTable::encode):
        - Add back a comment that Yusuke requested but was lost when the patch was rolled
          out and relanded.
        - Applied bitwise_casts that Saam requested.

2019-02-26  Mark Lam  <mark.lam@apple.com>

        Gardening: 32-bit build fix after r242096.
        https://bugs.webkit.org/show_bug.cgi?id=194989

        Not reviewed.

        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitLoadStructure):

2019-02-26  Mark Lam  <mark.lam@apple.com>

        Unpoison MacroAssemblerCodePtr, ClassInfo pointers, and a few other things.
        https://bugs.webkit.org/show_bug.cgi?id=195039

        Reviewed by Saam Barati.

        1. Unpoison MacroAssemblerCodePtrs, ReturnAddressPtr.
        2. Replace PoisonedClassInfoPtr with ClassInfo*.
        3. Replace PoisonedMasmPtr with const void*.
        4. Remove all references to CodeBlockPoison, JITCodePoison, and GlobalDataPoison.

        * API/JSCallbackObject.h:
        * API/JSObjectRef.cpp:
        (classInfoPrivate):
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::FunctionPtr::FunctionPtr):
        (JSC::FunctionPtr::executableAddress const):
        (JSC::FunctionPtr::retaggedExecutableAddress const):
        (JSC::ReturnAddressPtr::ReturnAddressPtr):
        (JSC::ReturnAddressPtr::value const):
        (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
        (JSC::MacroAssemblerCodePtr:: const):
        (JSC::MacroAssemblerCodePtr::operator! const):
        (JSC::MacroAssemblerCodePtr::operator== const):
        (JSC::MacroAssemblerCodePtr::hash const):
        (JSC::MacroAssemblerCodePtr::emptyValue):
        (JSC::MacroAssemblerCodePtr::deletedValue):
        (JSC::FunctionPtr<tag>::FunctionPtr):
        (JSC::MacroAssemblerCodePtr::poisonedPtr const): Deleted.
        * b3/B3LowerMacros.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testInterpreter):
        * dfg/DFGOSRExitCompilerCommon.h:
        (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        (JSC::DFG::SpeculativeJIT::emitSwitchImm):
        (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        (JSC::boundThisNoArgsFunctionCallGenerator):
        * runtime/JSCPoison.h:
        * runtime/JSDestructibleObject.h:
        (JSC::JSDestructibleObject::classInfo const):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::classInfo const):
        * runtime/Structure.h:
        * runtime/VM.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::addCall):
        (JSC::Wasm::B3IRGenerator::addCallIndirect):
        * wasm/WasmBinding.cpp:
        (JSC::Wasm::wasmToWasm):

2019-02-26  Mark Lam  <mark.lam@apple.com>

        [Re-landing] Add some randomness into the StructureID.
        https://bugs.webkit.org/show_bug.cgi?id=194989
        <rdar://problem/47975563>

        Reviewed by Yusuke Suzuki.

        1. On 64-bit, the StructureID will now be encoded as:

            ----------------------------------------------------------------
            | 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
            ----------------------------------------------------------------

           The entropy bits are chosen at random and assigned when a StructureID is
           allocated.

        2. Instead of Structure pointers, the StructureIDTable will now contain
           encodedStructureBits, which is encoded as such:

            ----------------------------------------------------------------
            | 7 entropy bits |                   57 structure pointer bits |
            ----------------------------------------------------------------

           The entropy bits here are the same 7 bits used in the encoding of the
           StructureID for this structure entry in the StructureIDTable.

        3. Retrieval of the structure pointer given a StructureID is now computed as
           follows:

                index = structureID >> 7; // with arithmetic shift.
                encodedStructureBits = structureIDTable[index];
                structure = encodedStructureBits ^ (structureID << 57);

            We use an arithmetic shift for the right shift because that will preserve
            the nuke bit in the high bit of the index if the StructureID was not
            decontaminated before use as expected.

        4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.

        5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
           instead of always being the same as m_capacity.

        6. Change StructureIDTable::s_unusedID's value to 0.

           Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
           StructureID on 64-bit.  Also, there was never any code that initializes unused
           IDs to the s_unusedID.  The only meaningful value for s_unusedID is 0, which
           is the ID we'll get when the freelist is empty, prompting a resize of the
           structureIDTable.

        This patch appears to be perf neutral on JetStream 2 run via the cli on a
        11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::loadStructure):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitLoadStructure):
        * jit/AssemblyHelpers.h:
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::StructureIDTable):
        (JSC::StructureIDTable::makeFreeListFromRange):
        (JSC::StructureIDTable::resize):
        (JSC::StructureIDTable::allocateID):
        (JSC::StructureIDTable::deallocateID):
        * runtime/StructureIDTable.h:
        (JSC::StructureIDTable::decode):
        (JSC::StructureIDTable::encode):
        (JSC::StructureIDTable::get):
        (JSC::StructureIDTable::isValid):

2019-02-26  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r242071.

        Breaks internal builds.

        Reverted changeset:

        "Add some randomness into the StructureID."
        https://bugs.webkit.org/show_bug.cgi?id=194989
        https://trac.webkit.org/changeset/242071

2019-02-26  Guillaume Emont  <guijemont@igalia.com>

        [JSC] Fix compilation on 32-bit platforms after r242071
        https://bugs.webkit.org/show_bug.cgi?id=195042

        Reviewed by Carlos Garcia Campos.

        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitLoadStructure):

2019-02-26  Guillaume Emont  <guijemont@igalia.com>

        [JSC] Repeat string created from Array.prototype.join() take too much memory
        https://bugs.webkit.org/show_bug.cgi?id=193912

        Reviewed by Saam Barati.

        Added a fast case in Array.prototype.join when the array is
        uninitialized.

        * runtime/ArrayPrototype.cpp:
        (JSC::canUseFastJoin):
        (JSC::fastJoin):
        * runtime/JSStringInlines.h:
        (JSC::repeatCharacter): moved from StringPrototype.cpp
        * runtime/StringPrototype.cpp:

2019-02-25  Mark Lam  <mark.lam@apple.com>

        Add some randomness into the StructureID.
        https://bugs.webkit.org/show_bug.cgi?id=194989
        <rdar://problem/47975563>

        Reviewed by Yusuke Suzuki.

        1. On 64-bit, the StructureID will now be encoded as:

            ----------------------------------------------------------------
            | 1 Nuke Bit | 24 StructureIDTable index bits | 7 entropy bits |
            ----------------------------------------------------------------

           The entropy bits are chosen at random and assigned when a StructureID is
           allocated.

        2. Instead of Structure pointers, the StructureIDTable will now contain
           encodedStructureBits, which is encoded as such:

            ----------------------------------------------------------------
            | 7 entropy bits |                   57 structure pointer bits |
            ----------------------------------------------------------------

           The entropy bits here are the same 7 bits used in the encoding of the
           StructureID for this structure entry in the StructureIDTable.

        3. Retrieval of the structure pointer given a StructureID is now computed as
           follows:

                index = structureID >> 7; // with arithmetic shift.
                encodedStructureBits = structureIDTable[index];
                structure = encodedStructureBits ^ (structureID << 57);

            We use an arithmetic shift for the right shift because that will preserve
            the nuke bit in the high bit of the index if the StructureID was not
            decontaminated before use as expected.

        4. Remove unused function loadArgumentWithSpecificClass() in SpecializedThunkJIT.

        5. Define StructureIDTable::m_size to be the number of allocated StructureIDs
           instead of always being the same as m_capacity.

        6. Change StructureIDTable::s_unusedID's value to 0.

           Its previous value of unusedPointer i.e. 0xd1e7beef, does not make sense for
           StructureID on 64-bit.  Also, there was never any code that initializes unused
           IDs to the s_unusedID.  The only meaningful value for s_unusedID is 0, which
           is the ID we'll get when the freelist is empty, prompting a resize of the
           structureIDTable.

        This patch appears to be perf neutral on JetStream 2 run via the cli on a
        11" MacBook Air, 13" MacBook Pro, iPhone 6S, and iPhone XR.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::loadStructure):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::appendJSCellOrAuxiliary):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitLoadStructure):
        * jit/AssemblyHelpers.h:
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): Deleted.
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::StructureIDTable):
        (JSC::StructureIDTable::makeFreeListFromRange):
        (JSC::StructureIDTable::resize):
        (JSC::StructureIDTable::allocateID):
        (JSC::StructureIDTable::deallocateID):
        * runtime/StructureIDTable.h:
        (JSC::StructureIDTable::decode):
        (JSC::StructureIDTable::encode):
        (JSC::StructureIDTable::get):
        (JSC::StructureIDTable::isValid):

2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Revert r226885 to make SlotVisitor creation lazy
        https://bugs.webkit.org/show_bug.cgi?id=195013

        Reviewed by Saam Barati.

        We once changed SlotVisitor creation apriori to drop the lock. Also, it turns out that SlotVisitor is memory-consuming.
        We should defer SlotVisitor creation until it is actually required. This patch reverts r226885. Even with this patch,
        we still hold many SlotVisitors after we execute many parallel markers at least once. But recovering the feature of
        dynamically allocating SlotVisitors helps further memory optimizations in this area.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::runBeginPhase):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::forEachSlotVisitor):
        (JSC::Heap::numberOfSlotVisitors):
        * heap/MarkingConstraintSolver.cpp:
        (JSC::MarkingConstraintSolver::didVisitSomething const):
        * heap/SlotVisitor.h:

2019-02-25  Saam Barati  <sbarati@apple.com>

        testb3 and testair should test O0/O1/O2
        https://bugs.webkit.org/show_bug.cgi?id=194637

        Reviewed by Mark Lam.

        This patch makes it so that we run all tests in testair and testb3
        in O0, O1, and O2. However, some tests are invalid for O0 and O1.
        This patch makes it so we only run those tests in O2. These are
        often tests that assert certain optimizations have occurred. There
        are also a class of tests that rely on using patchpoints to stress 
        the register allocator into only a single valid allocation. The
        O0, and sometimes O1, register allocators are not always good enough
        to allocate such programs. To make these valid allocators to use, we rely
        on the FTL and Wasm to not emit such patchpoints.

        * b3/air/testair.cpp:
        (main):
        * b3/testb3.cpp:
        (JSC::B3::compileProc):
        (JSC::B3::testAddLoadTwice):
        (JSC::B3::testMulLoadTwice):
        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
        (JSC::B3::testPatchpointWithEarlyClobber):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::testCheckFalse):
        (JSC::B3::testCheckTrue):
        (JSC::B3::testCheckLessThan):
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckTrickyMegaCombo):
        (JSC::B3::testCheckTwoMegaCombos):
        (JSC::B3::testCheckTwoNonRedundantMegaCombos):
        (JSC::B3::testCheckAddImm):
        (JSC::B3::testCheckAddImmCommute):
        (JSC::B3::testCheckAddImmSomeRegister):
        (JSC::B3::testCheckAdd):
        (JSC::B3::testCheckAdd64):
        (JSC::B3::testCheckAddFold):
        (JSC::B3::testCheckAddFoldFail):
        (JSC::B3::testCheckAddSelfOverflow64):
        (JSC::B3::testCheckAddSelfOverflow32):
        (JSC::B3::testCheckSubImm):
        (JSC::B3::testCheckSubBadImm):
        (JSC::B3::testCheckSub):
        (JSC::B3::testCheckSub64):
        (JSC::B3::testCheckSubFold):
        (JSC::B3::testCheckSubFoldFail):
        (JSC::B3::testCheckNeg):
        (JSC::B3::testCheckNeg64):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul2):
        (JSC::B3::testCheckMul64):
        (JSC::B3::testCheckMulFold):
        (JSC::B3::testCheckMulFoldFail):
        (JSC::B3::testCheckMul64SShr):
        (JSC::B3::testLinearScanWithCalleeOnStack):
        (JSC::B3::testCheckSelect):
        (JSC::B3::testCheckSelectCheckSelect):
        (JSC::B3::testCheckSelectAndCSE):
        (JSC::B3::testLateRegister):
        (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
        (JSC::B3::testSomeEarlyRegister):
        (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
        (JSC::B3::testPinRegisters):
        (JSC::B3::testX86LeaAddAddShlLeft):
        (JSC::B3::testX86LeaAddAddShlRight):
        (JSC::B3::testX86LeaAddAdd):
        (JSC::B3::testX86LeaAddShlRight):
        (JSC::B3::testX86LeaAddShlLeftScale1):
        (JSC::B3::testX86LeaAddShlLeftScale2):
        (JSC::B3::testX86LeaAddShlLeftScale4):
        (JSC::B3::testX86LeaAddShlLeftScale8):
        (JSC::B3::testLoadBaseIndexShift2):
        (JSC::B3::testOptimizeMaterialization):
        (JSC::B3::testLICMPure):
        (JSC::B3::testLICMPureSideExits):
        (JSC::B3::testLICMPureWritesPinned):
        (JSC::B3::testLICMPureWrites):
        (JSC::B3::testLICMReadsPinned):
        (JSC::B3::testLICMReads):
        (JSC::B3::testLICMPureNotBackwardsDominant):
        (JSC::B3::testLICMPureNotBackwardsDominantFoiledByChild):
        (JSC::B3::testLICMControlDependent):
        (JSC::B3::testLICMControlDependentNotBackwardsDominant):
        (JSC::B3::testLICMReadsWritesDifferentHeaps):
        (JSC::B3::testWasmBoundsCheck):
        (JSC::B3::run):
        (main):

2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] stress/function-constructor-reading-from-global-lexical-environment.js fails in 32bit arch
        https://bugs.webkit.org/show_bug.cgi?id=195030
        <rdar://problem/48385088>

        Reviewed by Saam Barati.

        While LLInt64 has checkTDZInGlobalPutToScopeIfNecessary for op_put_to_scope GlobalLexicalVar to check the value in the variable slot is not empty,
        this check is missing in LLInt32_64. Previously, this check was subsumed accidentally by the WatchpointSet check in GlobalLexicalVar in `notifyWrite`:
        because no "put" attempt succeeds here, the status WatchpointSet was ClearWatchpoint, we always go to the slow path, and we always throw the TDZ error
        before configuring the WatchpointSet in the slow path. But after r241862, WatchpointSet is not used under non-JIT configuration. This skips WatchpointSet
        check and LLInt32_64 starts failing tests because of lack of checkTDZInGlobalPutToScopeIfNecessary. This patch adds checkTDZInGlobalPutToScopeIfNecessary
        in LLInt32_64 too. This patch fixes the following four failing tests.

            stress/function-constructor-reading-from-global-lexical-environment.js.bytecode-cache
            stress/function-constructor-reading-from-global-lexical-environment.js.default
            stress/global-lexical-variable-tdz.js.bytecode-cache
            stress/global-lexical-variable-tdz.js.default

        * llint/LowLevelInterpreter32_64.asm:

2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Make Intl fields lazily-allocated
        https://bugs.webkit.org/show_bug.cgi?id=195022

        Reviewed by Mark Lam.

        This patch makes the following memory footprint optimization in IntlObject.

        1. Make IntlObject fields including Intl.Collator lazily-allocated because we already removed direct references from JS builtins to these constructors (@Collator etc.).

        2. Move LazyProperty<IntlObject, Structure> structures from IntlObject to JSGlobalObject. This makes sizeof(IntlObject) the same to the other ones of usual runtime Objects,
           and drop one MarkedBlock.

        * runtime/IntlCollatorConstructor.h:
        * runtime/IntlDateTimeFormatConstructor.h:
        * runtime/IntlNumberFormatConstructor.h:
        * runtime/IntlObject.cpp:
        (JSC::createCollatorConstructor):
        (JSC::createNumberFormatConstructor):
        (JSC::createDateTimeFormatConstructor):
        (JSC::createPluralRulesConstructor):
        (JSC::IntlObject::finishCreation):
        (JSC::IntlObject::visitChildren): Deleted.
        * runtime/IntlObject.h:
        * runtime/IntlPluralRulesConstructor.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::defaultCollator):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::collatorStructure):
        (JSC::JSGlobalObject::numberFormatStructure):
        (JSC::JSGlobalObject::dateTimeFormatStructure):
        (JSC::JSGlobalObject::pluralRulesStructure):
        (JSC::JSGlobalObject::intlObject const): Deleted.
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncDateTimeFormat):
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToLocaleString):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncLocaleCompare):

2019-02-25  Tadeu Zagallo  <tzagallo@apple.com>

        Avoid hashing CompactVariableEnvironment when decoding CompactVariableMap::Handle
        https://bugs.webkit.org/show_bug.cgi?id=194937

        Reviewed by Saam Barati.

        Hashing the CompactVariableEnvironment is expensive and we could avoid it
        when decoding multiple handles to the same environment. This is sound because
        a pointer to the same CompactVariableEnvironment will hash the same.

        * runtime/CachedTypes.cpp:
        (JSC::Decoder::handleForEnvironment const):
        (JSC::Decoder::setHandleForEnvironment):
        (JSC::CachedCompactVariableMapHandle::decode const):

2019-02-25  Tadeu Zagallo  <tzagallo@apple.com>

        Remove unnecessary WTF:: prefixes in CachedTypes
        https://bugs.webkit.org/show_bug.cgi?id=194936

        Reviewed by Saam Barati.

        Cleanup unnecessary prefixes from Optional, roundUpToMultipleOf and
        pageSize.

        * runtime/CachedTypes.cpp:
        (JSC::Encoder::cachedOffsetForPtr):
        (JSC::Encoder::Page::malloc):
        (JSC::Encoder::allocateNewPage):
        (JSC::CachedPtr::encode):
        (JSC::CachedPtr::decode const):
        (JSC::CachedOptional::encode):
        (JSC::CachedOptional::decode const):

2019-02-25  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Drop direct references to Intl constructors by rewriting Intl JS builtins in C++
        https://bugs.webkit.org/show_bug.cgi?id=194976

        Reviewed by Michael Saboff.

        This patch paves the way to making IntlObject allocation lazy by removing direct references
        to Intl constructors (Intl.Collator etc.) from builtin JS. To achieve that,

        1. We implement String.prototype.toLocaleCompare and Number.prototype.toLocaleString in C++
           instead of JS builtins. Since these functions end up calling ICU C++ runtime, writing them in
           JS does not offer performance improvement.

        2. We remove @DateTimeFormat constructor reference, and instead, exposing @dateTimeFormat function,
           which returns formatted string directly. We still have JS builtins for DateTimeFormat things
           because the initialization of its "options" JSObject involves many get_by_id / put_by_id things,
           which are efficient in JS. But we avoid exposing @DateTimeFormat directly, so that Intl constructors
           can be lazily allocated.

        * CMakeLists.txt:
        * DerivedSources-input.xcfilelist:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinNames.h:
        * builtins/DatePrototype.js:
        (toLocaleString):
        (toLocaleDateString):
        (toLocaleTimeString):
        * builtins/NumberPrototype.js: Removed.
        * builtins/StringPrototype.js:
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        (globalPrivate.getDefaultCollator): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::defaultCollator):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncDateTimeFormat):
        * runtime/JSGlobalObjectFunctions.h:
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        (JSC::throwVMToThisNumberError):
        (JSC::numberProtoFuncToExponential):
        (JSC::numberProtoFuncToFixed):
        (JSC::numberProtoFuncToPrecision):
        (JSC::numberProtoFuncToString):
        (JSC::numberProtoFuncToLocaleString):
        (JSC::numberProtoFuncValueOf):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncLocaleCompare):

2019-02-24  Devin Rousso  <drousso@apple.com>

        Web Inspector: Change the InspectorOverlay to use native rather than canvas
        https://bugs.webkit.org/show_bug.cgi?id=105023
        <rdar://problem/13443692>

        Reviewed by Brian Burg.

        * inspector/protocol/OverlayTypes.json: Removed.
        Now that the overlay is entirely generated in C++, we no longer need the special prototol
        types for transferring data to a JavaScript context.

        * inspector/protocol/Debugger.json:
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::setOverlayMessage): Deleted.
        Remove `Debugger.setOverlayMessage` command as it hasn't been used and is no longer supported.

        * CMakeLists.txt:
        * DerivedSources-input.xcfilelist:
        * DerivedSources.make:

2019-02-24  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Lazily create sentinel Map and Set buckets
        https://bugs.webkit.org/show_bug.cgi?id=194975

        Reviewed by Saam Barati.

        If VM::canUseJIT() returns false, we can lazily initialize sentinel Map and Set buckets.
        This patch adds getters to VM which lazily allocate these buckets. We eagerly initialize
        them if VM::canUseJIT() returns true since they can be touched from DFG and FTL.

        * bytecode/BytecodeIntrinsicRegistry.cpp:
        (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
        (JSC::BytecodeIntrinsicRegistry::sentinelMapBucketValue):
        (JSC::BytecodeIntrinsicRegistry::sentinelSetBucketValue):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetMapBucketNext):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
        (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucketNext):
        * runtime/MapConstructor.cpp:
        (JSC::mapPrivateFuncMapBucketNext):
        * runtime/SetConstructor.cpp:
        (JSC::setPrivateFuncSetBucketNext):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::sentinelSetBucketSlow):
        (JSC::VM::sentinelMapBucketSlow):
        * runtime/VM.h:
        (JSC::VM::sentinelSetBucket):
        (JSC::VM::sentinelMapBucket):

2019-02-20  Darin Adler  <darin@apple.com>

        Finish removing String::format
        https://bugs.webkit.org/show_bug.cgi?id=194893

        Reviewed by Daniel Bates.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
        using the new "pad" function.

2019-02-23  Robin Morisset  <rmorisset@apple.com>

        Remove dead code: AdjacencyList::justOneChild()
        https://bugs.webkit.org/show_bug.cgi?id=194965

        Reviewed by Sam Weinig.

        * dfg/DFGAdjacencyList.h:
        (JSC::DFG::AdjacencyList::justOneChild const): Deleted.

2019-02-23  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, fix -Wunused-param warning

        * jsc.cpp:

2019-02-23  Mark Lam  <mark.lam@apple.com>

        Add an exception check and some assertions in StringPrototype.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=194962
        <rdar://problem/48013416>

        Reviewed by Yusuke Suzuki and Saam Barati.

        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):

2019-02-23  Keith Miller  <keith_miller@apple.com>

        Add new mac target numbers
        https://bugs.webkit.org/show_bug.cgi?id=194955

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:

2019-02-22  Robin Morisset  <rmorisset@apple.com>

        DFGBytecodeParser should not declare that a node won't clobberExit if DFGFixupPhase can later declare it does clobberExit
        https://bugs.webkit.org/show_bug.cgi?id=194953
        <rdar://problem/47595253>

        Reviewed by Saam Barati.

        For each node that
        (a) may or may not clobberExit depending on their arrayMode
        (b) and get their arrayMode from profiling information in DFGBytecodeParser
        (c) and can have their arrayMode refined by DFGFixupPhase,
        We must make sure to be conservative in the DFGBytecodeParser and treat it as if it unconditionnally clobbered the exit.
        Otherwise we will hit a validation failure after fixup if the next node was marked ExitValid and exits to the same semantic origin.

        The list of nodes that fit (a) is:
        - StringCharAt
        - HasIndexProperty
        - GetByVal
        - PutByValDirect
        - PutByVal
        - PutByValAlias
        - GetIndexedPropertyStorage

        Out of these, the following also fit (b) and (c):
        - HasIndexedProperty
        - GetByVal
        - PutByValDirect
        - PutByVal

        GetByVal already had "m_exitOK = false; // GetByVal must be treated as if it clobbers exit state, since FixupPhase may make it generic."
        So we just have to fix the other three the same way.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::handlePutByVal):

2019-02-22  Robin Morisset  <rmorisset@apple.com>

        B3ReduceStrength: missing peephole optimizations for binary operations
        https://bugs.webkit.org/show_bug.cgi?id=194252

        Reviewed by Saam Barati.

        Adds several sets of optimizations for BitAnd, BitOr and BitXor.
        Using BitAnd distributivity over BitOr and BitXor:
          Turn any of these (for Op == BitOr || Op == BitXor):
                Op(BitAnd(x1, x2), BitAnd(x1, x3))
                Op(BitAnd(x2, x1), BitAnd(x1, x3))
                Op(BitAnd(x1, x2), BitAnd(x3, x1))
                Op(BitAnd(x2, x1), BitAnd(x3, x1))
           Into this: BitAnd(Op(x2, x3), x1)
           And any of these:
                Op(BitAnd(x1, x2), x1)
                Op(BitAnd(x2, x1), x1)
                Op(x1, BitAnd(x1, x2))
                Op(x1, BitAnd(x2, x1))
           Into this: BitAnd(Op(x2, x1), x1)
           This second set is equivalent to doing x1 => BitAnd(x1, x1), and then applying the first set.
        Using de Morgan laws (we represent not as BitXor with allOnes):
          BitAnd(BitXor(x1, allOnes), BitXor(x2, allOnes)) => BitXor(BitOr(x1, x2), allOnes)
          BitOr(BitXor(x1, allOnes), BitXor(x2, allOnes) => BitXor(BitAnd(x1, x2), allOnes)
          BitOr(BitXor(x, allOnes), c) => BitXor(BitAnd(x, ~c), allOnes)
          BitAnd(BitXor(x, allOnes), c) => BitXor(BitOr(x, ~c), allOnes)
        The latter two are equivalent to doing c => BitXor(~c, allOnes), and then applying the former two.

        All of these transformations either reduce the number of operations (which we always do when possible), or bring the expression closer to having:
          - BitXor with all ones at the outermost
          - then BitAnd
          - then other BitXor
          - then BitOr at the innermost.
        These transformations that don't directly reduce the number of operations are still useful for normalization (helping things like CSE), and also can enable
        more optimizations (for example BitXor with all ones can easily cancel each other once they are all at the outermost level).

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testBitAndNotNot):
        (JSC::B3::testBitAndNotImm):
        (JSC::B3::testBitOrAndAndArgs):
        (JSC::B3::testBitOrAndSameArgs):
        (JSC::B3::testBitOrNotNot):
        (JSC::B3::testBitOrNotImm):
        (JSC::B3::testBitXorAndAndArgs):
        (JSC::B3::testBitXorAndSameArgs):
        (JSC::B3::run):

2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] putNonEnumerable in JSWrapperMap is too costly
        https://bugs.webkit.org/show_bug.cgi?id=194935

        Reviewed by Mark Lam.

        When we convert Objective-C blocks to JS objects, we need to set up a corresponding function object correctly.
        During this allocation, we call [JSValue defineProperty:descriptor] to connect a "prototype" object and "constructor" object.
        The problem is that this API has a particularly costly implementation:

            [[_context globalObject][@"Object"] invokeMethod:@"defineProperty" withArguments:@[ self, key, descriptor ]];

        This wraps each JS objects appear in this code with Objective-C wrapper. And we convert a NSDictionary to JSObject, which
        has "writable", "enumerable", "configurable", "value" fields, and call the "defineProperty" JS function through Objective-C wrapper.
        This allocates many Objective-C wrappers and JS objects for descriptors. Since JSC has a direct C++ API "defineOwnProperty", we should
        bypass these Objective-C APIs and call JSC's code directly.

        This patch changes `putNonEnumerable` implementation, from calling [JSValue defineProperty:descriptor] to calling JSC C++ code directly.
        We do not change [JSValue defineProperty:descriptor] implementation for now because of two reasons. (1) This is not used in our benchmarks
        except for this (converting an Objective-C block to a JS object) one path. And (2) even if we were to re-write [JSValue defineProperty:descriptor]
        to be more optimized, we would still want to call the JSC C++ version of defineProperty directly here to avoid NSDictionary allocation for a descriptor.

        * API/APIUtils.h:
        (setException):
        * API/JSWrapperMap.mm:
        (putNonEnumerable):
        (copyMethodsToObject):
        (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
        (-[JSObjCClassInfo wrapperForObject:inContext:]):

2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, build fix after r241954
        https://bugs.webkit.org/show_bug.cgi?id=194939

        Renaming setCanAccessHeap was incomplete.

        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::initializeCommonStrings):
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2019-02-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] SmallStringsStorage is unnecessary
        https://bugs.webkit.org/show_bug.cgi?id=194939

        Reviewed by Mark Lam.

        SmallStrings hold common small JSStrings. Their underlying StringImpl is also held by SmallStringsStorage.
        But it is duplicate since we can get StringImpl from small JSStrings. This patch removes SmallStringsStorage,
        and get StringImpls from JSStrings if necessary.

        We also add m_canAccessHeap flag to SmallStrings. At the time of VM destruction, JSStrings are destroyed when
        VM's Heap is finalized. We must not touch JSStrings before VM's heap (and JSStrings in SmallStrings) is initialized,
        and after VM's Heap is destroyed. We add this m_canAccessHeap flag to allow users to get StringImpl during the
        this sensitive period. If m_canAccessHeap is false, we get StringImpl from AtomicStringImpl::add.

        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::initializeCommonStrings):
        (JSC::SmallStrings::singleCharacterStringRep):
        (JSC::SmallStringsStorage::rep): Deleted.
        (JSC::SmallStringsStorage::SmallStringsStorage): Deleted.
        (JSC::SmallStrings::createSingleCharacterString): Deleted.
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::setCanAccessHeap):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):

2019-02-22  Tadeu Zagallo  <tzagallo@apple.com>

        Cache CompactVariableMap::Handle instead of VariableEnvironment for UnlinkedFunctionExecutable
        https://bugs.webkit.org/show_bug.cgi?id=194706

        Reviewed by Saam Barati.

        In https://bugs.webkit.org/show_bug.cgi?id=194583 we started using a
        CompactVariableMap::Handle instead of VariableEnvironment for
        UnlinkedFunctionExecutables, but we were creating the full environment
        to encode the executable in the bytecode cache. This patch changes it so
        that we cache the handle instead of the environment. This avoids duplicating
        the VariableEnvironment whenever we have to cache two handles that point
        to the environment.

        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/VariableEnvironment.cpp:
        (JSC::CompactVariableMap::get):
        * parser/VariableEnvironment.h:
        * runtime/CachedTypes.cpp:
        (JSC::CachedCompactVariableEnvironment::encode):
        (JSC::CachedCompactVariableEnvironment::decode const):
        (JSC::CachedCompactVariableMapHandle::encode):
        (JSC::CachedCompactVariableMapHandle::decode const):
        (JSC::CachedFunctionExecutable::encode):
        (JSC::CachedFunctionExecutable::decode const):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):

2019-02-21  Saam Barati  <sbarati@apple.com>

        Update JSScript SPI based on feedback
        https://bugs.webkit.org/show_bug.cgi?id=194517

        Reviewed by Keith Miller.

        This patch updates the JSScript SPI in the following ways:
        - JSScript can now represent both modules and programs. This is a property
        of the script determined during creation.
        - JSScript now takes a sourceURL during construction. For modules, this acts
        as the module identifier.
        - JSScript now has SPI for writing the cache out to disk. We don't do this
        automatically.
        - JSScript will load the bytecode cache on creation if it exists.
        - We retrofit these new requirements on the prior JSScript SPI that
        we're going to remove as soon as we can: https://bugs.webkit.org/show_bug.cgi?id=194909.
        Previous SPI assumes all JSScripts are modules. Previous SPI also assigns
        a sourceURL to the JSScript based on what the module loader decided the
        identifier should be. We'll remove this once we remove the old SPI.
        
        This patch also adds SPI to JSContext to evaluate a JSScript. For modules,
        this is like returning the result of doing dynamic import. For programs,
        this does normal program evaluation.
        
        This patch also fixes a bug in generateBytecode/generateModuleBytecode where
        we would try to cache the bytecode even if recursivelyGenerateUnlinkedCodeBlock
        returned null. E.g, if the script had a syntax error.
        
        When writing tests, I also discovered that someone previously broke
        testapi. This patch also fixes those failures. They were broken when
        we switched to using a testapiScripts directory to hold our test .js
        scripts. 

        * API/JSAPIGlobalObject.h:
        * API/JSAPIGlobalObject.mm:
        (JSC::JSAPIGlobalObject::moduleLoaderResolve):
        (JSC::JSAPIGlobalObject::moduleLoaderFetch):
        (JSC::JSAPIGlobalObject::loadAndEvaluateJSScriptModule):
        * API/JSBase.cpp:
        (JSEvaluateScriptInternal):
        (JSEvaluateScript):
        * API/JSBaseInternal.h: Added.
        * API/JSContext.mm:
        (-[JSContext evaluateScript:withSourceURL:]):
        (-[JSContext evaluateJSScript:]):
        * API/JSContextPrivate.h:
        * API/JSScript.h:
        * API/JSScript.mm:
        (+[JSScript scriptWithSource:inVirtualMachine:]):
        (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
        (createError):
        (+[JSScript scriptOfType:inVirtualMachine:withSourceURL:andSource:andBytecodeCache:error:]):
        (+[JSScript scriptOfType:inVirtualMachine:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:error:]):
        (-[JSScript cacheBytecodeWithError:]):
        (-[JSScript sourceURL]):
        (-[JSScript type]):
        (-[JSScript jsSourceCode]):
        (-[JSScript writeCache:]):
        (-[JSScript setSourceURL:]):
        (-[JSScript forceRecreateJSSourceCode]):
        (-[JSScript writeCache]): Deleted.
        (-[JSScript jsSourceCode:]): Deleted.
        * API/JSScriptInternal.h:
        * API/tests/FunctionOverridesTest.cpp:
        (testFunctionOverrides):
        * API/tests/testapi.c:
        (main):
        * API/tests/testapi.mm:
        (tempFile):
        (testModuleBytecodeCache):
        (testProgramBytecodeCache):
        (testBytecodeCacheWithSyntaxError):
        (testProgramJSScriptException):
        (testLoadBasicFileLegacySPI):
        (+[JSContextMemoryMappedLoaderDelegate newContext]):
        (-[JSContextMemoryMappedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
        (testLoadBasicFile):
        (+[JSContextAugmentedLoaderDelegate newContext]):
        (-[JSContextAugmentedLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
        (testJSScriptURL):
        (testObjectiveCAPI):
        (testBytecodeCache): Deleted.
        * API/tests/testapiScripts/foo.js: Added.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/Completion.cpp:
        (JSC::generateBytecode):
        (JSC::generateModuleBytecode):

2019-02-21  Mark Lam  <mark.lam@apple.com>

        Add more doesGC() assertions.
        https://bugs.webkit.org/show_bug.cgi?id=194911
        <rdar://problem/48285723>

        Reviewed by Saam Barati and Yusuke Suzuki.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::compileOSRExit):
        - Set expectDoesGC here because we no longer have to worry about missing store
          barriers in optimized code after this point.  This will prevent false positive
          assertion failures arising from functions called beneath compileOSRExit().

        (JSC::DFG::OSRExit::compileExit):
        - Add a comment to explain why the generated ramp needs to set expectDoesGC even
          though compileOSRExit() also sets it.  Reason: compileOSRExit() is only called
          for the first OSR from this code origin, the generated ramp is called for many
          subsequents OSR exits from this code origin.

        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        - Added a comment for the equivalent reason to the one above.

        (JSC::FTL::compileFTLOSRExit):
        - Set expectDoesGC here because we no longer have to worry about missing store
          barriers in optimized code after this point.  This will prevent false positive
          assertion failures arising from functions called beneath compileFTLOSRExit().

        * heap/CompleteSubspace.cpp:
        (JSC::CompleteSubspace::tryAllocateSlow):
        * heap/CompleteSubspaceInlines.h:
        (JSC::CompleteSubspace::allocateNonVirtual):
        - assert expectDoesGC.

        * heap/DeferGC.h:
        (JSC::DeferGC::~DeferGC):
        - assert expectDoesGC.
        - Also added WTF_FORBID_HEAP_ALLOCATION to DeferGC, DeferGCForAWhile, and DisallowGC
          because all 3 should be stack allocated RAII objects.

        * heap/GCDeferralContext.h:
        * heap/GCDeferralContextInlines.h:
        (JSC::GCDeferralContext::~GCDeferralContext):
        - Added WTF_FORBID_HEAP_ALLOCATION.
        - assert expectDoesGC.

        * heap/Heap.cpp:
        (JSC::Heap::collectNow):
        (JSC::Heap::collectAsync):
        (JSC::Heap::collectSync):
        (JSC::Heap::stopIfNecessarySlow):
        (JSC::Heap::collectIfNecessaryOrDefer):
        * heap/HeapInlines.h:
        (JSC::Heap::acquireAccess):
        (JSC::Heap::stopIfNecessary):
        * heap/LargeAllocation.cpp:
        (JSC::LargeAllocation::tryCreate):
        * heap/LocalAllocatorInlines.h:
        (JSC::LocalAllocator::allocate):
        - conservatively assert expectDoesGC on these functions that may trigger a GC
          though they don't always do.

        * runtime/DisallowScope.h:
        - DisallowScope should be stack allocated because it's an RAII object.

        * runtime/JSCellInlines.h:
        (JSC::tryAllocateCellHelper):
        - Remove the expectDoesGC assertion because it is now covered by assertions in
          CompleteSubspace, LargeAllocation, and LocalAllocator.

        * runtime/RegExpMatchesArray.h:
        (JSC::createRegExpMatchesArray):
        - assert expectDoesGC.

2019-02-21  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Use Fast Malloc as much as possible
        https://bugs.webkit.org/show_bug.cgi?id=194316

        Reviewed by Mark Lam.

        We should use Fast Malloc as much as possible to offer the whole memory view to bmalloc.

        * inspector/scripts/codegen/cpp_generator_templates.py:
        * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/enum-values.json-result:
        * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
        * jit/ExecutableAllocator.h:
        * jsc.cpp:
        * runtime/JSRunLoopTimer.h:
        * tools/VMInspector.h:
        * wasm/WasmThunks.h:

2019-02-20  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Remove WatchpointSet creation for SymbolTable entries if VM::canUseJIT() returns false
        https://bugs.webkit.org/show_bug.cgi?id=194891

        Reviewed by Geoffrey Garen.

        WatchpointSet in SymbolTable is used to fold the value into a constant in JIT tiers. And it is
        not useful under the non-JIT mode. This patch avoids creation of WatchpointSet in SymbolTable
        if VM::canUseJIT() returns false.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTableEntry::addWatchpoint): Deleted.
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::isWatchable const):
        (JSC::SymbolTableEntry::watchpointSet):

2019-02-20  Mark Lam  <mark.lam@apple.com>

        Add code to validate expected GC activity modelled by doesGC() against what the runtime encounters.
        https://bugs.webkit.org/show_bug.cgi?id=193938
        <rdar://problem/47616277>

        Reviewed by Michael Saboff, Saam Barati, and Robin Morisset.

        In DFG::SpeculativeJIT::compile() and FTL::LowerDFGToB3::compileNode(), before
        emitting code / B3IR for each DFG node, we emit a write to set Heap::m_expectDoesGC
        to the value returned by doesGC() for that node.  In the runtime (i.e. in allocateCell()
        and functions that can resolve a rope), we assert that Heap::m_expectDoesGC is
        true.

        This validation code is currently only enabled for debug builds.  It is disabled
        for release builds by default, but it can easily be made to run on release builds
        as well by forcing ENABLE_DFG_DOES_GC_VALIDATION to 1 in Heap.h.

        To allow this validation code to run on release builds as well, the validation uses
        RELEASE_ASSERT instead of ASSERT.

        To ensure that Heap.h is #include'd for all files that needs to do this validation
        (so that the validation code is accidentally disabled), we guard the validation
        code with an if conditional on constexpr bool validateDFGDoesGC (instead of using
        a #if ENABLE(DFG_DOES_GC_VALIDATION)).  This way, if Heap.h isn't #include'd, the
        validation code will fail to build (no silent failures).

        Currently, all JSC tests and Layout tests should pass with this validation enabled
        in debug builds.  We'll only see new failures if there's a regression or if new
        tests reveal a previously untested code path that has an undetected issue.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        (JSC::DFG::OSRExit::compileExit):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * heap/Heap.h:
        (JSC::Heap::expectDoesGC const):
        (JSC::Heap::setExpectDoesGC):
        (JSC::Heap::addressOfExpectDoesGC):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_compareAndJump):
        * runtime/JSCellInlines.h:
        (JSC::tryAllocateCellHelper):
        * runtime/JSString.h:
        (JSC::jsSingleCharacterString):
        (JSC::JSString::toAtomicString const):
        (JSC::JSString::toExistingAtomicString const):
        (JSC::JSString::value const):
        (JSC::JSString::tryGetValue const):
        (JSC::JSRopeString::unsafeView const):
        (JSC::JSRopeString::viewWithUnderlyingString const):
        (JSC::JSString::unsafeView const):

2019-02-20  Andy Estes  <aestes@apple.com>

        [Xcode] Add SDKVariant.xcconfig to various Xcode projects
        https://bugs.webkit.org/show_bug.cgi?id=194869

        Rubber-stamped by Jer Noble.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2019-02-19  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view
        https://bugs.webkit.org/show_bug.cgi?id=172848
        <rdar://problem/25709212>

        Reviewed by Mark Lam.

        * heap/HeapSnapshotBuilder.h:
        * heap/HeapSnapshotBuilder.cpp:
        Update the snapshot version. Change the node's 0 | 1 internal value
        to be a 32bit bit flag. This is nice in that it is both compatible
        with the previous snapshot version and the same size. We can use more
        flags in the future.

        (JSC::HeapSnapshotBuilder::json):
        In cases where the classInfo gives us "Object" check for a better
        class name by checking (o).__proto__.constructor.name. We avoid this
        check in cases where (o).hasOwnProperty("constructor") which is the
        case for most Foo.prototype objects. Otherwise this would get the
        name of the Foo superclass for the Foo.prototype object.

        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        Handle some possible edge cases that were not handled before, such as
        a JSObject without a GlobalObject or an object which doesn't
        have a default getPrototype. Try to make the code a little clearer.

2019-02-19  Truitt Savell  <tsavell@apple.com>

        Unreviewed, rolling out r241784.

        Broke all OpenSource builds.

        Reverted changeset:

        "Web Inspector: Improve ES6 Class instances in Heap Snapshot
        instances view"
        https://bugs.webkit.org/show_bug.cgi?id=172848
        https://trac.webkit.org/changeset/241784

2019-02-19  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view
        https://bugs.webkit.org/show_bug.cgi?id=172848
        <rdar://problem/25709212>

        Reviewed by Mark Lam.

        * heap/HeapSnapshotBuilder.h:
        * heap/HeapSnapshotBuilder.cpp:
        Update the snapshot version. Change the node's 0 | 1 internal value
        to be a 32bit bit flag. This is nice in that it is both compatible
        with the previous snapshot version and the same size. We can use more
        flags in the future.

        (JSC::HeapSnapshotBuilder::json):
        In cases where the classInfo gives us "Object" check for a better
        class name by checking (o).__proto__.constructor.name. We avoid this
        check in cases where (o).hasOwnProperty("constructor") which is the
        case for most Foo.prototype objects. Otherwise this would get the
        name of the Foo superclass for the Foo.prototype object.

        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        Handle some possible edge cases that were not handled before, such as
        a JSObject without a GlobalObject or an object which doesn't
        have a default getPrototype. Try to make the code a little clearer.

2019-02-19  Robin Morisset  <rmorisset@apple.com>

        B3-O2 incorrectly optimizes this subtest
        https://bugs.webkit.org/show_bug.cgi?id=194625

        Reviewed by Saam Barati.

        Trivial fix. Instead of doing
            if (!cond) foo else bar => if (cond) bar else foo
        B3LowerToAir was doing
            if (x^C) foo else bar => if (cond) bar else foo whenever C&1, even if C was for example 3.

        * b3/B3LowerToAir.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testBitNotOnBooleanAndBranch32):
        (JSC::B3::testNotOnBooleanAndBranch32): Added.

2019-02-19  Robin Morisset  <rmorisset@apple.com>

        CachedCall should not consider it UNLIKELY that it will not stack overflow
        https://bugs.webkit.org/show_bug.cgi?id=194831

        Reviewed by Mark Lam.

        * interpreter/CachedCall.h:
        (JSC::CachedCall::CachedCall):

2019-02-19  Mark Lam  <mark.lam@apple.com>

        Fix DFG doesGC() for TryGetById and ProfileType nodes.
        https://bugs.webkit.org/show_bug.cgi?id=194821
        <rdar://problem/48206690>

        Reviewed by Saam Barati.

        Fix doesGC() for the following nodes:

            ProfileType:
                calls operationProcessTypeProfilerLogDFG(), which can calculatedClassName(),
                which can call JSString::tryGetValue(), which can resolve a rope.

            TryGetById:
                calls operationTryGetByIdOptimize(), which can startWatchingPropertyForReplacements()
                on a structure, which can allocate StructureRareData.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-02-18  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Introduce JSNonDestructibleProxy for JavaScriptCore.framework's GlobalThis
        https://bugs.webkit.org/show_bug.cgi?id=194799

        Reviewed by Saam Barati.

        JSProxy is destructible one because we have JSWindowProxy which has ref counted object.
        However, JavaScriptCore.framework's JSProxy for GlobalThis does not need to be destructible.
        This is important since we need to separate Heap subspaces between destructible and non-destructible objects.
        If we can put more and more objects in non-destructible status, we can get rid of low-usage MarkedBlock.
        This patch adds JSNonDestructibleProxy, which is not destructible JSProxy. While it inherits JSDestructibleObject,
        we can make the subclass still non-destructible thanks to Subspace mechanism. This drops one more low-usage MarkedBlock.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::resetPrototype):
        (JSC::JSGlobalObject::finishCreation):
        * runtime/JSNonDestructibleProxy.cpp: Added.
        * runtime/JSNonDestructibleProxy.h: Added.
        (JSC::JSNonDestructibleProxy::subspaceFor):
        (JSC::JSNonDestructibleProxy::create):
        (JSC::JSNonDestructibleProxy::createStructure):
        (JSC::JSNonDestructibleProxy::JSNonDestructibleProxy):
        * runtime/JSProxy.h:
        (JSC::JSProxy::JSProxy):

2019-02-19  Robin Morisset  <rmorisset@apple.com>

        B3ReduceStrength::simplifyCFG() could do a lot more on each iteration
        https://bugs.webkit.org/show_bug.cgi?id=194475

        Reviewed by Saam Barati.

        B3ReduceStrength::simplifyCFG() does three optimizations (which I will call A, B and C):
        - A makes any terminal that points to a block that is empty except for a jump point to that jump's target instead.
        - B transforms any branch or switch that points to a single block into a jump
        - C finds blocks ending with jumps, whose successor has a single predecessor, and inline that successor block in place of the jump

        It currently is limited in the following way:
        - A and C can only fire once per block per iteration
        - B can create jumps that would trigger A, but they may not be seen until the next iteration

        Both problems are mitigated by going through the blocks in post-order, so that when a block is optimized most of its successors have already been optimized.
        In a sense it is the symmetric of the peephole optimizer that goes in pre-order so that when an instruction is optimized most of its children have already been optimized.

        On JetStream2 it reduces the average number of iterations from 3.35 to 3.24.

        * b3/B3ReduceStrength.cpp:

2019-02-19  Tadeu Zagallo  <tzagallo@apple.com>

        Move bytecode cache-related filesystem code out of CodeCache
        https://bugs.webkit.org/show_bug.cgi?id=194675

        Reviewed by Saam Barati.

        The code is only used for the bytecode-cache tests, so it should live in
        jsc.cpp rather than in the CodeCache. The logic now lives in ShellSourceProvider,
        which overrides the a virtual method in SourceProvider, `cacheBytecode`,
        in order to write the cache to disk.

        * jsc.cpp:
        (ShellSourceProvider::create):
        (ShellSourceProvider::~ShellSourceProvider):
        (ShellSourceProvider::cachePath const):
        (ShellSourceProvider::loadBytecode):
        (ShellSourceProvider::ShellSourceProvider):
        (jscSource):
        (GlobalObject::moduleLoaderFetch):
        (functionDollarEvalScript):
        (runWithOptions):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::cacheBytecode const):
        * runtime/CodeCache.cpp:
        (JSC::writeCodeBlock):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::fetchFromDiskImpl):

2019-02-18  Dominik Infuehr  <dinfuehr@igalia.com>

        [ARM] Fix crash with sampling profiler
        https://bugs.webkit.org/show_bug.cgi?id=194772

        Reviewed by Mark Lam.

        sampling-profiler-richards.js was crashing with an enabled sampling profiler. add32
        did not update the stack pointer in a single instruction. The src register was first
        moved into the stack pointer, the immediate imm was added in a subsequent instruction.

        This was problematic when a signal handler was invoked before applying the immediate,
        when the stack pointer is still set to the temporary value. Avoid this by calculating src+imm in
        a temporary register and then move it in one go into the stack pointer.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::add32):

2019-02-18  Mark Lam  <mark.lam@apple.com>

        Fix DFG doesGC() for CompareEq/Less/LessEq/Greater/GreaterEq and CompareStrictEq nodes.
        https://bugs.webkit.org/show_bug.cgi?id=194800
        <rdar://problem/48183773>

        Reviewed by Yusuke Suzuki.

        Fix doesGC() for the following nodes:

            CompareEq:
            CompareLess:
            CompareLessEq:
            CompareGreater:
            CompareGreaterEq:
            CompareStrictEq:
                Only return false (i.e. does not GC) for child node use kinds that have
                been vetted to not do anything that can GC.  For all other use kinds
                (including StringUse and BigIntUse), we return true (i.e. does GC).

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-02-16  Darin Adler  <darin@apple.com>

        Continue reducing use of String::format, now focusing on hex: "%p", "%x", etc.
        https://bugs.webkit.org/show_bug.cgi?id=194752

        Reviewed by Daniel Bates.

        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::json): Added back the "0x" that was removed when changing
        this file to use appendUnsignedAsHex instead of "%p". The intent at that time was to
        keep behavior the same, so let's do that.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::invalidCharacterMessage const): Use makeString and hex instead of
        String::format and "%04x".

2019-02-18  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Add LazyClassStructure::getInitializedOnMainThread
        https://bugs.webkit.org/show_bug.cgi?id=194784
        <rdar://problem/48154820>

        Reviewed by Mark Lam.

        LazyClassStructure::get and LazyProperty::get functions do not allow compiler threads to call them. But for booleanPrototype, numberPrototype and symbolPrototype cases,
        we would like to call them from compiler threads. We eagerly initialize them if VM::canUseJIT() is true, so that compiler threads can safely call LazyClassStructure::get
        and LazyProperty::get for booleanPrototype, numberPrototype and symbolPrototype. But still assertion hits because the assertion requires that these functions need to be
        called in non compiler threads. Calling `getConcurrently()` is not possible since symbolPrototype() function is called from both the main thread and compiler threads,
        and we would like to lazily initialize SymbolPrototype object if it is called from the main thread, which can happen with non-JIT configuration.

        This patch adds `getInitializedOnMainThread()`. Compiler threads can call it only when we know that the value is already initialized on the main thread. The main thread
        can call it at anytime and this function lazily initializes the value. This is useful to make some of prototypes lazy with non-JIT configuration: With non-JIT configuration,
        this function is always called from the main thread and it initializes the value lazily. Non-JIT configuration does not care about compiler threads since they do not exist.
        With JIT configuration, we eagerly initialize them in JSGlobalObject::init so that `getInitializedOnMainThread()` always succeeds.

        Basically, `getInitializedOnMainThread()` is `get` with different assertion location: While `get` always crashes if it is called from compiler threads, `getInitializedOnMainThread()`
        crashes only when actual initialization happens on compiler threads. We do not merge them since `get` is still useful to find accidental initialization from compiler threads.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::booleanPrototype const):
        (JSC::JSGlobalObject::numberPrototype const):
        (JSC::JSGlobalObject::symbolPrototype const):
        * runtime/LazyClassStructure.h:
        (JSC::LazyClassStructure::getInitializedOnMainThread const):
        (JSC::LazyClassStructure::prototypeInitializedOnMainThread const):
        (JSC::LazyClassStructure::constructorInitializedOnMainThread const):
        * runtime/LazyProperty.h:
        (JSC::LazyProperty::get const):
        (JSC::LazyProperty::getInitializedOnMainThread const):

2019-02-18  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Better categorize CPU usage per-thread / worker
        https://bugs.webkit.org/show_bug.cgi?id=194564

        Reviewed by Devin Rousso.

        * inspector/protocol/CPUProfiler.json:
        Add additional properties per-Event, and new per-Thread object info.

2019-02-18  Tadeu Zagallo  <tzagallo@apple.com>

        Bytecode cache should a have a boot-specific validation
        https://bugs.webkit.org/show_bug.cgi?id=194769
        <rdar://problem/48149509>

        Reviewed by Keith Miller.

        Add the boot UUID to the cached bytecode to enforce that it is not reused
        across reboots.

        * runtime/CachedTypes.cpp:
        (JSC::Encoder::malloc):
        (JSC::GenericCacheEntry::GenericCacheEntry):
        (JSC::GenericCacheEntry::tag const):
        (JSC::CacheEntry::CacheEntry):
        (JSC::CacheEntry::decode const):
        (JSC::GenericCacheEntry::decode const):
        (JSC::encodeCodeBlock):

2019-02-18  Eric Carlson  <eric.carlson@apple.com>

        Add MSE logging configuration
        https://bugs.webkit.org/show_bug.cgi?id=194719
        <rdar://problem/48122151>

        Reviewed by Joseph Pecoraro.

        * inspector/ConsoleMessage.cpp:
        (Inspector::messageSourceValue):
        * inspector/protocol/Console.json:
        * inspector/scripts/codegen/generator.py:
        * runtime/ConsoleTypes.h:

2019-02-18  Tadeu Zagallo  <tzagallo@apple.com>

        Add version number to cached bytecode
        https://bugs.webkit.org/show_bug.cgi?id=194768
        <rdar://problem/48147968>

        Reviewed by Saam Barati.

        Add a version number to the bytecode cache that should be unique per build.

        * CMakeLists.txt:
        * DerivedSources-output.xcfilelist:
        * DerivedSources.make:
        * runtime/CachedTypes.cpp:
        (JSC::Encoder::malloc):
        (JSC::GenericCacheEntry::GenericCacheEntry):
        (JSC::CacheEntry::CacheEntry):
        (JSC::CacheEntry::encode):
        (JSC::CacheEntry::decode const):
        (JSC::GenericCacheEntry::decode const):
        (JSC::decodeCodeBlockImpl):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::fetchFromDiskImpl):

2019-02-17  Saam Barati  <sbarati@apple.com>

        WasmB3IRGenerator models some effects incorrectly
        https://bugs.webkit.org/show_bug.cgi?id=194038

        Reviewed by Keith Miller.

        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
        (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
        These two functions were using global state instead of the
        arguments passed into the function.

        (JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF64>):
        (JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF32>):
        Any patchpoint that allows scratch register usage must
        also say that it clobbers the scratch registers.

2019-02-17  Saam Barati  <sbarati@apple.com>

        Deadlock when adding a Structure property transition and then doing incremental marking
        https://bugs.webkit.org/show_bug.cgi?id=194767

        Reviewed by Mark Lam.

        This can happen in the following scenario:
        
        You have a Structure S. S is on the mark stack. Then:
        1. S grabs its lock
        2. S adds a new property transition
        3. We find out we need to do some incremental marking
        4. We mark S
        5. visitChildren on S will try to grab its lock
        6. We are now in a deadlock

        * heap/Heap.cpp:
        (JSC::Heap::performIncrement):
        * runtime/Structure.cpp:
        (JSC::Structure::addNewPropertyTransition):

2019-02-17  David Kilzer  <ddkilzer@apple.com>

        Unreviewed, rolling out r241620.

        "Causes use-after-free crashes running layout tests with ASan and GuardMalloc."
        (Requested by ddkilzer on #webkit.)

        Reverted changeset:

        "[WTF] Add environment variable helpers"
        https://bugs.webkit.org/show_bug.cgi?id=192405
        https://trac.webkit.org/changeset/241620

2019-02-17  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r241612.
        https://bugs.webkit.org/show_bug.cgi?id=194762

        "It regressed JetStream2 parsing tests by ~40%" (Requested by
        saamyjoon on #webkit).

        Reverted changeset:

        "Move bytecode cache-related filesystem code out of CodeCache"
        https://bugs.webkit.org/show_bug.cgi?id=194675
        https://trac.webkit.org/changeset/241612

2019-02-16  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] JSWrapperObject should not be destructible
        https://bugs.webkit.org/show_bug.cgi?id=194743

        Reviewed by Saam Barati.

        JSWrapperObject should be just a wrapper object for JSValue, thus, it should not be a JSDestructibleObject.
        Currently it is destructible object because DateInstance uses it. This patch changes Base of DateInstance from
        JSWrapperObject to JSDestructibleObject, and makes JSWrapperObject non-destructible.

        * runtime/BigIntObject.cpp:
        (JSC::BigIntObject::BigIntObject):
        * runtime/BooleanConstructor.cpp:
        (JSC::BooleanConstructor::finishCreation):
        * runtime/BooleanObject.cpp:
        (JSC::BooleanObject::BooleanObject):
        * runtime/BooleanObject.h:
        * runtime/DateInstance.cpp:
        (JSC::DateInstance::DateInstance):
        (JSC::DateInstance::finishCreation):
        * runtime/DateInstance.h:
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncGetTime):
        (JSC::dateProtoFuncSetTime):
        (JSC::setNewValueFromTimeArgs):
        (JSC::setNewValueFromDateArgs):
        (JSC::dateProtoFuncSetYear):
        * runtime/JSCPoison.h:
        * runtime/JSWrapperObject.h:
        (JSC::JSWrapperObject::JSWrapperObject):
        * runtime/NumberObject.cpp:
        (JSC::NumberObject::NumberObject):
        * runtime/NumberObject.h:
        * runtime/StringConstructor.cpp:
        (JSC::StringConstructor::finishCreation):
        * runtime/StringObject.cpp:
        (JSC::StringObject::StringObject):
        * runtime/StringObject.h:
        (JSC::StringObject::internalValue const):
        * runtime/SymbolObject.cpp:
        (JSC::SymbolObject::SymbolObject):
        * runtime/SymbolObject.h:

2019-02-16  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink UnlinkedFunctionExecutable
        https://bugs.webkit.org/show_bug.cgi?id=194733

        Reviewed by Mark Lam.

        UnlinkedFunctionExecutable has sourceURLDirective and sourceMappingURLDirective. These
        directives can be found in the comment of non typical function's source code (Program,
        Eval code, and Global function from function constructor etc.), and tricky thing is that
        SourceProvider's directives are updated by Parser. The reason why we have these fields in
        UnlinkedFunctionExecutable is that we need to update the SourceProvider's directives even
        if we skip parsing by using CodeCache. These fields are effective only if (1)
        UnlinkedFunctionExecutable is for non typical function things, and (2) it has sourceURLDirective
        or sourceMappingURLDirective. This is rare enough to purge them to a separated
        UnlinkedFunctionExecutable::RareData to make UnlinkedFunctionExecutable small.
        sizeof(UnlinkedFunctionExecutable) is very important since it is super frequently allocated
        cell. Furthermore, the current JSC allocates two MarkedBlocks for UnlinkedFunctionExecutable
        in JSGlobalObject initialization, but the usage of the second MarkedBlock is quite low (8%).
        If we can reduce the size of UnlinkedFunctionExecutable, we can make them one MarkedBlock.
        Since UnlinkedFunctionExecutable is allocated from IsoSubspace, we do not need to fit it to
        one of size class.

        This patch adds RareData to UnlinkedFunctionExecutable and move some rare datas into RareData.
        And kill one MarkedBlock allocation in JSC initialization phase.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::ensureRareDataSlow):
        * bytecode/UnlinkedFunctionExecutable.h:
        * debugger/DebuggerLocation.cpp:
        (JSC::DebuggerLocation::DebuggerLocation):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::dispatchDidParseSource):
        * parser/Lexer.h:
        (JSC::Lexer::sourceURLDirective const):
        (JSC::Lexer::sourceMappingURLDirective const):
        (JSC::Lexer::sourceURL const): Deleted.
        (JSC::Lexer::sourceMappingURL const): Deleted.
        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::sourceURLDirective const):
        (JSC::SourceProvider::sourceMappingURLDirective const):
        (JSC::SourceProvider::setSourceURLDirective):
        (JSC::SourceProvider::setSourceMappingURLDirective):
        (JSC::SourceProvider::sourceURL const): Deleted. We rename it from sourceURL to sourceURLDirective
        since it is the correct name.
        (JSC::SourceProvider::sourceMappingURL const): Deleted. We rename it from sourceMappingURL to
        sourceMappingURLDirective since it is the correct name.
        * runtime/CachedTypes.cpp:
        (JSC::CachedSourceProviderShape::encode):
        (JSC::CachedFunctionExecutableRareData::encode):
        (JSC::CachedFunctionExecutableRareData::decode const): CachedFunctionExecutable did not have
        sourceMappingURL to sourceMappingURLDirective. So this patch keeps the same logic.
        (JSC::CachedFunctionExecutable::rareData const):
        (JSC::CachedFunctionExecutable::encode):
        (JSC::CachedFunctionExecutable::decode const):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/CodeCache.h:
        (JSC::generateUnlinkedCodeBlockImpl):
        * runtime/FunctionExecutable.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::url):

2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Remove unused global private variables
        https://bugs.webkit.org/show_bug.cgi?id=194741

        Reviewed by Joseph Pecoraro.

        There are some private functions and constants that are no longer referenced from builtin JS code.
        This patch cleans up them.

        * builtins/BuiltinNames.h:
        * builtins/ObjectConstructor.js:
        (entries):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Lazily create empty RegExp
        https://bugs.webkit.org/show_bug.cgi?id=194735

        Reviewed by Keith Miller.

        Some scripts do not have any RegExp. In that case, allocating MarkedBlock for RegExp is costly.
        Previously, there was always one RegExp, "empty RegExp". This patch lazily creates it and drop
        one MarkedBlock.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::ensureEmptyRegExpSlow):
        (JSC::RegExpCache::initialize): Deleted.
        * runtime/RegExpCache.h:
        (JSC::RegExpCache::ensureEmptyRegExp):
        (JSC::RegExpCache::emptyRegExp const): Deleted.
        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::lastResult):
        * runtime/RegExpCachedResult.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):

2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Make builtin objects more lazily initialized under non-JIT mode
        https://bugs.webkit.org/show_bug.cgi?id=194727

        Reviewed by Saam Barati.

        Boolean, Symbol, and Number constructors and prototypes are initialized eagerly, but this is largely
        because concurrent compiler can touch NumberPrototype etc. when traversing object's prototypes. This
        means that eager initialization is not necessary under non-JIT mode. While we can investigate all the
        accesses to these prototypes from the concurrent compiler threads, this "lazily initialize under non-JIT"
        is safe and beneficial to non-JIT mode. This patch lazily initializes them under non-JIT mode, and
        drop some @Number references to avoid eager initialization. This removes some object allocations and 1
        MarkedBlock allocation just for Symbols.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::numberToStringWatchpoint):
        (JSC::JSGlobalObject::booleanPrototype const):
        (JSC::JSGlobalObject::numberPrototype const):
        (JSC::JSGlobalObject::symbolPrototype const):
        (JSC::JSGlobalObject::booleanObjectStructure const):
        (JSC::JSGlobalObject::symbolObjectStructure const):
        (JSC::JSGlobalObject::numberObjectStructure const):
        (JSC::JSGlobalObject::stringObjectStructure const):

2019-02-15  Michael Saboff  <msaboff@apple.com>

        RELEASE_ASSERT at com.apple.JavaScriptCore: JSC::jsSubstringOfResolved
        https://bugs.webkit.org/show_bug.cgi?id=194558

        Reviewed by Saam Barati.

        Added an in bounds check before the read of the next character for Unicode regular expressions
        for pattern generation that didn't already have such checks.

        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
        (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
        (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
        (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):

2019-02-15  Dean Jackson  <dino@apple.com>

        Allow emulation of user gestures from Web Inspector console
        https://bugs.webkit.org/show_bug.cgi?id=194725
        <rdar://problem/48126604>

        Reviewed by Joseph Pecoraro and Devin Rousso.

        * inspector/agents/InspectorRuntimeAgent.cpp: Add a new optional parameter, emulateUserGesture,
        to the evaluate function, and mark the function as override so that PageRuntimeAgent
        can change the behaviour.
        (Inspector::InspectorRuntimeAgent::evaluate):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Runtime.json:

2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Do not initialize Wasm related data if Wasm is not enabled
        https://bugs.webkit.org/show_bug.cgi?id=194728

        Reviewed by Mark Lam.

        Under non-JIT mode, these data structures are unnecessary. Should not allocate extra memory for that.

        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreading):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):

2019-02-15  Ross Kirsling  <ross.kirsling@sony.com>

        [WTF] Add environment variable helpers
        https://bugs.webkit.org/show_bug.cgi?id=192405

        Reviewed by Michael Catanzaro.

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::RemoteInspector):
        (Inspector::RemoteInspector::start):
        * jsc.cpp:
        (startTimeoutThreadIfNeeded):
        * runtime/Options.cpp:
        (JSC::overrideOptionWithHeuristic):
        (JSC::Options::overrideAliasedOptionWithHeuristic):
        (JSC::Options::initialize):
        * runtime/VM.cpp:
        (JSC::enableAssembler):
        (JSC::VM::VM):
        * tools/CodeProfiling.cpp:
        (JSC::CodeProfiling::notifyAllocator):
        Utilize WTF::Environment where possible.

2019-02-15  Mark Lam  <mark.lam@apple.com>

        SamplingProfiler::stackTracesAsJSON() should escape strings.
        https://bugs.webkit.org/show_bug.cgi?id=194649
        <rdar://problem/48072386>

        Reviewed by Saam Barati.

        Ditto for TypeSet::toJSONString() and TypeSet::toJSONString().

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::stackTracesAsJSON):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::toJSONString const):
        (JSC::StructureShape::toJSONString const):

2019-02-15  Robin Morisset  <rmorisset@apple.com>

        CodeBlock::jettison should clear related watchpoints
        https://bugs.webkit.org/show_bug.cgi?id=194544

        Reviewed by Mark Lam.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):
        * dfg/DFGCommonData.h:
        (JSC::DFG::CommonData::clearWatchpoints): Added.
        * dfg/CommonData.cpp:
        (JSC::DFG::CommonData::clearWatchpoints): Added.

2019-02-15  Tadeu Zagallo  <tzagallo@apple.com>

        Move bytecode cache-related filesystem code out of CodeCache
        https://bugs.webkit.org/show_bug.cgi?id=194675

        Reviewed by Saam Barati.

        That code is only used for the bytecode-cache tests, so it should live in
        jsc.cpp rather than in the CodeCache.

        * jsc.cpp:
        (CliSourceProvider::create):
        (CliSourceProvider::~CliSourceProvider):
        (CliSourceProvider::cachePath const):
        (CliSourceProvider::loadBytecode):
        (CliSourceProvider::CliSourceProvider):
        (jscSource):
        (GlobalObject::moduleLoaderFetch):
        (functionDollarEvalScript):
        (runWithOptions):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::cacheBytecode const):
        * runtime/CodeCache.cpp:
        (JSC::writeCodeBlock):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::fetchFromDiskImpl):

2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] DFG, FTL, and Wasm worklist creation should be fenced
        https://bugs.webkit.org/show_bug.cgi?id=194714

        Reviewed by Mark Lam.

        Let's consider about the following extreme case.

        1. VM (A) is created.
        2. Another VM (B) is created on a different thread.
        3. (A) is being destroyed. It calls DFG::existingWorklistForIndexOrNull in a destructor.
        4. At the same time, (B) starts using DFG Worklist and it is instantiated in call_once.
        5. But (A) reads the pointer directly through DFG::existingWorklistForIndexOrNull.
        6. (A) sees the half-baked worklist, which may be in the middle of creation.

        This patch puts store-store fence just before putting a pointer to a global variable.
        This fence is executed only three times at most, for DFG, FTL, and Wasm worklist initializations.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::ensureGlobalDFGWorklist):
        (JSC::DFG::ensureGlobalFTLWorklist):
        * wasm/WasmWorklist.cpp:
        (JSC::Wasm::ensureWorklist):

2019-02-15  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r241559 and r241566.
        https://bugs.webkit.org/show_bug.cgi?id=194710

        Causes layout test crashes under GuardMalloc (Requested by
        ryanhaddad on #webkit).

        Reverted changesets:

        "[WTF] Add environment variable helpers"
        https://bugs.webkit.org/show_bug.cgi?id=192405
        https://trac.webkit.org/changeset/241559

        "Unreviewed build fix for WinCairo Debug after r241559."
        https://trac.webkit.org/changeset/241566

2019-02-15  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Do not even allocate JIT worklists in non-JIT mode
        https://bugs.webkit.org/show_bug.cgi?id=194693

        Reviewed by Mark Lam.

        Heap always allocates JIT worklists for Baseline, DFG, and FTL. While they do not have actual threads, Worklist itself already allocates some memory.
        And we do not perform any GC operations that are only meaningful in JIT environment.

        1. We add VM::canUseJIT() check in Heap's ensureXXXWorklist things to prevent them from being allocated.
        2. We remove DFG marking constraint in non-JIT mode.
        3. We do not gather conservative roots from scratch buffers under the non-JIT mode (BTW, # of scratch buffers are always zero in non-JIT mode)
        4. We do not visit JITStubRoutineSet.
        5. Align JITWorklist function names to the other worklists.

        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGPlan.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::markCodeBlocks): Deleted.
        * dfg/DFGWorklist.h:
        * heap/Heap.cpp:
        (JSC::Heap::completeAllJITPlans):
        (JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
        (JSC::Heap::gatherScratchBufferRoots):
        (JSC::Heap::removeDeadCompilerWorklistEntries):
        (JSC::Heap::stopThePeriphery):
        (JSC::Heap::suspendCompilerThreads):
        (JSC::Heap::resumeCompilerThreads):
        (JSC::Heap::addCoreConstraints):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::existingGlobalWorklistOrNull):
        (JSC::JITWorklist::ensureGlobalWorklist):
        (JSC::JITWorklist::instance): Deleted.
        * jit/JITWorklist.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        * runtime/VM.cpp:
        (JSC::VM::~VM):
        (JSC::VM::gatherScratchBufferRoots):
        (JSC::VM::gatherConservativeRoots): Deleted.
        * runtime/VM.h:

2019-02-15  Saam barati  <sbarati@apple.com>

        [WebAssembly] Write a new register allocator for Air O0 and make BBQ use it
        https://bugs.webkit.org/show_bug.cgi?id=194036

        Reviewed by Yusuke Suzuki.

        This patch adds a new Air-O0 backend. Air-O0 runs fewer passes and doesn't
        use linear scan for register allocation. Instead of linear scan, Air-O0 does
        mostly block-local register allocation, and it does this as it's emitting
        code directly. The register allocator uses liveness analysis to reduce
        the number of spills. Doing register allocation as we're emitting code
        allows us to skip editing the IR to insert spills, which saves a non trivial
        amount of compile time. For stack allocation, we give each Tmp its own slot.
        This is less than ideal. We probably want to do some trivial live range analysis
        in the future. The reason this isn't a deal breaker for Wasm is that this patch
        makes it so that we reuse Tmps as we're generating Air IR in the AirIRGenerator.
        Because Wasm is a stack machine, we trivially know when we kill a stack value (its last use).
        
        This patch is another 25% Wasm startup time speedup. It seems to be worth
        another 1% on JetStream2.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: Added.
        (JSC::B3::Air::GenerateAndAllocateRegisters::GenerateAndAllocateRegisters):
        (JSC::B3::Air::GenerateAndAllocateRegisters::buildLiveRanges):
        (JSC::B3::Air::GenerateAndAllocateRegisters::insertBlocksForFlushAfterTerminalPatchpoints):
        (JSC::B3::Air::callFrameAddr):
        (JSC::B3::Air::GenerateAndAllocateRegisters::flush):
        (JSC::B3::Air::GenerateAndAllocateRegisters::spill):
        (JSC::B3::Air::GenerateAndAllocateRegisters::alloc):
        (JSC::B3::Air::GenerateAndAllocateRegisters::freeDeadTmpsIfNeeded):
        (JSC::B3::Air::GenerateAndAllocateRegisters::assignTmp):
        (JSC::B3::Air::GenerateAndAllocateRegisters::isDisallowedRegister):
        (JSC::B3::Air::GenerateAndAllocateRegisters::prepareForGeneration):
        (JSC::B3::Air::GenerateAndAllocateRegisters::generate):
        * b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: Added.
        * b3/air/AirCode.cpp:
        * b3/air/AirCode.h:
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        (JSC::B3::Air::generateWithAlreadyAllocatedRegisters):
        (JSC::B3::Air::generate):
        * b3/air/AirHandleCalleeSaves.cpp:
        (JSC::B3::Air::handleCalleeSaves):
        * b3/air/AirHandleCalleeSaves.h:
        * b3/air/AirTmpMap.h:
        * runtime/Options.h:
        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::didKill):
        (JSC::Wasm::AirIRGenerator::newTmp):
        (JSC::Wasm::AirIRGenerator::AirIRGenerator):
        (JSC::Wasm::parseAndCompileAir):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF32>):
        * wasm/WasmAirIRGenerator.h:
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::didKill):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::compileFunctions):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseBody):
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::didKill):

2019-02-14  Saam barati  <sbarati@apple.com>

        lowerStackArgs should lower Lea32/64 on ARM64 to Add
        https://bugs.webkit.org/show_bug.cgi?id=194656

        Reviewed by Yusuke Suzuki.

        On arm64, Lea is just implemented as an add. However, Air treats it as an
        address with a given width. Because of this width, we were incorrectly
        computing whether or not this immediate could fit into the instruction itself
        or it needed to be explicitly put into a register. This patch makes
        AirLowerStackArgs lower Lea to Add on arm64.

        * b3/air/AirLowerStackArgs.cpp:
        (JSC::B3::Air::lowerStackArgs):
        * b3/air/AirOpcode.opcodes:
        * b3/air/testair.cpp:

2019-02-14  Saam Barati  <sbarati@apple.com>

        Cache the results of BytecodeGenerator::getVariablesUnderTDZ
        https://bugs.webkit.org/show_bug.cgi?id=194583
        <rdar://problem/48028140>

        Reviewed by Yusuke Suzuki.

        This patch makes it so that getVariablesUnderTDZ caches a result of
        CompactVariableMap::Handle. getVariablesUnderTDZ is costly when
        it's called in an environment where there are a lot of variables.
        This patch makes it so we cache its results. This is profitable when
        getVariablesUnderTDZ is called repeatedly with the same environment
        state. This is common since we call this every time we encounter a
        function definition/expression node.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::popLexicalScopeInternal):
        (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
        (JSC::BytecodeGenerator::pushTDZVariables):
        (JSC::BytecodeGenerator::getVariablesUnderTDZ):
        (JSC::BytecodeGenerator::restoreTDZStack):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::makeFunction):
        * parser/VariableEnvironment.cpp:
        (JSC::CompactVariableMap::Handle::Handle):
        (JSC::CompactVariableMap::Handle::operator=):
        * parser/VariableEnvironment.h:
        (JSC::CompactVariableMap::Handle::operator bool const):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):

2019-02-14  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Non-JIT entrypoints should share NativeJITCode per entrypoint type
        https://bugs.webkit.org/show_bug.cgi?id=194659

        Reviewed by Mark Lam.

        Non-JIT entrypoints create NativeJITCode every time it is called. But it is meaningless since these entry point code are identical.
        We should create one per entrypoint type (for function, we should have CodeForCall and CodeForConstruct) and continue to use them.
        And we use NativeJITCode instead of DirectJITCode if it does not have difference between usual entrypoint and arity check entrypoint.

        * dfg/DFGJITCode.h:
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        * jit/JITCode.cpp:
        (JSC::DirectJITCode::initializeCodeRefForDFG):
        (JSC::DirectJITCode::initializeCodeRef): Deleted.
        (JSC::NativeJITCode::initializeCodeRef): Deleted.
        * jit/JITCode.h:
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        (JSC::LLInt::setModuleProgramEntrypoint): Retagged is removed since the tag is the same.

2019-02-14  Ross Kirsling  <ross.kirsling@sony.com>

        [WTF] Add environment variable helpers
        https://bugs.webkit.org/show_bug.cgi?id=192405

        Reviewed by Michael Catanzaro.

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::RemoteInspector):
        (Inspector::RemoteInspector::start):
        * jsc.cpp:
        (startTimeoutThreadIfNeeded):
        * runtime/Options.cpp:
        (JSC::overrideOptionWithHeuristic):
        (JSC::Options::overrideAliasedOptionWithHeuristic):
        (JSC::Options::initialize):
        * runtime/VM.cpp:
        (JSC::enableAssembler):
        (JSC::VM::VM):
        * tools/CodeProfiling.cpp:
        (JSC::CodeProfiling::notifyAllocator):
        Utilize WTF::Environment where possible.

2019-02-14  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Should have default NativeJITCode
        https://bugs.webkit.org/show_bug.cgi?id=194634

        Reviewed by Mark Lam.

        In JSC_useJIT=false mode, we always create identical NativeJITCode for call and construct when we create NativeExecutable.
        This is meaningless since we do not modify NativeJITCode after the creation. This patch adds singleton used as a default one.
        Since NativeJITCode (& JITCode) is ThreadSafeRefCounted, we can just share it in a whole process level. This removes 446 NativeJITCode
        allocations, which takes 14KB.

        * runtime/VM.cpp:
        (JSC::jitCodeForCallTrampoline):
        (JSC::jitCodeForConstructTrampoline):
        (JSC::VM::getHostFunction):

2019-02-14  Tadeu Zagallo  <tzagallo@apple.com>

        generateUnlinkedCodeBlockForFunctions shouldn't need to create a FunctionExecutable just to get its source code
        https://bugs.webkit.org/show_bug.cgi?id=194576

        Reviewed by Saam Barati.

        Extract a new function, `linkedSourceCode` from UnlinkedFunctionExecutable::link
        and use it in `generateUnlinkedCodeBlockForFunctions` instead.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::linkedSourceCode const):
        (JSC::UnlinkedFunctionExecutable::link):
        * bytecode/UnlinkedFunctionExecutable.h:
        * runtime/CodeCache.cpp:
        (JSC::generateUnlinkedCodeBlockForFunctions):

2019-02-14  Tadeu Zagallo  <tzagallo@apple.com>

        CachedBitVector's size must be converted from bits to bytes
        https://bugs.webkit.org/show_bug.cgi?id=194441

        Reviewed by Saam Barati.

        CachedBitVector used its size in bits for memcpy. That didn't cause any
        issues when encoding, since the size in bits was also used in the allocation,
        but would overflow the actual BitVector buffer when decoding.

        * runtime/CachedTypes.cpp:
        (JSC::CachedBitVector::encode):
        (JSC::CachedBitVector::decode const):

2019-02-13  Brian Burg  <bburg@apple.com>

        Web Inspector: don't include accessibility role in DOM.Node object payloads
        https://bugs.webkit.org/show_bug.cgi?id=194623
        <rdar://problem/36384037>

        Reviewed by Devin Rousso.

        Remove property of DOM.Node that is no longer being sent.

        * inspector/protocol/DOM.json:

2019-02-13  Keith Miller  <keith_miller@apple.com> and Yusuke Suzuki  <ysuzuki@apple.com>

        We should only make rope strings when concatenating strings long enough.
        https://bugs.webkit.org/show_bug.cgi?id=194465

        Reviewed by Mark Lam.

        This patch stops us from allocating a rope string if the resulting
        rope would be smaller than the size of the JSRopeString object we
        would need to allocate.

        This patch also adds paths so that we don't unnecessarily allocate
        JSString cells for primitives we are going to concatenate with a
        string anyway.

        The important change from the previous one is that we do not apply
        the above rule to JSRopeStrings generated by JSStrings. If we convert
        it to JSString, comparison of memory consumption becomes the following,
        because JSRopeString does not have StringImpl until it is resolved.

            sizeof(JSRopeString) v.s. sizeof(JSString) + sizeof(StringImpl) + content

        Since sizeof(JSString) + sizeof(StringImpl) is larger than sizeof(JSRopeString),
        resolving eagerly increases memory footprint. The point is that we need to
        account newly created JSString and JSRopeString from the operands. This is the
        reason why this patch adds different thresholds for each jsString functions.

        This patch also avoids concatenation for ropes conservatively. Many ropes are
        temporary cells. So we do not resolve eagerly if one of operands is already a
        rope.

        In CLI execution, this change is performance neutral in JetStream2 (run 6 times, 1 for warming up and average in latter 5.).

            Before: 159.3778
            After:  160.72340000000003

        * dfg/DFGOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSString.h:
        (JSC::JSString::isRope const):
        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):
        * runtime/Operations.h:
        (JSC::jsString):
        (JSC::jsAddNonNumber):
        (JSC::jsAdd):

2019-02-13  Saam Barati  <sbarati@apple.com>

        AirIRGenerator::addSwitch switch patchpoint needs to model clobbering the scratch register
        https://bugs.webkit.org/show_bug.cgi?id=194610

        Reviewed by Michael Saboff.

        BinarySwitch might use the scratch register. We must model the
        effects of that properly. This is already caught by our br-table
        tests on arm64.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::addSwitch):

2019-02-13  Mark Lam  <mark.lam@apple.com>

        Create a randomized free list for new StructureIDs on StructureIDTable resize.
        https://bugs.webkit.org/show_bug.cgi?id=194566
        <rdar://problem/47975502>

        Reviewed by Michael Saboff.

        Also isolate 32-bit implementation of StructureIDTable out more so the 64-bit
        implementation is a little easier to read.

        This patch appears to be perf neutral on JetStream2 (as run from the command line).

        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::StructureIDTable):
        (JSC::StructureIDTable::makeFreeListFromRange):
        (JSC::StructureIDTable::resize):
        (JSC::StructureIDTable::allocateID):
        (JSC::StructureIDTable::deallocateID):
        * runtime/StructureIDTable.h:
        (JSC::StructureIDTable::get):
        (JSC::StructureIDTable::deallocateID):
        (JSC::StructureIDTable::allocateID):
        (JSC::StructureIDTable::flushOldTables):

2019-02-13  Tadeu Zagallo  <tzagallo@apple.com>

        VariableLengthObject::allocate<T> should initialize objects
        https://bugs.webkit.org/show_bug.cgi?id=194534

        Reviewed by Michael Saboff.

        `buffer()` should not be called for empty VariableLengthObjects, but
        these cases were not being caught due to the objects not being properly
        initialized. Fix it so that allocate calls the constructor and fix the
        assertion failues.

        * runtime/CachedTypes.cpp:
        (JSC::CachedObject::operator new):
        (JSC::VariableLengthObject::allocate):
        (JSC::CachedVector::encode):
        (JSC::CachedVector::decode const):
        (JSC::CachedUniquedStringImpl::decode const):
        (JSC::CachedBitVector::encode):
        (JSC::CachedBitVector::decode const):
        (JSC::CachedArray::encode):
        (JSC::CachedArray::decode const):
        (JSC::CachedImmutableButterfly::CachedImmutableButterfly):
        (JSC::CachedBigInt::decode const):

2019-02-13  Tadeu Zagallo  <tzagallo@apple.com>

        CodeBlocks read from disk should not be re-written
        https://bugs.webkit.org/show_bug.cgi?id=194535

        Reviewed by Michael Saboff.

        Keep track of which CodeBlocks have been read from disk or have already
        been serialized in CodeCache.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::write):
        * runtime/CodeCache.h:
        (JSC::SourceCodeValue::SourceCodeValue):
        (JSC::CodeCacheMap::fetchFromDiskImpl):

2019-02-13  Tadeu Zagallo  <tzagallo@apple.com>

        SourceCode should be copied when generating bytecode for functions
        https://bugs.webkit.org/show_bug.cgi?id=194536

        Reviewed by Saam Barati.

        The FunctionExecutable might be collected while generating the bytecode
        for nested functions, in which case the SourceCode reference would no
        longer be valid.

        * runtime/CodeCache.cpp:
        (JSC::generateUnlinkedCodeBlockForFunctions):

2019-02-12  Saam barati  <sbarati@apple.com>

        JSScript needs to retain its cache path NSURL*
        https://bugs.webkit.org/show_bug.cgi?id=194577

        Reviewed by Tim Horton.

        * API/JSScript.mm:
        (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
        (-[JSScript dealloc]):

2019-02-12  Robin Morisset  <rmorisset@apple.com>

        Make B3Value::returnsBool() more precise
        https://bugs.webkit.org/show_bug.cgi?id=194457

        Reviewed by Saam Barati.

        It is currently used repeatedly in B3ReduceStrength, as well as once in B3LowerToAir.
        It has a needlessly complex rule for BitAnd, and has no rule for other easy cases such as BitOr or Select.
        No new tests added as this should be indirectly tested by the already existing tests.

        * b3/B3Value.cpp:
        (JSC::B3::Value::returnsBool const):

2019-02-12  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, fix -Wimplicit-fallthrough warning after r241140
        https://bugs.webkit.org/show_bug.cgi?id=194399
        <rdar://problem/47889777>

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-02-12  Michael Catanzaro  <mcatanzaro@igalia.com>

        [WPE][GTK] Unsafe g_unsetenv() use in WebProcessPool::platformInitialize
        https://bugs.webkit.org/show_bug.cgi?id=194370

        Reviewed by Darin Adler.

        Change a couple WTFLogAlways to use g_warning, for good measure. Of course this isn't
        necessary, but it will make errors more visible.

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::start):
        (Inspector::dbusConnectionCallAsyncReadyCallback):
        * inspector/remote/glib/RemoteInspectorServer.cpp:
        (Inspector::RemoteInspectorServer::start):

2019-02-12  Andy Estes  <aestes@apple.com>

        [iOSMac] Enable Parental Controls Content Filtering
        https://bugs.webkit.org/show_bug.cgi?id=194521
        <rdar://39732376>

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

2019-02-11  Mark Lam  <mark.lam@apple.com>

        Randomize insertion of deallocated StructureIDs into the StructureIDTable's free list.
        https://bugs.webkit.org/show_bug.cgi?id=194512
        <rdar://problem/47975465>

        Reviewed by Yusuke Suzuki.

        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::StructureIDTable):
        (JSC::StructureIDTable::allocateID):
        (JSC::StructureIDTable::deallocateID):
        * runtime/StructureIDTable.h:

2019-02-10  Mark Lam  <mark.lam@apple.com>

        Remove the RELEASE_ASSERT check for duplicate cases in the BinarySwitch constructor.
        https://bugs.webkit.org/show_bug.cgi?id=194493
        <rdar://problem/36380852>

        Reviewed by Yusuke Suzuki.

        Having duplicate cases in the BinarySwitch is not a correctness issue.  It is
        however not good for performance and memory usage.  As such, a debug ASSERT will
        do.  We'll also do an audit of the clients of BinarySwitch to see if it's
        possible to be instantiated with duplicate cases in
        https://bugs.webkit.org/show_bug.cgi?id=194492 later.

        Also added some value dumps to the RELEASE_ASSERT to help debug the issue when we
        see duplicate cases.

        * jit/BinarySwitch.cpp:
        (JSC::BinarySwitch::BinarySwitch):

2019-02-10  Darin Adler  <darin@apple.com>

        Switch uses of StringBuilder with String::format for hex numbers to use HexNumber.h instead
        https://bugs.webkit.org/show_bug.cgi?id=194485

        Reviewed by Daniel Bates.

        * heap/HeapSnapshotBuilder.cpp:
        (JSC::HeapSnapshotBuilder::json): Use appendUnsignedAsHex along with
        reinterpret_cast<uintptr_t> to replace uses of String::format with "%p".

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode): Removed some unneeded casts in StringBuilder code,
        including one in a call to appendByteAsHex.
        (JSC::globalFuncEscape): Ditto.

2019-02-10  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r241230.
        https://bugs.webkit.org/show_bug.cgi?id=194488

        "It regressed JetStream2 by ~6%" (Requested by saamyjoon on
        #webkit).

        Reverted changeset:

        "We should only make rope strings when concatenating strings
        long enough."
        https://bugs.webkit.org/show_bug.cgi?id=194465
        https://trac.webkit.org/changeset/241230

2019-02-10  Saam barati  <sbarati@apple.com>

        BBQ-Air: Emit better code for switch
        https://bugs.webkit.org/show_bug.cgi?id=194053

        Reviewed by Yusuke Suzuki.

        Instead of emitting a linear set of jumps for Switch, this patch
        makes the BBQ-Air backend emit a binary switch.

        * wasm/WasmAirIRGenerator.cpp:
        (JSC::Wasm::AirIRGenerator::addSwitch):

2019-02-09  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, Lexer should use isLatin1 implementation in WTF
        https://bugs.webkit.org/show_bug.cgi?id=194466

        Follow-up after r241233 pointed by Darin.

        * parser/Lexer.cpp:
        (JSC::isLatin1): Deleted.

2019-02-09  Darin Adler  <darin@apple.com>

        Eliminate unnecessary String temporaries by using StringConcatenateNumbers
        https://bugs.webkit.org/show_bug.cgi?id=194021

        Reviewed by Geoffrey Garen.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::count): Remove String::number and let
        makeString do the conversion without allocating/destroying a String.
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::objectGroupForBreakpointAction): Ditto.
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl): Ditto.
        (Inspector::InspectorDebuggerAgent::setBreakpoint): Ditto.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty): Ditto.
        * runtime/NumberPrototype.cpp:
        (JSC::numberProtoFuncToFixed): Use String::numberToStringFixedWidth instead
        of calling numberToFixedWidthString to do the same thing.
        (JSC::numberProtoFuncToPrecision): Use String::number instead of calling
        numberToFixedPrecisionString to do the same thing.
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::reportTopFunctions): Ditto.

2019-02-09  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, rolling in r241237 again
        https://bugs.webkit.org/show_bug.cgi?id=194469

        * runtime/JSString.h:
        (JSC::jsSubstring):

2019-02-09  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r241237.
        https://bugs.webkit.org/show_bug.cgi?id=194474

        Shows significant memory increase in WSL (Requested by
        yusukesuzuki on #webkit).

        Reverted changeset:

        "[WTF] Use BufferInternal StringImpl if substring StringImpl
        takes more memory"
        https://bugs.webkit.org/show_bug.cgi?id=194469
        https://trac.webkit.org/changeset/241237

2019-02-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [WTF] Use BufferInternal StringImpl if substring StringImpl takes more memory
        https://bugs.webkit.org/show_bug.cgi?id=194469

        Reviewed by Geoffrey Garen.

        * runtime/JSString.h:
        (JSC::jsSubstring):

2019-02-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] CachedTypes should use jsString instead of JSString::create
        https://bugs.webkit.org/show_bug.cgi?id=194471

        Reviewed by Mark Lam.

        Use jsString() here because JSString::create is a bit low-level API and it requires some invariant like "length is not zero".

        * runtime/CachedTypes.cpp:
        (JSC::CachedJSValue::decode const):

2019-02-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Increase StructureIDTable initial capacity
        https://bugs.webkit.org/show_bug.cgi?id=194468

        Reviewed by Mark Lam.

        Currently, # of structures just after initializing JSGlobalObject (precisely, initializing GlobalObject in
        JSC shell), 281, already exceeds the current initial value 256. We should increase the capacity since
        unnecessary resizing requires more operations, keeps old StructureID array until GC happens, and makes
        more memory dirty. We also remove some structures that are no longer used.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::callbackObjectStructure const):
        (JSC::JSGlobalObject::propertyNameIteratorStructure const): Deleted.
        * runtime/StructureIDTable.h:
        * runtime/VM.h:

2019-02-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] String.fromCharCode's slow path always generates 16bit string
        https://bugs.webkit.org/show_bug.cgi?id=194466

        Reviewed by Keith Miller.

        String.fromCharCode(a1) has a fast path and the most frequently used. And String.fromCharCode(a1, a2, ...)
        goes to the slow path. However, in the slow path, we always create 16bit string. 16bit string takes 2x memory,
        and even worse, taints ropes 16bit if 16bit string is included in the given rope. We find that acorn-wtb
        creates very large strings multiple times with String.fromCharCode, and String.fromCharCode always produces
        16bit string. However, only few strings are actually 16bit strings. This patch attempts to make 8bit string
        as much as possible.

        It improves non JIT acorn-wtb's peak and current memory footprint by 6% and 3% respectively.

        * runtime/StringConstructor.cpp:
        (JSC::stringFromCharCode):

2019-02-08  Keith Miller  <keith_miller@apple.com>

        We should only make rope strings when concatenating strings long enough.
        https://bugs.webkit.org/show_bug.cgi?id=194465

        Reviewed by Saam Barati.

        This patch stops us from allocating a rope string if the resulting
        rope would be smaller than the size of the JSRopeString object we
        would need to allocate.

        This patch also adds paths so that we don't unnecessarily allocate
        JSString cells for primitives we are going to concatenate with a
        string anyway.

        * dfg/DFGOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSString.h:
        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):
        * runtime/Operations.h:
        (JSC::jsString):
        (JSC::jsAdd):

2019-02-08  Saam barati  <sbarati@apple.com>

        Nodes that rely on being dominated by CheckInBounds should have a child edge to it
        https://bugs.webkit.org/show_bug.cgi?id=194334
        <rdar://problem/47844327>

        Reviewed by Mark Lam.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::convertToHasIndexedProperty):
        * dfg/DFGIntegerCheckCombiningPhase.cpp:
        (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
        * dfg/DFGIntegerRangeOptimizationPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGSSALoweringPhase.cpp:
        (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileCheckInBounds):
        (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):

2019-02-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink sizeof(CodeBlock) more
        https://bugs.webkit.org/show_bug.cgi?id=194419

        Reviewed by Mark Lam.

        This patch further shrinks the size of CodeBlock, from 352 to 296 (304).

        1. CodeBlock copies so many data from ScriptExecutable even if ScriptExecutable
        has the same information. These data is not touched in CodeBlock::~CodeBlock,
        so we can just use the data in ScriptExecutable instead of holding it in CodeBlock.

        2. We remove m_instructions pointer since the ownership is managed by UnlinkedCodeBlock.
        And we do not touch it in CodeBlock::~CodeBlock.

        3. We move m_calleeSaveRegisters from CodeBlock to CodeBlock::JITData. For baseline and LLInt
        cases, this patch offers RegisterAtOffsetList::llintBaselineCalleeSaveRegisters() which returns
        singleton to `const RegisterAtOffsetList*` usable for LLInt and Baseline JIT CodeBlocks.

        4. Move m_catchProfiles to RareData and materialize only when op_catch's slow path is called.

        5. Drop ownerScriptExecutable. ownerExecutable() returns ScriptExecutable*.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::hash const):
        (JSC::CodeBlock::sourceCodeForTools const):
        (JSC::CodeBlock::dumpAssumingJITType const):
        (JSC::CodeBlock::dumpSource):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::setCalleeSaveRegisters):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
        (JSC::CodeBlock::lineNumberForBytecodeOffset):
        (JSC::CodeBlock::expressionRangeForBytecodeOffset const):
        (JSC::CodeBlock::hasOpDebugForLineAndColumn):
        (JSC::CodeBlock::newReplacement):
        (JSC::CodeBlock::replacement):
        (JSC::CodeBlock::computeCapabilityLevel):
        (JSC::CodeBlock::jettison):
        (JSC::CodeBlock::calleeSaveRegisters const):
        (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
        (JSC::CodeBlock::getArrayProfile):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::notifyLexicalBindingUpdate):
        (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
        (JSC::CodeBlock::validate):
        (JSC::CodeBlock::outOfLineJumpTarget):
        (JSC::CodeBlock::arithProfileForBytecodeOffset):
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::specializationKind const):
        (JSC::CodeBlock::isStrictMode const):
        (JSC::CodeBlock::isConstructor const):
        (JSC::CodeBlock::codeType const):
        (JSC::CodeBlock::isKnownNotImmediate):
        (JSC::CodeBlock::instructions const):
        (JSC::CodeBlock::ownerExecutable const):
        (JSC::CodeBlock::thisRegister const):
        (JSC::CodeBlock::source const):
        (JSC::CodeBlock::sourceOffset const):
        (JSC::CodeBlock::firstLineColumnOffset const):
        (JSC::CodeBlock::createRareDataIfNecessary):
        (JSC::CodeBlock::ownerScriptExecutable const): Deleted.
        (JSC::CodeBlock::setThisRegister): Deleted.
        (JSC::CodeBlock::calleeSaveRegisters const): Deleted.
        * bytecode/EvalCodeBlock.h:
        * bytecode/FunctionCodeBlock.h:
        * bytecode/GlobalCodeBlock.h:
        (JSC::GlobalCodeBlock::GlobalCodeBlock):
        * bytecode/ModuleProgramCodeBlock.h:
        * bytecode/ProgramCodeBlock.h:
        * debugger/Debugger.cpp:
        (JSC::Debugger::toggleBreakpoint):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::sourceID const):
        (JSC::DebuggerCallFrame::sourceIDForCallFrame):
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::location const):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::isSupportedForInlining):
        (JSC::DFG::mightCompileEval):
        (JSC::DFG::mightCompileProgram):
        (JSC::DFG::mightCompileFunctionForCall):
        (JSC::DFG::mightCompileFunctionForConstruct):
        (JSC::DFG::canUseOSRExitFuzzing):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::executableFor):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::restoreCalleeSavesFor):
        (JSC::DFG::saveCalleeSavesFor):
        (JSC::DFG::saveOrCopyCalleeSavesFor):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        * dfg/DFGOperations.cpp:
        * dfg/DFGToFTLDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::callerSourceOrigin):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::calleeSaveRegisters):
        (JSC::StackVisitor::Frame::sourceURL const):
        (JSC::StackVisitor::Frame::sourceID):
        (JSC::StackVisitor::Frame::computeLineAndColumn const):
        * interpreter/StackVisitor.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
        (JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor):
        (JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
        * jit/CallFrameShuffleData.cpp:
        (JSC::CallFrameShuffleData::setupCalleeSaveRegisters):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/JITToDFGDeferredCompilationCallback.cpp:
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
        * jit/JITWorklist.cpp:
        (JSC::JITWorklist::Plan::finalize):
        (JSC::JITWorklist::compileNow):
        * jit/RegisterAtOffsetList.cpp:
        (JSC::RegisterAtOffsetList::llintBaselineCalleeSaveRegisters):
        * jit/RegisterAtOffsetList.h:
        (JSC::RegisterAtOffsetList::at const):
        * runtime/ErrorInstance.cpp:
        (JSC::appendSourceToError):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::sourceID const):
        (JSC::StackFrame::sourceURL const):
        (JSC::StackFrame::computeLineAndColumn const):

2019-02-08  Robin Morisset  <rmorisset@apple.com>

        B3LowerMacros wrongly sets m_changed to true in the case of AtomicWeakCAS on x86
        https://bugs.webkit.org/show_bug.cgi?id=194460

        Reviewed by Mark Lam.

        Trivial fix, should already be covered by testAtomicWeakCAS in testb3.cpp.

        * b3/B3LowerMacros.cpp:

2019-02-08  Mark Lam  <mark.lam@apple.com>

        Use maxSingleCharacterString in comparisons instead of literal constants.
        https://bugs.webkit.org/show_bug.cgi?id=194452

        Reviewed by Yusuke Suzuki.

        This way, if we ever change maxSingleCharacterString, it won't break all this code
        that relies on it being 0xff implicitly.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStringSlice):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
        * jit/ThunkGenerators.cpp:
        (JSC::stringGetByValGenerator):
        (JSC::charToString):

2019-02-08  Mark Lam  <mark.lam@apple.com>

        Fix DFG's doesGC() for CheckTierUp*, GetByVal, PutByVal*, and StringCharAt nodes.
        https://bugs.webkit.org/show_bug.cgi?id=194446
        <rdar://problem/47926792>

        Reviewed by Saam Barati.

        Fix doesGC() for the following nodes:

            CheckTierUpAtReturn:
                Calls triggerTierUpNow(), which calls triggerFTLReplacementCompile(),
                which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC.

            CheckTierUpInLoop:
                Calls triggerTierUpNowInLoop(), which calls tierUpCommon(), which calls
                Worklist::completeAllReadyPlansForVM(), which uses DeferGC.

            CheckTierUpAndOSREnter:
                Calls triggerOSREntryNow(), which calls tierUpCommon(), which calls
                Worklist::completeAllReadyPlansForVM(), which uses DeferGC.

            GetByVal:
                case Array::String calls operationSingleCharacterString(), which calls
                jsSingleCharacterString(), which can allocate a string.

            PutByValDirect:
            PutByVal:
            PutByValAlias:
                For the DFG only, the integer TypeArrays calls compilePutByValForIntTypedArray(),
                which may call slow paths operationPutByValDirectStrict(), operationPutByValDirectNonStrict(),
                operationPutByValStrict(), or operationPutByValNonStrict().  All of these
                slow paths call putByValInternal(), which may create exception objects, or
                call the generic JSValue::put() which may execute arbitrary code.

            StringCharAt:
                Can call operationSingleCharacterString(), which calls jsSingleCharacterString(),
                which can allocate a string.

        Also fix DFG::SpeculativeJIT::compileGetByValOnString() and FTL's compileStringCharAt()
        to use the maxSingleCharacterString constant instead of a literal constant.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):

2019-02-08  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] SourceProviderCacheItem should be small
        https://bugs.webkit.org/show_bug.cgi?id=194432

        Reviewed by Saam Barati.

        Some JetStream2 tests stress the JS parser. At that time, so many SourceProviderCacheItems are created.
        While they are removed when full-GC happens, it significantly increases the peak memory usage.
        This patch reduces the size of SourceProviderCacheItem from 56 to 32.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/ParserModes.h:
        * parser/ParserTokens.h:
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::endFunctionToken const):
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):

2019-02-07  Robin Morisset  <rmorisset@apple.com>

        Fix Abs(Neg(x)) -> Abs(x) optimization in B3ReduceStrength
        https://bugs.webkit.org/show_bug.cgi?id=194420

        Reviewed by Saam Barati.

        In https://bugs.webkit.org/show_bug.cgi?id=194250, I added an optimization: Abs(Neg(x)) -> Abs(x).
        But I introduced two bugs, one is that I actually implemented Abs(Neg(x)) -> x, and the other is that the test is looking at Abs(Abs(x)) instead (both were stupid copy-paste mistakes).
        This trivial patch fixes both.

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testAbsNegArg):

2019-02-07  Keith Miller  <keith_miller@apple.com>

        Better error messages for module loader SPI
        https://bugs.webkit.org/show_bug.cgi?id=194421

        Reviewed by Saam Barati.

        * API/JSAPIGlobalObject.mm:
        (JSC::JSAPIGlobalObject::moduleLoaderImportModule):

2019-02-07  Mark Lam  <mark.lam@apple.com>

        Fix more doesGC() for CheckTraps, GetMapBucket, and Switch nodes.
        https://bugs.webkit.org/show_bug.cgi?id=194399
        <rdar://problem/47889777>

        Reviewed by Yusuke Suzuki.

        Fix doesGC() for the following nodes:

            CheckTraps:
                We normally will not emit this node because Options::usePollingTraps() is
                false by default.  However, as it is implemented now, CheckTraps can GC
                because it can allocate a TerminatedExecutionException.  If we make the
                TerminatedExecutionException a singleton allocated at initialization time,
                doesGC() can return false for CheckTraps.
                https://bugs.webkit.org/show_bug.cgi?id=194323

            GetMapBucket:
                Can call operationJSMapFindBucket() or operationJSSetFindBucket(),
                which calls HashMapImpl::findBucket(), which calls jsMapHash(), which
                can resolve a rope.

            Switch:
                If switchData kind is SwitchChar, can call operationResolveRope() .
                If switchData kind is SwitchString and the child use kind is not StringIdentUse,
                    can call operationSwitchString() which resolves ropes.

            DirectTailCall:
            ForceOSRExit:
            Return:
            TailCallForwardVarargs:
            TailCallVarargs:
            Throw:
                These are terminal nodes.  It shouldn't really matter what doesGC() returns
                for them, but following our conservative practice, unless we have a good
                reason for doesGC() to return false, we should just return true.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-02-07  Robin Morisset  <rmorisset@apple.com>

        B3ReduceStrength: missing peephole optimizations for Neg and Sub
        https://bugs.webkit.org/show_bug.cgi?id=194250

        Reviewed by Saam Barati.

        Adds the following optimizations for integers:
        - Sub(x, x) => 0
            Already covered by the test testSubArg
        - Sub(x1, Neg(x2)) => Add (x1, x2)
            Added test: testSubNeg
        - Neg(Sub(x1, x2)) => Sub(x2, x1)
            Added test: testNegSub
        - Add(Neg(x1), x2) => Sub(x2, x1)
            Added test: testAddNeg1
        - Add(x1, Neg(x2)) => Sub(x1, x2)
            Added test: testAddNeg2
        Adds the following optimization for floating point values:
        - Abs(Neg(x)) => Abs(x)
            Added test: testAbsNegArg
            Adds the following optimization:

        Also did some trivial refactoring, using m_value->isInteger() everywhere instead of isInt(m_value->type()), and using replaceWithNew<Value> instead of replaceWithNewValue(m_proc.add<Value(..))

        * b3/B3ReduceStrength.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testAddNeg1):
        (JSC::B3::testAddNeg2):
        (JSC::B3::testSubNeg):
        (JSC::B3::testNegSub):
        (JSC::B3::testAbsAbsArg):
        (JSC::B3::testAbsNegArg):
        (JSC::B3::run):

2019-02-06  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Use BufferInternal single character StringImpl for SmallStrings
        https://bugs.webkit.org/show_bug.cgi?id=194374

        Reviewed by Geoffrey Garen.

        Currently, we first create a large StringImpl, and create bunch of substrings with length = 1.
        But pointer is larger than single character. BufferInternal StringImpl with single character
        is more memory efficient.

        * runtime/SmallStrings.cpp:
        (JSC::SmallStringsStorage::SmallStringsStorage):
        (JSC::SmallStrings::SmallStrings):
        * runtime/SmallStrings.h:

2019-02-06  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] InitializeEntrypointArguments should produce SpecCellCheck if FlushFormat is FlushedCell
        https://bugs.webkit.org/show_bug.cgi?id=194369
        <rdar://problem/47813087>

        Reviewed by Saam Barati.

        InitializeEntrypointArguments says SpecCell if the FlushFormat is FlushedCell. But this actually has
        JSEmpty if it is TDZ. This incorrectly proved type information removes necessary CheckNotEmpty in
        constant folding phase.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2019-02-06  Devin Rousso  <drousso@apple.com>

        Web Inspector: DOM: don't send the entire function string with each event listener
        https://bugs.webkit.org/show_bug.cgi?id=194293
        <rdar://problem/47822809>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:

        * runtime/JSFunction.h:
        Export `calculatedDisplayName`.

2019-02-06  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] PrivateName to PublicName hash table is wasteful
        https://bugs.webkit.org/show_bug.cgi?id=194277

        Reviewed by Michael Saboff.

        PrivateNames account for a lot of memory in the initial JSC footprint. BuiltinNames have Identifier fields corresponding to these PrivateNames
        which makes the sizeof(BuiltinNames) about 6KB. It also maintains hash tables for "PublicName to PrivateName" and "PrivateName to PublicName",
        each of which takes 16KB memory. While "PublicName to PrivateName" functionality is used in builtin JS (parsing "@xxx" and get a private
        name for "xxx"), "PrivateName to PublicName" is rarely used. Holding 16KB hash table for rarely used feature is costly.

        In this patch, we add some rules to remove "PrivateName to PublicName" hash table.

        1. PrivateName's content should be the same to PublicName.
        2. If PrivateName is not actually a private name (we introduced hacky mapping like "@iteratorSymbol" => Symbol.iterator),
           the public name should be easily crafted from the given PrivateName.

        We modify the content of private names to ensure (1). And for (2), we can meet this requirement by ensuring that the "@xxxSymbol"
        is converted to "Symbol.xxx". (1) and (2) allow us to convert a private name to a public name without a large hash table.

        We also remove unused identifiers in CommonIdentifiers. And we also move some of them to WebCore's WebCoreBuiltinNames if it is only used in
        WebCore.

        * builtins/BuiltinNames.cpp:
        (JSC::BuiltinNames::BuiltinNames):
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::lookUpPrivateName const):
        (JSC::BuiltinNames::getPublicName const):
        (JSC::BuiltinNames::checkPublicToPrivateMapConsistency):
        (JSC::BuiltinNames::appendExternalName):
        (JSC::BuiltinNames::lookUpPublicName const): Deleted.
        * builtins/BuiltinUtils.h:
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpIdentifiers):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_getByIdDirectPrivate):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirectPrivate):
        * parser/Lexer.cpp:
        (JSC::Lexer<LChar>::parseIdentifier):
        (JSC::Lexer<UChar>::parseIdentifier):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClassDeclaration):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/ParserArena.h:
        (JSC::IdentifierArena::makeIdentifier):
        * runtime/CachedTypes.cpp:
        (JSC::CachedUniquedStringImpl::encode):
        (JSC::CachedUniquedStringImpl::decode const):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers):
        (JSC::CommonIdentifiers::lookUpPrivateName const):
        (JSC::CommonIdentifiers::getPublicName const):
        (JSC::CommonIdentifiers::lookUpPublicName const): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/ExceptionHelpers.cpp:
        (JSC::createUndefinedVariableError):
        * runtime/Identifier.cpp:
        (JSC::Identifier::dump const):
        * runtime/Identifier.h:
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::fromUid):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * tools/JSDollarVM.cpp:
        (JSC::functionGetPrivateProperty):

2019-02-06  Keith Rollin  <krollin@apple.com>

        Really enable the automatic checking and regenerations of .xcfilelists during builds
        https://bugs.webkit.org/show_bug.cgi?id=194357
        <rdar://problem/47861231>

        Reviewed by Chris Dumez.

        Bug 194124 was supposed to enable the automatic checking and
        regenerating of .xcfilelist files during the build. While related
        changes were included in that patch, the change to actually enable the
        operation somehow was omitted. This patch actually enables the
        operation. The check-xcfilelist.sh scripts now check
        WK_DISABLE_CHECK_XCFILELISTS, and if it's "1", opts-out the developer
        from the checking.

        * Scripts/check-xcfilelists.sh:

2019-02-06  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Unify indirectEvalExecutableSpace and directEvalExecutableSpace
        https://bugs.webkit.org/show_bug.cgi?id=194339

        Reviewed by Michael Saboff.

        DirectEvalExecutable and IndirectEvalExecutable have completely same memory layout.
        They have even the same structure. This patch unifies the subspaces for them.

        * runtime/DirectEvalExecutable.h:
        * runtime/EvalExecutable.h:
        (JSC::EvalExecutable::subspaceFor):
        * runtime/IndirectEvalExecutable.h:
        * runtime/VM.cpp:
        * runtime/VM.h:
        (JSC::VM::forEachScriptExecutableSpace):

2019-02-06  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] NativeExecutable should be smaller
        https://bugs.webkit.org/show_bug.cgi?id=194331

        Reviewed by Michael Saboff.

        NativeExecutable takes 88 bytes now. Since our GC rounds the size with 16, it actually takes 96 bytes in IsoSubspaces.
        Since a lot of NativeExecutable are allocated, we already has two MarkedBlocks even just after JSGlobalObject initialization.
        This patch makes sizeof(NativeExecutable) 64 bytes, which is 32 bytes smaller than 96 bytes. Now our JSGlobalObject initialization
        only takes one MarkedBlock for NativeExecutable.

        To make NativeExecutable smaller,

        1. m_numParametersForCall and m_numParametersForConstruct in ExecutableBase are only meaningful in ScriptExecutable subclasses. Since
           they are not touched from JIT, we can remove them from ExecutableBase and move them to ScriptExecutable.

        2. DOMJIT::Signature* is rarely used. Rather than having it in NativeExecutable, we should put it in NativeJITCode. Since NativeExecutable
           always has JITCode, we can safely query the value from NativeExecutable. This patch creates NativeDOMJITCode, which is a subclass of
           NativeJITCode, and instantiated only when DOMJIT::Signature* is given.

        3. Move Intrinsic to a member of ScriptExecutable or JITCode. Since JITCode has some paddings to put things, we can leverage this to put
           Intrinsic for NativeExecutable.

        We also move "clearCode" code from ExecutableBase to ScriptExecutable since it is only valid for ScriptExecutable subclasses.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CallVariant.h:
        * interpreter/Interpreter.cpp:
        * jit/JITCode.cpp:
        (JSC::DirectJITCode::DirectJITCode):
        (JSC::NativeJITCode::NativeJITCode):
        (JSC::NativeDOMJITCode::NativeDOMJITCode):
        * jit/JITCode.h:
        (JSC::JITCode::signature const):
        (JSC::JITCode::intrinsic):
        * jit/JITOperations.cpp:
        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):
        * jit/Repatch.cpp:
        * llint/LLIntSlowPaths.cpp:
        * runtime/ExecutableBase.cpp:
        (JSC::ExecutableBase::dump const):
        (JSC::ExecutableBase::hashFor const):
        (JSC::ExecutableBase::hasClearableCode const): Deleted.
        (JSC::ExecutableBase::clearCode): Deleted.
        * runtime/ExecutableBase.h:
        (JSC::ExecutableBase::ExecutableBase):
        (JSC::ExecutableBase::isModuleProgramExecutable):
        (JSC::ExecutableBase::isHostFunction const):
        (JSC::ExecutableBase::generatedJITCodeForCall const):
        (JSC::ExecutableBase::generatedJITCodeForConstruct const):
        (JSC::ExecutableBase::generatedJITCodeFor const):
        (JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
        (JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
        (JSC::ExecutableBase::generatedJITCodeFor): Deleted.
        (JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
        (JSC::ExecutableBase::hasJITCodeForCall const): Deleted.
        (JSC::ExecutableBase::hasJITCodeForConstruct const): Deleted.
        (JSC::ExecutableBase::intrinsic const): Deleted.
        * runtime/ExecutableBaseInlines.h: Added.
        (JSC::ExecutableBase::intrinsic const):
        (JSC::ExecutableBase::hasJITCodeForCall const):
        (JSC::ExecutableBase::hasJITCodeForConstruct const):
        * runtime/JSBoundFunction.cpp:
        * runtime/JSType.cpp:
        (WTF::printInternal):
        * runtime/JSType.h:
        * runtime/NativeExecutable.cpp:
        (JSC::NativeExecutable::create):
        (JSC::NativeExecutable::createStructure):
        (JSC::NativeExecutable::NativeExecutable):
        (JSC::NativeExecutable::signatureFor const):
        (JSC::NativeExecutable::intrinsic const):
        * runtime/NativeExecutable.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::ScriptExecutable::clearCode):
        (JSC::ScriptExecutable::installCode):
        (JSC::ScriptExecutable::hasClearableCode const):
        * runtime/ScriptExecutable.h:
        (JSC::ScriptExecutable::intrinsic const):
        (JSC::ScriptExecutable::hasJITCodeForCall const):
        (JSC::ScriptExecutable::hasJITCodeForConstruct const):
        * runtime/VM.cpp:
        (JSC::VM::getHostFunction):

2019-02-06  Pablo Saavedra  <psaavedra@igalia.com>

        Build failure after r240431
        https://bugs.webkit.org/show_bug.cgi?id=194330

        Reviewed by Žan Doberšek.

        * API/glib/JSCOptions.cpp:

2019-02-05  Mark Lam  <mark.lam@apple.com>

        Fix DFG's doesGC() for a few more nodes.
        https://bugs.webkit.org/show_bug.cgi?id=194307
        <rdar://problem/47832956>

        Reviewed by Yusuke Suzuki.

        Fix doesGC() for the following nodes:

            NumberToStringWithValidRadixConstant:
                Calls operationInt32ToStringWithValidRadix(), which calls int32ToString(),
                which can allocate a string.
                Calls operationInt52ToStringWithValidRadix(), which calls int52ToString(),
                which can allocate a string.
                Calls operationDoubleToStringWithValidRadix(), which calls numberToString(),
                which can allocate a string.

            RegExpExecNonGlobalOrSticky: calls createRegExpMatchesArray() which allocates
                memory for all kinds of objects.
            RegExpMatchFast: calls operationRegExpMatchFastString(), which calls
                RegExpObject::execInline() and RegExpObject::matchGlobal().  Both of
                these allocates memory for the match result.
            RegExpMatchFastGlobal: calls operationRegExpMatchFastGlobalString(), which
                calls RegExpObject's collectMatches(), which allocates an array amongst
                other objects.

            StringFromCharCode:
                If the uint32 code to convert is greater than maxSingleCharacterString,
                we'll call operationStringFromCharCode(), which calls jsSingleCharacterString(),
                which allocates a new string if the code is greater than maxSingleCharacterString.

        Also fix SpeculativeJIT::compileFromCharCode() and FTL's compileStringFromCharCode()
        to use maxSingleCharacterString instead of a literal constant.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileFromCharCode):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):

2019-02-05  Keith Rollin  <krollin@apple.com>

        Enable the automatic checking and regenerations of .xcfilelists during builds
        https://bugs.webkit.org/show_bug.cgi?id=194124
        <rdar://problem/47721277>

        Reviewed by Tim Horton.

        Bug 193790 add a facility for checking -- during build time -- that
        any needed .xcfilelist files are up-to-date and for updating them if
        they are not. This facility was initially opt-in by setting
        WK_ENABLE_CHECK_XCFILELISTS until other pieces were in place and until
        the process seemed robust. Its now time to enable this facility and
        make it opt-out. If there is a need to disable this facility, set and
        export WK_DISABLE_CHECK_XCFILELISTS=1 in your environment before
        running `make` or `build-webkit`, or before running Xcode from the
        command line.

        Additionally, remove the step that generates a list of source files
        going into the UnifiedSources build step. It's only necessarily to
        specify Sources.txt and SourcesCocoa.txt as inputs.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * UnifiedSources-input.xcfilelist: Removed.

2019-02-05  Keith Rollin  <krollin@apple.com>

        Update .xcfilelist files
        https://bugs.webkit.org/show_bug.cgi?id=194121
        <rdar://problem/47720863>

        Reviewed by Tim Horton.

        Preparatory to enabling the facility for automatically updating the
        .xcfilelist files, check in a freshly-updated set so that not everyone
        runs up against having to regenerate them themselves.

        * DerivedSources-input.xcfilelist:
        * DerivedSources-output.xcfilelist:

2019-02-05  Andy VanWagoner  <andy@vanwagoner.family>

        [INTL] improve efficiency of Intl.NumberFormat formatToParts
        https://bugs.webkit.org/show_bug.cgi?id=185557

        Reviewed by Mark Lam.

        Since field nesting depth is minimal, this algorithm should be effectively O(n),
        where n is the number of characters in the formatted string.
        It may be less memory efficient than the previous impl, since the intermediate Vector
        is the length of the string, instead of the count of the fields.

        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormat::formatToParts):
        * runtime/IntlNumberFormat.h:

2019-02-05  Mark Lam  <mark.lam@apple.com>

        Move DFG nodes that clobberize() says will write(Heap) to the doesGC() list that returns true.
        https://bugs.webkit.org/show_bug.cgi?id=194298
        <rdar://problem/47827555>

        Reviewed by Saam Barati.

        We do this for 3 reasons:
        1. It's clearer when reading doesGC()'s code that these nodes will return true.
        2. If things change in the future where clobberize() no longer reports these nodes
           as write(Heap), each node should be vetted first to make sure that it can never
           GC before being moved back to the doesGC() list that returns false.
        3. This reduces the list of nodes that we need to audit to make sure doesGC() is
           correct in its claims about the nodes' GCing possibility.

        The list of nodes moved are:

            ArrayPush
            ArrayPop
            Call
            CallEval
            CallForwardVarargs
            CallVarargs
            Construct
            ConstructForwardVarargs
            ConstructVarargs
            DefineDataProperty
            DefineAccessorProperty
            DeleteById
            DeleteByVal
            DirectCall
            DirectConstruct
            DirectTailCallInlinedCaller
            GetById
            GetByIdDirect
            GetByIdDirectFlush
            GetByIdFlush
            GetByIdWithThis
            GetByValWithThis
            GetDirectPname
            GetDynamicVar
            HasGenericProperty
            HasOwnProperty
            HasStructureProperty
            InById
            InByVal
            InstanceOf
            InstanceOfCustom
            LoadVarargs
            NumberToStringWithRadix
            PutById
            PutByIdDirect
            PutByIdFlush
            PutByIdWithThis
            PutByOffset
            PutByValWithThis
            PutDynamicVar
            PutGetterById
            PutGetterByVal
            PutGetterSetterById
            PutSetterById
            PutSetterByVal
            PutStack
            PutToArguments
            RegExpExec
            RegExpTest
            ResolveScope
            ResolveScopeForHoistingFuncDeclInEval
            TailCall
            TailCallForwardVarargsInlinedCaller
            TailCallInlinedCaller
            TailCallVarargsInlinedCaller
            ToNumber
            ToPrimitive
            ValueNegate

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-02-05  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink sizeof(UnlinkedCodeBlock)
        https://bugs.webkit.org/show_bug.cgi?id=194281

        Reviewed by Michael Saboff.

        This patch first attempts to reduce the size of UnlinkedCodeBlock in a relatively simpler way. Reordering members, remove unused member, and
        move rarely used members to RareData. This changes sizeof(UnlinkedCodeBlock) from 312 to 256.

        Still we have several chances to reduce sizeof(UnlinkedCodeBlock). Making more Vectors to RefCountedArrays can be done with some restructuring
        of generatorification phase. It would be possible to remove m_sourceURLDirective and m_sourceMappingURLDirective from UnlinkedCodeBlock since
        they should be in SourceProvider and that should be enough. These changes require some intrusive modifications and we make them as a future work.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::bitVectors const): Deleted.
        * bytecode/CodeType.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::UnlinkedCodeBlock::shrinkToFit):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::bitVector):
        (JSC::UnlinkedCodeBlock::addBitVector):
        (JSC::UnlinkedCodeBlock::addSetConstant):
        (JSC::UnlinkedCodeBlock::constantRegisters):
        (JSC::UnlinkedCodeBlock::numberOfConstantIdentifierSets const):
        (JSC::UnlinkedCodeBlock::constantIdentifierSets):
        (JSC::UnlinkedCodeBlock::codeType const):
        (JSC::UnlinkedCodeBlock::didOptimize const):
        (JSC::UnlinkedCodeBlock::setDidOptimize):
        (JSC::UnlinkedCodeBlock::usesGlobalObject const): Deleted.
        (JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
        (JSC::UnlinkedCodeBlock::globalObjectRegister const): Deleted.
        (JSC::UnlinkedCodeBlock::bitVectors const): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::emitLoadGlobalObject): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * runtime/CachedTypes.cpp:
        (JSC::CachedCodeBlockRareData::encode):
        (JSC::CachedCodeBlockRareData::decode const):
        (JSC::CachedCodeBlock::scopeRegister const):
        (JSC::CachedCodeBlock::codeType const):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::CachedCodeBlock<CodeBlockType>::decode const):
        (JSC::CachedCodeBlock<CodeBlockType>::encode):
        (JSC::CachedCodeBlock::globalObjectRegister const): Deleted.

2019-02-04  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, add missing exception checks after r240637
        https://bugs.webkit.org/show_bug.cgi?id=193546

        * tools/JSDollarVM.cpp:
        (JSC::functionShadowChickenFunctionsOnStack):

2019-02-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink size of VM by lazily allocating IsoSubspaces for non-common types
        https://bugs.webkit.org/show_bug.cgi?id=193993

        Reviewed by Keith Miller.

        JSC::VM has a lot of IsoSubspaces, and each takes 504B. This unnecessarily makes VM so large.
        And some of them are rarely used. We should allocate it lazily.

        In this patch, we make some `IsoSubspaces` `std::unique_ptr<IsoSubspace>`. And we add ensureXXXSpace
        functions which allocate IsoSubspaces lazily. This function is used by subspaceFor<> in each class.
        And we also add subspaceForConcurrently<> function, which is called from concurrent JIT tiers. This
        returns nullptr if the subspace is not allocated yet. JSCell::subspaceFor now takes second template
        parameter which tells the function whether subspaceFor is concurrently done. If the IsoSubspace is
        lazily created, we may return nullptr for the concurrent access. We ensure the space's initialization
        by using WTF::storeStoreFence when lazily allocating it.

        In GC's constraint solving, we may touch these lazily allocated spaces. At that time, we check the
        existence of the space before touching this. This is not racy because the main thread is stopped when
        the constraint solving is working.

        This changes sizeof(VM) from 64736 to 56472.

        Another interesting thing is that we removed `PreventCollectionScope preventCollectionScope(heap);` in
        `Subspace::initialize`. This is really dangerous API since it easily causes dead-lock between the
        collector and the mutator if IsoSubspace is dynamically created. We do want to make IsoSubspaces
        dynamically-created ones since the requirement of the pre-allocation poses a scalability problem
        of IsoSubspace adoption because IsoSubspace is large. Registered Subspace is only touched in the
        EndPhase, and the peripheries should be stopped when running EndPhase. Thus, as long as the main thread
        can run this IsoSubspace code, the collector is never EndPhase. So this is safe.

        * API/JSCallbackFunction.h:
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::subspaceFor):
        * API/glib/JSCCallbackFunction.h:
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitChildren):
        (JSC::CodeBlock::finalizeUnconditionally):
        * bytecode/CodeBlock.h:
        * bytecode/EvalCodeBlock.h:
        * bytecode/ExecutableToCodeBlockEdge.h:
        * bytecode/FunctionCodeBlock.h:
        * bytecode/ModuleProgramCodeBlock.h:
        * bytecode/ProgramCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (JSC::DFG::SpeculativeJIT::compileNewObject):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
        (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        (JSC::Heap::deleteAllCodeBlocks):
        (JSC::Heap::deleteAllUnlinkedCodeBlocks):
        (JSC::Heap::addCoreConstraints):
        * heap/Subspace.cpp:
        (JSC::Subspace::initialize):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
        (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_object):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_new_object):
        * runtime/DirectArguments.h:
        * runtime/DirectEvalExecutable.h:
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::subspaceFor):
        * runtime/ExecutableBase.h:
        * runtime/FunctionExecutable.h:
        * runtime/IndirectEvalExecutable.h:
        * runtime/InferredValue.cpp:
        (JSC::InferredValue::visitChildren):
        * runtime/InferredValue.h:
        * runtime/InferredValueInlines.h:
        (JSC::InferredValue::finalizeUnconditionally):
        * runtime/InternalFunction.h:
        * runtime/JSAsyncFunction.h:
        * runtime/JSAsyncGeneratorFunction.h:
        * runtime/JSBoundFunction.h:
        * runtime/JSCell.h:
        (JSC::subspaceFor):
        (JSC::subspaceForConcurrently):
        * runtime/JSCellInlines.h:
        (JSC::allocatorForNonVirtualConcurrently):
        * runtime/JSCustomGetterSetterFunction.h:
        * runtime/JSDestructibleObject.h:
        * runtime/JSFunction.h:
        * runtime/JSGeneratorFunction.h:
        * runtime/JSImmutableButterfly.h:
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::subspaceFor):
        * runtime/JSNativeStdFunction.h:
        * runtime/JSSegmentedVariableObject.h:
        * runtime/JSString.h:
        * runtime/ModuleProgramExecutable.h:
        * runtime/NativeExecutable.h:
        * runtime/ProgramExecutable.h:
        * runtime/PropertyMapHashTable.h:
        * runtime/ProxyRevoke.h:
        * runtime/ScopedArguments.h:
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::clearCode):
        (JSC::ScriptExecutable::installCode):
        * runtime/Structure.h:
        * runtime/StructureRareData.h:
        * runtime/SubspaceAccess.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::SpaceAndSet::SpaceAndSet):
        (JSC::VM::SpaceAndSet::setFor):
        (JSC::VM::forEachScriptExecutableSpace):
        (JSC::VM::SpaceAndFinalizerSet::SpaceAndFinalizerSet): Deleted.
        (JSC::VM::SpaceAndFinalizerSet::finalizerSetFor): Deleted.
        (JSC::VM::ScriptExecutableSpaceAndSet::ScriptExecutableSpaceAndSet): Deleted.
        (JSC::VM::ScriptExecutableSpaceAndSet::clearableCodeSetFor): Deleted.
        (JSC::VM::UnlinkedFunctionExecutableSpaceAndSet::UnlinkedFunctionExecutableSpaceAndSet): Deleted.
        (JSC::VM::UnlinkedFunctionExecutableSpaceAndSet::clearableCodeSetFor): Deleted.
        * runtime/WeakMapImpl.h:
        (JSC::WeakMapImpl::subspaceFor):
        * wasm/js/JSWebAssemblyCodeBlock.h:
        * wasm/js/JSWebAssemblyMemory.h:
        * wasm/js/WebAssemblyFunction.h:
        * wasm/js/WebAssemblyWrapperFunction.h:

2019-02-04  Keith Miller  <keith_miller@apple.com>

        Change llint operand macros to inline functions
        https://bugs.webkit.org/show_bug.cgi?id=194248

        Reviewed by Mark Lam.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getNonConstantOperand):
        (JSC::LLInt::getOperand):
        (JSC::LLInt::llint_trace_value):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::getByVal):
        (JSC::LLInt::genericCall):
        (JSC::LLInt::varargsSetup):
        (JSC::LLInt::commonCallEval):

2019-02-04  Robin Morisset  <rmorisset@apple.com>

        when lowering AssertNotEmpty, create the value before creating the patchpoint
        https://bugs.webkit.org/show_bug.cgi?id=194231

        Reviewed by Saam Barati.

        This is a very simple change: we should never generate B3 IR where an instruction depends on a value that comes later in the instruction stream.
        AssertNotEmpty was generating some such IR, it probably slipped through until now because it is a rather rare and tricky instruction to generate.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileAssertNotEmpty):

2019-02-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] ExecutableToCodeBlockEdge should be smaller
        https://bugs.webkit.org/show_bug.cgi?id=194244

        Reviewed by Michael Saboff.

        ExecutableToCodeBlockEdge is allocated so many times. However its memory layout is not efficient.
        sizeof(ExecutableToCodeBlockEdge) is 24bytes, but it discards 7bytes due to one bool m_isActive flag.
        Because our size classes are rounded by 16bytes, ExecutableToCodeBlockEdge takes 32bytes. So, half of
        it is wasted. We should fit it into 16bytes so that we can efficiently allocate it.

        In this patch, we leverages TypeInfoMayBePrototype bit in JSTypeInfo. It is a bit special TypeInfo bit
        since this is per-cell bit. We rename this to TypeInfoPerCellBit, and use it as a `m_isActive` mark in
        ExecutableToCodeBlockEdge. In JSObject subclasses, we use it as MayBePrototype flag.

        Since this flag is not changed in CAS style, we must not change this in concurrent threads. This is OK
        for ExecutableToCodeBlockEdge's m_isActive flag since this is touched on the main thread (ScriptExecutable::installCode
        does not touch it if it is called in non-main threads).

        * bytecode/ExecutableToCodeBlockEdge.cpp:
        (JSC::ExecutableToCodeBlockEdge::finishCreation):
        (JSC::ExecutableToCodeBlockEdge::visitChildren):
        (JSC::ExecutableToCodeBlockEdge::activate):
        (JSC::ExecutableToCodeBlockEdge::deactivate):
        (JSC::ExecutableToCodeBlockEdge::isActive const):
        * bytecode/ExecutableToCodeBlockEdge.h:
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::perCellBit const):
        (JSC::JSCell::setPerCellBit):
        (JSC::JSCell::mayBePrototype const): Deleted.
        (JSC::JSCell::didBecomePrototype): Deleted.
        * runtime/JSObject.cpp:
        (JSC::JSObject::setPrototypeDirect):
        * runtime/JSObject.h:
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::mayBePrototype const):
        (JSC::JSObject::didBecomePrototype):
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::perCellBit):
        (JSC::TypeInfo::mergeInlineTypeFlags):
        (JSC::TypeInfo::mayBePrototype): Deleted.

2019-02-04  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Shrink size of FunctionExecutable
        https://bugs.webkit.org/show_bug.cgi?id=194191

        Reviewed by Michael Saboff.

        This patch reduces the size of FunctionExecutable. Since it is allocated in IsoSubspace, reducing the size directly
        improves the allocation efficiency.

        1. ScriptExecutable (base class of FunctionExecutable) has several members, but it is meaningful only in FunctionExecutable.
           We remove this from ScriptExecutable, and move it to FunctionExecutable.

        2. FunctionExecutable has several data which are rarely used. One for FunctionOverrides functionality, which is typically
           used for JSC debugging purpose, and another is TypeSet and offsets for type profiler. We move them to RareData and reduce
           the size of FunctionExecutable in the common case.

        This patch changes the size of FunctionExecutable from 176 to 144.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpSource):
        (JSC::CodeBlock::finishCreation):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::OpInfoWrapper::as const):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::computeLineAndColumn const):
        * runtime/ExecutableBase.h:
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::FunctionExecutable::ensureRareDataSlow):
        * runtime/FunctionExecutable.h:
        * runtime/Intrinsic.h:
        * runtime/ModuleProgramExecutable.cpp:
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::ProgramExecutable):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::ScriptExecutable::overrideLineNumber const):
        (JSC::ScriptExecutable::typeProfilingStartOffset const):
        (JSC::ScriptExecutable::typeProfilingEndOffset const):
        * runtime/ScriptExecutable.h:
        (JSC::ScriptExecutable::firstLine const):
        (JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
        (JSC::ScriptExecutable::hasOverrideLineNumber const): Deleted.
        (JSC::ScriptExecutable::overrideLineNumber const): Deleted.
        (JSC::ScriptExecutable::typeProfilingStartOffset const): Deleted.
        (JSC::ScriptExecutable::typeProfilingEndOffset const): Deleted.
        * runtime/StackFrame.cpp:
        (JSC::StackFrame::computeLineAndColumn const):
        * tools/JSDollarVM.cpp:
        (JSC::functionReturnTypeFor):

2019-02-04  Mark Lam  <mark.lam@apple.com>

        DFG's doesGC() is incorrect about the SameValue node's behavior.
        https://bugs.webkit.org/show_bug.cgi?id=194211
        <rdar://problem/47608913>

        Reviewed by Saam Barati.

        Only the DoubleRepUse case is guaranteed to not GC.  The other case may GC because
        it calls operationSameValue() which may allocate memory for resolving ropes.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-02-03  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] UnlinkedMetadataTable assumes that MetadataTable is destroyed before it is destructed, but order of destruction of JS heap cells are not guaranteed
        https://bugs.webkit.org/show_bug.cgi?id=194031

        Reviewed by Saam Barati.

        UnlinkedMetadataTable assumes that MetadataTable linked against this UnlinkedMetadataTable is already destroyed when UnlinkedMetadataTable is destroyed.
        This means that UnlinkedCodeBlock is destroyed after all the linked CodeBlocks are destroyed. But this assumption is not valid since GC's finalizer
        sweeps objects without considering the dependencies among swept objects. UnlinkedMetadataTable can be destroyed even before linked MetadataTable is
        destroyed if UnlinkedCodeBlock is destroyed before linked CodeBlock is destroyed.

        To make the above assumption valid, we make UnlinkedMetadataTable RefCounted object, and make MetadataTable hold the strong ref to UnlinkedMetadataTable.
        This ensures that UnlinkedMetadataTable is destroyed after all the linked MetadataTables are destroyed.

        * bytecode/MetadataTable.cpp:
        (JSC::MetadataTable::MetadataTable):
        (JSC::MetadataTable::~MetadataTable):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::UnlinkedCodeBlock::visitChildren):
        (JSC::UnlinkedCodeBlock::estimatedSize):
        (JSC::UnlinkedCodeBlock::setInstructions):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::metadata):
        (JSC::UnlinkedCodeBlock::metadataSizeInBytes):
        * bytecode/UnlinkedMetadataTable.h:
        (JSC::UnlinkedMetadataTable::create):
        * bytecode/UnlinkedMetadataTableInlines.h:
        (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
        * runtime/CachedTypes.cpp:
        (JSC::CachedMetadataTable::decode const):
        (JSC::CachedCodeBlock::metadata const):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::CachedCodeBlock<CodeBlockType>::decode const):
        (JSC::CachedCodeBlock<CodeBlockType>::encode):

2019-02-01  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Decouple JIT related data from CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=194187

        Reviewed by Saam Barati.

        CodeBlock holds bunch of data which is only used after JIT starts compiling it.
        We have three types of data in CodeBlock.

        1. The data which is always used. CodeBlock needs to hold it.
        2. The data which is touched even in LLInt, but it is only meaningful in JIT tiers. The example is profiling.
        3. The data which is used after the JIT compiler starts running for the given CodeBlock.

        This patch decouples (3) from CodeBlock as CodeBlock::JITData. Even if we have bunch of CodeBlocks, only small
        number of them gets JIT compilation. Always allocating (3) data enlarges the size of CodeBlock, leading to the
        memory waste. Potentially we can decouple (2) in another data structure, but we first do (3) since (3) is beneficial
        in both non-JIT and *JIT* modes.

        JITData is created only when JIT compiler wants to use it. So it can be concurrently created and used, so it is guarded
        by the lock of CodeBlock.

        The size of CodeBlock is reduced from 512 to 352.

        This patch improves memory footprint and gets 1.1% improvement in RAMification.

            Footprint geomean: 36696503 (34.997 MB)
            Peak Footprint geomean: 38595988 (36.808 MB)
            Score: 37634263 (35.891 MB)

            Footprint geomean: 37172768 (35.451 MB)
            Peak Footprint geomean: 38978288 (37.173 MB)
            Score: 38064824 (36.301 MB)

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::ensureJITDataSlow):
        (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
        (JSC::CodeBlock::getICStatusMap):
        (JSC::CodeBlock::addStubInfo):
        (JSC::CodeBlock::addJITAddIC):
        (JSC::CodeBlock::addJITMulIC):
        (JSC::CodeBlock::addJITSubIC):
        (JSC::CodeBlock::addJITNegIC):
        (JSC::CodeBlock::findStubInfo):
        (JSC::CodeBlock::addByValInfo):
        (JSC::CodeBlock::addCallLinkInfo):
        (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
        (JSC::CodeBlock::addRareCaseProfile):
        (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
        (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::resetJITData):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::linkIncomingCall):
        (JSC::CodeBlock::linkIncomingPolymorphicCall):
        (JSC::CodeBlock::unlinkIncomingCalls):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::dumpValueProfiles):
        (JSC::CodeBlock::setPCToCodeOriginMap):
        (JSC::CodeBlock::findPC):
        (JSC::CodeBlock::dumpMathICStats):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::ensureJITData):
        (JSC::CodeBlock::setJITCodeMap):
        (JSC::CodeBlock::jitCodeMap):
        (JSC::CodeBlock::likelyToTakeSlowCase):
        (JSC::CodeBlock::couldTakeSlowCase):
        (JSC::CodeBlock::lazyOperandValueProfiles):
        (JSC::CodeBlock::stubInfoBegin): Deleted.
        (JSC::CodeBlock::stubInfoEnd): Deleted.
        (JSC::CodeBlock::callLinkInfosBegin): Deleted.
        (JSC::CodeBlock::callLinkInfosEnd): Deleted.
        (JSC::CodeBlock::jitCodeMap const): Deleted.
        (JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::emitReportValue const):
        (JSC::MethodOfGettingAValueProfile::reportValue):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        (JSC::tryGetByValOptimize):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompilePutByVal):

2018-12-16  Darin Adler  <darin@apple.com>

        Convert additional String::format clients to alternative approaches
        https://bugs.webkit.org/show_bug.cgi?id=192746

        Reviewed by Alexey Proskuryakov.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::stopTiming): Use makeString
        and FormattedNumber::fixedWidth.

2019-02-01  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Remove some of IsoSubspaces for JSFunction subclasses
        https://bugs.webkit.org/show_bug.cgi?id=194177

        Reviewed by Saam Barati.

        JSGeneratorFunction, JSAsyncFunction, and JSAsyncGeneratorFunction do not add any fields / classInfo methods.
        We can share the IsoSubspace for JSFunction.

        * runtime/JSAsyncFunction.h:
        * runtime/JSAsyncGeneratorFunction.h:
        * runtime/JSGeneratorFunction.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-02-01  Mark Lam  <mark.lam@apple.com>

        Remove invalid assertion in DFG's compileDoubleRep().
        https://bugs.webkit.org/show_bug.cgi?id=194130
        <rdar://problem/47699474>

        Reviewed by Saam Barati.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):

2019-02-01  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Unify CodeBlock IsoSubspaces
        https://bugs.webkit.org/show_bug.cgi?id=194167

        Reviewed by Saam Barati.

        When we move CodeBlock into its IsoSubspace, we create IsoSubspaces for each subclass of CodeBlock.
        But this is not necessary since,

        1. They do not override the classInfo methods.
        2. sizeof(ProgramCodeBlock etc.) == sizeof(CodeBlock) since subclasses adds no additional fields.

        Creating IsoSubspace for each subclass is costly in terms of memory. Especially, IsoSubspace for
        ProgramCodeBlock is. We typically create only one ProgramCodeBlock, and it means the rest of the
        MarkedBlock (16KB - sizeof(footer) - sizeof(ProgramCodeBlock)) is just wasted.

        This patch unifies these IsoSubspaces into one.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::destroy):
        * bytecode/CodeBlock.h:
        * bytecode/EvalCodeBlock.cpp:
        (JSC::EvalCodeBlock::destroy): Deleted.
        * bytecode/EvalCodeBlock.h: We drop some utility functions in EvalCodeBlock and use UnlinkedEvalCodeBlock's one directly.
        * bytecode/FunctionCodeBlock.cpp:
        (JSC::FunctionCodeBlock::destroy): Deleted.
        * bytecode/FunctionCodeBlock.h:
        * bytecode/GlobalCodeBlock.h:
        * bytecode/ModuleProgramCodeBlock.cpp:
        (JSC::ModuleProgramCodeBlock::destroy): Deleted.
        * bytecode/ModuleProgramCodeBlock.h:
        * bytecode/ProgramCodeBlock.cpp:
        (JSC::ProgramCodeBlock::destroy): Deleted.
        * bytecode/ProgramCodeBlock.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::forEachCodeBlockSpace):

2019-02-01  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, follow-up after r240859
        https://bugs.webkit.org/show_bug.cgi?id=194145

        Replace OOB HeapCellType with cellHeapCellType since they are completely the same.
        And rename cellDangerousBitsSpace back to cellSpace.

        * runtime/JSCellInlines.h:
        (JSC::JSCell::subspaceFor):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-02-01  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Remove cellJSValueOOBSpace
        https://bugs.webkit.org/show_bug.cgi?id=194145

        Reviewed by Mark Lam.

        * runtime/JSObject.h:
        (JSC::JSObject::subspaceFor): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-01-31  Mark Lam  <mark.lam@apple.com>

        Remove poisoning from CodeBlock and LLInt code.
        https://bugs.webkit.org/show_bug.cgi?id=194113

        Reviewed by Yusuke Suzuki.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::setConstantRegisters):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::jettison):
        (JSC::CodeBlock::predictedMachineCodeSize):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::vm const):
        (JSC::CodeBlock::addConstant):
        (JSC::CodeBlock::heap const):
        (JSC::CodeBlock::replaceConstant):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2019-01-31  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Remove finalizer in AsyncFromSyncIteratorPrototype
        https://bugs.webkit.org/show_bug.cgi?id=194107

        Reviewed by Saam Barati.

        AsyncFromSyncIteratorPrototype uses the finalizer, but it is not necessary since it does not hold any objects which require destruction.
        We drop this finalizer. And we also make methods of AsyncFromSyncIteratorPrototype lazily allocated.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/AsyncFromSyncIteratorPrototype.cpp:
        (JSC::AsyncFromSyncIteratorPrototype::AsyncFromSyncIteratorPrototype):
        (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
        (JSC::AsyncFromSyncIteratorPrototype::create):
        * runtime/AsyncFromSyncIteratorPrototype.h:

2019-01-31  Tadeu Zagallo  <tzagallo@apple.com>

        Fix `runJITThreadLimitTests` in testapi
        https://bugs.webkit.org/show_bug.cgi?id=194064
        <rdar://problem/46139147>

        Reviewed by Mark Lam.

        Fix typo where `targetNumberOfThreads` was not being used.

        * API/tests/testapi.mm:
        (runJITThreadLimitTests):

2019-01-31  Tadeu Zagallo  <tzagallo@apple.com>

        testapi fails RELEASE_ASSERT(codeBlock) in fetchFromDisk() of CodeCache.h
        https://bugs.webkit.org/show_bug.cgi?id=194112

        Reviewed by Mark Lam.

        `testBytecodeCache` does not populate the bytecode cache for the global
        CodeBlock, so it should only enable `forceDiskCache` after its execution.

        * API/tests/testapi.mm:
        (testBytecodeCache):

2019-01-31  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, follow-up after r240796

        Initialize WriteBarrier<InferredValue> in the constructor. Otherwise, GC can see the broken one
        when allocating InferredValue in FunctionExecutable::finishCreation.

        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::FunctionExecutable::finishCreation):

2019-01-31  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Do not use InferredValue in non-JIT configuration
        https://bugs.webkit.org/show_bug.cgi?id=194084

        Reviewed by Saam Barati.

        InferredValue is not meaningful if our VM is non-JIT configuration. InferredValue is used to watch the instantiation of the  FunctionExecutable's
        JSFunction and SymbolTable's JSScope to explore the chance of folding them into constants in DFG and FTL. If it is instantiated only once, we can
        put a watchpoint and fold it into this constant. But if JIT is disabled, we do not need to care it.
        Even in non-JIT configuration, we still use InferredValue for FunctionExecutable to determine whether the given FunctionExecutable is preferable
        target for poly proto. If JSFunction for the FunctionExecutable is used as a constructor and instantiated more than once, poly proto Structure
        seems appropriate for objects created by this JSFunction. But at that time, only thing we would like to know is that whether JSFunction for this
        FunctionExecutable is instantiated multiple times. This does not require the full feature of InferredValue, WatchpointState is enough.
        To summarize, since nobody uses InferredValue feature in non-JIT configuration, we should not create it.

        * bytecode/ObjectAllocationProfileInlines.h:
        (JSC::ObjectAllocationProfile::initializeProfile):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::finishCreation):
        (JSC::FunctionExecutable::visitChildren):
        * runtime/FunctionExecutable.h:
        * runtime/InferredValue.cpp:
        (JSC::InferredValue::create):
        * runtime/JSAsyncFunction.cpp:
        (JSC::JSAsyncFunction::create):
        * runtime/JSAsyncGeneratorFunction.cpp:
        (JSC::JSAsyncGeneratorFunction::create):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::create):
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSGeneratorFunction.cpp:
        (JSC::JSGeneratorFunction::create):
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::setSymbolTable):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::finishCreation):
        * runtime/VM.cpp:
        (JSC::VM::VM):

2019-01-31  Fujii Hironori  <Hironori.Fujii@sony.com>

        [CMake][JSC] Changing ud_opcode.py should trigger invoking ud_opcode.py
        https://bugs.webkit.org/show_bug.cgi?id=194085

        Reviewed by Yusuke Suzuki.

        r240730 changed ud_itab.py and caused incremental build failures
        for Ninja builds.

        * CMakeLists.txt: Added ud_itab.py and optable.xml to UDIS_GEN_DEP.

2019-01-30  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Symbol should be in destructibleCellSpace
        https://bugs.webkit.org/show_bug.cgi?id=194082

        Reviewed by Saam Barati.

        Because Symbol's member was not poisoned, we changed the subspace for Symbol from destructibleCellSpace
        to cellJSValueOOBSpace. But the problem is cellJSValueOOBSpace is a space for cells which are not
        destructible. As a result, Symbol::destroy is never called, and SymbolImpl is leaked. This patch makes
        Symbol's space destructibleCellSpace to appropriately call the destructor.

        * runtime/Symbol.h:

2019-01-30  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, rolling out r240755.

        This was not correct

        Reverted changeset:

        "Unreviewed, fix GCC build after r240730"
        https://bugs.webkit.org/show_bug.cgi?id=194041
        https://trac.webkit.org/changeset/240755

2019-01-30  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, fix GCC build after r240730
        https://bugs.webkit.org/show_bug.cgi?id=194041
        <rdar://problem/47680981>

        * disassembler/udis86/ud_itab.py:
        (UdItabGenerator.genOpcodeTablesLookupIndex):

2019-01-30  Tadeu Zagallo  <tzagallo@apple.com>

        testapi's `testBytecodeCache` does not need to run the code twice
        https://bugs.webkit.org/show_bug.cgi?id=194046

        Reviewed by Mark Lam.

        Since we populate the cache eagerly (unlike the stress tests) we don't
        need to run the code twice.

        * API/tests/testapi.mm:
        (testBytecodeCache):

2019-01-30  Saam barati  <sbarati@apple.com>

        [WebAssembly] Change BBQ to generate Air IR
        https://bugs.webkit.org/show_bug.cgi?id=191802
        <rdar://problem/47651718>

        Reviewed by Keith Miller.

        This patch adds a new Wasm compiler for the BBQ tier. Instead
        of compiling using  B3-01, we now generate Air code directly.
        The goal of doing this was to speed up compile times for Wasm
        programs.
        
        This patch provides us with a 20-30% compile time speedup. However, I
        have ideas on how to improve compile times even further. For example,
        we should probably implement a faster running register allocator:
        https://bugs.webkit.org/show_bug.cgi?id=194036
        
        We can also improve on the code we generate.
        We should emit better code for Switch: https://bugs.webkit.org/show_bug.cgi?id=194053
        And we should do better instruction selection in various
        areas: https://bugs.webkit.org/show_bug.cgi?id=193999

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * b3/B3LowerToAir.cpp:
        * b3/B3StackmapSpecial.h:
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::emitDefaultPrologue):
        * b3/air/AirCode.h:
        * b3/air/AirTmp.h:
        (JSC::B3::Air::Tmp::Tmp):
        * runtime/Options.h:
        * wasm/WasmAirIRGenerator.cpp: Added.
        (JSC::Wasm::ConstrainedTmp::ConstrainedTmp):
        (JSC::Wasm::TypedTmp::TypedTmp):
        (JSC::Wasm::TypedTmp::operator== const):
        (JSC::Wasm::TypedTmp::operator!= const):
        (JSC::Wasm::TypedTmp::operator bool const):
        (JSC::Wasm::TypedTmp::operator Tmp const):
        (JSC::Wasm::TypedTmp::operator Arg const):
        (JSC::Wasm::TypedTmp::tmp const):
        (JSC::Wasm::TypedTmp::type const):
        (JSC::Wasm::AirIRGenerator::ControlData::ControlData):
        (JSC::Wasm::AirIRGenerator::ControlData::dump const):
        (JSC::Wasm::AirIRGenerator::ControlData::type const):
        (JSC::Wasm::AirIRGenerator::ControlData::signature const):
        (JSC::Wasm::AirIRGenerator::ControlData::hasNonVoidSignature const):
        (JSC::Wasm::AirIRGenerator::ControlData::targetBlockForBranch):
        (JSC::Wasm::AirIRGenerator::ControlData::convertIfToBlock):
        (JSC::Wasm::AirIRGenerator::ControlData::resultForBranch const):
        (JSC::Wasm::AirIRGenerator::emptyExpression):
        (JSC::Wasm::AirIRGenerator::fail const):
        (JSC::Wasm::AirIRGenerator::setParser):
        (JSC::Wasm::AirIRGenerator::toTmpVector):
        (JSC::Wasm::AirIRGenerator::validateInst):
        (JSC::Wasm::AirIRGenerator::extractArg):
        (JSC::Wasm::AirIRGenerator::append):
        (JSC::Wasm::AirIRGenerator::appendEffectful):
        (JSC::Wasm::AirIRGenerator::newTmp):
        (JSC::Wasm::AirIRGenerator::g32):
        (JSC::Wasm::AirIRGenerator::g64):
        (JSC::Wasm::AirIRGenerator::f32):
        (JSC::Wasm::AirIRGenerator::f64):
        (JSC::Wasm::AirIRGenerator::tmpForType):
        (JSC::Wasm::AirIRGenerator::addPatchpoint):
        (JSC::Wasm::AirIRGenerator::emitPatchpoint):
        (JSC::Wasm::AirIRGenerator::emitCheck):
        (JSC::Wasm::AirIRGenerator::emitCCall):
        (JSC::Wasm::AirIRGenerator::moveOpForValueType):
        (JSC::Wasm::AirIRGenerator::instanceValue):
        (JSC::Wasm::AirIRGenerator::fixupPointerPlusOffset):
        (JSC::Wasm::AirIRGenerator::restoreWasmContextInstance):
        (JSC::Wasm::AirIRGenerator::AirIRGenerator):
        (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
        (JSC::Wasm::AirIRGenerator::emitThrowException):
        (JSC::Wasm::AirIRGenerator::addLocal):
        (JSC::Wasm::AirIRGenerator::addConstant):
        (JSC::Wasm::AirIRGenerator::addArguments):
        (JSC::Wasm::AirIRGenerator::getLocal):
        (JSC::Wasm::AirIRGenerator::addUnreachable):
        (JSC::Wasm::AirIRGenerator::addGrowMemory):
        (JSC::Wasm::AirIRGenerator::addCurrentMemory):
        (JSC::Wasm::AirIRGenerator::setLocal):
        (JSC::Wasm::AirIRGenerator::getGlobal):
        (JSC::Wasm::AirIRGenerator::setGlobal):
        (JSC::Wasm::AirIRGenerator::emitCheckAndPreparePointer):
        (JSC::Wasm::sizeOfLoadOp):
        (JSC::Wasm::AirIRGenerator::emitLoadOp):
        (JSC::Wasm::AirIRGenerator::load):
        (JSC::Wasm::sizeOfStoreOp):
        (JSC::Wasm::AirIRGenerator::emitStoreOp):
        (JSC::Wasm::AirIRGenerator::store):
        (JSC::Wasm::AirIRGenerator::addSelect):
        (JSC::Wasm::AirIRGenerator::emitTierUpCheck):
        (JSC::Wasm::AirIRGenerator::addLoop):
        (JSC::Wasm::AirIRGenerator::addTopLevel):
        (JSC::Wasm::AirIRGenerator::addBlock):
        (JSC::Wasm::AirIRGenerator::addIf):
        (JSC::Wasm::AirIRGenerator::addElse):
        (JSC::Wasm::AirIRGenerator::addElseToUnreachable):
        (JSC::Wasm::AirIRGenerator::addReturn):
        (JSC::Wasm::AirIRGenerator::addBranch):
        (JSC::Wasm::AirIRGenerator::addSwitch):
        (JSC::Wasm::AirIRGenerator::endBlock):
        (JSC::Wasm::AirIRGenerator::addEndToUnreachable):
        (JSC::Wasm::AirIRGenerator::addCall):
        (JSC::Wasm::AirIRGenerator::addCallIndirect):
        (JSC::Wasm::AirIRGenerator::unify):
        (JSC::Wasm::AirIRGenerator::unifyValuesWithBlock):
        (JSC::Wasm::AirIRGenerator::dump):
        (JSC::Wasm::AirIRGenerator::origin):
        (JSC::Wasm::parseAndCompileAir):
        (JSC::Wasm::AirIRGenerator::emitChecksForModOrDiv):
        (JSC::Wasm::AirIRGenerator::emitModOrDiv):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32DivS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32RemS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32DivU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32RemU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64DivS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64RemS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64DivU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64RemU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Ctz>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Ctz>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Popcnt>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Popcnt>):
        (JSC::Wasm::AirIRGenerator::addOp<F64ConvertUI64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertUI64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Nearest>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Nearest>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Trunc>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Trunc>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncUF64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncUF32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncSF64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncSF32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF32>):
        (JSC::Wasm::AirIRGenerator::addShift):
        (JSC::Wasm::AirIRGenerator::addIntegerSub):
        (JSC::Wasm::AirIRGenerator::addFloatingPointAbs):
        (JSC::Wasm::AirIRGenerator::addFloatingPointBinOp):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ceil>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Mul>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Sub>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Le>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32DemoteF64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ne>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Lt>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Mul>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Div>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Clz>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Copysign>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertUI32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32ReinterpretI32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64And>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ne>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Gt>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Sqrt>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ge>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64GtS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64GtU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Eqz>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Div>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Add>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Or>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32LeU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32LeS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Ne>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Clz>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Neg>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32And>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32LtU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Rotr>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Abs>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32LtS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Eq>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Copysign>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertSI64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Rotl>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Lt>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertSI32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Eq>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Le>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Ge>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32ShrU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertUI32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32ShrS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32GeU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Ceil>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32GeS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Shl>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Floor>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Xor>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Abs>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Mul>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Sub>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32ReinterpretF32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Add>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Sub>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Or>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64LtU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64LtS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64ConvertSI64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Xor>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64GeU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Mul>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Sub>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64PromoteF32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Add>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64GeS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64ExtendUI32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Ne>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64ReinterpretI64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Eq>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Eq>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Floor>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32ConvertSI32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Eqz>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64ReinterpretF64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64ShrS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64ShrU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Sqrt>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Shl>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Gt>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32WrapI64>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Rotl>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32Rotr>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32GtU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64ExtendSI32>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I32GtS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Neg>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64LeU>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64LeS>):
        (JSC::Wasm::AirIRGenerator::addOp<OpType::I64Add>):
        * wasm/WasmAirIRGenerator.h: Added.
        * wasm/WasmB3IRGenerator.cpp:
        (JSC::Wasm::B3IRGenerator::emptyExpression):
        * wasm/WasmBBQPlan.cpp:
        (JSC::Wasm::BBQPlan::compileFunctions):
        * wasm/WasmCallingConvention.cpp:
        (JSC::Wasm::jscCallingConventionAir):
        (JSC::Wasm::wasmCallingConventionAir):
        * wasm/WasmCallingConvention.h:
        (JSC::Wasm::CallingConvention::CallingConvention):
        (JSC::Wasm::CallingConvention::marshallArgumentImpl const):
        (JSC::Wasm::CallingConvention::marshallArgument const):
        (JSC::Wasm::CallingConventionAir::CallingConventionAir):
        (JSC::Wasm::CallingConventionAir::prologueScratch const):
        (JSC::Wasm::CallingConventionAir::marshallArgumentImpl const):
        (JSC::Wasm::CallingConventionAir::marshallArgument const):
        (JSC::Wasm::CallingConventionAir::headerSizeInBytes):
        (JSC::Wasm::CallingConventionAir::loadArguments const):
        (JSC::Wasm::CallingConventionAir::setupCall const):
        (JSC::Wasm::nextJSCOffset):
        * wasm/WasmFunctionParser.h:
        (JSC::Wasm::FunctionParser<Context>::parseExpression):
        * wasm/WasmValidate.cpp:
        (JSC::Wasm::Validate::emptyExpression):

2019-01-30  Robin Morisset  <rmorisset@apple.com>

        Object.keys can now lead to a PhantomNewArrayBuffer, OSR exit from the FTL should know how to materialize a NewArrayBuffer in that case
        https://bugs.webkit.org/show_bug.cgi?id=194050
        <rdar://problem/47595592>

        Following https://bugs.webkit.org/show_bug.cgi?id=190047, PhantomNewArrayBuffer is no longer guaranteed to originate from a NewArrayBuffer in the baseline jit.
        It can now come from Object.keys, which is a function call. We must teach the FTL how to OSR exit in that case.

        Reviewed by Yusuke Suzuki.

        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):

2019-01-30  Tadeu Zagallo  <tzagallo@apple.com>

        Remove assertion that CachedSymbolTables should have no RareData
        https://bugs.webkit.org/show_bug.cgi?id=194037

        Reviewed by Mark Lam.

        It turns out that we don't need to cache the SymbolTableRareData and
        we should not assert that it's empty.

        * runtime/CachedTypes.cpp:
        (JSC::CachedSymbolTable::encode):

2019-01-30  Tadeu Zagallo  <tzagallo@apple.com>

        CachedBytecode's move constructor should not call `freeDataIfOwned`
        https://bugs.webkit.org/show_bug.cgi?id=194045

        Reviewed by Mark Lam.

        That might result in freeing a garbage value

        * parser/SourceProvider.h:
        (JSC::CachedBytecode::CachedBytecode):

2019-01-30  Keith Miller  <keith_miller@apple.com>

        mul32 should convert powers of 2 to an lshift
        https://bugs.webkit.org/show_bug.cgi?id=193957

        Reviewed by Yusuke Suzuki.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::mul32):
        * assembler/testmasm.cpp:
        (JSC::int32Operands):
        (JSC::testMul32WithImmediates):
        (JSC::run):

2019-01-30  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Make disassembler data structures constant read-only data
        https://bugs.webkit.org/show_bug.cgi?id=194041

        Reviewed by Mark Lam.

        Bunch of disassembler data structures are not marked "const", which prevents the loader to put them in read-only region.
        This patch makes them "const".

        * disassembler/ARM64/A64DOpcode.cpp:
        * disassembler/udis86/ud_itab.py:
        (UdItabGenerator.genOpcodeTablesLookupIndex):
        (UdItabGenerator.genInsnTable):
        (UdItabGenerator.genMnemonicsList):
        (genItabH):
        * disassembler/udis86/udis86_decode.h:
        * disassembler/udis86/udis86_syn.c:
        * disassembler/udis86/udis86_syn.h:
        * disassembler/udis86/udis86_types.h:

2019-01-30  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, update the builtin test results
        https://bugs.webkit.org/show_bug.cgi?id=194015

        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2019-01-30  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Make global static variables "const" as much as possible
        https://bugs.webkit.org/show_bug.cgi?id=194015

        Reviewed by Mark Lam.

        Some of global static variables are not "const". For example, `static const char* name = ...`
        is not constant variable. We should make it `static const char* const name = ...`.

        * Scripts/wkbuiltins/builtins_generate_combined_header.py:
        (generate_externs_for_object):
        * Scripts/wkbuiltins/builtins_generate_separate_header.py:
        (generate_externs_for_object):
        * Scripts/wkbuiltins/builtins_generator.py:
        (BuiltinsGenerator.generate_embedded_code_string_section_for_data):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::additionBlindedConstant):
        * b3/air/AirFormTable.h:
        * b3/air/opcode_generator.rb:
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        * tools/CodeProfile.cpp:
        * tools/CodeProfile.h:

2019-01-29  Keith Miller  <keith_miller@apple.com>

        Remove default constructor from LLIntPrototypeLoadAdaptiveStructureWatchpoint
        https://bugs.webkit.org/show_bug.cgi?id=194000
        <rdar://problem/47642894>

        Reviewed by Mark Lam.

        default constructor is unused and
        LLIntPrototypeLoadAdaptiveStructureWatchpoint has a reference
        data member which causes sadness.

        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:

2019-01-29  Ross Kirsling  <ross.kirsling@sony.com>

        Remove FIXME for Annex B.3.5's "for-of var" subcase.

        Rubber-stamped by Yusuke Suzuki.

        This subcase is removed from the spec in https://github.com/tc39/ecma262/pull/1393.

        * parser/Parser.h:
        (JSC::Parser::declareHoistedVariable):

2019-01-29  Mark Lam  <mark.lam@apple.com>

        Remove unneeded CPU(BIG_ENDIAN) handling in LLInt after new bytecode format.
        https://bugs.webkit.org/show_bug.cgi?id=132333

        Reviewed by Yusuke Suzuki.

        * bytecode/InstructionStream.h:
        (JSC::InstructionStreamWriter::write):
        - The 32-bit write() function need not invert the order of the bytes written to
          the bytecode stream for CPU(BUG_ENDIAN) because the incoming uint32_t value to
          be written is already in big endian order for CPU(BUG_ENDIAN) platforms.

        * llint/LLIntOfflineAsmConfig.h:
        - OFFLINE_ASM_BIG_ENDIAN is no longer needed nor used after the new bytecode format.

2019-01-29  Mark Lam  <mark.lam@apple.com>

        ValueRecovery::recover() should purify NaN values it recovers.
        https://bugs.webkit.org/show_bug.cgi?id=193978
        <rdar://problem/47625488>

        Reviewed by Saam Barati.

        According to DFG::OSRExit::executeOSRExit() and DFG::OSRExit::compileExit(),
        recovered DoubleDisplacedInJSStack values need to be purified.
        ValueRecovery::recover() should do the same.

        * bytecode/ValueRecovery.cpp:
        (JSC::ValueRecovery::recover const):

2019-01-29  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] FTL should handle LocalAllocator*
        https://bugs.webkit.org/show_bug.cgi?id=193980

        Reviewed by Saam Barati.

        At some point, Allocator holds LocalAllocator* instead of 32bit integer. In FTL allocation path, we fail to use this constant LocalAllocator*
        because the FTL still use the incoming value as 32bit integer there.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):

2019-01-29  Keith Rollin  <krollin@apple.com>

        Add .xcfilelists to Run Script build phases
        https://bugs.webkit.org/show_bug.cgi?id=193792
        <rdar://problem/47201785>

        Reviewed by Alex Christensen.

        As part of supporting XCBuild, update the necessary Run Script build
        phases in their Xcode projects to refer to their associated
        .xcfilelist files.

        Note that the addition of these files bumps the Xcode project version
        number to something that's Xcode 10 compatible. This change means that
        older versions of the Xcode IDE can't read these projects. Nor can it
        fully load workspaces that refer to these projects (the updated
        projects are shown as non-expandable placeholders). `xcodebuild` can
        still build these projects; it's just that the IDE can't open them.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2019-01-29  Dominik Infuehr  <dinfuehr@igalia.com>

        [ARM] Check for negative zero instead of just zero
        https://bugs.webkit.org/show_bug.cgi?id=193689

        Reviewed by Mark Lam.

        ARM now performs a negative zero check in branchConvertDoubleToInt32 instead
        of just bailing out for zero.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::branchConvertDoubleToInt32):

2019-01-28  Devin Rousso  <drousso@apple.com>

        Web Inspector: provide a way to edit page WebRTC settings on a remote target
        https://bugs.webkit.org/show_bug.cgi?id=193863
        <rdar://problem/47572764>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Page.json:
        Add more values to the `Setting` enum type:
         - `ICECandidateFilteringEnabled`
         - `MediaCaptureRequiresSecureConnection`
         - `MockCaptureDevicesEnabled`

2019-01-28  Ross Kirsling  <ross.kirsling@sony.com>

        Remove unnecessary `using namespace WTF`s (or at least restrict their scope).
        https://bugs.webkit.org/show_bug.cgi?id=193941

        Reviewed by Alex Christensen.

        * API/JSWeakObjectMapRefPrivate.cpp:
        * bytecompiler/NodesCodegen.cpp:
        * heap/MachineStackMarker.cpp:
        * jit/ExecutableAllocator.cpp:
        * jsc.cpp:
        * parser/Nodes.cpp:
        * runtime/DateConstructor.cpp:
        * runtime/DateConversion.cpp:
        * runtime/DateInstance.cpp:
        * runtime/DatePrototype.cpp:
        * runtime/InitializeThreading.cpp:
        * runtime/IteratorOperations.cpp:
        * runtime/JSDateMath.cpp:
        * runtime/JSGlobalObjectFunctions.cpp:
        * runtime/StringPrototype.cpp:
        * runtime/VM.cpp:
        * testRegExp.cpp:
        * tools/JSDollarVM.cpp:
        * yarr/YarrInterpreter.cpp:
        * yarr/YarrJIT.cpp:
        * yarr/YarrPattern.cpp:
        * yarr/YarrUnicodeProperties.cpp:

2019-01-28  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Reduce size of memory used for ShadowChicken
        https://bugs.webkit.org/show_bug.cgi?id=193546

        Reviewed by Mark Lam.

        This patch lazily instantiate ShadowChicken. We do not need this until we start logging ShadowChicken packets.
        The removal of ShadowChicken saves 55KB memory.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::create):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
        * heap/Heap.cpp:
        (JSC::Heap::stopThePeriphery):
        (JSC::Heap::addCoreConstraints):
        * jit/CCallHelpers.cpp:
        (JSC::CCallHelpers::ensureShadowChickenPacket):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setDebugger):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::setDebugger): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::ensureShadowChicken):
        * runtime/VM.h:
        (JSC::VM::shadowChicken):
        * tools/JSDollarVM.cpp:
        (JSC::functionShadowChickenFunctionsOnStack):
        (JSC::changeDebuggerModeWhenIdle):

2019-01-28  Andy Estes  <aestes@apple.com>

        [watchOS] Enable Parental Controls content filtering
        https://bugs.webkit.org/show_bug.cgi?id=193939
        <rdar://problem/46641912>

        Reviewed by Ryosuke Niwa.

        * Configurations/FeatureDefines.xcconfig:

2019-01-28  Mark Lam  <mark.lam@apple.com>

        ToString node actually does GC.
        https://bugs.webkit.org/show_bug.cgi?id=193920
        <rdar://problem/46695900>

        Reviewed by Yusuke Suzuki.

        Other than for StringObjectUse and StringOrStringObjectUse, ToString and
        CallStringConstructor can allocate new JSStrings, and hence, can GC.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-01-28  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] RegExpConstructor should not have own IsoSubspace
        https://bugs.webkit.org/show_bug.cgi?id=193801

        Reviewed by Mark Lam.

        This patch finally removes RegExpConstructor's cached data to JSGlobalObject and remove IsoSubspace for RegExpConstructor.
        sizeof(RegExpConstructor) != sizeof(InternalFunction), so that we have 16KB memory just for RegExpConstructor. But cached
        regexp matching data (e.g. `RegExp.$1`) is per-JSGlobalObject one, and we can move this data to JSGlobalObject and remove
        it from RegExpConstructor members.

        We introduce RegExpGlobalData, which holds the per-global RegExp matching data. And we perform `performMatch` etc. with
        JSGlobalObject instead of RegExpConstructor. This change requires small changes in DFG / FTL's RecordRegExpCachedResult
        node since its 1st argument is changed from RegExpConstructor to JSGlobalObject.

        We also move emptyRegExp from RegExpPrototype to VM's RegExpCache because it is more natural place to put it.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::regExpGlobalData):
        (JSC::JSGlobalObject::regExpGlobalDataOffset):
        (JSC::JSGlobalObject::regExpConstructor const): Deleted.
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::initialize):
        * runtime/RegExpCache.h:
        (JSC::RegExpCache::emptyRegExp const):
        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::visitAggregate):
        (JSC::RegExpCachedResult::visitChildren): Deleted.
        * runtime/RegExpCachedResult.h:
        (JSC::RegExpCachedResult::RegExpCachedResult): Deleted.
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::RegExpConstructor):
        (JSC::regExpConstructorDollar):
        (JSC::regExpConstructorInput):
        (JSC::regExpConstructorMultiline):
        (JSC::regExpConstructorLastMatch):
        (JSC::regExpConstructorLastParen):
        (JSC::regExpConstructorLeftContext):
        (JSC::regExpConstructorRightContext):
        (JSC::setRegExpConstructorInput):
        (JSC::setRegExpConstructorMultiline):
        (JSC::RegExpConstructor::destroy): Deleted.
        (JSC::RegExpConstructor::visitChildren): Deleted.
        (JSC::RegExpConstructor::getBackref): Deleted.
        (JSC::RegExpConstructor::getLastParen): Deleted.
        (JSC::RegExpConstructor::getLeftContext): Deleted.
        (JSC::RegExpConstructor::getRightContext): Deleted.
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::performMatch): Deleted.
        (JSC::RegExpConstructor::recordMatch): Deleted.
        * runtime/RegExpGlobalData.cpp: Added.
        (JSC::RegExpGlobalData::visitAggregate):
        (JSC::RegExpGlobalData::getBackref):
        (JSC::RegExpGlobalData::getLastParen):
        (JSC::RegExpGlobalData::getLeftContext):
        (JSC::RegExpGlobalData::getRightContext):
        * runtime/RegExpGlobalData.h: Added.
        (JSC::RegExpGlobalData::cachedResult):
        (JSC::RegExpGlobalData::setMultiline):
        (JSC::RegExpGlobalData::multiline const):
        (JSC::RegExpGlobalData::input):
        (JSC::RegExpGlobalData::offsetOfCachedResult):
        * runtime/RegExpGlobalDataInlines.h: Added.
        (JSC::RegExpGlobalData::setInput):
        (JSC::RegExpGlobalData::performMatch):
        (JSC::RegExpGlobalData::recordMatch):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::matchGlobal):
        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::execInline):
        (JSC::RegExpObject::matchInline):
        (JSC::collectMatches):
        * runtime/RegExpPrototype.cpp:
        (JSC::RegExpPrototype::finishCreation):
        (JSC::regExpProtoFuncSearchFast):
        (JSC::RegExpPrototype::visitChildren): Deleted.
        * runtime/RegExpPrototype.h:
        * runtime/StringPrototype.cpp:
        (JSC::removeUsingRegExpSearch):
        (JSC::replaceUsingRegExpSearch):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2018-12-15  Darin Adler  <darin@apple.com>

        Replace many uses of String::format with more type-safe alternatives
        https://bugs.webkit.org/show_bug.cgi?id=192742

        Reviewed by Mark Lam.

        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeCall): Use makeString.
        (Inspector::InjectedScriptBase::makeAsyncCall): Ditto.
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::getPropertyValue): Ditto.
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::enable): Ditto.
        * jsc.cpp:
        (FunctionJSCStackFunctor::operator() const): Ditto.

        * runtime/CodeCache.cpp:
        (JSC::writeCodeBlock): Use makeString's numeric capabilities instead of
        using String::number.

        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat): Use string concatenation.
        * runtime/IntlObject.cpp:
        (JSC::canonicalizeLocaleList): Ditto.

2019-01-27  Chris Fleizach  <cfleizach@apple.com>

        AX: Introduce a static accessibility tree
        https://bugs.webkit.org/show_bug.cgi?id=193348
        <rdar://problem/47203295>

        Reviewed by Ryosuke Niwa.

        * Configurations/FeatureDefines.xcconfig:

2019-01-26  Devin Rousso  <drousso@apple.com>

        Web Inspector: provide a way to edit the user agent of a remote target
        https://bugs.webkit.org/show_bug.cgi?id=193862
        <rdar://problem/47359292>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Page.json:
        Add `overrideUserAgent` command.

2019-01-25  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] NativeErrorConstructor should not have own IsoSubspace
        https://bugs.webkit.org/show_bug.cgi?id=193713

        Reviewed by Saam Barati.

        This removes an additional member in NativeErrorConstructor, and make sizeof(NativeErrorConstructor) == sizeof(InternalFunction).
        We also make error constructors lazily allocated by using LazyClassStructure. Since error structures are not accessed from DFG / FTL
        threads, this is OK. While TypeError constructor is eagerly allocated because it is touched from our builtin JS as @TypeError, we should
        offer some function instead of exposing TypeError constructor in the future, and remove this @TypeError reference. This change removes
        IsoSubspace for NativeErrorConstructor in VM. We also remove @Error and @RangeError references for builtins since they are no longer
        referenced.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/BuiltinNames.h:
        * interpreter/Interpreter.h:
        * runtime/Error.cpp:
        (JSC::createEvalError):
        (JSC::createRangeError):
        (JSC::createReferenceError):
        (JSC::createSyntaxError):
        (JSC::createTypeError):
        (JSC::createURIError):
        (WTF::printInternal): Deleted.
        * runtime/Error.h:
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::create):
        (JSC::ErrorPrototype::finishCreation):
        * runtime/ErrorPrototype.h:
        (JSC::ErrorPrototype::create): Deleted.
        * runtime/ErrorType.cpp: Added.
        (JSC::errorTypeName):
        (WTF::printInternal):
        * runtime/ErrorType.h: Added.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::initializeErrorConstructor):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::internalPromiseConstructor const):
        (JSC::JSGlobalObject::errorStructure const):
        (JSC::JSGlobalObject::evalErrorConstructor const): Deleted.
        (JSC::JSGlobalObject::rangeErrorConstructor const): Deleted.
        (JSC::JSGlobalObject::referenceErrorConstructor const): Deleted.
        (JSC::JSGlobalObject::syntaxErrorConstructor const): Deleted.
        (JSC::JSGlobalObject::typeErrorConstructor const): Deleted.
        (JSC::JSGlobalObject::URIErrorConstructor const): Deleted.
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor<errorType>::NativeErrorConstructor):
        (JSC::NativeErrorConstructorBase::finishCreation):
        (JSC::NativeErrorConstructor<errorType>::constructNativeErrorConstructor):
        (JSC::NativeErrorConstructor<errorType>::callNativeErrorConstructor):
        (JSC::NativeErrorConstructor::NativeErrorConstructor): Deleted.
        (JSC::NativeErrorConstructor::finishCreation): Deleted.
        (JSC::NativeErrorConstructor::visitChildren): Deleted.
        (JSC::Interpreter::constructWithNativeErrorConstructor): Deleted.
        (JSC::Interpreter::callNativeErrorConstructor): Deleted.
        * runtime/NativeErrorConstructor.h:
        (JSC::NativeErrorConstructorBase::createStructure):
        (JSC::NativeErrorConstructorBase::NativeErrorConstructorBase):
        * runtime/NativeErrorPrototype.cpp:
        (JSC::NativeErrorPrototype::finishCreation): Deleted.
        * runtime/NativeErrorPrototype.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * wasm/js/WasmToJS.cpp:
        (JSC::Wasm::handleBadI64Use):

2019-01-25  Devin Rousso  <drousso@apple.com>

        Web Inspector: provide a way to edit page settings on a remote target
        https://bugs.webkit.org/show_bug.cgi?id=193813
        <rdar://problem/47359510>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Page.json:
        Add `overrideSetting` command with supporting `Setting` enum type.

2019-01-25  Keith Rollin  <krollin@apple.com>

        Update Xcode projects with "Check .xcfilelists" build phase
        https://bugs.webkit.org/show_bug.cgi?id=193790
        <rdar://problem/47201374>

        Reviewed by Alex Christensen.

        Support for XCBuild includes specifying inputs and outputs to various
        Run Script build phases. These inputs and outputs are specified as
        .xcfilelist files. Once created, these .xcfilelist files need to be
        kept up-to-date. In order to check that they are up-to-date or not,
        add an Xcode build step that invokes an external script that performs
        the checking. If the .xcfilelists are found to be out-of-date, update
        them, halt the build, and instruct the developer to restart the build
        with up-to-date files.

        At this time, the checking and regenerating is performed only if the
        WK_ENABLE_CHECK_XCFILELISTS environment variable is set to 1. People
        who want to use this facility can set this variable and test out the
        checking/regenerating. Once it seems like there are no egregious
        issues that upset a developer's workflow, we'll unconditionally enable
        this facility.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/check-xcfilelists.sh: Added.

2019-01-25  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Exclude Debugger Threads from CPU Usage values in Web Inspector
        https://bugs.webkit.org/show_bug.cgi?id=193796
        <rdar://problem/47532910>

        Reviewed by Devin Rousso.

        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::machThread):
        * runtime/SamplingProfiler.h:
        Expose the mach_port_t of the SamplingProfiler thread
        so it can be tested against later.

2019-01-25  Alex Christensen  <achristensen@webkit.org>

        Fix Windows build after r240511

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):

2019-01-25  Keith Rollin  <krollin@apple.com>

        Update Xcode projects with "Apply Configuration to XCFileLists" build target
        https://bugs.webkit.org/show_bug.cgi?id=193781
        <rdar://problem/47201153>

        Reviewed by Alex Christensen.

        Part of generating the .xcfilelists used as part of adopting XCBuild
        includes running `make DerivedSources.make` from a standalone script.
        It’s important for this invocation to have the same environment as
        when the actual build invokes `make DerivedSources.make`. If the
        environments are different, then the two invocations will provide
        different results. In order to get the same environment in the
        standalone script, have the script launch xcodebuild targeting the
        "Apply Configuration to XCFileLists" build target, which will then
        re-invoke our standalone script. The script is now running again, this
        time in an environment with all workspace, project, target, xcconfig
        and other environment variables established.

        The "Apply Configuration to XCFileLists" build target accomplishes
        this task via a small embedded shell script that consists only of:

            eval "${WK_SUBLAUNCH_SCRIPT_PARAMETERS[@]}"

        The process that invokes "Apply Configuration to XCFileLists" first
        sets WK_SUBLAUNCH_SCRIPT_PARAMETERS to an array of commands to be
        evaluated and exports it into the shell environment. When xcodebuild
        is invoked, it inherits the value of this variable and can `eval` the
        contents of that variable. Our external standalone script can then set
        WK_SUBLAUNCH_SCRIPT_PARAMETERS to the path to itself, along with a set
        of command-line parameters needed to restart itself in the appropriate
        state.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2019-01-25  Tadeu Zagallo  <tzagallo@apple.com>

        Add API to generate and consume cached bytecode
        https://bugs.webkit.org/show_bug.cgi?id=193401
        <rdar://problem/47514099>

        Reviewed by Keith Miller.

        Add the `generateBytecode` and `generateModuleBytecode` functions to
        generate serialized bytecode for a given `SourceCode`. These functions
        will eagerly generate code for all the nested functions.

        Additionally, update the API methods in JSScript to generate and use the
        bytecode when the bytecodeCache path is provided.

        * API/JSAPIGlobalObject.mm:
        (JSC::JSAPIGlobalObject::moduleLoaderFetch):
        * API/JSContext.mm:
        (-[JSContext wrapperMap]):
        * API/JSContextInternal.h:
        * API/JSScript.mm:
        (+[JSScript scriptWithSource:inVirtualMachine:]):
        (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
        (-[JSScript dealloc]):
        (-[JSScript readCache]):
        (-[JSScript writeCache]):
        (-[JSScript hash]):
        (-[JSScript source]):
        (-[JSScript cachedBytecode]):
        (-[JSScript jsSourceCode:]):
        * API/JSScriptInternal.h:
        * API/JSScriptSourceProvider.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
        (JSScriptSourceProvider::create):
        (JSScriptSourceProvider::JSScriptSourceProvider):
        * API/JSScriptSourceProvider.mm: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
        (JSScriptSourceProvider::hash const):
        (JSScriptSourceProvider::source const):
        (JSScriptSourceProvider::cachedBytecode const):
        * API/JSVirtualMachine.mm:
        (-[JSVirtualMachine vm]):
        * API/JSVirtualMachineInternal.h:
        * API/tests/testapi.mm:
        (testBytecodeCache):
        (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
        (testObjectiveCAPI):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * SourcesCocoa.txt:
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::source const):
        * parser/SourceProvider.h:
        (JSC::CachedBytecode::CachedBytecode):
        (JSC::CachedBytecode::operator=):
        (JSC::CachedBytecode::data const):
        (JSC::CachedBytecode::size const):
        (JSC::CachedBytecode::owned const):
        (JSC::CachedBytecode::~CachedBytecode):
        (JSC::CachedBytecode::freeDataIfOwned):
        (JSC::SourceProvider::cachedBytecode const):
        * parser/UnlinkedSourceCode.h:
        (JSC::UnlinkedSourceCode::provider const):
        * runtime/CodeCache.cpp:
        (JSC::generateUnlinkedCodeBlockForFunctions):
        (JSC::writeCodeBlock):
        (JSC::serializeBytecode):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::fetchFromDiskImpl):
        (JSC::CodeCacheMap::findCacheAndUpdateAge):
        (JSC::generateUnlinkedCodeBlockImpl):
        (JSC::generateUnlinkedCodeBlock):
        * runtime/Completion.cpp:
        (JSC::generateBytecode):
        (JSC::generateModuleBytecode):
        * runtime/Completion.h:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2019-01-25  Keith Rollin  <krollin@apple.com>

        Update WebKitAdditions.xcconfig with correct order of variable definitions
        https://bugs.webkit.org/show_bug.cgi?id=193793
        <rdar://problem/47532439>

        Reviewed by Alex Christensen.

        XCBuild changes the way xcconfig variables are evaluated. In short,
        all config file assignments are now considered in part of the
        evaluation. When using the new build system and an .xcconfig file
        contains multiple assignments of the same build setting:

        - Later assignments using $(inherited) will inherit from earlier
          assignments in the xcconfig file.
        - Later assignments not using $(inherited) will take precedence over
          earlier assignments. An assignment to a more general setting will
          mask an earlier assignment to a less general setting. For example,
          an assignment without a condition ('FOO = bar') will completely mask
          an earlier assignment with a condition ('FOO[sdk=macos*] = quux').

        This affects some of our .xcconfig files, in that sometimes platform-
        or sdk-specific definitions appear before the general definitions.
        Under the new evaluations rules, the general definitions alway take
        effect because they always overwrite the more-specific definitions. The
        solution is to swap the order, so that the general definitions are
        established first, and then conditionally overwritten by the
        more-specific definitions.

        * Configurations/Version.xcconfig:

2019-01-25  Keith Rollin  <krollin@apple.com>

        Update existing .xcfilelists
        https://bugs.webkit.org/show_bug.cgi?id=193791
        <rdar://problem/47201706>

        Reviewed by Alex Christensen.

        Many .xcfilelist files were added in r238824 in order to support
        XCBuild. Update these with recent changes to the set of build files
        and with the current generate-xcfilelist script.

        * DerivedSources-input.xcfilelist:
        * DerivedSources-output.xcfilelist:
        * UnifiedSources-input.xcfilelist:
        * UnifiedSources-output.xcfilelist:

2019-01-25  Jon Davis  <jond@apple.com>

        Update JavaScriptCore feature status entries.
        https://bugs.webkit.org/show_bug.cgi?id=193797

        Reviewed by Mark Lam.
        
        Updated feature status for Async Iteration, and Object rest/spread.

        * features.json:

2019-01-24  Keith Miller  <keith_miller@apple.com>

        Remove usage of internal macro from private header
        https://bugs.webkit.org/show_bug.cgi?id=193809

        Reviewed by Saam Barati.

        Also, add a new file to include all of our API headers to make sure
        they don't accidentally include C++ or internal values.

        * API/JSScript.h:
        * API/tests/testIncludes.m: Added.
        * JavaScriptCore.xcodeproj/project.pbxproj:

2019-01-24  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] ErrorConstructor should not have own IsoSubspace
        https://bugs.webkit.org/show_bug.cgi?id=193800

        Reviewed by Saam Barati.

        Similar to r240456, sizeof(ErrorConstructor) != sizeof(InternalFunction), and that is why we have
        IsoSubspace errorConstructorSpace in VM. But it is allocated only one-per-JSGlobalObject, and it is
        too costly to have IsoSubspace which allocates 16KB. Since stackTraceLimit information is per
        JSGlobalObject information, we should have m_stackTraceLimit in JSGlobalObject instead and put
        ErrorConstructor in InternalFunction's IsoSubspace. As r230813 (moving InternalFunction and subclasses
        into IsoSubspaces) described,

            "subclasses that are the same size as InternalFunction share its subspace. I did this because the subclasses
            appear to just override methods, which are called dynamically via the structure or class of the object.
            So, I don't see a type confusion risk if UAF is used to allocate one kind of InternalFunction over another."

        Then, putting ErrorConstructor in InternalFunction IsoSubspace is fine since it meets the above condition.
        This patch removes m_stackTraceLimit in ErrorConstructor, and drops IsoSubspace for errorConstructorSpace.
        This reduces the memory usage.

        * interpreter/Interpreter.h:
        * runtime/Error.cpp:
        (JSC::getStackTrace):
        * runtime/ErrorConstructor.cpp:
        (JSC::ErrorConstructor::ErrorConstructor):
        (JSC::ErrorConstructor::finishCreation):
        (JSC::constructErrorConstructor):
        (JSC::callErrorConstructor):
        (JSC::ErrorConstructor::put):
        (JSC::ErrorConstructor::deleteProperty):
        (JSC::Interpreter::constructWithErrorConstructor): Deleted.
        (JSC::Interpreter::callErrorConstructor): Deleted.
        * runtime/ErrorConstructor.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::stackTraceLimit const):
        (JSC::JSGlobalObject::setStackTraceLimit):
        (JSC::JSGlobalObject::errorConstructor const): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-01-24  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: CPU Usage Timeline
        https://bugs.webkit.org/show_bug.cgi?id=193730
        <rdar://problem/46797201>

        Reviewed by Devin Rousso.

        * CMakeLists.txt:
        * DerivedSources-input.xcfilelist:
        * DerivedSources.make:
        New files.

        * inspector/protocol/CPUProfiler.json: Added.
        New domain that follows the pattern of Memory/ScriptProfiler.

        * inspector/protocol/Timeline.json:
        New enum to auto-start a CPU instrument in the backend.

2019-01-24  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] SharedArrayBufferConstructor and ArrayBufferConstructor should not have their own IsoSubspace
        https://bugs.webkit.org/show_bug.cgi?id=193774

        Reviewed by Mark Lam.

        We put all the instances of InternalFunction and its subclasses in IsoSubspace to make safer from UAF.
        But since IsoSubspace requires the memory layout of instances is the same, we created different IsoSubspace
        for subclasses of InternalFunction if sizeof(subclass) != sizeof(InternalFunction). One example is
        ArrayBufferConstructor and SharedArrayBufferConstructor. But it is too costly to allocate 16KB page just
        for these two constructor instances. They are only two instances per JSGlobalObject.

        This patch makes sizeof(ArrayBufferConstructor) == sizeof(InternalFunction) so that they can use IsoSubspace
        of InternalFunction. We introduce JSGenericArrayBufferConstructor, and it takes ArrayBufferSharingMode as
        its template parameter. We define JSArrayBufferConstructor as JSGenericArrayBufferConstructor<ArrayBufferSharingMode::Default>
        and JSSharedArrayBufferConstructor as JSGenericArrayBufferConstructor<ArrayBufferSharingMode::Shared> so that
        we do not need to hold ArrayBufferSharingMode in the field of the constructor. This change removes IsoSubspace
        for ArrayBufferConstructors, and reduces the memory usage.

        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::JSGenericArrayBufferConstructor<sharingMode>::JSGenericArrayBufferConstructor):
        (JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
        (JSC::JSGenericArrayBufferConstructor<sharingMode>::constructArrayBuffer):
        (JSC::JSGenericArrayBufferConstructor<sharingMode>::createStructure):
        (JSC::JSGenericArrayBufferConstructor<sharingMode>::info):
        (JSC::JSArrayBufferConstructor::JSArrayBufferConstructor): Deleted.
        (JSC::JSArrayBufferConstructor::finishCreation): Deleted.
        (JSC::JSArrayBufferConstructor::create): Deleted.
        (JSC::JSArrayBufferConstructor::createStructure): Deleted.
        (JSC::constructArrayBuffer): Deleted.
        * runtime/JSArrayBufferConstructor.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-01-24  Yusuke Suzuki  <ysuzuki@apple.com>

        stress/const-semantics.js fails a dfg-eager / ftl-eager run with an ASAN release build.
        https://bugs.webkit.org/show_bug.cgi?id=190693

        Reviewed by Michael Saboff.

        JITStubRoutine's fields are marked only when JITStubRoutine::m_mayBeExecuting is true.
        This becomes true when we find the executable address in our conservative roots, which
        means that we could be executing it right now. This means that object liveness in
        JITStubRoutine depends on the information gathered in ConservativeRoots. However, our
        constraints are separated, "Conservative Scan" and "JIT Stub Routines". They can even
        be executed concurrently, so that "JIT Stub Routines" may miss to mark the actually
        executing JITStubRoutine because "Conservative Scan" finds it later.
        When finalizing the GC, we delete the dead JITStubRoutines. At that time, since
        "Conservative Scan" already finishes, we do not delete some JITStubRoutines which do not
        mark the depending objects. Then, in the next cycle, we find JITStubRoutines still live,
        attempt to mark the depending objects, and encounter the dead objects which are collected
        in the previous cycles.

        This patch removes "JIT Stub Routines" and merge it to "Conservative Scan". Since
        "Conservative Scan" and "JIT Stub Routines" need to be executed only when the execution
        happens (ensured by GreyedByExecution and CollectionPhase check), this change is OK for
        GC stop time.

        * heap/ConservativeRoots.h:
        (JSC::ConservativeRoots::roots const):
        (JSC::ConservativeRoots::roots): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::addCoreConstraints):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::append):
        * heap/SlotVisitor.h:
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
        * jit/GCAwareJITStubRoutine.h:

2019-01-24  Saam Barati  <sbarati@apple.com>

        Update ARM64EHash
        https://bugs.webkit.org/show_bug.cgi?id=193776
        <rdar://problem/47526457>

        Reviewed by Mark Lam.

        See radar for details.

        * assembler/AssemblerBuffer.h:
        (JSC::ARM64EHash::update):
        (JSC::ARM64EHash::finalHash const):

2019-01-24  Saam Barati  <sbarati@apple.com>

        Object Allocation Sinking phase can move a node that walks the stack into a place where the InlineCallFrame is no longer valid
        https://bugs.webkit.org/show_bug.cgi?id=193751
        <rdar://problem/47280215>

        Reviewed by Michael Saboff.

        The Object Allocation Sinking phase may move allocations around inside
        of the program. However, it was not ensuring that it's still possible 
        to walk the stack at the point in the program that it moved the allocation to.
        Certain InlineCallFrames rely on data in the stack when taking a stack trace.
        All allocation sites can do a stack walk (we do a stack walk when we GC).
        Conservatively, this patch says we're ok to move this allocation if we are
        moving within the same InlineCallFrame. We could be more precise and do an
        analysis of stack writes. However, this scenario is so rare that we just
        take the conservative-and-straight-forward approach of checking that the place
        we're moving to is the same InlineCallFrame as the allocation site.
        
        In general, this issue arises anytime we do any kind of code motion.
        Interestingly, LICM gets this right. It gets it right because the only
        InlineCallFrames we can't move out of are the InlineCallFrames that
        have metadata stored on the stack (callee for closure calls and argument
        count for varargs calls). LICM doesn't have this issue because it relies
        on Clobberize for doing its effects analysis. In clobberize, we model every
        node within an InlineCallFrame that meets the above criteria as reading
        from those stack fields. Consequently, LICM won't hoist any node in that
        InlineCallFrame past the beginning of the InlineCallFrame since the IR
        we generate to set up such an InlineCallFrame contains writes to that
        stack location.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2019-01-24  Guillaume Emont  <guijemont@igalia.com>

        [JSC] Reenable baseline JIT on mips
        https://bugs.webkit.org/show_bug.cgi?id=192983

        Reviewed by Mark Lam.

        Use $s0 as metadata register and make sure it's properly saved and
        restored.

        * jit/GPRInfo.h:
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::vmCalleeSaveRegisters):
        (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
        * llint/LowLevelInterpreter.asm:
        * offlineasm/mips.rb:

2019-01-24  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLIB] Expose JavaScriptCore options in GLib public API
        https://bugs.webkit.org/show_bug.cgi?id=188742

        Reviewed by Michael Catanzaro.

        Add new API to set, get and iterate JSC options.

        * API/glib/JSCOptions.cpp: Added.
        (valueFromGValue):
        (valueToGValue):
        (jscOptionsSetValue):
        (jscOptionsGetValue):
        (jsc_options_set_boolean):
        (jsc_options_get_boolean):
        (jsc_options_set_int):
        (jsc_options_get_int):
        (jsc_options_set_uint):
        (jsc_options_get_uint):
        (jsc_options_set_size):
        (jsc_options_get_size):
        (jsc_options_set_double):
        (jsc_options_get_double):
        (jsc_options_set_string):
        (jsc_options_get_string):
        (jsc_options_set_range_string):
        (jsc_options_get_range_string):
        (jscOptionsType):
        (jsc_options_foreach):
        (setOptionEntry):
        (jsc_options_get_option_group):
        * API/glib/JSCOptions.h: Added.
        * API/glib/docs/jsc-glib-4.0-sections.txt:
        * API/glib/docs/jsc-glib-docs.sgml:
        * API/glib/jsc.h:
        * GLib.cmake:

2019-01-23  Mark Lam  <mark.lam@apple.com>

        ARM64E should not ENABLE(SEPARATED_WX_HEAP).
        https://bugs.webkit.org/show_bug.cgi?id=193744
        <rdar://problem/46262952>

        Reviewed by Saam Barati.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):

2019-01-23  Yusuke Suzuki  <ysuzuki@apple.com>

        [DFG] AvailabilityMap::pruneByLiveness should make non-live operands Availability::unavailable instead of Availability()
        https://bugs.webkit.org/show_bug.cgi?id=193711
        <rdar://problem/47250262>

        Reviewed by Saam Barati.

        When pruning OSR Availability based on bytecode liveness, we accidentally clear the Availability (making it DeadFlush) instead of
        making it Availability::unavailable() (Making it ConflictingFlush). In OSRAvailabilityAnalysisPhase, we perform forward analysis.
        We first clear all the availability of basic blocks DeadFlush, which is an empty set. And then, we set operands in the root block
        ConflictingFlush. In this forward analysis, DeadFlush is BOTTOM, and ConflictingFlush is TOP. Then, we propagate information by
        merging availability until we reach to the fixed-point. As an optimization, we perform "pruning" of the availability in the head
        of the basic blocks. We remove availabilities of operands which are not live in the bytecode liveness at the head of the basic block.
        The problem is, when removing availabilities, we set DeadFlush for them instead of ConflictingFlush. Basically, it means that we set
        BOTTOM (an empty set) instead of TOP. Let's consider the following simple example. We have 6 basic blocks, and they are connected
        as follows.

            BB0 -> BB1 -> BB2 -> BB4
             |        \        ^
             v          > BB3 /
            BB5

        And consider about loc1 in FTL, which is required to be recovered in BB4's OSR exit.

            BB0 does nothing
                head: loc1 is dead
                tail: loc1 is dead

            BB1 has MovHint @1, loc1
                head: loc1 is dead
                tail: loc1 is live

            BB2 does nothing
                head: loc1 is live
                tail: loc1 is live

            BB3 has PutStack @1, loc1
                head: loc1 is live
                tail: loc1 is live

            BB4 has OSR exit using loc1
                head: loc1 is live
                tail: loc1 is live (in bytecode)

            BB5 does nothing
                head: loc1 is dead
                tail: loc1 is dead

        In our OSR Availability analysis, we always prune loc1 result in BB1's head since its head says "loc1 is dead".
        But at that time, we clear the availability for loc1, which makes it DeadFlush, instead of making it ConflictingFlush.

        So, the flush format of loc1 in each tail of BB is like this.

            BB0
                ConflictingFlush (because all the local operands are initialized with ConflictingFlush)
            BB1
                DeadFlush+@1 (pruning clears it)
            BB2
                DeadFlush+@1 (since it is propagated from BB1)
            BB3
                FlushedJSValue+@1 with loc1 (since it has PutStack)
            BB4
                FlushedJSValue+@1 with loc1 (since MERGE(DeadFlush, FlushedJSValue) = FlushedJSValue)
            BB5
                DeadFlush (pruning clears it)

        Then, if we go the path BB0->BB1->BB2->BB4, we read the value from the stack while it is not flushed.
        The correct fix is making availability "unavailable" when pruning based on bytecode liveness.

        * dfg/DFGAvailabilityMap.cpp:
        (JSC::DFG::AvailabilityMap::pruneByLiveness): When pruning availability, we first set all the operands Availability::unavailable(),
        and copy the calculated value from the current availability map.
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::OSRAvailabilityAnalysisPhase::run): Add logging things for debugging.

2019-01-23  David Kilzer  <ddkilzer@apple.com>

        [JSC] Duplicate global variables: JSC::opcodeLengths
        <https://webkit.org/b/193714>
        <rdar://problem/47340200>

        Reviewed by Mark Lam.

        * bytecode/Opcode.cpp:
        (JSC::opcodeLengths): Move array implementation here and mark
        const.
        * bytecode/Opcode.h:
        (JSC::opcodeLengths): Change to extern declaration.

2019-01-23  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLIB] Remote Inspector: no data displayed
        https://bugs.webkit.org/show_bug.cgi?id=193569

        Reviewed by Michael Catanzaro.

        Release the remote inspector mutex before using RemoteConnectionToTarget in RemoteInspector::setup() to avoid a
        deadlock.

        * inspector/remote/glib/RemoteInspectorGlib.cpp:
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::setup):

2019-01-22  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, fix initial global lexical binding epoch
        https://bugs.webkit.org/show_bug.cgi?id=193603
        <rdar://problem/47380869>

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):

2019-01-22  Yusuke Suzuki  <ysuzuki@apple.com>

        REGRESSION(r239612) Crash at runtime due to broken DFG assumption
        https://bugs.webkit.org/show_bug.cgi?id=193709
        <rdar://problem/47363838>

        Unreviewed, rollout to watch the tests.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupObjectToString): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectToString): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf):
        (JSC::FTL::DFG::LowerDFGToB3::compileObjectToString): Deleted.
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        (JSC::objectProtoFuncToString):
        * runtime/ObjectPrototype.h:
        * runtime/ObjectPrototypeInlines.h: Removed.
        * runtime/StructureRareData.h:

2019-01-22  Devin Rousso  <drousso@apple.com>

        Web Inspector: expose Audit and Recording versions to the frontend
        https://bugs.webkit.org/show_bug.cgi?id=193262
        <rdar://problem/47130684>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Audit.json:
        * inspector/protocol/Recording.json:
        Add `version` values.

        * inspector/scripts/codegen/models.py:
        (Protocol.parse_domain):
        (Domain.__init__):
        (Domain.version): Added.
        (Domains):

        * inspector/scripts/codegen/generator.py:
        (Generator.version_for_domain): Added.

        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator.generate_output):
        (CppProtocolTypesHeaderGenerator._generate_versions): Added.

        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.should_generate_domain):
        (JSBackendCommandsGenerator.generate_domain):

        * inspector/scripts/tests/generic/version.json: Added.
        * inspector/scripts/tests/generic/expected/version.json-result: Added.

        * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/domain-availability.json-result:
        * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/generic/expected/enum-values.json-result:
        * inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
        * inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result:
        * inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:

2019-01-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Intl constructors should fit in sizeof(InternalFunction)
        https://bugs.webkit.org/show_bug.cgi?id=193661

        Reviewed by Mark Lam.

        Previously all the Intl constructors have their own subspace. This is because these constructors have different size from InternalFunction.
        But it is too costly approach in terms of the memory usage since these constructors are only one per JSGlobalObject. This patch attempts to
        reduce the memory size consumed by these Intl objects by holding instance structures in IntlObject instead of in each Intl constructors.
        So that we can make sizeof(Intl constructors) == sizeof(InternalFunction) and drop costly subspaces. Since this patch drops subspaces in VM,
        it also significantly reduces the sizeof(VM), from 76696 to 74680.

        This patch also includes the preparation for making Intl properties lazy. But currently it is not possible since @Collator reference exists
        in builtin code.

        * CMakeLists.txt:
        * DerivedSources.make:
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructor::create):
        (JSC::IntlCollatorConstructor::finishCreation):
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        (JSC::IntlCollatorConstructor::visitChildren): Deleted.
        * runtime/IntlCollatorConstructor.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructor::create):
        (JSC::IntlDateTimeFormatConstructor::finishCreation):
        (JSC::constructIntlDateTimeFormat):
        (JSC::callIntlDateTimeFormat):
        (JSC::IntlDateTimeFormatConstructor::visitChildren): Deleted.
        * runtime/IntlDateTimeFormatConstructor.h:
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructor::create):
        (JSC::IntlNumberFormatConstructor::finishCreation):
        (JSC::constructIntlNumberFormat):
        (JSC::callIntlNumberFormat):
        (JSC::IntlNumberFormatConstructor::visitChildren): Deleted.
        * runtime/IntlNumberFormatConstructor.h:
        * runtime/IntlObject.cpp:
        (JSC::createCollatorConstructor):
        (JSC::createNumberFormatConstructor):
        (JSC::createDateTimeFormatConstructor):
        (JSC::createPluralRulesConstructor):
        (JSC::IntlObject::create):
        (JSC::IntlObject::finishCreation):
        (JSC::IntlObject::visitChildren):
        * runtime/IntlObject.h:
        * runtime/IntlPluralRulesConstructor.cpp:
        (JSC::IntlPluralRulesConstructor::create):
        (JSC::IntlPluralRulesConstructor::finishCreation):
        (JSC::constructIntlPluralRules):
        (JSC::IntlPluralRulesConstructor::visitChildren): Deleted.
        * runtime/IntlPluralRulesConstructor.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::intlObject const):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-01-22  Saam Barati  <sbarati@apple.com>

        Unreviewed. Rollout r240223. It regressed JetStream2 by 1%.

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):

2019-01-22  Tadeu Zagallo  <tzagallo@apple.com>

        Unreviewed, restore bytecode cache-related JSC options deleted in r240254
        https://bugs.webkit.org/show_bug.cgi?id=192782

        The JSC options were committed as part of r240210, which got rolled out in
        r240224. However, the options got re-landed in r240248  and then deleted
        again in 240254 (immediately before the caching code code landed in 240255)

        * runtime/Options.h:

2019-01-22  Tadeu Zagallo  <tzagallo@apple.com>

        Cache bytecode to disk
        https://bugs.webkit.org/show_bug.cgi?id=192782
        <rdar://problem/46084932>

        Reviewed by Keith Miller.

        Add the logic to serialize and deserialize the new JSC bytecode. For now,
        the cache is only used for tests.

        Each class that can be serialized has a counterpart in CachedTypes, which
        handles the decoding and encoding. When decoding, the cached objects are
        mmap'd from disk, but only used for creating instances of the respective
        in-memory version of each object. Ideally, the mmap'd objects should be
        used at runtime in the future.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/BuiltinNames.cpp:
        (JSC::BuiltinNames::BuiltinNames):
        * builtins/BuiltinNames.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantIdentifierSetRegisters):
        * bytecode/CodeBlock.h:
        * bytecode/HandlerInfo.h:
        (JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
        * bytecode/InstructionStream.h:
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addSetConstant):
        (JSC::UnlinkedCodeBlock::constantIdentifierSets):
        * bytecode/UnlinkedEvalCodeBlock.h:
        * bytecode/UnlinkedFunctionCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecode/UnlinkedGlobalCodeBlock.h:
        (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
        * bytecode/UnlinkedMetadataTable.h:
        * bytecode/UnlinkedModuleProgramCodeBlock.h:
        * bytecode/UnlinkedProgramCodeBlock.h:
        * interpreter/Interpreter.cpp:
        * jsc.cpp:
        (functionQuit):
        (runJSC):
        * parser/SourceCode.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::operator!= const):
        * parser/UnlinkedSourceCode.h:
        * parser/VariableEnvironment.h:
        * runtime/CachedTypes.cpp: Added.
        (JSC::Encoder::Allocation::buffer const):
        (JSC::Encoder::Allocation::offset const):
        (JSC::Encoder::Allocation::Allocation):
        (JSC::Encoder::Encoder):
        (JSC::Encoder::vm):
        (JSC::Encoder::malloc):
        (JSC::Encoder::offsetOf):
        (JSC::Encoder::cachePtr):
        (JSC::Encoder::offsetForPtr):
        (JSC::Encoder::release):
        (JSC::Encoder::Page::Page):
        (JSC::Encoder::Page::malloc):
        (JSC::Encoder::Page::buffer const):
        (JSC::Encoder::Page::size const):
        (JSC::Encoder::Page::getOffset const):
        (JSC::Encoder::allocateNewPage):
        (JSC::Decoder::Decoder):
        (JSC::Decoder::~Decoder):
        (JSC::Decoder::vm):
        (JSC::Decoder::offsetOf):
        (JSC::Decoder::cacheOffset):
        (JSC::Decoder::addFinalizer):
        (JSC::encode):
        (JSC::decode):
        (JSC::VariableLengthObject::buffer const):
        (JSC::VariableLengthObject::allocate):
        (JSC::CachedPtr::encode):
        (JSC::CachedPtr::decode const):
        (JSC::CachedPtr::operator-> const):
        (JSC::CachedPtr::get const):
        (JSC::CachedRefPtr::encode):
        (JSC::CachedRefPtr::decode const):
        (JSC::CachedWriteBarrier::encode):
        (JSC::CachedWriteBarrier::decode const):
        (JSC::CachedVector::encode):
        (JSC::CachedVector::decode const):
        (JSC::CachedPair::encode):
        (JSC::CachedPair::decode const):
        (JSC::CachedHashMap::encode):
        (JSC::CachedHashMap::decode const):
        (JSC::CachedUniquedStringImpl::encode):
        (JSC::CachedUniquedStringImpl::decode const):
        (JSC::CachedStringImpl::encode):
        (JSC::CachedStringImpl::decode const):
        (JSC::CachedString::encode):
        (JSC::CachedString::decode const):
        (JSC::CachedIdentifier::encode):
        (JSC::CachedIdentifier::decode const):
        (JSC::CachedOptional::encode):
        (JSC::CachedOptional::decode const):
        (JSC::CachedOptional::decodeAsPtr const):
        (JSC::CachedSimpleJumpTable::encode):
        (JSC::CachedSimpleJumpTable::decode const):
        (JSC::CachedStringJumpTable::encode):
        (JSC::CachedStringJumpTable::decode const):
        (JSC::CachedCodeBlockRareData::encode):
        (JSC::CachedCodeBlockRareData::decode const):
        (JSC::CachedBitVector::encode):
        (JSC::CachedBitVector::decode const):
        (JSC::CachedHashSet::encode):
        (JSC::CachedHashSet::decode const):
        (JSC::CachedConstantIdentifierSetEntry::encode):
        (JSC::CachedConstantIdentifierSetEntry::decode const):
        (JSC::CachedVariableEnvironment::encode):
        (JSC::CachedVariableEnvironment::decode const):
        (JSC::CachedArray::encode):
        (JSC::CachedArray::decode const):
        (JSC::CachedScopedArgumentsTable::encode):
        (JSC::CachedScopedArgumentsTable::decode const):
        (JSC::CachedSymbolTableEntry::encode):
        (JSC::CachedSymbolTableEntry::decode const):
        (JSC::CachedSymbolTable::encode):
        (JSC::CachedSymbolTable::decode const):
        (JSC::CachedImmutableButterfly::encode):
        (JSC::CachedImmutableButterfly::decode const):
        (JSC::CachedRegExp::encode):
        (JSC::CachedRegExp::decode const):
        (JSC::CachedTemplateObjectDescriptor::encode):
        (JSC::CachedTemplateObjectDescriptor::decode const):
        (JSC::CachedBigInt::encode):
        (JSC::CachedBigInt::decode const):
        (JSC::CachedJSValue::encode):
        (JSC::CachedJSValue::decode const):
        (JSC::CachedInstructionStream::encode):
        (JSC::CachedInstructionStream::decode const):
        (JSC::CachedMetadataTable::encode):
        (JSC::CachedMetadataTable::decode const):
        (JSC::CachedSourceOrigin::encode):
        (JSC::CachedSourceOrigin::decode const):
        (JSC::CachedTextPosition::encode):
        (JSC::CachedTextPosition::decode const):
        (JSC::CachedSourceProviderShape::encode):
        (JSC::CachedSourceProviderShape::decode const):
        (JSC::CachedStringSourceProvider::encode):
        (JSC::CachedStringSourceProvider::decode const):
        (JSC::CachedWebAssemblySourceProvider::encode):
        (JSC::CachedWebAssemblySourceProvider::decode const):
        (JSC::CachedSourceProvider::encode):
        (JSC::CachedSourceProvider::decode const):
        (JSC::CachedUnlinkedSourceCodeShape::encode):
        (JSC::CachedUnlinkedSourceCodeShape::decode const):
        (JSC::CachedSourceCode::encode):
        (JSC::CachedSourceCode::decode const):
        (JSC::CachedFunctionExecutable::firstLineOffset const):
        (JSC::CachedFunctionExecutable::lineCount const):
        (JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const):
        (JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const):
        (JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const):
        (JSC::CachedFunctionExecutable::startOffset const):
        (JSC::CachedFunctionExecutable::sourceLength const):
        (JSC::CachedFunctionExecutable::parametersStartOffset const):
        (JSC::CachedFunctionExecutable::typeProfilingStartOffset const):
        (JSC::CachedFunctionExecutable::typeProfilingEndOffset const):
        (JSC::CachedFunctionExecutable::parameterCount const):
        (JSC::CachedFunctionExecutable::features const):
        (JSC::CachedFunctionExecutable::sourceParseMode const):
        (JSC::CachedFunctionExecutable::isInStrictContext const):
        (JSC::CachedFunctionExecutable::hasCapturedVariables const):
        (JSC::CachedFunctionExecutable::isBuiltinFunction const):
        (JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const):
        (JSC::CachedFunctionExecutable::constructAbility const):
        (JSC::CachedFunctionExecutable::constructorKind const):
        (JSC::CachedFunctionExecutable::functionMode const):
        (JSC::CachedFunctionExecutable::scriptMode const):
        (JSC::CachedFunctionExecutable::superBinding const):
        (JSC::CachedFunctionExecutable::derivedContextType const):
        (JSC::CachedFunctionExecutable::name const):
        (JSC::CachedFunctionExecutable::ecmaName const):
        (JSC::CachedFunctionExecutable::inferredName const):
        (JSC::CachedCodeBlock::instructions const):
        (JSC::CachedCodeBlock::thisRegister const):
        (JSC::CachedCodeBlock::scopeRegister const):
        (JSC::CachedCodeBlock::globalObjectRegister const):
        (JSC::CachedCodeBlock::sourceURLDirective const):
        (JSC::CachedCodeBlock::sourceMappingURLDirective const):
        (JSC::CachedCodeBlock::usesEval const):
        (JSC::CachedCodeBlock::isStrictMode const):
        (JSC::CachedCodeBlock::isConstructor const):
        (JSC::CachedCodeBlock::hasCapturedVariables const):
        (JSC::CachedCodeBlock::isBuiltinFunction const):
        (JSC::CachedCodeBlock::superBinding const):
        (JSC::CachedCodeBlock::scriptMode const):
        (JSC::CachedCodeBlock::isArrowFunctionContext const):
        (JSC::CachedCodeBlock::isClassContext const):
        (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const):
        (JSC::CachedCodeBlock::constructorKind const):
        (JSC::CachedCodeBlock::derivedContextType const):
        (JSC::CachedCodeBlock::evalContextType const):
        (JSC::CachedCodeBlock::hasTailCalls const):
        (JSC::CachedCodeBlock::lineCount const):
        (JSC::CachedCodeBlock::endColumn const):
        (JSC::CachedCodeBlock::numVars const):
        (JSC::CachedCodeBlock::numCalleeLocals const):
        (JSC::CachedCodeBlock::numParameters const):
        (JSC::CachedCodeBlock::features const):
        (JSC::CachedCodeBlock::parseMode const):
        (JSC::CachedCodeBlock::codeType const):
        (JSC::CachedCodeBlock::rareData const):
        (JSC::CachedProgramCodeBlock::encode):
        (JSC::CachedProgramCodeBlock::decode const):
        (JSC::CachedModuleCodeBlock::encode):
        (JSC::CachedModuleCodeBlock::decode const):
        (JSC::CachedEvalCodeBlock::encode):
        (JSC::CachedEvalCodeBlock::decode const):
        (JSC::CachedFunctionCodeBlock::encode):
        (JSC::CachedFunctionCodeBlock::decode const):
        (JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::CachedCodeBlock<CodeBlockType>::decode const):
        (JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock):
        (JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock):
        (JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock):
        (JSC::CachedFunctionExecutable::encode):
        (JSC::CachedFunctionExecutable::decode const):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::CachedCodeBlock<CodeBlockType>::encode):
        (JSC::CachedSourceCodeKey::encode):
        (JSC::CachedSourceCodeKey::decode const):
        (JSC::CacheEntry::encode):
        (JSC::CacheEntry:: const):
        (JSC:: const):
        (JSC::encodeCodeBlock):
        (JSC::decodeCodeBlockImpl):
        * runtime/CachedTypes.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedGlobalCodeBlock.h.
        (JSC::decodeCodeBlock):
        * runtime/CodeCache.cpp:
        (JSC::CodeCacheMap::pruneSlowCase):
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        (JSC::CodeCache::write):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::begin):
        (JSC::CodeCacheMap::end):
        (JSC::CodeCacheMap::fetchFromDiskImpl):
        (JSC::CodeCacheMap::findCacheAndUpdateAge):
        (JSC::writeCodeBlock):
        * runtime/JSBigInt.cpp:
        * runtime/JSBigInt.h:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/RegExp.h:
        * runtime/ScopedArgumentsTable.h:
        * runtime/StackFrame.h:
        * runtime/StructureInlines.h:
        * runtime/SymbolTable.h:

2019-01-22  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Invalidate old scope operations using global lexical binding epoch
        https://bugs.webkit.org/show_bug.cgi?id=193603
        <rdar://problem/47380869>

        Reviewed by Saam Barati.

        Even if the global lexical binding does not shadow the global property at that time, we need to clear the cached information in
        scope related operations since we may have a global property previously. Consider the following example,

            foo = 0;
            function get() { return foo; }
            print(get()); // 0
            print(get()); // 0
            delete globalThis.foo;
            $.evalScript(`const foo = 42;`);
            print(get()); // Should be 42, but it returns 0 if the cached information in get() is not cleared.

        To invalidate the cache easily, we introduce global lexical binding epoch. It is bumped every time we introduce a new lexical binding
        into JSGlobalLexicalEnvironment, since that name could shadow the global property name previously. In op_resolve_scope, we first check
        the epoch stored in the metadata, and go to slow path if it is not equal to the current epoch. Our slow path code convert the scope
        operation to the appropriate one even if the resolve type is not UnresolvedProperty type. After updating the resolve type of the bytecode,
        we update the cached epoch to the current one, so that we can use the cached information as long as we stay in the same epoch.

        In op_get_from_scope and op_put_to_scope, we do not use this epoch since Structure check can do the same thing instead. If op_resolve_type
        is updated by the epoch, and if it starts returning JSGlobalLexicalEnvironment instead JSGlobalObject, obviously the structure check fails.
        And in the slow path, we update op_get_from_scope and op_put_to_scope appropriately.

        So, the metadata for scope related bytecodes are eventually updated to the appropriate one. In DFG and FTL, we use the watchpoint based approach.
        In DFG and FTL, we concurrently attempt to get the watchpoint for the lexical binding and look into it by using `isStillValid()` to avoid
        infinite compile-and-fail loop.

        When the global lexical binding epoch overflows we iterate all the live CodeBlock and update the op_resolve_scope's epoch. Even if the shadowing
        happens, it is OK if we bump the epoch, since op_resolve_scope will return JSGlobalLexicalEnvironment instead of JSGlobalObject, and following
        structure check in op_put_to_scope and op_get_from_scope fail. We do not need to update op_get_from_scope and op_put_to_scope because of the same
        reason.

        * bytecode/BytecodeList.rb:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::notifyLexicalBindingUpdate):
        (JSC::CodeBlock::notifyLexicalBindingShadowing): Deleted.
        * bytecode/CodeBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGDesiredGlobalProperties.cpp:
        (JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
        * dfg/DFGDesiredGlobalProperties.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::watchGlobalProperty):
        * dfg/DFGGraph.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::isStillValidOnMainThread):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch):
        (JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
        (JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
        (JSC::JSGlobalObject::notifyLexicalBindingShadowing): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::globalLexicalBindingEpoch const):
        (JSC::JSGlobalObject::globalLexicalBindingEpochOffset):
        (JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch):
        * runtime/Options.cpp:
        (JSC::correctOptions):
        (JSC::Options::initialize):
        (JSC::Options::setOptions):
        (JSC::Options::setOptionWithoutAlias):
        * runtime/Options.h:
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):

2019-01-21  Yusuke Suzuki  <ysuzuki@apple.com>

        Unreviewed, roll out r240220 due to date-format-xparb regression
        https://bugs.webkit.org/show_bug.cgi?id=193603

        * bytecode/BytecodeList.rb:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::notifyLexicalBindingShadowing):
        (JSC::CodeBlock::notifyLexicalBindingUpdate): Deleted.
        * bytecode/CodeBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGDesiredGlobalProperties.cpp:
        (JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
        * dfg/DFGDesiredGlobalProperties.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::watchGlobalProperty): Deleted.
        * dfg/DFGGraph.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::isStillValidOnMainThread):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::notifyLexicalBindingShadowing):
        (JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
        (JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
        (JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::globalLexicalBindingEpoch const): Deleted.
        (JSC::JSGlobalObject::globalLexicalBindingEpochOffset): Deleted.
        (JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch): Deleted.
        * runtime/Options.cpp:
        (JSC::Options::initialize):
        (JSC::Options::setOptions):
        (JSC::Options::setOptionWithoutAlias):
        (JSC::correctOptions): Deleted.
        * runtime/Options.h:
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):

2019-01-21  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] StrictModeTypeErrorFunction is no longer used
        https://bugs.webkit.org/show_bug.cgi?id=193662

        Reviewed by Mark Lam.

        StrictModeTypeErrorFunction is no longer used. This patch drops it. Furthermore, it also allows us to drop
        strictModeTypeErrorFunctionSpace from VM.

        * runtime/Error.cpp:
        (JSC::StrictModeTypeErrorFunction::destroy): Deleted.
        * runtime/Error.h:
        (): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-01-21  Caio Lima  <ticaiolima@gmail.com>

        DoesGC rule is wrong for nodes with BigIntUse
        https://bugs.webkit.org/show_bug.cgi?id=193652

        Reviewed by Saam Barati.

        Former rule was that ValueOp does not GC. However this is wrong, since
        these operations can trigger GC and mess up memory management. In the end, this
        will generate wrong code because we will have wrong GC epoch value during 
        Store Barrier Insertion phase.
        We changed this to consider BigIntUse for such nodes and properly return true when
        they are BigIntUse.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2019-01-21  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Lazily initialize JSModuleLoader
        https://bugs.webkit.org/show_bug.cgi?id=193646

        Reviewed by Keith Miller and Saam Barati.

        Lazily initialize JSModuleLoader so that we do not need to initialize it until we need modules.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::moduleLoader const):

2019-01-20  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] sub op with 0 should be optimized
        https://bugs.webkit.org/show_bug.cgi?id=190751

        Reviewed by Mark Lam.

        LLInt sometimes emit `subp 0, %rxx`. For example, `maxFrameExtentForSlowPathCall` is 0 in X86_64, ARM64, and ARM64E.
        So `subp maxFrameExtentForSlowPathCall sp` becomes `subp 0, %rsp`. While `addp 0, %rsp` is removed in offlineasm,
        sub operation does not have such an optimization. This patch applies the same optimization to sub operation already
        done in add operation. Since the CPU flags changed in offlineasm's these operations are not considered (if these flags
        are required, we use special branch operations instead), this optimization is sane.

        One problem is that zero-extension of the 32bit register in 64bit architecture. If the instruction emission is skipped,
        this won't be happen. Currently, we align our sub to add operation: we skip emission in this case.

        * offlineasm/arm64.rb:
        * offlineasm/x86.rb:

2019-01-20  Saam Barati  <sbarati@apple.com>

        DFG: When inlining DataView set* intrinsics we need to set undefined as our result
        https://bugs.webkit.org/show_bug.cgi?id=193644
        <rdar://problem/46209745>

        Reviewed by Yusuke Suzuki.

        This patch also makes it so we fail fast when we make this mistake.
        I've made this mistake more than once.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):

2019-01-20  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Reduce size of SourceProvider
        https://bugs.webkit.org/show_bug.cgi?id=193544

        Reviewed by Saam Barati.

        This patch attempts to reduce the dirty memory footprint by the following 3 optimizations.

        1. Reordering the members of SourceProvider to reduce the size. This affects on JSC, and CachedScriptSourceProvider used in WebCore.

        2. Create one SourceProvider for all the builtin code and use substring to create builtin JS functions.
           This reduces # of SourceProvider created for builtins.

        3. Drop m_validated flag in SourceProvider since nobody uses it. It also deletes dead code in Parser.cpp.

        Unfortunately, MSVC does not accept super long C string literal. So instead, we construct combined string in a form of C array.

        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
        * Scripts/wkbuiltins/builtins_generate_combined_header.py:
        (BuiltinsCombinedHeaderGenerator.generate_output):
        * Scripts/wkbuiltins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_output):
        * Scripts/wkbuiltins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_output):
        * Scripts/wkbuiltins/builtins_generator.py:
        (BuiltinsGenerator.generate_embedded_code_data_for_function):
        (BuiltinsGenerator.generate_embedded_code_string_section_for_data):
        (BuiltinsGenerator.generate_embedded_code_string_section_for_function): Deleted.
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::BuiltinExecutables):
        (JSC::JSC_FOREACH_BUILTIN_CODE):
        (JSC::BuiltinExecutables::createExecutable):
        * builtins/BuiltinExecutables.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        (JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
        (JSC::Parser<LexerType>::parseObjectLiteral):
        (JSC::Parser<LexerType>::parseUnaryExpression):
        * parser/Parser.h:
        * parser/SourceCode.h:
        * parser/SourceProvider.cpp:
        (JSC::SourceProvider::SourceProvider):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::isValid const): Deleted.
        (JSC::SourceProvider::setValid): Deleted.
        * runtime/CachedTypes.cpp:
        (JSC::CachedSourceProviderShape::encode):
        (JSC::CachedSourceProviderShape::decode const):

2019-01-20  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, fix -Wint-in-bool-context warning
        https://bugs.webkit.org/show_bug.cgi?id=193483
        <rdar://problem/47280522>

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse):

2019-01-20  Saam Barati  <sbarati@apple.com>

        Rollout r240210: It broke tests on iOS
        https://bugs.webkit.org/show_bug.cgi?id=193640

        Unreviewed. ~2650 tests are failing on iOS.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/BuiltinNames.cpp:
        (JSC::BuiltinNames::BuiltinNames):
        * builtins/BuiltinNames.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantIdentifierSetRegisters):
        * bytecode/CodeBlock.h:
        * bytecode/HandlerInfo.h:
        * bytecode/InstructionStream.h:
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addSetConstant):
        (JSC::UnlinkedCodeBlock::constantIdentifierSets):
        * bytecode/UnlinkedEvalCodeBlock.h:
        * bytecode/UnlinkedFunctionCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecode/UnlinkedGlobalCodeBlock.h:
        (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
        * bytecode/UnlinkedMetadataTable.h:
        * bytecode/UnlinkedModuleProgramCodeBlock.h:
        * bytecode/UnlinkedProgramCodeBlock.h:
        * interpreter/Interpreter.cpp:
        * jsc.cpp:
        (functionQuit):
        (runJSC):
        * parser/SourceCode.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::operator!= const): Deleted.
        * parser/UnlinkedSourceCode.h:
        * parser/VariableEnvironment.h:
        * runtime/CachedTypes.cpp:
        (): Deleted.
        (JSC::Encoder::Allocation::buffer const): Deleted.
        (JSC::Encoder::Allocation::offset const): Deleted.
        (JSC::Encoder::Allocation::Allocation): Deleted.
        (JSC::Encoder::Encoder): Deleted.
        (JSC::Encoder::vm): Deleted.
        (JSC::Encoder::malloc): Deleted.
        (JSC::Encoder::offsetOf): Deleted.
        (JSC::Encoder::cachePtr): Deleted.
        (JSC::Encoder::offsetForPtr): Deleted.
        (JSC::Encoder::release): Deleted.
        (JSC::Encoder::Page::Page): Deleted.
        (JSC::Encoder::Page::malloc): Deleted.
        (JSC::Encoder::Page::buffer const): Deleted.
        (JSC::Encoder::Page::size const): Deleted.
        (JSC::Encoder::Page::getOffset const): Deleted.
        (JSC::Encoder::allocateNewPage): Deleted.
        (JSC::Decoder::Decoder): Deleted.
        (JSC::Decoder::~Decoder): Deleted.
        (JSC::Decoder::vm): Deleted.
        (JSC::Decoder::offsetOf): Deleted.
        (JSC::Decoder::cacheOffset): Deleted.
        (JSC::Decoder::addFinalizer): Deleted.
        (JSC::encode): Deleted.
        (JSC::decode): Deleted.
        (JSC::VariableLengthObject::buffer const): Deleted.
        (JSC::VariableLengthObject::allocate): Deleted.
        (JSC::CachedPtr::encode): Deleted.
        (JSC::CachedPtr::decode const): Deleted.
        (JSC::CachedPtr::operator-> const): Deleted.
        (JSC::CachedPtr::get const): Deleted.
        (JSC::CachedRefPtr::encode): Deleted.
        (JSC::CachedRefPtr::decode const): Deleted.
        (JSC::CachedWriteBarrier::encode): Deleted.
        (JSC::CachedWriteBarrier::decode const): Deleted.
        (JSC::CachedVector::encode): Deleted.
        (JSC::CachedVector::decode const): Deleted.
        (JSC::CachedPair::encode): Deleted.
        (JSC::CachedPair::decode const): Deleted.
        (JSC::CachedHashMap::encode): Deleted.
        (JSC::CachedHashMap::decode const): Deleted.
        (JSC::CachedUniquedStringImpl::encode): Deleted.
        (JSC::CachedUniquedStringImpl::decode const): Deleted.
        (JSC::CachedStringImpl::encode): Deleted.
        (JSC::CachedStringImpl::decode const): Deleted.
        (JSC::CachedString::encode): Deleted.
        (JSC::CachedString::decode const): Deleted.
        (JSC::CachedIdentifier::encode): Deleted.
        (JSC::CachedIdentifier::decode const): Deleted.
        (JSC::CachedOptional::encode): Deleted.
        (JSC::CachedOptional::decode const): Deleted.
        (JSC::CachedOptional::decodeAsPtr const): Deleted.
        (JSC::CachedSimpleJumpTable::encode): Deleted.
        (JSC::CachedSimpleJumpTable::decode const): Deleted.
        (JSC::CachedStringJumpTable::encode): Deleted.
        (JSC::CachedStringJumpTable::decode const): Deleted.
        (JSC::CachedCodeBlockRareData::encode): Deleted.
        (JSC::CachedCodeBlockRareData::decode const): Deleted.
        (JSC::CachedBitVector::encode): Deleted.
        (JSC::CachedBitVector::decode const): Deleted.
        (JSC::CachedHashSet::encode): Deleted.
        (JSC::CachedHashSet::decode const): Deleted.
        (JSC::CachedConstantIdentifierSetEntry::encode): Deleted.
        (JSC::CachedConstantIdentifierSetEntry::decode const): Deleted.
        (JSC::CachedVariableEnvironment::encode): Deleted.
        (JSC::CachedVariableEnvironment::decode const): Deleted.
        (JSC::CachedArray::encode): Deleted.
        (JSC::CachedArray::decode const): Deleted.
        (JSC::CachedScopedArgumentsTable::encode): Deleted.
        (JSC::CachedScopedArgumentsTable::decode const): Deleted.
        (JSC::CachedSymbolTableEntry::encode): Deleted.
        (JSC::CachedSymbolTableEntry::decode const): Deleted.
        (JSC::CachedSymbolTable::encode): Deleted.
        (JSC::CachedSymbolTable::decode const): Deleted.
        (JSC::CachedImmutableButterfly::encode): Deleted.
        (JSC::CachedImmutableButterfly::decode const): Deleted.
        (JSC::CachedRegExp::encode): Deleted.
        (JSC::CachedRegExp::decode const): Deleted.
        (JSC::CachedTemplateObjectDescriptor::encode): Deleted.
        (JSC::CachedTemplateObjectDescriptor::decode const): Deleted.
        (JSC::CachedBigInt::encode): Deleted.
        (JSC::CachedBigInt::decode const): Deleted.
        (JSC::CachedJSValue::encode): Deleted.
        (JSC::CachedJSValue::decode const): Deleted.
        (JSC::CachedInstructionStream::encode): Deleted.
        (JSC::CachedInstructionStream::decode const): Deleted.
        (JSC::CachedMetadataTable::encode): Deleted.
        (JSC::CachedMetadataTable::decode const): Deleted.
        (JSC::CachedSourceOrigin::encode): Deleted.
        (JSC::CachedSourceOrigin::decode const): Deleted.
        (JSC::CachedTextPosition::encode): Deleted.
        (JSC::CachedTextPosition::decode const): Deleted.
        (JSC::CachedSourceProviderShape::encode): Deleted.
        (JSC::CachedSourceProviderShape::decode const): Deleted.
        (JSC::CachedStringSourceProvider::encode): Deleted.
        (JSC::CachedStringSourceProvider::decode const): Deleted.
        (JSC::CachedWebAssemblySourceProvider::encode): Deleted.
        (JSC::CachedWebAssemblySourceProvider::decode const): Deleted.
        (JSC::CachedSourceProvider::encode): Deleted.
        (JSC::CachedSourceProvider::decode const): Deleted.
        (JSC::CachedUnlinkedSourceCodeShape::encode): Deleted.
        (JSC::CachedUnlinkedSourceCodeShape::decode const): Deleted.
        (JSC::CachedSourceCode::encode): Deleted.
        (JSC::CachedSourceCode::decode const): Deleted.
        (JSC::CachedFunctionExecutable::firstLineOffset const): Deleted.
        (JSC::CachedFunctionExecutable::lineCount const): Deleted.
        (JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const): Deleted.
        (JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const): Deleted.
        (JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const): Deleted.
        (JSC::CachedFunctionExecutable::startOffset const): Deleted.
        (JSC::CachedFunctionExecutable::sourceLength const): Deleted.
        (JSC::CachedFunctionExecutable::parametersStartOffset const): Deleted.
        (JSC::CachedFunctionExecutable::typeProfilingStartOffset const): Deleted.
        (JSC::CachedFunctionExecutable::typeProfilingEndOffset const): Deleted.
        (JSC::CachedFunctionExecutable::parameterCount const): Deleted.
        (JSC::CachedFunctionExecutable::features const): Deleted.
        (JSC::CachedFunctionExecutable::sourceParseMode const): Deleted.
        (JSC::CachedFunctionExecutable::isInStrictContext const): Deleted.
        (JSC::CachedFunctionExecutable::hasCapturedVariables const): Deleted.
        (JSC::CachedFunctionExecutable::isBuiltinFunction const): Deleted.
        (JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const): Deleted.
        (JSC::CachedFunctionExecutable::constructAbility const): Deleted.
        (JSC::CachedFunctionExecutable::constructorKind const): Deleted.
        (JSC::CachedFunctionExecutable::functionMode const): Deleted.
        (JSC::CachedFunctionExecutable::scriptMode const): Deleted.
        (JSC::CachedFunctionExecutable::superBinding const): Deleted.
        (JSC::CachedFunctionExecutable::derivedContextType const): Deleted.
        (JSC::CachedFunctionExecutable::name const): Deleted.
        (JSC::CachedFunctionExecutable::ecmaName const): Deleted.
        (JSC::CachedFunctionExecutable::inferredName const): Deleted.
        (JSC::CachedCodeBlock::instructions const): Deleted.
        (JSC::CachedCodeBlock::thisRegister const): Deleted.
        (JSC::CachedCodeBlock::scopeRegister const): Deleted.
        (JSC::CachedCodeBlock::globalObjectRegister const): Deleted.
        (JSC::CachedCodeBlock::sourceURLDirective const): Deleted.
        (JSC::CachedCodeBlock::sourceMappingURLDirective const): Deleted.
        (JSC::CachedCodeBlock::usesEval const): Deleted.
        (JSC::CachedCodeBlock::isStrictMode const): Deleted.
        (JSC::CachedCodeBlock::isConstructor const): Deleted.
        (JSC::CachedCodeBlock::hasCapturedVariables const): Deleted.
        (JSC::CachedCodeBlock::isBuiltinFunction const): Deleted.
        (JSC::CachedCodeBlock::superBinding const): Deleted.
        (JSC::CachedCodeBlock::scriptMode const): Deleted.
        (JSC::CachedCodeBlock::isArrowFunctionContext const): Deleted.
        (JSC::CachedCodeBlock::isClassContext const): Deleted.
        (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
        (JSC::CachedCodeBlock::constructorKind const): Deleted.
        (JSC::CachedCodeBlock::derivedContextType const): Deleted.
        (JSC::CachedCodeBlock::evalContextType const): Deleted.
        (JSC::CachedCodeBlock::hasTailCalls const): Deleted.
        (JSC::CachedCodeBlock::lineCount const): Deleted.
        (JSC::CachedCodeBlock::endColumn const): Deleted.
        (JSC::CachedCodeBlock::numVars const): Deleted.
        (JSC::CachedCodeBlock::numCalleeLocals const): Deleted.
        (JSC::CachedCodeBlock::numParameters const): Deleted.
        (JSC::CachedCodeBlock::features const): Deleted.
        (JSC::CachedCodeBlock::parseMode const): Deleted.
        (JSC::CachedCodeBlock::codeType const): Deleted.
        (JSC::CachedCodeBlock::rareData const): Deleted.
        (JSC::CachedProgramCodeBlock::encode): Deleted.
        (JSC::CachedProgramCodeBlock::decode const): Deleted.
        (JSC::CachedModuleCodeBlock::encode): Deleted.
        (JSC::CachedModuleCodeBlock::decode const): Deleted.
        (JSC::CachedEvalCodeBlock::encode): Deleted.
        (JSC::CachedEvalCodeBlock::decode const): Deleted.
        (JSC::CachedFunctionCodeBlock::encode): Deleted.
        (JSC::CachedFunctionCodeBlock::decode const): Deleted.
        (JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock): Deleted.
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
        (JSC::CachedCodeBlock<CodeBlockType>::decode const): Deleted.
        (JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock): Deleted.
        (JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock): Deleted.
        (JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock): Deleted.
        (JSC::CachedFunctionExecutable::encode): Deleted.
        (JSC::CachedFunctionExecutable::decode const): Deleted.
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): Deleted.
        (JSC::CachedCodeBlock<CodeBlockType>::encode): Deleted.
        (JSC::CachedSourceCodeKey::encode): Deleted.
        (JSC::CachedSourceCodeKey::decode const): Deleted.
        (JSC::CacheEntry::encode): Deleted.
        (JSC::CacheEntry:: const): Deleted.
        (JSC:: const): Deleted.
        (JSC::encodeCodeBlock): Deleted.
        (JSC::decodeCodeBlockImpl): Deleted.
        * runtime/CachedTypes.h:
        (JSC::decodeCodeBlock): Deleted.
        * runtime/CodeCache.cpp:
        (JSC::CodeCacheMap::pruneSlowCase):
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        (JSC::CodeCache::write): Deleted.
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::findCacheAndUpdateAge):
        (JSC::CodeCache::clear):
        (JSC::CodeCacheMap::begin): Deleted.
        (JSC::CodeCacheMap::end): Deleted.
        (JSC::CodeCacheMap::fetchFromDiskImpl): Deleted.
        (): Deleted.
        (JSC::writeCodeBlock): Deleted.
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::offsetOfData):
        (JSC::JSBigInt::dataStorage):
        * runtime/JSBigInt.h:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:
        * runtime/RegExp.h:
        * runtime/ScopedArgumentsTable.h:
        * runtime/StackFrame.h:
        * runtime/StructureInlines.h:
        * runtime/SymbolTable.h:

2019-01-20  Saam Barati  <sbarati@apple.com>

        MovHint must merge NodeBytecodeUsesAsValue for its child in backwards propagation
        https://bugs.webkit.org/show_bug.cgi?id=186916
        <rdar://problem/41396612>

        Reviewed by Yusuke Suzuki.

        Otherwise, we may not think we care about the non-integral part in
        a division (or perhaps overflow in an add, etc). Consider a program
        like this:
        
        ```return a / b```
        
        That gets compiled to:
        ```
        a: ArithDiv // We don't check that the remainder is zero here.
        b: MovHint(@a)
        c: ForceOSRExit
        d: Unreachable
        ```
        
        If we don't inform @a that we care about its result in full number
        accuracy, it will choose to ignore its non-integral remainder. This
        makes sense if *everybody* that all uses of the Div only cared about
        the integral part. However, OSR exit is not one of those users. OSR
        exit cares about the fractional bits in such a Div.

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):

2019-01-20  Yusuke Suzuki  <ysuzuki@apple.com>

        [JSC] Invalidate old scope operations using global lexical binding epoch
        https://bugs.webkit.org/show_bug.cgi?id=193603
        <rdar://problem/47380869>

        Reviewed by Saam Barati.

        Even if the global lexical binding does not shadow the global property at that time, we need to clear the cached information in
        scope related operations since we may have a global property previously. Consider the following example,

            foo = 0;
            function get() { return foo; }
            print(get()); // 0
            print(get()); // 0
            delete globalThis.foo;
            $.evalScript(`const foo = 42;`);
            print(get()); // Should be 42, but it returns 0 if the cached information in get() is not cleared.

        To invalidate the cache easily, we introduce global lexical binding epoch. It is bumped every time we introduce a new lexical binding
        into JSGlobalLexicalEnvironment, since that name could shadow the global property name previously. In op_resolve_scope, we first check
        the epoch stored in the metadata, and go to slow path if it is not equal to the current epoch. Our slow path code convert the scope
        operation to the appropriate one even if the resolve type is not UnresolvedProperty type. After updating the resolve type of the bytecode,
        we update the cached epoch to the current one, so that we can use the cached information as long as we stay in the same epoch.

        In op_get_from_scope and op_put_to_scope, we do not use this epoch since Structure check can do the same thing instead. If op_resolve_type
        is updated by the epoch, and if it starts returning JSGlobalLexicalEnvironment instead JSGlobalObject, obviously the structure check fails.
        And in the slow path, we update op_get_from_scope and op_put_to_scope appropriately.

        So, the metadata for scope related bytecodes are eventually updated to the appropriate one. In DFG and FTL, we use the watchpoint based approach.
        In DFG and FTL, we concurrently attempt to get the watchpoint for the lexical binding and look into it by using `isStillValid()` to avoid
        infinite compile-and-fail loop.

        When the global lexical binding epoch overflows we iterate all the live CodeBlock and update the op_resolve_scope's epoch. Even if the shadowing
        happens, it is OK if we bump the epoch, since op_resolve_scope will return JSGlobalLexicalEnvironment instead of JSGlobalObject, and following
        structure check in op_put_to_scope and op_get_from_scope fail. We do not need to update op_get_from_scope and op_put_to_scope because of the same
        reason.

        * bytecode/BytecodeList.rb:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::notifyLexicalBindingUpdate):
        (JSC::CodeBlock::notifyLexicalBindingShadowing): Deleted.
        * bytecode/CodeBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGDesiredGlobalProperties.cpp:
        (JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
        * dfg/DFGDesiredGlobalProperties.h:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::watchGlobalProperty):
        * dfg/DFGGraph.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::isStillValidOnMainThread):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch):
        (JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
        (JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
        (JSC::JSGlobalObject::notifyLexicalBindingShadowing): Deleted.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::globalLexicalBindingEpoch const):
        (JSC::JSGlobalObject::globalLexicalBindingEpochOffset):
        (JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch):
        * runtime/Options.cpp:
        (JSC::correctOptions):
        (JSC::Options::initialize):
        (JSC::Options::setOptions):
        (JSC::Options::setOptionWithoutAlias):
        * runtime/Options.h:
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):

2019-01-20  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Shrink data structure size in JSC/heap
        https://bugs.webkit.org/show_bug.cgi?id=193612

        Reviewed by Saam Barati.

        This patch reduces the size of data structures in JSC/heap. Basically, we reorder the members to remove paddings.

        For Subspace, we drop CellAttributes `m_attributes`. Instead, we use `heapCellType->attributes()`. And we use
        FreeList::cellSize() instead of holding m_cellSize in LocalAllocator.

        This change reduces the size of JSC::VM too since it includes JSC::Heap. The size of VM becomes from 78208 to 76696.

        * heap/BlockDirectory.cpp:
        * heap/BlockDirectory.h:
        * heap/CollectionScope.h:
        * heap/CompleteSubspace.cpp:
        (JSC::CompleteSubspace::allocatorForSlow):
        * heap/FreeList.h:
        (JSC::FreeList::offsetOfCellSize):
        (JSC::FreeList::cellSize const):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::runBeginPhase):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
        (JSC::Heap::deleteSourceProviderCaches):
        (JSC::Heap::notifyIncrementalSweeper):
        (JSC::Heap::updateAllocationLimits):
        * heap/Heap.h:
        * heap/IsoAlignedMemoryAllocator.h:
        * heap/LargeAllocation.cpp:
        * heap/LocalAllocator.cpp:
        (JSC::LocalAllocator::LocalAllocator):
        * heap/LocalAllocator.h:
        (JSC::LocalAllocator::cellSize const):
        (JSC::LocalAllocator::offsetOfCellSize):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        * heap/MarkedSpace.h:
        * heap/MarkingConstraint.h:
        * heap/Subspace.cpp:
        (JSC::Subspace::initialize):
        * heap/Subspace.h:
        (JSC::Subspace::attributes const): Deleted.
        * heap/SubspaceInlines.h:
        (JSC::Subspace::forEachMarkedCell):
        (JSC::Subspace::forEachMarkedCellInParallel):
        (JSC::Subspace::forEachLiveCell):
        (JSC::Subspace::attributes const):

2019-01-20  Tadeu Zagallo  <tzagallo@apple.com>

        Cache bytecode to disk
        https://bugs.webkit.org/show_bug.cgi?id=192782
        <rdar://problem/46084932>

        Reviewed by Keith Miller.

        Add the logic to serialize and deserialize the new JSC bytecode. For now,
        the cache is only used for tests.

        Each class that can be serialized has a counterpart in CachedTypes, which
        handles the decoding and encoding. When decoding, the cached objects are
        mmap'd from disk, but only used for creating instances of the respective
        in-memory version of each object. Ideally, the mmap'd objects should be
        used at runtime in the future.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * builtins/BuiltinNames.cpp:
        (JSC::BuiltinNames::BuiltinNames):
        * builtins/BuiltinNames.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setConstantIdentifierSetRegisters):
        * bytecode/CodeBlock.h:
        * bytecode/HandlerInfo.h:
        (JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
        * bytecode/InstructionStream.h:
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addSetConstant):
        (JSC::UnlinkedCodeBlock::constantIdentifierSets):
        * bytecode/UnlinkedEvalCodeBlock.h:
        * bytecode/UnlinkedFunctionCodeBlock.h:
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecode/UnlinkedGlobalCodeBlock.h:
        (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
        * bytecode/UnlinkedMetadataTable.h:
        * bytecode/UnlinkedModuleProgramCodeBlock.h:
        * bytecode/UnlinkedProgramCodeBlock.h:
        * interpreter/Interpreter.cpp:
        * jsc.cpp:
        (functionQuit):
        (runJSC):
        * parser/SourceCode.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::operator!= const):
        * parser/UnlinkedSourceCode.h:
        * parser/VariableEnvironment.h:
        * runtime/CachedTypes.cpp: Added.
        (JSC::Encoder::Allocation::buffer const):
        (JSC::Encoder::Allocation::offset const):
        (JSC::Encoder::Allocation::Allocation):
        (JSC::Encoder::Encoder):
        (JSC::Encoder::vm):
        (JSC::Encoder::malloc):
        (JSC::Encoder::offsetOf):
        (JSC::Encoder::cachePtr):
        (JSC::Encoder::offsetForPtr):
        (JSC::Encoder::release):
        (JSC::Encoder::Page::Page):
        (JSC::Encoder::Page::malloc):
        (JSC::Encoder::Page::buffer const):
        (JSC::Encoder::Page::size const):
        (JSC::Encoder::Page::getOffset const):
        (JSC::Encoder::allocateNewPage):
        (JSC::Decoder::Decoder):
        (JSC::Decoder::~Decoder):
        (JSC::Decoder::vm):
        (JSC::Decoder::offsetOf):
        (JSC::Decoder::cacheOffset):
        (JSC::Decoder::addFinalizer):
        (JSC::encode):
        (JSC::decode):
        (JSC::VariableLengthObject::buffer const):
        (JSC::VariableLengthObject::allocate):
        (JSC::CachedPtr::encode):
        (JSC::CachedPtr::decode const):
        (JSC::CachedPtr::operator-> const):
        (JSC::CachedPtr::get const):
        (JSC::CachedRefPtr::encode):
        (JSC::CachedRefPtr::decode const):
        (JSC::CachedWriteBarrier::encode):
        (JSC::CachedWriteBarrier::decode const):
        (JSC::CachedVector::encode):
        (JSC::CachedVector::decode const):
        (JSC::CachedPair::encode):
        (JSC::CachedPair::decode const):
        (JSC::CachedHashMap::encode):
        (JSC::CachedHashMap::decode const):
        (JSC::CachedUniquedStringImpl::encode):
        (JSC::CachedUniquedStringImpl::decode const):
        (JSC::CachedStringImpl::encode):
        (JSC::CachedStringImpl::decode const):
        (JSC::CachedString::encode):
        (JSC::CachedString::decode const):
        (JSC::CachedIdentifier::encode):
        (JSC::CachedIdentifier::decode const):
        (JSC::CachedOptional::encode):
        (JSC::CachedOptional::decode const):
        (JSC::CachedOptional::decodeAsPtr const):
        (JSC::CachedSimpleJumpTable::encode):
        (JSC::CachedSimpleJumpTable::decode const):
        (JSC::CachedStringJumpTable::encode):
        (JSC::CachedStringJumpTable::decode const):
        (JSC::CachedCodeBlockRareData::encode):
        (JSC::CachedCodeBlockRareData::decode const):
        (JSC::CachedBitVector::encode):
        (JSC::CachedBitVector::decode const):
        (JSC::CachedHashSet::encode):
        (JSC::CachedHashSet::decode const):
        (JSC::CachedConstantIdentifierSetEntry::encode):
        (JSC::CachedConstantIdentifierSetEntry::decode const):
        (JSC::CachedVariableEnvironment::encode):
        (JSC::CachedVariableEnvironment::decode const):
        (JSC::CachedArray::encode):
        (JSC::CachedArray::decode const):
        (JSC::CachedScopedArgumentsTable::encode):
        (JSC::CachedScopedArgumentsTable::decode const):
        (JSC::CachedSymbolTableEntry::encode):
        (JSC::CachedSymbolTableEntry::decode const):
        (JSC::CachedSymbolTable::encode):
        (JSC::CachedSymbolTable::decode const):
        (JSC::CachedImmutableButterfly::encode):
        (JSC::CachedImmutableButterfly::decode const):
        (JSC::CachedRegExp::encode):
        (JSC::CachedRegExp::decode const):
        (JSC::CachedTemplateObjectDescriptor::encode):
        (JSC::CachedTemplateObjectDescriptor::decode const):
        (JSC::CachedBigInt::encode):
        (JSC::CachedBigInt::decode const):
        (JSC::CachedJSValue::encode):
        (JSC::CachedJSValue::decode const):
        (JSC::CachedInstructionStream::encode):
        (JSC::CachedInstructionStream::decode const):
        (JSC::CachedMetadataTable::encode):
        (JSC::CachedMetadataTable::decode const):
        (JSC::CachedSourceOrigin::encode):
        (JSC::CachedSourceOrigin::decode const):
        (JSC::CachedTextPosition::encode):
        (JSC::CachedTextPosition::decode const):
        (JSC::CachedSourceProviderShape::encode):
        (JSC::CachedSourceProviderShape::decode const):
        (JSC::CachedStringSourceProvider::encode):
        (JSC::CachedStringSourceProvider::decode const):
        (JSC::CachedWebAssemblySourceProvider::encode):
        (JSC::CachedWebAssemblySourceProvider::decode const):
        (JSC::CachedSourceProvider::encode):
        (JSC::CachedSourceProvider::decode const):
        (JSC::CachedUnlinkedSourceCodeShape::encode):
        (JSC::CachedUnlinkedSourceCodeShape::decode const):
        (JSC::CachedSourceCode::encode):
        (JSC::CachedSourceCode::decode const):
        (JSC::CachedFunctionExecutable::firstLineOffset const):
        (JSC::CachedFunctionExecutable::lineCount const):
        (JSC::CachedFunctionExecutable::unlinkedFunctionNameStart const):
        (JSC::CachedFunctionExecutable::unlinkedBodyStartColumn const):
        (JSC::CachedFunctionExecutable::unlinkedBodyEndColumn const):
        (JSC::CachedFunctionExecutable::startOffset const):
        (JSC::CachedFunctionExecutable::sourceLength const):
        (JSC::CachedFunctionExecutable::parametersStartOffset const):
        (JSC::CachedFunctionExecutable::typeProfilingStartOffset const):
        (JSC::CachedFunctionExecutable::typeProfilingEndOffset const):
        (JSC::CachedFunctionExecutable::parameterCount const):
        (JSC::CachedFunctionExecutable::features const):
        (JSC::CachedFunctionExecutable::sourceParseMode const):
        (JSC::CachedFunctionExecutable::isInStrictContext const):
        (JSC::CachedFunctionExecutable::hasCapturedVariables const):
        (JSC::CachedFunctionExecutable::isBuiltinFunction const):
        (JSC::CachedFunctionExecutable::isBuiltinDefaultClassConstructor const):
        (JSC::CachedFunctionExecutable::constructAbility const):
        (JSC::CachedFunctionExecutable::constructorKind const):
        (JSC::CachedFunctionExecutable::functionMode const):
        (JSC::CachedFunctionExecutable::scriptMode const):
        (JSC::CachedFunctionExecutable::superBinding const):
        (JSC::CachedFunctionExecutable::derivedContextType const):
        (JSC::CachedFunctionExecutable::name const):
        (JSC::CachedFunctionExecutable::ecmaName const):
        (JSC::CachedFunctionExecutable::inferredName const):
        (JSC::CachedCodeBlock::instructions const):
        (JSC::CachedCodeBlock::thisRegister const):
        (JSC::CachedCodeBlock::scopeRegister const):
        (JSC::CachedCodeBlock::globalObjectRegister const):
        (JSC::CachedCodeBlock::sourceURLDirective const):
        (JSC::CachedCodeBlock::sourceMappingURLDirective const):
        (JSC::CachedCodeBlock::usesEval const):
        (JSC::CachedCodeBlock::isStrictMode const):
        (JSC::CachedCodeBlock::isConstructor const):
        (JSC::CachedCodeBlock::hasCapturedVariables const):
        (JSC::CachedCodeBlock::isBuiltinFunction const):
        (JSC::CachedCodeBlock::superBinding const):
        (JSC::CachedCodeBlock::scriptMode const):
        (JSC::CachedCodeBlock::isArrowFunctionContext const):
        (JSC::CachedCodeBlock::isClassContext const):
        (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const):
        (JSC::CachedCodeBlock::constructorKind const):
        (JSC::CachedCodeBlock::derivedContextType const):
        (JSC::CachedCodeBlock::evalContextType const):
        (JSC::CachedCodeBlock::hasTailCalls const):
        (JSC::CachedCodeBlock::lineCount const):
        (JSC::CachedCodeBlock::endColumn const):
        (JSC::CachedCodeBlock::numVars const):
        (JSC::CachedCodeBlock::numCalleeLocals const):
        (JSC::CachedCodeBlock::numParameters const):
        (JSC::CachedCodeBlock::features const):
        (JSC::CachedCodeBlock::parseMode const):
        (JSC::CachedCodeBlock::codeType const):
        (JSC::CachedCodeBlock::rareData const):
        (JSC::CachedProgramCodeBlock::encode):
        (JSC::CachedProgramCodeBlock::decode const):
        (JSC::CachedModuleCodeBlock::encode):
        (JSC::CachedModuleCodeBlock::decode const):
        (JSC::CachedEvalCodeBlock::encode):
        (JSC::CachedEvalCodeBlock::decode const):
        (JSC::CachedFunctionCodeBlock::encode):
        (JSC::CachedFunctionCodeBlock::decode const):
        (JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::CachedCodeBlock<CodeBlockType>::decode const):
        (JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock):
        (JSC::UnlinkedModuleProgramCodeBlock::UnlinkedModuleProgramCodeBlock):
        (JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock):
        (JSC::CachedFunctionExecutable::encode):
        (JSC::CachedFunctionExecutable::decode const):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::CachedCodeBlock<CodeBlockType>::encode):
        (JSC::CachedSourceCodeKey::encode):
        (JSC::CachedSourceCodeKey::decode const):
        (JSC::CacheEntry::encode):
        (JSC::CacheEntry:: const):
        (JSC:: const):
        (JSC::encodeCodeBlock):
        (JSC::decodeCodeBlockImpl):
        * runtime/CachedTypes.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedGlobalCodeBlock.h.
        (JSC::decodeCodeBlock):
        * runtime/CodeCache.cpp:
        (JSC::CodeCacheMap::pruneSlowCase):
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        (JSC::CodeCache::write):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::begin):
        (JSC::CodeCacheMap::end):
        (JSC::CodeCacheMap::fetchFromDiskImpl):
        (JSC::CodeCacheMap::findCacheAndUpdateAge):
        (JSC::writeCodeBlock):
        * runtime/JSBigInt.cpp:
        * runtime/JSBigInt.h:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:
        * runtime/RegExp.h:
        * runtime/ScopedArgumentsTable.h:
        * runtime/StackFrame.h:
        * runtime/StructureInlines.h:
        * runtime/SymbolTable.h:

2019-01-20  Antoine Quint  <graouts@apple.com>

        Add a POINTER_EVENTS feature flag
        https://bugs.webkit.org/show_bug.cgi?id=193577
        <rdar://problem/47408511>

        Unreviewed. Also enable Pointer Events for iosmac.

        * Configurations/FeatureDefines.xcconfig:

2019-01-19  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Reorder JSSegmentedVariableObject member for preparation of JSGlobalObject memory reduction
        https://bugs.webkit.org/show_bug.cgi?id=193609

        Reviewed by Sam Weinig.

        Basically, we should order the members in large => small order not to add paddings.

        * runtime/JSSegmentedVariableObject.h:

2019-01-19  Antoine Quint  <graouts@apple.com>

        Add a POINTER_EVENTS feature flag
        https://bugs.webkit.org/show_bug.cgi?id=193577

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig:

2019-01-18  Keith Miller  <keith_miller@apple.com>

        JSScript API should only take ascii files.
        https://bugs.webkit.org/show_bug.cgi?id=193420

        Reviewed by Saam Barati.

        This patch leaves the UTF8 method for binary compatablity, which
        will be removed later.

        * API/JSScript.h:
        * API/JSScript.mm:
        (fillBufferWithContentsOfFile):
        (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
        (+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
        * API/tests/testapi.mm:
        (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):

2019-01-18  David Kilzer  <ddkilzer@apple.com>

        Follow-up: Gigacages should start allocations from a slide
        <https://bugs.webkit.org/show_bug.cgi?id=193523>
        <rdar://problem/44958707>

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged): Add UNUSED_PARAM(kind) to
        fix the build.

2019-01-18  Jer Noble  <jer.noble@apple.com>

        SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
        https://bugs.webkit.org/show_bug.cgi?id=189553

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:
        * Configurations/SDKVariant.xcconfig: Added.

2019-01-18  Keith Miller  <keith_miller@apple.com>

        Gigacages should start allocations from a slide
        https://bugs.webkit.org/show_bug.cgi?id=193523

        Reviewed by Mark Lam.

        This patch changes some macros into constants since macros are the
        devil.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::caged):
        * llint/LowLevelInterpreter64.asm:

2019-01-18  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r240160.

        This broke multiple internal builds.

        Reverted changeset:

        "Gigacages should start allocations from a slide"
        https://bugs.webkit.org/show_bug.cgi?id=193523
        https://trac.webkit.org/changeset/240160

2019-01-18  Keith Miller  <keith_miller@apple.com>

        Gigacages should start allocations from a slide
        https://bugs.webkit.org/show_bug.cgi?id=193523

        Reviewed by Mark Lam.

        This patch changes some macros into constants since macros are the
        devil.

        * llint/LowLevelInterpreter64.asm:

2019-01-17  Mark Lam  <mark.lam@apple.com>

        Audit bytecode fields and ensure that LLInt instructions for accessing them are appropriate.
        https://bugs.webkit.org/show_bug.cgi?id=193557
        <rdar://problem/47369125>

        Reviewed by Yusuke Suzuki.

        1. Rename some bytecode fields so that it's easier to discern whether the LLInt
           is accessing them the right way:
           - distinguish between targetVirtualRegister and targetLabel.
           - name all StructureID fields as structureID (oldStructureID, newStructureID)
             instead of structure (oldStructure, newStructure).

        2. Use bitwise_cast in struct Fits when sizeof(T) == size.
           This prevents potential undefined behavior issues arising from doing
           assignments with reinterpret_cast'ed pointers.

        3. Make Special::Pointer an unsigned type (previously int).
           Make ResolveType an unsigned type (previously int).

        4. In LowLevelInterpreter*.asm:

           - rename the op macro argument to opcodeName or opcodeStruct respectively.
             This makes it clearer which argument type the macro is working with.

           - rename the name macro argument to opcodeName.

           - fix operator types to match the field type being accessed.  The following
             may have resulted in bugs before:

             1. The following should be read with getu() instead of get() because they
                are unsigned ints:
                    OpSwitchImm::m_tableIndex
                    OpSwitchChar::m_tableIndex
                    OpGetFromArguments::m_index
                    OpPutToArguments::m_index
                    OpGetRestLength::m_numParametersToSkip

                OpJneqPtr::m_specialPointer should also be read with getu() though this
                wasn't a bug because it was previously an int by default, and is only
                changed to an unsigned int in this patch.

             2.The following should be read with loadi (not loadp) because they are of
               unsigned type (not a pointer):
                    OpResolveScope::Metadata::m_resolveType
                    CodeBlock::m_numParameters (see prepareForTailCall)

             3. OpPutToScope::Metadata::m_operand should be read with loadp (not loadis)
                because it is a uintptr_t.

             4. The following should be read with loadi (not loadis) because they are
                unsigned ints:
                    OpNegate::Metadata::m_arithProfile + ArithProfile::m_bits
                    OpPutById::Metadata::m_oldStructureID
                    OpPutToScope::Metadata::m_getPutInfo + GetPutInfo::m_operand

                These may not have manifested in bugs because the operations that follow
                the load are 32-bit instructions which ignore the high word.

        5. Give class GetPutInfo a default constructor so that we can use bitwise_cast
           on it.  Also befriend LLIntOffsetsExtractor so that we can take the offset of
           m_operand in it.

        * bytecode/ArithProfile.h:
        * bytecode/BytecodeList.rb:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/Fits.h:
        * bytecode/GetByIdMetadata.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::jumpTargetForInstruction):
        (JSC::updateStoredJumpTargetsForInstruction):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        * bytecode/SpecialPointer.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::Label::setLocation):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareAndJumpSlow):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emitBinaryDoubleOp):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_jmp):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_jeq):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_jneq):
        (JSC::JIT::compileOpStrictEqJump):
        (JSC::JIT::emitSlow_op_jstricteq):
        (JSC::JIT::emitSlow_op_jnstricteq):
        (JSC::JIT::emit_op_check_tdz):
        (JSC::JIT::emitSlow_op_jeq):
        (JSC::JIT::emitSlow_op_jneq):
        (JSC::JIT::emit_op_profile_type):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_jmp):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_jeq):
        (JSC::JIT::emitSlow_op_jeq):
        (JSC::JIT::emit_op_jneq):
        (JSC::JIT::emitSlow_op_jneq):
        (JSC::JIT::compileOpStrictEqJump):
        (JSC::JIT::emitSlow_op_jstricteq):
        (JSC::JIT::emitSlow_op_jnstricteq):
        (JSC::JIT::emit_op_check_tdz):
        (JSC::JIT::emit_op_profile_type):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setupGetByIdPrototypeCache):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        * runtime/GetPutInfo.h:

2019-01-17  Truitt Savell  <tsavell@apple.com>

        Unreviewed, rolling out r240124.

        This commit broke an internal build.

        Reverted changeset:

        "SDK_VARIANT build destinations should be separate from non-
        SDK_VARIANT builds"
        https://bugs.webkit.org/show_bug.cgi?id=189553
        https://trac.webkit.org/changeset/240124

2019-01-17  Jer Noble  <jer.noble@apple.com>

        SDK_VARIANT build destinations should be separate from non-SDK_VARIANT builds
        https://bugs.webkit.org/show_bug.cgi?id=189553

        Reviewed by Tim Horton.

        * Configurations/Base.xcconfig:
        * Configurations/SDKVariant.xcconfig: Added.

2019-01-17  Saam barati  <sbarati@apple.com>

        StringObjectUse should not be a structure check for the original string object structure
        https://bugs.webkit.org/show_bug.cgi?id=193483
        <rdar://problem/47280522>

        Reviewed by Yusuke Suzuki.

        Prior to this patch, the use kind for StringObjectUse implied that we
        do a StructureCheck on the input operand for the *original* StringObject
        structure. This is generally not how we use UseKinds, so it's no surprise
        that this is buggy. A UseKind should map to a set of SpeculatedTypes, not an
        actual set of structures. This patch changes the meaning of StringObjectUse
        to mean an object where jsDynamicCast<StringObject*> would succeed.
        
        This patch also fixes a bug that was caused by the old and weird usage of the
        UseKind to mean StructureCheck. Consider a program like this:
        ```
        S1 = Original StringObject structure
        S2 = Original StringObject structure with the field "f" added
        
        a: GetLocal()
        b: CheckStructure(@a, {S2})
        c: ToString(StringObject:@a)
        ```
        
        According to AI, in the above program, we would exit at @c, since
        StringObject:@a implies a structure check of {S1}, and the intersection
        of {S1} and {S2} is {}. So, we'd convert the program to be:
        ```
        a: GetLocal()
        b: CheckStructure(@a, {S2})
        c: Check(StringObject:@a)
        d: Unreachable
        ```
        
        However, AI would set the proof status of the StringObject:@a edge
        to be proven, since the SpeculatedType for @a is SpecStringObject.
        This was incorrect of AI to do because the SpeculatedType itself
        didn't capture the full power of StringObjectUse. However, having
        a UseKind mean CheckStructure is weird precisely because what AI was
        doing is a natural fit to how we typically we think about UseKinds.
        
        So the above program would then incorrectly be converted to this, and
        we'd crash when reaching the Unreachable node:
        ```
        a: GetLocal()
        b: CheckStructure(@a, {S2})
        d: Unreachable
        ```
        
        This patch makes it so that StringObjectUse just means that the object that
        filters through a StringObjectUse check must !!jsDynamicCast<StringObject*>.
        This is now in line with all other UseKinds. It also lets us simplify a bunch
        of other code that had weird checks for the StringObjectUse UseKind.
        
        This patch also makes it so that anywhere where we used to rely on
        StringObjectUse implying a structure check we actually emit an explicit
        CheckStructure node.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGEdgeUsesStructure.h: Removed.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
        (JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse):
        (JSC::DFG::FixupPhase::fixupToPrimitive):
        (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        (JSC::DFG::FixupPhase::isStringObjectUse): Deleted.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::canOptimizeStringObjectAccess):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOrStringValueOf):
        (JSC::DFG::SpeculativeJIT::speculateStringObject):
        (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): Deleted.
        * dfg/DFGUseKind.h:
        (JSC::DFG::alreadyChecked):
        (JSC::DFG::usesStructure): Deleted.
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrStringObject):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForCell):
        (JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForStructureID): Deleted.
        * runtime/JSType.cpp:
        (WTF::printInternal):
        * runtime/JSType.h:
        * runtime/StringObject.h:
        (JSC::StringObject::createStructure):
        * runtime/StringPrototype.h:

2019-01-17  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Add generateHeapSnapshotForGCDebugging function to dump GCDebugging data
        https://bugs.webkit.org/show_bug.cgi?id=193526

        Reviewed by Michael Saboff.

        This patch adds generateHeapSnapshotForGCDebugging to JSC shell to dump heap snapshot JSON string with GCDebugging option.
        GCDebuggingSnapshot mode is slightly different from InspectorSnapshot in terms of both the output data and the behavior.
        It always takes full snapshot, and it reports internal data too. This is useful to view the live heap objects after running
        the code. Also, generateHeapSnapshotForGCDebugging returns String instead of parsing it to JSObject internally by calling
        JSON.parse. If we convert the String to bunch of objects by using JSON.parse, it is difficult to call generateHeapSnapshotForGCDebugging
        multiple times for debugging. Currently, it only generates a large string, which is easily distinguishable in the heap inspector tool.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionGenerateHeapSnapshotForGCDebugging):

2019-01-17  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] ToThis omission in DFGByteCodeParser is wrong
        https://bugs.webkit.org/show_bug.cgi?id=193513
        <rdar://problem/45842236>

        Reviewed by Saam Barati.

        DFGByteCodeParser omitted ToThis node when we have `ToThis(ToThis(value))`. This semantics is wrong if ToThis has different semantics
        in the sloppy mode and the strict mode. If we convert `ToThisInSloppyMode(ToThisInStrictMode(boolean))` to `ToThisInStrictMode(boolean)`,
        we get boolean instead of BooleanObject.

        This optimization is introduced more than 7 years ago, and from that, we have several optimizations that can remove such ToThis nodes
        in BytecodeParser, AI, and Fixup. Furthermore, this optimization is simply wrong since `toThis()` function of JSCell can be defined
        as they want. Before ensuring all the toThis function is safe, we should not fold `ToThis(ToThis(value))` => `ToThis(value)`.
        This patch just removes the problematic optimization. The performance numbers look neutral.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2019-01-16  Mark Lam  <mark.lam@apple.com>

        Refactor new bytecode structs so that the fields are prefixed with "m_".
        https://bugs.webkit.org/show_bug.cgi?id=193467

        Reviewed by Saam Barati and Tadeu Zagallo.

        This makes it easier to do a manual audit of type correctness of the LLInt
        instructions used to access these fields.  Without this change, it would be
        difficult (and error prone) to distinguish the difference between field names and
        macro variables.  This audit will be done after this patch lands.

        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
        (JSC::CodeBlock::getArrayProfile):
        (JSC::CodeBlock::notifyLexicalBindingShadowing):
        (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForPC):
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        * bytecode/CodeBlockInlines.h:
        (JSC::CodeBlock::forEachValueProfile):
        (JSC::CodeBlock::forEachArrayProfile):
        (JSC::CodeBlock::forEachArrayAllocationProfile):
        (JSC::CodeBlock::forEachObjectAllocationProfile):
        (JSC::CodeBlock::forEachLLIntCallLinkInfo):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::jumpTargetForInstruction):
        (JSC::extractStoredJumpTargetsForInstruction):
        (JSC::updateStoredJumpTargetsForInstruction):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::dumpLineColumnEntry):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::fuseCompareAndJump):
        (JSC::BytecodeGenerator::fuseTestAndJmp):
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::endSwitch):
        (JSC::StructureForInContext::finalize):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::parseGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::handlePutByVal):
        (JSC::DFG::ByteCodeParser::handlePutAccessorById):
        (JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
        (JSC::DFG::ByteCodeParser::handleNewFunc):
        (JSC::DFG::ByteCodeParser::handleNewFuncExp):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareCatchOSREntry):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * generator/Argument.rb:
        * generator/Metadata.rb:
        * generator/Opcode.rb:
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_unsigned):
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_inc):
        (JSC::JIT::emit_op_dec):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emitBitBinaryOpFastPath):
        (JSC::JIT::emit_op_bitnot):
        (JSC::JIT::emitRightShiftFastPath):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emit_op_sub):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_unsigned):
        (JSC::JIT::emit_op_inc):
        (JSC::JIT::emit_op_dec):
        (JSC::JIT::emitBinaryDoubleOp):
        (JSC::JIT::emit_op_mod):
        * jit/JITCall.cpp:
        (JSC::JIT::emitPutCallResult):
        (JSC::JIT::compileSetupFrame):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileTailCall):
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitPutCallResult):
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::compileSetupFrame):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITInlines.h:
        (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
        (JSC::JIT::emitValueProfilingSite):
        (JSC::JIT::copiedGetPutInfo):
        (JSC::JIT::copiedArithProfile):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_mov):
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_jmp):
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emit_op_is_empty):
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_is_undefined_or_null):
        (JSC::JIT::emit_op_is_boolean):
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_is_cell_with_type):
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::emit_op_set_function_name):
        (JSC::JIT::emit_op_not):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        (JSC::JIT::emit_op_jeq):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_neq):
        (JSC::JIT::emit_op_jneq):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::compileOpStrictEqJump):
        (JSC::JIT::emitSlow_op_jstricteq):
        (JSC::JIT::emitSlow_op_jnstricteq):
        (JSC::JIT::emit_op_to_number):
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emit_op_to_object):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_get_parent_scope):
        (JSC::JIT::emit_op_switch_imm):
        (JSC::JIT::emit_op_switch_char):
        (JSC::JIT::emit_op_switch_string):
        (JSC::JIT::emit_op_debug):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emit_op_get_scope):
        (JSC::JIT::emit_op_to_this):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_check_tdz):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::emitSlow_op_jeq):
        (JSC::JIT::emitSlow_op_jneq):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_new_regexp):
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_array):
        (JSC::JIT::emit_op_new_array_with_size):
        (JSC::JIT::emit_op_has_structure_property):
        (JSC::JIT::emit_op_has_indexed_property):
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        (JSC::JIT::emit_op_profile_control_flow):
        (JSC::JIT::emit_op_argument_count):
        (JSC::JIT::emit_op_get_rest_length):
        (JSC::JIT::emit_op_get_argument):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_mov):
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_jmp):
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_is_empty):
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_is_undefined_or_null):
        (JSC::JIT::emit_op_is_boolean):
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_is_cell_with_type):
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::emit_op_set_function_name):
        (JSC::JIT::emit_op_not):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emit_op_jeq):
        (JSC::JIT::emitSlow_op_jeq):
        (JSC::JIT::emit_op_neq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::emit_op_jneq):
        (JSC::JIT::emitSlow_op_jneq):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::compileOpStrictEqJump):
        (JSC::JIT::emitSlow_op_jstricteq):
        (JSC::JIT::emitSlow_op_jnstricteq):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_to_number):
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emit_op_to_object):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_get_parent_scope):
        (JSC::JIT::emit_op_switch_imm):
        (JSC::JIT::emit_op_switch_char):
        (JSC::JIT::emit_op_switch_string):
        (JSC::JIT::emit_op_debug):
        (JSC::JIT::emit_op_get_scope):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_to_this):
        (JSC::JIT::emit_op_check_tdz):
        (JSC::JIT::emit_op_has_structure_property):
        (JSC::JIT::emit_op_has_indexed_property):
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/JITOperations.cpp:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_by_val):
        (JSC::JIT::emit_op_put_setter_by_val):
        (JSC::JIT::emit_op_del_by_id):
        (JSC::JIT::emit_op_del_by_val):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id_direct):
        (JSC::JIT::emitSlow_op_get_by_id_direct):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emit_op_in_by_id):
        (JSC::JIT::emitSlow_op_in_by_id):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_by_val):
        (JSC::JIT::emit_op_put_setter_by_val):
        (JSC::JIT::emit_op_del_by_id):
        (JSC::JIT::emit_op_del_by_val):
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id_direct):
        (JSC::JIT::emitSlow_op_get_by_id_direct):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emit_op_in_by_id):
        (JSC::JIT::emitSlow_op_in_by_id):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::getByVal):
        (JSC::LLInt::genericCall):
        (JSC::LLInt::varargsSetup):
        (JSC::LLInt::commonCallEval):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        (JSC::updateArithProfileForUnaryArithOp):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):

2019-01-15  Mark Lam  <mark.lam@apple.com>

        JSFunction::canUseAllocationProfile() should account for builtin functions with no own prototypes.
        https://bugs.webkit.org/show_bug.cgi?id=193423
        <rdar://problem/46209355>

        Reviewed by Saam Barati.

        JSFunction::canUseAllocationProfile() should return false for most builtins
        because the majority of them have no prototype property.  The only exception to
        this is the few builtin functions that are explicitly used as constructors.

        For these builtin constructors, JSFunction::canUseAllocationProfile() should also
        return false if the prototype property is a getter or custom getter because
        getting the prototype would then be effectful.

        * dfg/DFGOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::canUseAllocationProfile):
        * runtime/PropertySlot.h:

2019-01-15  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Use KnownStringUse for GetByVal(Array::String) since AI would offer wider type information and offer non-string type after removing Check(String)
        https://bugs.webkit.org/show_bug.cgi?id=193438
        <rdar://problem/45581249>

        Reviewed by Saam Barati and Keith Miller.

        GetByVal(Array::String) emits Check(String) before that. But AI can broaden type constraint in the second run.
        After the first run removes Check(String), it would happen that AI starts saying the type of 1st child is not String.
        To claim that it *is* a String type, we should use KnownStringUse here.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): StringCharAt and GetByVal(Array::String) share the underlying compiler code. We should
        change StringUse => KnownStringUse for StringCharAt too. And StringCharAt and StringCharCodeAt potentially have the same
        problem. This patch fixes it too.
        * dfg/DFGSSALoweringPhase.cpp:
        (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):

2019-01-15  Saam Barati  <sbarati@apple.com>

        Try ripping out inferred types because it might be a performance improvement
        https://bugs.webkit.org/show_bug.cgi?id=190906

        Reviewed by Yusuke Suzuki.

        This patch removes inferred types from JSC. Initial evidence shows that
        this might be around a ~1% speedup on Speedometer2 and JetStream2.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/AccessCase.cpp:
        (JSC::AccessCase::generateImpl):
        * bytecode/Fits.h:
        * bytecode/PutByIdFlags.cpp:
        (WTF::printInternal):
        * bytecode/PutByIdFlags.h:
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeForStubInfo):
        (JSC::PutByIdStatus::computeFor):
        * bytecode/PutByIdVariant.cpp:
        (JSC::PutByIdVariant::operator=):
        (JSC::PutByIdVariant::replace):
        (JSC::PutByIdVariant::transition):
        (JSC::PutByIdVariant::setter):
        (JSC::PutByIdVariant::attemptToMerge):
        (JSC::PutByIdVariant::dumpInContext const):
        * bytecode/PutByIdVariant.h:
        (JSC::PutByIdVariant::requiredType const): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::isType const): Deleted.
        * dfg/DFGAbstractValue.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (JSC::DFG::ByteCodeParser::handlePutByOffset):
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::store):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        * dfg/DFGDesiredInferredType.h: Removed.
        * dfg/DFGDesiredWatchpoints.cpp:
        (JSC::DFG::DesiredWatchpoints::reallyAdd):
        (JSC::DFG::DesiredWatchpoints::areStillValid const):
        (JSC::DFG::DesiredWatchpoints::dumpInContext const):
        (JSC::DFG::InferredTypeAdaptor::add): Deleted.
        * dfg/DFGDesiredWatchpoints.h:
        (JSC::DFG::DesiredWatchpoints::isWatched):
        (JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated): Deleted.
        (JSC::DFG::InferredTypeAdaptor::dumpInContext): Deleted.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::inferredValueForProperty):
        (JSC::DFG::Graph::inferredTypeFor): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::registerInferredType): Deleted.
        (JSC::DFG::Graph::inferredTypeForProperty): Deleted.
        * dfg/DFGInferredTypeCheck.cpp: Removed.
        * dfg/DFGInferredTypeCheck.h: Removed.
        * dfg/DFGNode.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
        (JSC::FTL::DFG::LowerDFGToB3::checkInferredType): Deleted.
        * generator/DSL.rb:
        * heap/Heap.cpp:
        (JSC::Heap::finalizeUnconditionalFinalizers):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::branchIfNotType): Deleted.
        * jit/AssemblyHelpers.h:
        * jit/Repatch.cpp:
        (JSC::tryCachePutByID):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/InferredStructure.cpp:
        (JSC::InferredStructure::InferredStructure): Deleted.
        * runtime/InferredStructure.h:
        (): Deleted.
        * runtime/InferredStructureWatchpoint.cpp:
        (JSC::InferredStructureWatchpoint::fireInternal): Deleted.
        * runtime/InferredType.cpp: Removed.
        * runtime/InferredType.h: Removed.
        * runtime/InferredTypeInlines.h: Removed.
        * runtime/InferredTypeTable.cpp: Removed.
        * runtime/InferredTypeTable.h: Removed.
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putDirectInternal):
        * runtime/Structure.cpp:
        (JSC::Structure::materializePropertyTable):
        (JSC::Structure::addNewPropertyTransition):
        (JSC::Structure::removePropertyTransition):
        (JSC::Structure::willStoreValueSlow):
        (JSC::Structure::visitChildren):
        * runtime/Structure.h:
        (JSC::PropertyMapEntry::PropertyMapEntry):
        * runtime/StructureInlines.h:
        (JSC::Structure::get):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2019-01-15  Tomas Popela  <tpopela@redhat.com>

        Unreviewed: Fix the -Wformat compiler warnings

        * jsc.cpp:
        (jscmain):

2019-01-15  Caio Lima  <ticaiolima@gmail.com>

        DFGByteCodeParser rules for bitwise operations should consider type of their operands
        https://bugs.webkit.org/show_bug.cgi?id=192966

        Reviewed by Yusuke Suzuki.

        This patch is changing the logic how we lower bitwise operations, to
        consider only the type of input nodes and fix them during FixupPhase,
        if necessary. We are also changing the prediction propagation rules
        for ValueBitOp to use `getHeapPrediction()`. 

        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasInt32Result):
        (JSC::DFG::Node::hasNumberOrAnyIntResult):
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGPredictionPropagationPhase.cpp:

2019-01-15  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Generate the DOMDebugger domain for Augmenting Agents (ObjC protocol)
        https://bugs.webkit.org/show_bug.cgi?id=193409
        <rdar://problem/44349411>

        Reviewed by Devin Rousso.

        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator):
        Generate DOMDebugger domain ObjC interfaces.

2019-01-15  Devin Rousso  <drousso@apple.com>

        Web Inspector: Audit: create new IDL type for exposing special functionality in test context
        https://bugs.webkit.org/show_bug.cgi?id=193149
        <rdar://problem/46801218>

        Reviewed by Joseph Pecoraro.

        Create a new `AuditAgent` (and various subclasses for different inspection targets)

        * inspector/protocol/Audit.json: Added.
        Add a `run` command that is a simpler version of `Runtime.evaluate`, except that it expects
        a function string instead of an arbitrary JavaScript expression.
        Add `setup` and `teardown` commands that create a JavaScript object that will be passed in
        to the test as an argument. Keep this object alive so that tests can add to the object and
        have later tests use what was added.

        * inspector/agents/InspectorAuditAgent.h: Added.
        * inspector/agents/InspectorAuditAgent.cpp: Added.
        (Inspector::InspectorAuditAgent::InspectorAuditAgent):
        (Inspector::InspectorAuditAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorAuditAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorAuditAgent::setup):
        (Inspector::InspectorAuditAgent::run):
        (Inspector::InspectorAuditAgent::teardown):
        (Inspector::InspectorAuditAgent::hasActiveAudit):
        (Inspector::InspectorAuditAgent::populateAuditObject):

        * inspector/agents/JSGlobalObjectAuditAgent.h: Added.
        * inspector/agents/JSGlobalObjectAuditAgent.cpp: Added.
        (Inspector::JSGlobalObjectAuditAgent::JSGlobalObjectAuditAgent):
        (Inspector::JSGlobalObjectAuditAgent::injectedScriptForEval):

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::jsAgentContext): Added.
        (Inspector::JSGlobalObjectInspectorController::createLazyAgents): Added.

        * inspector/InjectedScript.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::execute): Added.
        (Inspector::InjectedScript::arrayFromVector): Added.
        Create a version of `evaluate` that accepts a list of values to be passed in as arguments
        to the function that was created by the `eval` of the given `functionString`.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.execute): Added.
        (InjectedScript.prototype.evaluate):
        (InjectedScript.prototype.evaluateOnCallFrame):
        (InjectedScript.prototype._evaluateAndWrap):
        (InjectedScript.prototype._wrapAndSaveCall): Added.
        (InjectedScript.prototype._wrapCall): Added.
        (InjectedScript.prototype._evaluateOn):
        Refactor the `eval` and `saveResult` logic to allow for more flexibility for other callers.

        * CMakeLists.txt:
        * DerivedSources-input.xcfilelist:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * UnifiedSources-input.xcfilelist:

2019-01-14  Michael Saboff  <msaboff@apple.com>

        Add option to JSC to dump memory footprint on script completion
        https://bugs.webkit.org/show_bug.cgi?id=193422

        Reviewed by Mark Lam.

        Added the --footprint option to dump peak and current memory usage.  This uses the same
        OS calls added in r2362362.

        * jsc.cpp:
        (printUsageStatement):
        (CommandLine::parseArguments):
        (jscmain):

2019-01-14  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] AI should check the given constant's array type when folding GetByVal into constant
        https://bugs.webkit.org/show_bug.cgi?id=193413
        <rdar://problem/46092389>

        Reviewed by Keith Miller.

        If GetByVal's DFG::ArrayMode's type is Array::Double, we expect that the result of GetByVal is Double, since we already performed CheckStructure or CheckArray
        to ensure this array type. But this assumption on the given value becomes wrong in AI, since CheckStructure may not perform filtering. And the proven AbstractValue
        in GetByVal would not be expected one.

        We have the graph before performing constant folding.

        53:<!0:->     GetLocal(Check:Untyped:@77, JS|MustGen|UseAsOther, Array, arg2(C<Array>/FlushedCell), R:Stack(7), bc#37, ExitValid)  predicting Array
        54:< 1:->     JSConstant(JS|PureNum|UseAsOther|UseAsInt|ReallyWantsInt, BoolInt32, Int32: 0, bc#37, ExitValid)
        93:<!0:->     CheckStructure(Cell:@53, MustGen, [%C7:Array], R:JSCell_structureID, Exits, bc#37, ExitValid)
        94:< 1:->     GetButterfly(Check:Cell:@53, Storage|PureInt, R:JSObject_butterfly, Exits, bc#37, ExitValid)
        55:<!0:->     GetByVal(Check:KnownCell:@53, Check:Int32:@54, Check:Untyped:@94, Double|MustGen|VarArgs|PureInt, AnyIntAsDouble|NonIntAsdouble, Double+OriginalCopyOnWriteArray+SaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedDoubleProperties, Exits, bc#37, ExitValid)  predicting StringIdent|NonIntAsdouble

        And 53 is converted to JSConstant in the constant folding. It leads to constant folding attempt in GetByVal.

        53:< 1:->     JSConstant(JS|UseAsOther, Array, Weak:Object: 0x117fb4370 with butterfly 0x8000e4050 (Structure %BV:Array), StructureID: 104, bc#37, ExitValid)
        54:< 1:->     JSConstant(JS|PureNum|UseAsOther|UseAsInt|ReallyWantsInt, BoolInt32, Int32: 0, bc#37, ExitValid)
        93:<!0:->     CheckStructure(Cell:@53, MustGen, [%C7:Array], R:JSCell_structureID, Exits, bc#37, ExitValid)
        94:< 1:->     GetButterfly(Check:Cell:@53, Storage|PureInt, R:JSObject_butterfly, Exits, bc#37, ExitValid)
        55:<!0:->     GetByVal(Check:KnownCell:@53, Check:Int32:@54, Check:Untyped:@94, Double|MustGen|VarArgs|PureInt, AnyIntAsDouble|NonIntAsdouble, Double+OriginalCopyOnWriteArray+SaneChain+AsIs+Read, R:Butterfly_publicLength,IndexedDoubleProperties, Exits, bc#37, ExitValid)  predicting StringIdent|NonIntAsdouble

        GetByVal gets constant Array from @53, and attempt to perform constant folding by leverating CoW state: if the given array's butterfly is CoW and we performed CoW array check for this GetByVal, the array would not be changed as long as the check works.
        However, CheckStructure for @53 does not filter anything at AI. So, if @53 is CopyOnWrite | Contiguous array (not CopyOnWrite | Double array!), GetByVal will get a JSValue. But it does not meet the requirement of GetByVal since it has Double Array mode, and says it returns Double.
        Here, CheckStructure is valid because structure of the constant object would be changed. What we should do is additional CoW & ArrayShape check in GetByVal when folding since this node leverages CoW's interesting feature,
        "If CoW array check (CheckStructure etc.) is emitted by GetByVal's DFG::ArrayMode, the content is not changed from the creation!".

        This patch adds ArrayShape check in addition to CoW status check in GetByVal.

        Unfortunately, this crash is very flaky. In the above case, if @53 stays GetLocal after the constant folding phase, this issue does not occur. We can see this crash in r238109, but it is really hard to reproduce it in the current ToT.
        I verified this fix works in r238109 with the attached test.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::fixTypeForRepresentation):

2019-01-14  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Literal parsing is crashing when used inside a Object Literal
        https://bugs.webkit.org/show_bug.cgi?id=193404

        Reviewed by Yusuke Suzuki.

        Former implementation was relying into token.m_data.radix after the
        call of `next()` into Parser.cpp. This is not safe because next
        clobbers token.m_data.radix in some cases (e.g is CLOSEBRACE).
        Now we get radix value before calling `next()` into parser and store
        in a local variable.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parsePrimaryExpression):

2019-01-14  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Do not use asArrayModes() with Structures because it discards TypedArray information
        https://bugs.webkit.org/show_bug.cgi?id=193372

        Reviewed by Saam Barati.

        When RegisteredStructureSet is filtered with AbstractValue, we use structure, SpeculationType, and ArrayModes.
        However, we use asArrayModes() function with IndexingMode to compute the ArrayModes in AbstractValue. This is
        wrong since this discards TypedArray ArrayModes. As a result, if RegisteredStructureSet with TypedArrays is
        filtered with ArrayModes of AbstractValue populated from TypedArrays, we filter all the structures out since
        AbstractValue's ArrayModes become NonArray, which is wrong with the TypedArrays' ArrayModes. This leads to
        incorrect FTL code generation with MultiGetByOffset etc. nodes because,

        1. AI think that this MultiGetByOffset never succeeds since all the values of RegisteredStructureSet are filtered out by the AbstractValue.
        2. AI says the state of MultiGetByOffset is invalid since AI think it never succeeds.
        3. So subsequent code becomes FTL crash code since AI think the execution should do OSR exit.
        4. Then, FTL emits the code for MultiGetByOffset, and emits crash after that.
        5. But in reality, the incoming value can match to the one of the RegisteredStructureSet value since (1)'s structures are incorrectly filtered by the incorrect ArrayModes.
        6. Then, the execution goes on, and falls into the FTL crash.

        This patch fixes the incorrect ArrayModes calculation by the following changes

        1. Rename asArrayModes to asArrayModesIgnoringTypedArrays.
        2. Fix incorrect asArrayModesIgnoringTypedArrays use in our code. Use arrayModesFromStructure instead.
        3. Fix OSR exit code which stores incorrect ArrayModes to the profiles.

        * bytecode/ArrayProfile.cpp:
        (JSC::dumpArrayModes):
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * bytecode/ArrayProfile.h:
        (JSC::asArrayModesIgnoringTypedArrays):
        (JSC::arrayModesFromStructure):
        (JSC::arrayModesIncludeIgnoringTypedArrays):
        (JSC::shouldUseSlowPutArrayStorage):
        (JSC::shouldUseFastArrayStorage):
        (JSC::shouldUseContiguous):
        (JSC::shouldUseDouble):
        (JSC::shouldUseInt32):
        (JSC::asArrayModes): Deleted.
        (JSC::arrayModeFromStructure): Deleted.
        (JSC::arrayModesInclude): Deleted.
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::observeTransitions):
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::mergeOSREntryValue):
        (JSC::DFG::AbstractValue::contains const):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::observeTransition):
        (JSC::DFG::AbstractValue::validate const):
        (JSC::DFG::AbstractValue::observeIndexingTypeTransition):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::alreadyChecked const):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering):
        (JSC::DFG::ArrayMode::arrayModesThatPassFiltering const):
        (JSC::DFG::ArrayMode::arrayModesWithIndexingShape const):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        (JSC::DFG::OSRExit::compileExit):
        * dfg/DFGRegisteredStructureSet.cpp:
        (JSC::DFG::RegisteredStructureSet::filterArrayModes):
        (JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * jit/JITInlines.h:
        (JSC::JIT::chooseArrayMode):
        (JSC::arrayProfileSaw): Deleted.
        * runtime/JSType.h:
        (JSC::isTypedArrayType):

2019-01-14  Mark Lam  <mark.lam@apple.com>

        Re-enable ability to build --cloop builds.
        https://bugs.webkit.org/show_bug.cgi?id=192955
        <rdar://problem/46882363>

        Reviewed by Saam barati and Keith Miller.

        * Configurations/FeatureDefines.xcconfig:

2019-01-14  Mark Lam  <mark.lam@apple.com>

        Fix all CLoop JSC test failures (including some LLInt bugs due to recent bytecode format change).
        https://bugs.webkit.org/show_bug.cgi?id=193402
        <rdar://problem/46012309>

        Reviewed by Keith Miller.

        The CLoop builds via build-jsc were previously completely disabled after our
        change to enable ASM LLInt build without the JIT.  As a result, JSC tests have
        regressed on CLoop builds.  The CLoop builds and tests will be re-enabled when
        the fix for https://bugs.webkit.org/show_bug.cgi?id=192955 lands.  This patch
        fixes all the regressions (and some old bugs) so that the CLoop test bots won't
        be red when CLoop build gets re-enabled.

        In this patch, we do the following:

        1. Change CLoopStack::grow() to set the new CLoop stack top at the maximum
           allocated capacity (after discounting the reserved zone) as opposed to setting
           it only at the level that the client requested.

           This fixes a small performance bug that I happened to noticed when I was
           debugging a stack issue.  It does not affect correctness.

        2. In LowLevelInterpreter32_64.asm:

           1. Fix loadConstantOrVariableTag() to use subi for computing the constant
              index because the VirtualRegister offset and FirstConstantRegisterIndex
              values it is operating on are both signed ints.  This is just to be
              pedantic.  The previous use of subu will still produce a correct value.

           2. Fix llintOpWithReturn() to use getu (instead of get) for reading
              OpIsCellWithType::type because it is of type JSType, which is a uint8_t.

           3. Fix llintOpWithMetadata() to use loadis for loading
              OpGetById::Metadata::modeMetadata.protoLoadMode.cachedOffset[t5] because it
              is of type PropertyOffset, which is a signed int.

           4. Fix commonCallOp() to use getu for loading fields argv and argc because they
              are  of type unsigned for OpCall, OpConstruct, and OpTailCall, which are the
              clients of commonCallOp.

           5. Fix llintOpWithMetadata() and getClosureVar() to use loadp for loading
              OpGetFromScope::Metadata::operand because it is of type uintptr_t.

        3. In LowLevelInterpreter64.asm:

           1. Fix llintOpWithReturn() to use getu for reading OpIsCellWithType::type
              because it is of type JSType, which is a uint8_t.

           2. Fix llintOpWithMetadata() to use loadi for loading
              OpGetById::Metadata::modeMetadata.protoLoadMode.structure[t2] because it is
              of type StructureID, which is a uint32_t.

              Fix llintOpWithMetadata() to use loadis for loading
              OpGetById::Metadata::modeMetadata.protoLoadMode.cachedOffset[t2] because it
              is of type PropertyOffset, which is a signed int.

           3. commonOp() should reload the metadataTable for op_catch because unlike
              for the ASM LLInt, the exception unwinding code is not able to restore
              "callee saved registers" for the CLoop interpreter because the CLoop uses
              pseudo-registers (see the CLoopRegister class).

              This was the source of many exotic Cloop failures after the bytecode format
              change (which introduced the metadataTable callee saved register).  Hence,
              we fix it by reloading metadataTable's value on re-entry via op_catch for
              exception handling.  We already take care of restoring it in op_ret.

           4. Fix llintOpWithMetadata() and getClosureVar() to use loadp for loading
              OpGetFromScope::Metadata::operand because it is of type uintptr_t.

        4. In LowLevelInterpreter.asm:

           Fix metadata() to use loadi for loading metadataTable offsets because they are
           of type unsigned.  This was also a source of many exotic CLoop test failures.

        5. Change CLoopRegister into a class with a uintptr_t as its storage element.
           Previously, we were using a union to convert between various value types that
           we would store in this pseudo-register.  This method of type conversion is
           undefined behavior according to the C++ spec.  As a result, the C++ compiler
           may choose to elide some CLoop statements, thereby resulting in some exotic
           bugs.

           We fix this by now always using accessor methods and assignment operators to
           ensure that we use bitwise_cast to do the type conversions.  Since bitwise_cast
           uses a memcpy, this ensures that there's no undefined behavior, and that CLoop
           statements won't get elided willy-nilly by the compiler.

           Ditto for the CloopDobleRegisters.

           Similarly, use bitwise_cast for ints2Double() and double2Ints() utility
           functions.

           Also use bitwise_cast (instead of reinterpret_cast) for the CLoop CAST macro.

        6. Fix cloop.rb to use the new CLoopRegister and CLoopDoubleRegister classes.

           Add a clLValue accessor for offlineasm operand types to distinguish
           LValue use of the operands from RValue uses.

           Replace the use of clearHighWord() with simply casting to uint32_t.  This is
           more efficient for the C++ compiler (and help speed up debug build runs).

           Also fix 32-bit arithmetic operations to only set the lower 32-bit value of
           the pseudo registers.  This fixes some CLoop JSC test failures.

        This patch has been manually tested with the JSC tests on the following builds:
        64bit X86 ASM LLLint (without JIT), 64bit and 32bit X86 CLoop, and ARMv7 Cloop.

        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::grow):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoopRegister::i const):
        (JSC::CLoopRegister::u const):
        (JSC::CLoopRegister::i32 const):
        (JSC::CLoopRegister::u32 const):
        (JSC::CLoopRegister::i8 const):
        (JSC::CLoopRegister::u8 const):
        (JSC::CLoopRegister::ip const):
        (JSC::CLoopRegister::i8p const):
        (JSC::CLoopRegister::vp const):
        (JSC::CLoopRegister::cvp const):
        (JSC::CLoopRegister::callFrame const):
        (JSC::CLoopRegister::execState const):
        (JSC::CLoopRegister::instruction const):
        (JSC::CLoopRegister::vm const):
        (JSC::CLoopRegister::cell const):
        (JSC::CLoopRegister::protoCallFrame const):
        (JSC::CLoopRegister::nativeFunc const):
        (JSC::CLoopRegister::i64 const):
        (JSC::CLoopRegister::u64 const):
        (JSC::CLoopRegister::encodedJSValue const):
        (JSC::CLoopRegister::opcode const):
        (JSC::CLoopRegister::operator ExecState*):
        (JSC::CLoopRegister::operator const Instruction*):
        (JSC::CLoopRegister::operator JSCell*):
        (JSC::CLoopRegister::operator ProtoCallFrame*):
        (JSC::CLoopRegister::operator Register*):
        (JSC::CLoopRegister::operator VM*):
        (JSC::CLoopRegister::operator=):
        (JSC::CLoopRegister::bitsAsDouble const):
        (JSC::CLoopRegister::bitsAsInt64 const):
        (JSC::CLoopDoubleRegister::operator T const):
        (JSC::CLoopDoubleRegister::d const):
        (JSC::CLoopDoubleRegister::bitsAsInt64 const):
        (JSC::CLoopDoubleRegister::operator=):
        (JSC::LLInt::ints2Double):
        (JSC::LLInt::double2Ints):
        (JSC::LLInt::decodeResult):
        (JSC::CLoop::execute):
        (JSC::LLInt::Ints2Double): Deleted.
        (JSC::LLInt::Double2Ints): Deleted.
        (JSC::CLoopRegister::CLoopRegister): Deleted.
        (JSC::CLoopRegister::clearHighWord): Deleted.
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/cloop.rb:

2019-01-14  Keith Miller  <keith_miller@apple.com>

        JSC should have a module loader API
        https://bugs.webkit.org/show_bug.cgi?id=191121

        Reviewed by Michael Saboff.

        This patch adds a new delegate to JSContext that is called to fetch
        any resolved module. The resolution of a module identifier is computed
        as if it were a URL on the web with the caveat that it must be a file URL.

        A new class JSScript has also been added that is similar to JSScriptRef.
        Right now all JSScripts are copied into memory. In the future we should
        mmap the provided file into memory so the OS can evict it to disk under
        pressure. Additionally, the API does not make use of the code signing path
        nor the bytecode caching path, which we will add in subsequent patches.

        Lastly, a couple of new convenience methods have been added. C API
        conversion, can now toRef a JSValue with just a vm rather than
        requiring an ExecState. Secondly, there is now a call wrapper that
        does not require CallData and CallType since many places don't
        care about this.

        * API/APICast.h:
        (toRef):
        * API/JSAPIGlobalObject.cpp: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
        * API/JSAPIGlobalObject.h: Added.
        (JSC::JSAPIGlobalObject::create):
        (JSC::JSAPIGlobalObject::createStructure):
        (JSC::JSAPIGlobalObject::JSAPIGlobalObject):
        * API/JSAPIGlobalObject.mm: Added.
        (JSC::JSAPIGlobalObject::moduleLoaderResolve):
        (JSC::JSAPIGlobalObject::moduleLoaderImportModule):
        (JSC::JSAPIGlobalObject::moduleLoaderFetch):
        (JSC::JSAPIGlobalObject::moduleLoaderCreateImportMetaProperties):
        * API/JSAPIValueWrapper.h:
        (JSC::jsAPIValueWrapper): Deleted.
        * API/JSContext.h:
        * API/JSContext.mm:
        (-[JSContext moduleLoaderDelegate]):
        (-[JSContext setModuleLoaderDelegate:]):
        * API/JSContextInternal.h:
        * API/JSContextPrivate.h:
        * API/JSContextRef.cpp:
        (JSGlobalContextCreateInGroup):
        * API/JSScript.h: Added.
        * API/JSScript.mm: Added.
        (+[JSScript scriptWithSource:inVirtualMachine:]):
        (fillBufferWithContentsOfFile):
        (+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]):
        (getJSScriptSourceCode):
        * API/JSScriptInternal.h: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
        * API/JSValueInternal.h:
        * API/JSVirtualMachineInternal.h:
        * API/tests/testapi.mm:
        (+[JSContextFetchDelegate contextWithBlockForFetch:]):
        (-[JSContextFetchDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
        (checkModuleCodeRan):
        (checkModuleWasRejected):
        (testFetch):
        (testFetchWithTwoCycle):
        (testFetchWithThreeCycle):
        (testLoaderResolvesAbsoluteScriptURL):
        (testLoaderRejectsNilScriptURL):
        (testLoaderRejectsFailedFetch):
        (testImportModuleTwice):
        (+[JSContextFileLoaderDelegate newContext]):
        (resolvePathToScripts):
        (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
        (testLoadBasicFile):
        (testObjectiveCAPI):
        * API/tests/testapiScripts/basic.js: Copied from Source/JavaScriptCore/API/JSVirtualMachineInternal.h.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * SourcesCocoa.txt:
        * config.h:
        * postprocess-headers.sh:
        * runtime/CallData.cpp:
        (JSC::call):
        * runtime/CallData.h:
        * runtime/Completion.cpp:
        (JSC::loadAndEvaluateModule):
        * runtime/Completion.h:
        * runtime/JSCast.h:
        (JSC::jsSecureCast):
        * runtime/JSGlobalObject.cpp:
        (JSC::createProxyProperty):

2019-01-14  Dominik Infuehr  <dinfuehr@igalia.com>

        Fix property access on ARM with the baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=193393

        Reviewed by Yusuke Suzuki.

        Code was still using currentInstruction[4] to access the instruction's metadata.
        Updated to use metadata.getPutInfo and metadata.resolveType.

        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):

2019-01-12  Timothy Hatcher  <timothy@apple.com>

        Have prefers-color-scheme: light always match on macOS versions before Mojave.
        https://bugs.webkit.org/show_bug.cgi?id=191655
        rdar://problem/46074680

        Reviewed by Megan Gardner.

        * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions.

2019-01-12  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, fix scope check assertions
        https://bugs.webkit.org/show_bug.cgi?id=193308

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::notifyLexicalBindingShadowing):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::notifyLexicalBindingShadowing):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):

2019-01-11  John Wilander  <wilander@apple.com>

        Compile out Web API Statistics Collection
        https://bugs.webkit.org/show_bug.cgi?id=193370
        <rdar://problem/45388584>

        Reviewed by Brent Fulgham.

        * Configurations/FeatureDefines.xcconfig:
            Defined ENABLE_WEB_API_STATISTICS, off by default.

2019-01-11  Saam barati  <sbarati@apple.com>

        DFG combined liveness can be wrong for terminal basic blocks
        https://bugs.webkit.org/show_bug.cgi?id=193304
        <rdar://problem/45268632>

        Reviewed by Yusuke Suzuki.

        If a block doesn't have any successors, it can't rely on the typical
        backwards liveness propagation that CombinedLiveness was doing. The phase
        first got what was live in bytecode and IR at the heads of each block. Then
        for each block, it made the live at tail the union of the live at head for
        each successor. For a terminal block though, this could be wrong. We could
        end up saying nothing is live even though many things may be live in bytecode.
        We must account for what's bytecode live at the end of the block. Consider a
        block that ends with:
        ```
        ForceOSRExit
        Unreachable
        ```
        
        Things may definitely be live in bytecode at the tail. However, we'll
        report nothing as being alive. This probably subtly breaks many analyses,
        but we have a test case of it breaking the interference analysis that
        the ArgumentsEliminationPhase performs.

        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::last const):
        * dfg/DFGCombinedLiveness.cpp:
        (JSC::DFG::addBytecodeLiveness):
        (JSC::DFG::liveNodesAtHead):
        (JSC::DFG::CombinedLiveness::CombinedLiveness):
        * dfg/DFGCombinedLiveness.h:

2019-01-11  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Global lexical bindings can shadow global variables if it is `configurable = true`
        https://bugs.webkit.org/show_bug.cgi?id=193308
        <rdar://problem/45546542>

        Reviewed by Saam Barati.

        Previously, we assumed that lexical bindings in JSGlobalLexicalEnvironment cannot shadow existing global properties.
        However, it is wrong. According to the spec, we can shadow global properties if a property's attribute is configurable = true.
        For example, we execute two scripts.

        script1.js

            bar = 42;
            function load() { return bar; }
            print(bar); // 42
            print(load()); // 42

        script2.js

            let bar = 0; // This lexical binding can shadow the global.bar defined in script1.js
            print(bar); // 0
            print(load()); // 0

        In JSC, we cache GlobalProperty resolve type and its associated information in op_resolve_type, op_get_from_scope, and op_put_to_scope.
        They attempt to load a property from JSGlobalObject directly. However, once the newly added lexical binding starts shadowing this, our existing instructions
        become invalid since they do not respect JSGlobalLexicalEnvironment.

        In this patch, we fix this issue by introducing the following mechanisms.

        1. We have a HashMap<property name, watchpoint set> in JSGlobalObject. DFG and FTL create a watchpoint set with the property name if the generated code
        depends on GlobalProperty condition of op_resolve_scope etc. These watchpoint will be fired when the shadowing happens, so that our generated DFG and FTL
        code will be invalidated if it depends on the condition which is no longer valid.

        2. When we detect shadowing, we iterate all the live CodeBlocks which globalObject is the target one. And we rewrite instructions in them from GlobalProperty
        to GlobalLexicalVar (or Dynamic precisely). So, the subsequent LLInt code just works well. "Dynamic" conversion happens when your op_put_to_scope attempts to
        put a value onto a const lexical binding. This fails and it should throw a type error.

        3. GlobalProperty scope operations in Baseline JIT start checking ResolveType in metadata, and emit code for GlobalProperty and GlobalLexicalVar. Once the rewrite
        happens, baseline JIT continues working because it checks the rewritten metadata's ResolveType.

        We use this mechanism (which is similar to haveABadTime() thing) because,

        1. Shadowing should be super rare. Before r214145, we made these cases as SytaxError. Thus, before r214145, this type of code cannot be executed in WebKit.
        And the number of the live CodeBlocks for the given JSGlobalObject should be small. This supports introducing rather simple (but not so efficient) mechanism
        instead of the complicated one.

        2. Rewriting instructions immediately forces GlobalProperty => GlobalLexicalVar / Dynamic conversion in all the possible CodeBlock. This allows us to avoid
        compilation failure loop in DFG and FTL: DFG and FTL codes are invalidated by the watchpoint, but we may attempt to compile the code with the invalidated watchpoint
        and GlobalProperty status if we do not rewrite it. One possible other implementation is having and checking a counter in instruction, and every time we introduce
        a new shadow binding, bump the counter. And eventually executed instruction will go to the slow path and rewrite itself. However, this way leaves the not-executed-again-yet
        instructions as is, and DFG and FTL repeatedly fail to compile if we just watch the invalidated watchpoint for that. Rewriting all the existing GlobalProperty immediately
        avoids this situation easily.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::notifyLexicalBindingShadowing):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::scriptMode const):
        * bytecode/Watchpoint.h:
        (JSC::WatchpointSet::create):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGDesiredGlobalProperties.cpp: Added.
        (JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread):
        (JSC::DFG::DesiredGlobalProperties::reallyAdd):
        * dfg/DFGDesiredGlobalProperties.h: Added.
        (JSC::DFG::DesiredGlobalProperties::addLazily):
        We need this DesiredGlobalProperties mechanism since we do not want to ref() the UniquedStringImpl in DFG and FTL thread.
        We keep JSGlobalObject* and identifierNumber, and materialize WatchpointSets for each JSGlobalObject's property referenced
        from DFG and FTL and inject CodeBlock jettison watchpoints in the main thread.
        * dfg/DFGDesiredGlobalProperty.h: Added.
        (JSC::DFG::DesiredGlobalProperty::DesiredGlobalProperty):
        (JSC::DFG::DesiredGlobalProperty::globalObject const):
        (JSC::DFG::DesiredGlobalProperty::identifierNumber const):
        (JSC::DFG::DesiredGlobalProperty::operator== const):
        (JSC::DFG::DesiredGlobalProperty::operator!= const):
        (JSC::DFG::DesiredGlobalProperty::isHashTableDeletedValue const):
        (JSC::DFG::DesiredGlobalProperty::hash const):
        (JSC::DFG::DesiredGlobalProperty::dumpInContext const):
        (JSC::DFG::DesiredGlobalProperty::dump const):
        (JSC::DFG::DesiredGlobalPropertyHash::hash):
        (JSC::DFG::DesiredGlobalPropertyHash::equal):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::globalProperties):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::reallyAdd):
        (JSC::DFG::Plan::isStillValidOnMainThread):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        (JSC::DFG::Plan::cancel):
        * dfg/DFGPlan.h:
        (JSC::DFG::Plan::globalProperties):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addStaticGlobals):
        (JSC::JSGlobalObject::notifyLexicalBindingShadowing):
        (JSC::JSGlobalObject::getReferencedPropertyWatchpointSet):
        (JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet):
        * runtime/JSGlobalObject.h:
        * runtime/ProgramExecutable.cpp:
        (JSC::hasRestrictedGlobalProperty):
        (JSC::ProgramExecutable::initializeGlobalProperties):

2019-01-11  Dominik Infuehr  <dinfuehr@igalia.com>

        Enable DFG on ARM/Linux again
        https://bugs.webkit.org/show_bug.cgi?id=192496

        Reviewed by Yusuke Suzuki.

        After changing the bytecode format DFG was disabled on all 32-bit
        architectures. Enable DFG now again on ARM/Linux. Do not use register
        r11 in compiled DFG mode since it is already used in LLInt as metadataTable
        register. Also clean up code since ARM traditional isn't supported anymore.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::CallFrameShuffler):
        * jit/GPRInfo.h:
        (JSC::GPRInfo::toIndex):
        * llint/LowLevelInterpreter32_64.asm:
        * offlineasm/arm.rb:

2019-01-10  Brian Burg  <bburg@apple.com>

        Web Inspector: incorrect type signature used for protocol enums in async command results
        https://bugs.webkit.org/show_bug.cgi?id=193331

        Reviewed by Devin Rousso.

        When an enum is returned by an async command, the type signature should be that of the
        Inspector::Protocol::* generated enum, rather than the underlying primitive type (i.e., String).

        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.cpp_type_for_formal_async_parameter):
        * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
        Rebaseline generator test results.

2019-01-10  Brian Burg  <bburg@apple.com>

        Rebaseline inspector generator test results after recent changes.

        Unreviewed test gardening.

        * inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/generic/expected/fail-on-domain-availability-value.json-error:

2019-01-10  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r239825.
        https://bugs.webkit.org/show_bug.cgi?id=193330

        Broke tests on armv7/linux bots (Requested by guijemont on
        #webkit).

        Reverted changeset:

        "Enable DFG on ARM/Linux again"
        https://bugs.webkit.org/show_bug.cgi?id=192496
        https://trac.webkit.org/changeset/239825

2019-01-10  Dominik Infuehr  <dinfuehr@igalia.com>

        Enable DFG on ARM/Linux again
        https://bugs.webkit.org/show_bug.cgi?id=192496

        Reviewed by Yusuke Suzuki.

        After changing the bytecode format DFG was disabled on all 32-bit
        architectures. Enable DFG now again on ARM/Linux. Do not use register
        r11 in compiled DFG mode since it is already used in LLInt as metadataTable
        register. Also clean up code since ARM traditional isn't supported anymore.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::CallFrameShuffler):
        * jit/GPRInfo.h:
        (JSC::GPRInfo::toIndex):
        * llint/LowLevelInterpreter32_64.asm:
        * offlineasm/arm.rb:

2019-01-09  Mark Lam  <mark.lam@apple.com>

        Restore bytecode dumper's ability to dump jump target as offset#(->targetBytecodeIndex#).
        https://bugs.webkit.org/show_bug.cgi?id=193300

        Reviewed by Saam Barati.

        For example, instead of:
            [  95] jtrue              loc11, 9
        We can now again (as before the bytecode format rewrite) have:
            [  95] jtrue              loc11, 9(->104)

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printLocationAndOp):
        * bytecode/BytecodeDumper.h:
        (JSC::BytecodeDumper::dumpValue):

2019-01-09  Mark Lam  <mark.lam@apple.com>

        Gigacage disabling checks should handle the GIGACAGE_ALLOCATION_CAN_FAIL case properly.
        https://bugs.webkit.org/show_bug.cgi?id=193292
        <rdar://problem/46485450>

        Reviewed by Yusuke Suzuki.

        * runtime/VM.h:
        (JSC::VM::gigacageAuxiliarySpace):

2019-01-08  Keith Miller  <keith_miller@apple.com>

        builtins should be able to use async/await
        https://bugs.webkit.org/show_bug.cgi?id=193263

        Reviewed by Saam Barati.

        This patch makes it possible to use async functions when writing builtin JS code.

        * Scripts/wkbuiltins/builtins_generator.py:
        (BuiltinsGenerator.generate_embedded_code_string_section_for_function):
        * Scripts/wkbuiltins/builtins_model.py:
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        (BuiltinFunction.__str__):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutable):
        * builtins/ModuleLoader.js:
        (requestInstantiate):
        (async.loadModule):
        (async.loadAndEvaluateModule):
        (async.requestImportModule):
        (loadModule): Deleted.
        (): Deleted.
        (loadAndEvaluateModule): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):

2019-01-08  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Array.prototype.flat/flatMap have a minor bug in ArraySpeciesCreate
        https://bugs.webkit.org/show_bug.cgi?id=193127

        Reviewed by Saam Barati.

        `== null` is frequently used idiom to check `null` or `undefined` in JS.
        However, it has a problem in terms of the builtin JS implementation: it
        returns true if masquerade-as-undefined objects (e.g. document.all) come.

        In this patch, we introduce a convenient builtin intrinsic @isUndefinedOrNull,
        which is equivalent to C++ `JSValue::isUndefinedOrNull`. It does not consider
        about masquerade-as-undefined objects, so that we can use it instead of
        `value === null || value === @undefined`. We introduce is_undefined_or_null
        bytecode, IsUndefinedOrNull DFG node and its DFG and FTL backends. Since
        Null and Undefined have some bit patterns, we can implement this query
        very efficiently.

        * builtins/ArrayIteratorPrototype.js:
        (next):
        * builtins/ArrayPrototype.js:
        (globalPrivate.arraySpeciesCreate):
        * builtins/GlobalOperations.js:
        (globalPrivate.speciesConstructor):
        (globalPrivate.copyDataProperties):
        (globalPrivate.copyDataPropertiesNoExclusions):
        * builtins/MapIteratorPrototype.js:
        (next):
        * builtins/SetIteratorPrototype.js:
        (next):
        * builtins/StringIteratorPrototype.js:
        (next):
        * builtins/StringPrototype.js:
        (match):
        (repeat):
        (padStart):
        (padEnd):
        (intrinsic.StringPrototypeReplaceIntrinsic.replace):
        (search):
        (split):
        (concat):
        (globalPrivate.createHTML):
        * builtins/TypedArrayPrototype.js:
        (globalPrivate.typedArraySpeciesConstructor):
        (map):
        (filter):
        * bytecode/BytecodeIntrinsicRegistry.h:
        * bytecode/BytecodeList.rb:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitIsUndefinedOrNull):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_isUndefinedOrNull):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileIsUndefinedOrNull):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_undefined_or_null):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_undefined_or_null):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2019-01-08  David Kilzer  <ddkilzer@apple.com>

        Leak of VectorBufferBase.m_buffer (16-64 bytes) under JSC::CompactVariableEnvironment in com.apple.WebKit.WebContent running layout tests
        <https://webkit.org/b/193264>
        <rdar://problem/46651026>

        Reviewed by Yusuke Suzuki.

        * parser/VariableEnvironment.cpp:
        (JSC::CompactVariableMap::Handle::~Handle): Call delete on
        m_environment instead of fastFree() to make sure the destructors
        for the Vector instance variables are run.  This fixes the leaks
        because calling fastFree() would only free the
        CompactVariableEnvironment object, but not the heap-based
        buffers allocated for the Vector instance variables.

2019-01-08  Joseph Pecoraro  <pecoraro@apple.com>

        ASSERT when paused in debugger and console evaluation causes exception
        https://bugs.webkit.org/show_bug.cgi?id=193246

        Reviewed by Mark Lam.

        * runtime/VM.cpp:
        (JSC::VM::throwException):
        Improve assertion to allow for the debugger's evaluate on call frame condition.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::callFrameAtDebuggerEntry const):
        (JSC::JSGlobalObject::setCallFrameAtDebuggerEntry):
        Debugger call frame only used by assertions.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
        * debugger/DebuggerEvalEnabler.h:
        (JSC::DebuggerEvalEnabler::DebuggerEvalEnabler):
        (JSC::DebuggerEvalEnabler::~DebuggerEvalEnabler):
        When evaluating on a call frame, set a debug GlobalObject state.

2019-01-08  Keith Miller  <keith_miller@apple.com>

        Move JSValueMakeSymbol to private header
        https://bugs.webkit.org/show_bug.cgi?id=193254

        Reviewed by Saam Barati.

        When moving other functions in JSValueRef I guess I forgot to move this one.

        * API/JSObjectRefPrivate.h:
        * API/JSValueRef.h:

2019-01-08  Mark Lam  <mark.lam@apple.com>

        Fix some typos in comments.

        Not reviewed.

        * dfg/DFGIntegerRangeOptimizationPhase.cpp:

2019-01-08  Tadeu Zagallo  <tzagallo@apple.com>

        LLInt put_by_id uses the wrong load instruction for loading flags from the metadata
        https://bugs.webkit.org/show_bug.cgi?id=193221

        Reviewed by Mark Lam.

        The flags are only 4 bytes, but were loaded with loadp. It used to work,
        since the flags were followed by a 4-byte padding, but it broke after the
        struct was compacted in r239626.

        * llint/LowLevelInterpreter64.asm:

2019-01-07  Devin Rousso  <drousso@apple.com>

        Web Inspector: extend XHR breakpoints to work with fetch
        https://bugs.webkit.org/show_bug.cgi?id=185843
        <rdar://problem/40431027>

        Reviewed by Matt Baker.

        * inspector/protocol/DOMDebugger.json:
        Rename `XHR` to `URL`.

        * inspector/protocol/Debugger.json:
        Add `Fetch` to `reason` enum for the `Debugger.paused` event.

2019-01-07  Devin Rousso  <drousso@apple.com>

        Web Inspector: Network: show secure connection details per-request
        https://bugs.webkit.org/show_bug.cgi?id=191539
        <rdar://problem/45979891>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Security.json:
        Add `Connection` type.

        * inspector/protocol/Network.json:
        Send `Security.Connection` information when request metrics become available.

2019-01-04  Tadeu Zagallo  <tzagallo@apple.com>

        Baseline version of get_by_id may corrupt metadata
        https://bugs.webkit.org/show_bug.cgi?id=193085
        <rdar://problem/23453006>

        Reviewed by Saam Barati.

        The Baseline version of get_by_id unconditionally calls `emitArrayProfilingSiteForBytecodeIndexWithCell`
        if the property is `length`. However, since the bytecode rewrite, get_by_id only has an ArrayProfile entry
        in the metadata if its mode is `GetByIdMode::ArrayLength`. That might result in one of two bad things:
        1) get_by_id's mode is not ArrayLength, and a duplicate, out-of-line ArrayProfile entry will be created by
        `CodeBlock::getOrAddArrayProfile`.
        2) get_by_id's mode *is* ArrayLength and we generate the array profiling code pointing to the ArrayProfile
        that lives in the metadata table. This works fine as long as get_by_id does not change modes. If that happens,
        the JIT code will write into the metadata table, overwriting the 'GetByIdModeMetadata` for another mode.

        Add a check to the Baseline version of get_by_id so that we only do the ArrayProfiling if the get_by_id's
        mode is ArrayLength

        * bytecode/BytecodeList.rb:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::getArrayProfile):
        (JSC::CodeBlock::addArrayProfile): Deleted.
        (JSC::CodeBlock::getOrAddArrayProfile): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfArrayProfiles const): Deleted.
        (JSC::CodeBlock::arrayProfiles): Deleted.
        * bytecode/CodeBlockInlines.h:
        (JSC::CodeBlock::forEachArrayProfile):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::emitArrayProfilingSiteForBytecodeIndexWithCell): Deleted.
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_id):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

2019-01-02  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Optimize Object.prototype.toString
        https://bugs.webkit.org/show_bug.cgi?id=193031

        Reviewed by Saam Barati.

        Object.prototype.toString is frequently used for type checking.
        It is called many times in wtb-lebab.js. This patch optimizes
        Object.prototype.toString by the following two optimizations.

        1. We should emit code looking up cached to string in DFG and FTL.

        toString's result is cached in the Structure. We emit a fast path code
        in DFG and FTL to lookup this cache.

        2. We should not create objects for primitive values in major cases.

        When Object.prototype.toString(primitive) is called, this primitive is converted
        to an object by calling ToObject. But if the result is appropriately cached in
        the Structure, we should get it in the fast path without creating this object.
        When converting primitives to objects, Structures used in these newly created objects
        are known (Structure for StringObject etc.). So we can first query the cached string
        before actually converting primitives to objects.

        This patch improves wtb-lebab.js by roughly 2%.

            before:    lebab:  8.90 runs/s
            after :    lebab:  9.09 runs/s

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupObjectToString):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectToString):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileObjectToString):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        (JSC::objectProtoFuncToString):
        * runtime/ObjectPrototype.h:
        * runtime/ObjectPrototypeInlines.h: Added.
        (JSC::structureForPrimitiveValue):
        (JSC::objectToString):
        * runtime/StructureRareData.h:

2019-01-03  Michael Saboff  <msaboff@apple.com>

        DFG IntegerRangeOptimization phase exceeding loop limit shouldn't ASSERT
        https://bugs.webkit.org/show_bug.cgi?id=193094

        Reviewed by Saam Barati.

        Removed this debug only ASSERT as one can construct test cases that will exceed the giveUpThreshold
        amount.   This can be done with a large switch statement with at least one const or variable case
        clause.  Such code bytecompiles to compare / jtrue sequences.  Increasing the giveUpThreshold count
        doesn't help with the eventual code generated as B3 has optimizations to coalesce compare / branch
        code sequences even when we don't run the IntegerRangeOptimization phase.

        * dfg/DFGIntegerRangeOptimizationPhase.cpp:

2019-01-02  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: Implement `queryObjects` Command Line API
        https://bugs.webkit.org/show_bug.cgi?id=176766
        <rdar://problem/34890689>

        Reviewed by Joseph Pecoraro.

        Introduces a new Command Line function called `queryObjects` that will return an array of
        object that have the given constructor/prototype argument in their prototype chain.
         - `queryObjects(Promise)` will return an array of all Promises.
         - `queryObjects(Foo)` will return all objects created with the constructor `Foo`.

        Currently, an error is thrown if the first argument is one of the following:
         - Object
         - Object.prototype
         - Function
         - Function.prototype
         - Array
         - Array.prototype
         - Map
         - Map.prototype
         - Set
         - Set.prototype
         - Proxy

        The reason for this is that we don't want to expose any internal/builtin objects, as some of
        them are highly sensitive and undefined behaviour can occur if they are modified.

        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::checkForbiddenPrototype): Added.
        (Inspector::JSInjectedScriptHost::queryObjects): Added.
        Does a GC and then iterates over all live JSCell in the heap to find these objects.

        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionQueryObjects): Added.

        * inspector/InjectedScriptSource.js:
        (queryObjects): Added.

        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::promisePrototype): Added.

2018-12-31  Keith Miller  <keith_miller@apple.com>

        SourceProviders should use an actual URL instead of a string
        https://bugs.webkit.org/show_bug.cgi?id=192734

        Reviewed by Yusuke Suzuki.

        This will be useful for the Module loader API in the future where
        by default it will use the relative path from the referring module
        to resolve dependencies.

        I didn't change the JSC shell's urls to be absolute paths as it
        caused problems with the stack traces in our Chakra tests. Since
        the absolute paths included system directories the diff would
        appear incorrect.
        See: https://bugs.webkit.org/show_bug.cgi?id=193077

        * API/JSBase.cpp:
        (JSEvaluateScript):
        (JSCheckScriptSyntax):
        * API/JSScriptRef.cpp:
        (OpaqueJSScript::create):
        (OpaqueJSScript::OpaqueJSScript):
        * API/glib/JSCContext.cpp:
        (jsc_context_check_syntax):
        * jsc.cpp:
        (jscSource):
        (GlobalObject::moduleLoaderFetch):
        (functionCheckModuleSyntax):
        (runWithOptions):
        * parser/SourceCode.h:
        (JSC::makeSource):
        * parser/SourceProvider.cpp:
        (JSC::SourceProvider::SourceProvider):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::url const):
        (JSC::StringSourceProvider::create):
        (JSC::StringSourceProvider::StringSourceProvider):
        (JSC::WebAssemblySourceProvider::create):
        (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * tools/CodeProfile.h:
        (JSC::CodeProfile::CodeProfile):
        * tools/FunctionOverrides.cpp:
        (JSC::initializeOverrideInfo):

2019-01-01  Jeff Miller  <jeffm@apple.com>

        Update user-visible copyright strings to include 2019
        https://bugs.webkit.org/show_bug.cgi?id=192811

        Reviewed by Mark Lam.

        * Info.plist:

2018-12-30  Ross Kirsling  <ross.kirsling@sony.com>

        [JSC] Identifier validity should be based on ID_Start / ID_Continue properties
        https://bugs.webkit.org/show_bug.cgi?id=193050

        Reviewed by Yusuke Suzuki.

        From https://tc39.github.io/ecma262/#sec-names-and-keywords:
            UnicodeIDStart::
                any Unicode code point with the Unicode property "ID_Start"
            UnicodeIDContinue::
                any Unicode code point with the Unicode property "ID_Continue"

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        (JSC::isNonLatin1IdentStart):
        (JSC::isNonLatin1IdentPart):
        (JSC::isIdentPart):
        (JSC::Lexer<T>::lex):
        Ensure identifier start / part is based on ID_Start / ID_Continue.
        (Implies a special case for U+00B7, which is Latin-1 but Other_ID_Continue.)

2018-12-28  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Remove one indirection in JSObject::toStringName
        https://bugs.webkit.org/show_bug.cgi?id=193037

        Reviewed by Keith Miller.

        We should not have additional one-level indirection in JSObject::toStringName.
        JSObject::toStringName is dispatched through methodTable. Even after that, we
        need to call JSObject::className function through methodTable again. But className
        function is rarely defined. So instead of introducing this indirection here,
        classes having className functions should have toStringName function too. This can
        remove one-level indirection in toStringName in major cases.

        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::toStringName):
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::toStringName):
        * debugger/DebuggerScope.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::toStringName):

2018-12-27  Alex Christensen  <achristensen@webkit.org>

        Resurrect Mac CMake build
        https://bugs.webkit.org/show_bug.cgi?id=192658

        Reviewed by Yusuke Suzuki.

        * PlatformMac.cmake:

2018-12-25  Fujii Hironori  <Hironori.Fujii@sony.com>

        [JSC][Win][Clang] warning: implicit conversion from 'size_t' (aka 'unsigned long long') to 'int32_t' (aka 'int') changes value from 18446744073709551552 to -64 [-Wconstant-conversion]
        https://bugs.webkit.org/show_bug.cgi?id=193035

        Reviewed by Yusuke Suzuki.

        Clang-cl reports a compilation warning for implicit conversion
        from -64 size_t to int. Replaced '-maxFrameExtentForSlowPathCall'
        with '-static_cast<int32_t>(maxFrameExtentForSlowPathCall)'.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * jit/JIT.cpp:
        (JSC::JIT::compileWithoutLinking):
        * jit/ThunkGenerators.cpp:
        (JSC::slowPathFor):

2018-12-13  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [BigInt] Support BigInt in JSON.stringify
        https://bugs.webkit.org/show_bug.cgi?id=192624

        Reviewed by Saam Barati.

        This patch adds BigInt support to JSON.stringify, specified in [1].

        [1]: https://tc39.github.io/proposal-bigint/#sec-serializejsonproperty

        * runtime/JSONObject.cpp:
        (JSC::unwrapBoxedPrimitive):
        (JSC::Stringifier::toJSON):
        (JSC::Stringifier::toJSONImpl):
        (JSC::Stringifier::appendStringifiedValue):

2018-12-21  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Use appendUnbarriered for cached own keys
        https://bugs.webkit.org/show_bug.cgi?id=192981

        Reviewed by Saam Barati.

        m_cachedOwnKeys would be changed to sentinel after checking `thisObject->m_cachedOwnKeys.unvalidatedGet() != cachedOwnKeysSentinel()`
        and before executing `visitor.append(thisObject->m_cachedOwnKeys)`. We never do this now, but might in the future.
        To make the code safe, we should use appendUnbarriered to mark non sentinel cell.

        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::visitChildren):

2018-12-20  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Use Ref<> as much as possible
        https://bugs.webkit.org/show_bug.cgi?id=192808

        Reviewed by Alex Christensen.

        * API/JSTypedArray.cpp:
        (JSObjectMakeTypedArrayWithBytesNoCopy):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * bytecompiler/StaticPropertyAnalyzer.h:
        (JSC::StaticPropertyAnalyzer::newObject):
        * dfg/DFGDesiredWatchpoints.cpp:
        (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::sweeper):
        * heap/Heap.h:
        * heap/IsoCellSet.cpp:
        (JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource):
        * heap/IsoCellSet.h:
        * heap/IsoCellSetInlines.h:
        (JSC::IsoCellSet::forEachMarkedCellInParallel):
        * heap/Subspace.cpp:
        (JSC::Subspace::parallelDirectorySource):
        (JSC::Subspace::parallelNotEmptyMarkedBlockSource):
        * heap/Subspace.h:
        * heap/SubspaceInlines.h:
        (JSC::Subspace::forEachMarkedCellInParallel):
        * jsc.cpp:
        (functionDollarAgentReceiveBroadcast):
        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBuffer::slice const):
        (JSC::ArrayBuffer::sliceImpl const):
        * runtime/ArrayBuffer.h:
        * runtime/ArrayBufferNeuteringWatchpoint.cpp:
        (JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint):
        (JSC::ArrayBufferNeuteringWatchpoint::fireAll):
        * runtime/ArrayBufferNeuteringWatchpoint.h:
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice):

2018-12-21  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Crashes seen under Inspector::ScriptCallFrame::~ScriptCallFrame
        https://bugs.webkit.org/show_bug.cgi?id=180373
        <rdar://problem/33894170>

        Rubber-stamped by Devin Rousso.

        * inspector/AsyncStackTrace.cpp:
        (Inspector::AsyncStackTrace::truncate):
        The `lastUnlockedAncestor->remove()` may release the only reference to it's
        parent which we intend to use later but don't hold a RefPtr to. Keep the
        parent alive explicitly by protecting it.

2018-12-20  Chris Dumez  <cdumez@apple.com>

        Use Optional::hasValue() instead of Optional::has_value()
        https://bugs.webkit.org/show_bug.cgi?id=192948

        Reviewed by Tim Horton.

        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):

2018-12-20  Keith Miller  <keith_miller@apple.com>

        Add support for globalThis
        https://bugs.webkit.org/show_bug.cgi?id=165171

        Reviewed by Mark Lam.

        This patch adds support for the globalThis property on the global
        object. The globalThis property spec is in stage three and is
        quite simple. For reference: http://tc39.github.io/proposal-global/

        * runtime/JSGlobalObject.cpp:

2018-12-20  Chris Dumez  <cdumez@apple.com>

        Use Optional::valueOr() instead of Optional::value_or()
        https://bugs.webkit.org/show_bug.cgi?id=192933

        Reviewed by Geoffrey Garen.

        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
        (Inspector::RemoteConnectionToTarget::setup):
        * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
        (Inspector::RemoteConnectionToTarget::setup):
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):

2018-12-20  Joseph Pecoraro  <pecoraro@apple.com>

        ITMLKit Inspector: Elements tab does not show DOM Tree
        https://bugs.webkit.org/show_bug.cgi?id=192910
        <rdar://problem/46680585>

        Reviewed by Brian Burg.

        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::enable):
        (Inspector::InspectorAgent::activateExtraDomain):
        (Inspector::InspectorAgent::activateExtraDomains):
        Send extra domains immediately instead of waiting until
        the Inspector domain is enabled. This will ensure the frontend
        hears about extra augmented domains before augmenting agents
        get a chance to send any messages.

2018-12-20  Mark Lam  <mark.lam@apple.com>

        Fix a typo in slow_path_construct_arityCheck and operationConstructArityCheck.
        https://bugs.webkit.org/show_bug.cgi?id=192939
        <rdar://problem/46869516>

        Reviewed by Keith Miller.

        * jit/JITOperations.cpp:
        * runtime/CommonSlowPaths.cpp:

2018-12-20  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse
        https://bugs.webkit.org/show_bug.cgi?id=192723

        Reviewed by Yusuke Suzuki.

        This patch is adjusting clobberize rules into ValueOp nodes to enable
        more optimizations when we speculate BigIntUse. In such case, DFG now
        is able to apply CSE, LICM and commutativity on nodes like
        ValueAdd(BigInt, BigInt), ValueSub(BigInt, BigInt), etc.

        Here are the numbers we can observe with some microbenchmarks:

                                  baseline                 changes

        big-int-cse           108.2733+-0.8445    ^    80.9897+-4.9781   ^ definitely 1.3369x faster
        big-int-licm          75.6641+-0.3477     ^    57.8144+-1.6043   ^ definitely 1.3087x faster
        big-int-global-cse    145.3557+-1.0552    ^    86.5866+-0.3025   ^ definitely 1.6787x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

2018-12-19  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r239377.
        https://bugs.webkit.org/show_bug.cgi?id=192921

        broke 32-bit JSC tests (Requested by keith_miller on #webkit).

        Reverted changeset:

        "[BigInt] We should enable CSE into arithmetic operations that
        speculate BigIntUse"
        https://bugs.webkit.org/show_bug.cgi?id=192723
        https://trac.webkit.org/changeset/239377

2018-12-19  Chris Dumez  <cdumez@apple.com>

        wtf/Optional.h: move-constructor and move-assignment operator should disengage the value being moved from
        https://bugs.webkit.org/show_bug.cgi?id=192728
        <rdar://problem/46746779>

        Reviewed by Geoff Garen.

        * API/*:
        * Scripts/*:
        * assembler/*:
        * b3/*:
        * bytecode/*:
        * bytecompiler/*:
        * debugger/*:
        * dfg/*:
        * ftl/*:
        * heap/*:
        * inspector/*:
        * jit/*:
        * llint/*:
        * parser/*:
        * runtime/*:
        * tools/*:
        * wasm/*:
        * yarr/*:

2018-12-18  Simon Fraser  <simon.fraser@apple.com>

        Web Inspector: Timelines: correctly label Intersection Observer callbacks
        https://bugs.webkit.org/show_bug.cgi?id=192669
        <rdar://problem/46702490>

        Reviewed by Joseph Pecoraro.

        Add InspectorInstrumentation::willFireObserverCallback() and use it to wrap calls
        to Intersection Observer, Performance Observer and Mutation Observer callbacks so 
        that they get correctly labeled in the Inspector timeline.

        * inspector/protocol/Timeline.json:

2018-12-18  Mark Lam  <mark.lam@apple.com>

        JSPropertyNameEnumerator should cache the iterated object's structure only after getting its property names.
        https://bugs.webkit.org/show_bug.cgi?id=192464
        <rdar://problem/46519455>

        Reviewed by Saam Barati.

        This is because the process of getting its property names may cause some lazy
        properties to be reified, and the structure will change.  This is needed in order
        for get_direct_pname to work correctly.

        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):

2018-12-19  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse
        https://bugs.webkit.org/show_bug.cgi?id=192723

        Reviewed by Saam Barati.

        This patch is adjusting clobberize rules into ValueOp nodes to enable
        more optimizations when we speculate BigIntUse. In such case, DFG now
        is able to apply CSE, LICM and commutativity on nodes like
        ValueAdd(BigInt, BigInt), ValueSub(BigInt, BigInt), etc.

        Here are the numbers we can observe with some microbenchmarks:

                                  baseline                 changes

        big-int-cse           108.2733+-0.8445    ^    80.9897+-4.9781   ^ definitely 1.3369x faster
        big-int-licm          75.6641+-0.3477     ^    57.8144+-1.6043   ^ definitely 1.3087x faster
        big-int-global-cse    145.3557+-1.0552    ^    86.5866+-0.3025   ^ definitely 1.6787x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

2018-12-19  Tadeu Zagallo  <tzagallo@apple.com>

        String overflow in JSC::createError results in ASSERT in WTF::makeString
        https://bugs.webkit.org/show_bug.cgi?id=192833
        <rdar://problem/45706868>

        Reviewed by Mark Lam.

        JSC::createError was calling WTF::makeString which would result in an
        assertion failure when the string was too big. Change it to call
        WTF::tryMakeString instead and return an OutOfMemory error if we fail
        to create the error string.

        * runtime/ExceptionHelpers.cpp:
        (JSC::createError):

2018-12-18  Ross Kirsling  <ross.kirsling@sony.com>

        Error message for `-x ** y` contains a typo.
        https://bugs.webkit.org/show_bug.cgi?id=192832

        Reviewed by Saam Barati.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseBinaryExpression):
        Make corrections to error message: "amiguous" -> "ambiguous", "parenthesis" -> "parentheses"

2018-12-18  Saam Barati  <sbarati@apple.com>

        Update ARM64EHash
        https://bugs.webkit.org/show_bug.cgi?id=192823
        <rdar://problem/45468257>

        Reviewed by Mark Lam.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::ARM64Assembler):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
        * assembler/AssemblerBuffer.h:
        (JSC::ARM64EHash::update):
        (JSC::ARM64EHash::finalHash const):
        (JSC::AssemblerBuffer::AssemblerBuffer):
        (JSC::AssemblerBuffer::putIntegralUnchecked):
        (JSC::ARM64EHash::ARM64EHash): Deleted.
        (JSC::ARM64EHash::hash const): Deleted.
        (JSC::ARM64EHash::randomSeed const): Deleted.
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):

2018-12-18  Mark Lam  <mark.lam@apple.com>

        JSON.stringify() should throw OOM on StringBuilder overflows.
        https://bugs.webkit.org/show_bug.cgi?id=192822
        <rdar://problem/46670577>

        Reviewed by Saam Barati.

        * runtime/JSONObject.cpp:
        (JSC::Stringifier::stringify):
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Stringifier::Holder::appendNextProperty):

2018-12-18  Ross Kirsling  <ross.kirsling@sony.com>

        Redeclaration of var over let/const/class should be a syntax error.
        https://bugs.webkit.org/show_bug.cgi?id=192298

        Reviewed by Keith Miller.

        From https://tc39.github.io/ecma262/#sec-block-static-semantics-early-errors:
        It is a Syntax Error if any element of the LexicallyDeclaredNames of StatementList also occurs in the
        VarDeclaredNames of StatementList.

        Accordingly, this patch ensures that { let x; { var x; } } and { { var x; } let x; } are syntax errors.

        For the "var after" scenario:
        When checking for existing lexically-declared names, we can't simply check the current var scope;
        we need to check *all* enclosing scopes up to (and including) the current var scope. In so doing,
        we must also avoid violating the Annex B.3.5 condition that allows `try {} catch (e) { var e; }`.

        For the "var before" scenario:
        We ensure that lexical scopes always keep track of the vars being hoisted over them; this gives us
        a simple way to check the current block's var-declared names prior to making a lexical declaration.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseTryStatement):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setIsSimpleCatchParameterScope): Added.
        (JSC::Scope::isSimpleCatchParameterScope): Added.
        (JSC::Scope::declareVariable):
        (JSC::Scope::addVariableBeingHoisted): Added.
        (JSC::Scope::declareLexicalVariable):
        (JSC::Scope::hasDeclaredVariable):
        (JSC::Scope::hasLexicallyDeclaredVariable): Added.
        (JSC::Parser::declareHoistedVariable): Added.
        (JSC::Parser::declareVariable):

2018-12-18  David Kilzer  <ddkilzer@apple.com>

        clang-tidy: Use const reference for MediaTime parameter to prevent object copy
        <https://webkit.org/b/192814>

        Reviewed by Mark Lam.

        * runtime/JSCJSValue.h:
        (JSC::jsNumber):

2018-12-18  Saam Barati  <sbarati@apple.com>

        Unreviewed. Appease a build error where we weren't using a variable defined in an "if"

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2018-12-17  Mark Lam  <mark.lam@apple.com>

        Array unshift/shift should not race against the AI in the compiler thread.
        https://bugs.webkit.org/show_bug.cgi?id=192795
        <rdar://problem/46724263>

        Reviewed by Saam Barati.

        The Array unshift and shift operations for ArrayStorage type arrays are protected
        using the cellLock.  The AbstractInterpreter's foldGetByValOnConstantProperty()
        function does grab the cellLock before reading a value from the array's ArrayStorage,
        but does not get the array butterfly under the protection of the cellLock.

        This is insufficient and racy.  For ArrayStorage type arrays, the fetching of the
        butterfly also needs to be protected by the cellLock.  The unshift / shift
        operations can move values around in the butterfly.  Hence, the fact that AI has
        fetched a butterfly pointer (while ensuring no structure change) is insufficient
        to guarantee that the values in the butterfly haven't shifted.

        Having AI hold the cellLock the whole time (from before fetching the butterfly
        till after reading the value from it) eliminates this race.  Note: we only need
        to do this for ArrayStorage type arrays.

        Note also that though AI is holding the cellLock in this case, we still need to
        ensure that the array structure hasn't changed around the fetching of the butterfly.
        This is because operations other than unshift and shift are guarded by this
        protocol, and not the cellLock.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):

2018-12-16  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Optimize Object.keys by caching own keys results in StructureRareData
        https://bugs.webkit.org/show_bug.cgi?id=190047

        Reviewed by Saam Barati.

        Object.keys is one of the most frequently used function in web-tooling-benchmarks (WTB).
        Object.keys is dominant in lebab of WTB, and frequently called in babel and others.
        Since our Structure knows the shape of JSObject, we can cache the result of Object.keys
        in Structure (StructureRareData) as we cache JSPropertyNameEnumerator in StructureRareData.

        This patch caches the result of Object.keys in StructureRareData. The cached array is created
        as JSImmutableButterfly. And Object.keys creates CoW from this data. Currently, the lifetime
        strategy of this JSImmutableButterfly is the same to cached JSPropertyNameEnumerator. It is
        referenced from Structure, and collected when Structure is collected.

        This improves several benchmarks in SixSpeed.

                                        baseline                  patched

            object-assign.es5      350.1710+-3.6303     ^    226.0368+-4.7558        ^ definitely 1.5492x faster
            for-of-object.es6      269.1941+-3.3430     ^    127.9317+-2.3875        ^ definitely 2.1042x faster

        And it improves WTB lebab by 11.8%.

            Before: lebab:  6.10 runs/s
            After:  lebab:  6.82 runs/s

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToNewArrayBuffer):
        * dfg/DFGNode.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectKeys):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys):
        * runtime/Butterfly.h:
        (JSC::ContiguousData::Data::setStartingValue):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/JSImmutableButterfly.h:
        (JSC::JSImmutableButterfly::JSImmutableButterfly):
        We set JSEmpty to the underlying butterfly storage if indexing type is Contiguous.
        Otherwise, JSImmutableButterfly is half-baked one until all the storage is filled with some meaningful values, it leads to crash
        if half-baked JSImmutableButterfly is exposed to GC.
        * runtime/ObjectConstructor.cpp:
        (JSC::ownPropertyKeys):
        * runtime/Structure.cpp:
        (JSC::Structure::canCachePropertyNameEnumerator const):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::setCachedOwnKeys):
        (JSC::Structure::cachedOwnKeys const):
        (JSC::Structure::cachedOwnKeysIgnoringSentinel const):
        (JSC::Structure::canCacheOwnKeys const):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::visitChildren):
        (JSC::StructureRareData::cachedPropertyNameEnumerator const): Deleted.
        (JSC::StructureRareData::setCachedPropertyNameEnumerator): Deleted.
        * runtime/StructureRareData.h:
        * runtime/StructureRareDataInlines.h:
        (JSC::StructureRareData::cachedPropertyNameEnumerator const):
        (JSC::StructureRareData::setCachedPropertyNameEnumerator):
        (JSC::StructureRareData::cachedOwnKeys const):
        (JSC::StructureRareData::cachedOwnKeysIgnoringSentinel const):
        (JSC::StructureRareData::cachedOwnKeysConcurrently const):
        (JSC::StructureRareData::setCachedOwnKeys):
        (JSC::StructureRareData::previousID const): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):

2018-12-17  Mark Lam  <mark.lam@apple.com>

        SamplingProfiler's isValidFramePointer() should reject address at stack origin.
        https://bugs.webkit.org/show_bug.cgi?id=192779
        <rdar://problem/46775869>

        Reviewed by Saam Barati.

        isValidFramePointer() was previously treating the address at StackBounds::origin()
        as valid stack memory.  This is not true.  StackBounds::origin() is actually the
        first address beyond valid stack memory. This is now fixed.

        * runtime/SamplingProfiler.cpp:
        (JSC::FrameWalker::isValidFramePointer):

2018-12-17  Mark Lam  <mark.lam@apple.com>

        Suppress ASAN on valid stack accesses in Probe-based OSRExit::executeOSRExit().
        https://bugs.webkit.org/show_bug.cgi?id=192776
        <rdar://problem/46772368>

        Reviewed by Keith Miller.

        1. Add some asanUnsafe methods to the Register class.
        2. Update the probe-based OSRExit::executeOSRExit() to use these asanUnsafe methods.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        * interpreter/Register.h:
        (JSC::Register::asanUnsafeUnboxedInt32 const):
        (JSC::Register::asanUnsafeUnboxedInt52 const):
        (JSC::Register::asanUnsafeUnboxedStrictInt52 const):
        (JSC::Register::asanUnsafeUnboxedDouble const):
        (JSC::Register::asanUnsafeUnboxedCell const):

2018-12-17  Mark Lam  <mark.lam@apple.com>

        Fix stale assertion in attemptToForceStringArrayModeByToStringConversion().
        https://bugs.webkit.org/show_bug.cgi?id=192770
        <rdar://problem/46449037>

        Reviewed by Keith Miller.

        This assertion was added before Array::OriginalNonArray was introduced.  It just
        needs to be updated to allow for Array::OriginalNonArray.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):

2018-12-17  Matt Lewis  <jlewis3@apple.com>

        Unreviewed, rolling out r239254.

        This broke the Windows 10 Debug build

        Reverted changeset:

        "Replace many uses of String::format with more type-safe
        alternatives"
        https://bugs.webkit.org/show_bug.cgi?id=192742
        https://trac.webkit.org/changeset/239254

2018-12-15  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, suppress warnings in Linux

        * jsc.cpp:
        (jscmain):

2018-12-15  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Null pointer dereference in JSC::WriteBarrierBase()
        https://bugs.webkit.org/show_bug.cgi?id=191252

        Reviewed by Keith Miller.

        JSPromiseDeferred::create can return nullptr and an exception if stack overflow happens.
        We would like to make it RELEASE_ASSERT since the current module mechanism is not immune
        to stack overflow.

        This patch renames JSPromiseDeferred::create to JSPromiseDeferred::tryCreate to tell that
        it can return nullptr. And we insert error checks or assertions after this call.

        * jsc.cpp:
        (GlobalObject::moduleLoaderImportModule):
        (GlobalObject::moduleLoaderFetch):
        * runtime/Completion.cpp:
        (JSC::rejectPromise):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncImportModule):
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::tryCreate):
        (JSC::JSInternalPromiseDeferred::create): Deleted.
        * runtime/JSInternalPromiseDeferred.h:
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::importModule):
        (JSC::JSModuleLoader::resolve):
        (JSC::JSModuleLoader::fetch):
        (JSC::moduleLoaderParseModule):
        * runtime/JSPromise.h:
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::tryCreate):
        * runtime/JSPromiseDeferred.h:
        * wasm/js/WebAssemblyPrototype.cpp:
        (JSC::webAssemblyCompileFunc):
        (JSC::webAssemblyInstantiateFunc):
        (JSC::webAssemblyCompileStreamingInternal):
        (JSC::webAssemblyInstantiateStreamingInternal):

2018-12-15  Darin Adler  <darin@apple.com>

        Use warning-ignoring macros more consistently and simply
        https://bugs.webkit.org/show_bug.cgi?id=192743

        Reviewed by Mark Lam.

        * dfg/DFGSpeculativeJIT64.cpp: Use IGNORE_WARNINGS_BEGIN/END instead of
        IGNORE_CLANG_WARNINGS_BEGIN/END. Other callsites are using the non-clang-specific
        one for this warning, "implicit-fallthrough", and it seems there is no special
        need to use the clang-specific one here.
        * llint/LLIntData.cpp: Ditto, but here it's "missing-noreturn"."
        * tools/CodeProfiling.cpp: Ditto.

2018-12-15  Darin Adler  <darin@apple.com>

        Replace many uses of String::format with more type-safe alternatives
        https://bugs.webkit.org/show_bug.cgi?id=192742

        Reviewed by Mark Lam.

        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeCall): Use makeString.
        (Inspector::InjectedScriptBase::makeAsyncCall): Ditto.
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::getPropertyValue): Ditto.
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::enable): Ditto.
        * jsc.cpp:
        (FunctionJSCStackFunctor::operator() const): Ditto.

        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormat::initializeDateTimeFormat): Use string concatenation.
        * runtime/IntlObject.cpp:
        (JSC::canonicalizeLocaleList): Ditto.

2018-12-14  Darin Adler  <darin@apple.com>

        LiteralParser has a bunch of uses of String::format with untrusted data
        https://bugs.webkit.org/show_bug.cgi?id=108883
        rdar://problem/13666409

        Reviewed by Mark Lam.

        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::Lexer::lex): Use makeString instead of String::format.
        (JSC::LiteralParser<CharType>::Lexer::lexStringSlow): Ditto.
        (JSC::LiteralParser<CharType>::parse): Ditto.

        * runtime/LiteralParser.h:
        (JSC::LiteralParser::getErrorMessage): Use string concatenation instead of
        String::format.

2018-12-14  Mark Lam  <mark.lam@apple.com>

        CallFrame::convertToStackOverflowFrame() needs to keep the top CodeBlock alive.
        https://bugs.webkit.org/show_bug.cgi?id=192717
        <rdar://problem/46660677>

        Reviewed by Saam Barati.

        When throwing a StackOverflowError, we convert the topCallFrame into a
        StackOverflowFrame.  Previously, we would nullify the codeBlock field in the frame
        because a StackOverflowFrame is only a sentinel and doesn't really correspond to
        any CodeBlocks.  However, this is a problem because the topCallFrame may be the
        only remaining place that references the CodeBlock that the stack overflow is
        triggered in.  The way we handle exceptions in JIT code is to return (from the
        runtime operation function throwing the exception) to the JIT code to check for
        the exception and if needed, do some clean up before jumping to the exception
        handling thunk.  As a result, we need to keep that JIT code alive, which means we
        need to keep its CodeBlock alive.  We only need to keep this CodeBlock alive until
        we've unwound (in terms of exception handling) out of it.

        We fix this issue by storing the CodeBlock to keep alive in the StackOverflowFrame
        for the GC to scan while the frame is still on the stack.

        We removed the call to convertToStackOverflowFrame() in
        lookupExceptionHandlerFromCallerFrame() because it is redundant.
        lookupExceptionHandlerFromCallerFrame() will only every be called after
        a StackOverFlowError has been thrown.  Hence, the top frame is already
        guaranteed to be a StackOverflowFrame, and there should always be a
        StackOverFlowError exception pending.  We added assertions for these
        instead.

        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::convertToStackOverflowFrame):
        * interpreter/CallFrame.h:
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::codeBlockFromCallFrameCallee):
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/VM.h:
        (JSC::VM::exceptionForInspection const):

2018-12-14  David Kilzer  <ddkilzer@apple.com>

        clang-tidy: Fix unnecessary copy of objects for operator==() methods
        <https://webkit.org/b/192712>
        <rdar://problem/46739332>

        Reviewed by Andy Estes.

        * b3/air/AirAllocateRegistersByGraphColoring.cpp:
        (JSC::B3::Air::(anonymous namespace)::AbstractColoringAllocator::InterferenceEdge::operator==):
        - Change argument from const to const reference to avoid a copy.

2018-12-14  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r239153, r239154, and r239155.
        https://bugs.webkit.org/show_bug.cgi?id=192715

        Caused flaky GC-related crashes seen with layout tests
        (Requested by ryanhaddad on #webkit).

        Reverted changesets:

        "[JSC] Optimize Object.keys by caching own keys results in
        StructureRareData"
        https://bugs.webkit.org/show_bug.cgi?id=190047
        https://trac.webkit.org/changeset/239153

        "Unreviewed, build fix after r239153"
        https://bugs.webkit.org/show_bug.cgi?id=190047
        https://trac.webkit.org/changeset/239154

        "Unreviewed, build fix after r239153, part 2"
        https://bugs.webkit.org/show_bug.cgi?id=190047
        https://trac.webkit.org/changeset/239155

2018-12-14  Keith Miller  <keith_miller@apple.com>

        Callers of JSString::getIndex should check for OOM exceptions
        https://bugs.webkit.org/show_bug.cgi?id=192709

        Reviewed by Mark Lam.

        This patch also allows Strings to OOM when the StringObject wrapper
        attempts to look up an own property on the string.

        Remove isExtensibleImpl because it's only used in one place and call
        isStructureExtensible instead.

        * runtime/JSObject.cpp:
        (JSC::JSObject::isExtensible):
        * runtime/JSObject.h:
        (JSC::JSObject::isExtensibleImpl): Deleted.
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/StringObject.cpp:
        (JSC::StringObject::defineOwnProperty):

2018-12-13  Fujii Hironori  <Hironori.Fujii@sony.com>

        [WinCairo][Clang] DLLLauncherMain.cpp: warning: unused function 'prependPath' and 'appleApplicationSupportDirectory'
        https://bugs.webkit.org/show_bug.cgi?id=192688

        Reviewed by Ross Kirsling.

        These functions are used only in AppleWin port.

        * shell/DLLLauncherMain.cpp:
        (copyEnvironmentVariable): Moved.
        (getStringValue): Enclosed with #if !defined(WIN_CAIRO).
        (applePathFromRegistry): Ditto.
        (appleApplicationSupportDirectory): Ditto.
        (prependPath): Ditto.

2018-12-13  Dominik Infuehr  <dinfuehr@igalia.com>

        Improve GDB output for LLInt on Linux
        https://bugs.webkit.org/show_bug.cgi?id=192660

        Reviewed by Yusuke Suzuki.

        Annotate assembly code generated for LLInt with the bytecode operation. When debugging
        LLInt assembly code GDB is then able to show which bytecode instruction is implemented by
        the current assembly code. This also works for linux-perf.

        * llint/LowLevelInterpreter.cpp:
        * offlineasm/arm.rb:

2018-12-13  Mark Lam  <mark.lam@apple.com>

        Add a missing exception check.
        https://bugs.webkit.org/show_bug.cgi?id=192626
        <rdar://problem/46662163>

        Reviewed by Keith Miller.

        * runtime/ScopedArguments.h:

2018-12-13  Saam Barati  <sbarati@apple.com>

        The JSC shell should listen for memory pressure events and respond to them
        https://bugs.webkit.org/show_bug.cgi?id=192647

        Reviewed by Keith Miller.

        We want the JSC shell to behave more like the WebContent process when
        it comes to running performance tests. One way to make the shell
        more like this is to have it respond to memory pressure events in
        a similar way as the WebContent process. This makes it easier to run
        benchmarks like JetStream2 on the CLI on iOS.

        * jsc.cpp:
        (jscmain):
        * runtime/VM.cpp:
        (JSC::VM::drainMicrotasks):
        * runtime/VM.h:
        (JSC::VM::setOnEachMicrotaskTick):

2018-12-13  Mark Lam  <mark.lam@apple.com>

        Ensure that StructureFlags initialization always starts with Base::StructureFlags.
        https://bugs.webkit.org/show_bug.cgi?id=192686

        Reviewed by Keith Miller.

        This is purely a refactoring effort to make the code consistently start all
        StructureFlags initialization with Base::StructureFlags.  Previously, sometimes
        Base::StructureFlags is appended at the end, and sometimes, it is expressed using
        the name of the superclass.  This patch makes the code all consistent and easier
        to do a quick eye scan audit on to verify that no StructureFlags are forgetting
        to inherit Base::StructureFlags.

        Also added a static_assert in JSCallbackObject.h and JSBoundFunction.h.  Both of
        these implement a customHasInstance() method, and rely on ImplementsHasInstance
        being included in the StructureFlags, and conversely, ImplementsDefaultHasInstance
        has to be excluded.

        JSBoundFunction.h is the only case where a bit (ImplementsDefaultHasInstance)
        needs to be masked out of the inherited Base::StructureFlags.

        * API/JSCallbackObject.h:
        * runtime/ArrayConstructor.h:
        * runtime/ArrayIteratorPrototype.h:
        * runtime/Exception.h:
        * runtime/FunctionRareData.h:
        * runtime/InferredType.h:
        * runtime/InferredTypeTable.h:
        * runtime/InferredValue.h:
        * runtime/JSBoundFunction.h:
        * runtime/MapPrototype.h:
        * runtime/SetPrototype.h:
        * runtime/StringPrototype.h:
        * runtime/SymbolConstructor.h:

2018-12-13  Mark Lam  <mark.lam@apple.com>

        Add the JSC_traceBaselineJITExecution option for tracing baseline JIT execution.
        https://bugs.webkit.org/show_bug.cgi?id=192684

        Reviewed by Saam Barati.

        This dataLogs the bytecode execution order of baseline JIT code when the
        JSC_traceBaselineJITExecution option is true.

        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * runtime/Options.h:

2018-12-13  David Kilzer  <ddkilzer@apple.com>

        clang-tidy: Fix unnecessary object copies in JavaScriptCore
        <https://webkit.org/b/192680>
        <rdar://problem/46708767>

        Reviewed by Mark Lam.

        * assembler/testmasm.cpp:
        (JSC::invoke):
        - Make MacroAssemblerCodeRef<JSEntryPtrTag> argument a const
          reference.

        * b3/testb3.cpp:
        (JSC::B3::checkDisassembly):
        - Make CString argument a const reference.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStringEquality):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
        - Make JITCompiler::JumpList arguments a const reference.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::checkStructure):
        - Make RegisteredStructureSet argument a const reference.

        * jsc.cpp:
        (GlobalObject::moduleLoaderImportModule): Make local auto
        variables const references.
        (Workers::report): Make String argument a const reference.
        (addOption): Make Identifier argument a const reference.
        (runJSC): Make CString loop variable a const reference.

2018-12-13  Devin Rousso  <drousso@apple.com>

        Web Inspector: remove DOM.BackendNodeId and associated commands/events
        https://bugs.webkit.org/show_bug.cgi?id=192478

        Reviewed by Matt Baker.

        * inspector/protocol/DOM.json:

2018-12-13  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Add ValueDiv into DFG
        https://bugs.webkit.org/show_bug.cgi?id=186178

        Reviewed by Yusuke Suzuki.

        This patch is introducing a new node type called ValueDiv. This node
        is responsible to handle Untyped and Bigint specialization of division
        operator, while the ArithDiv variant handles Number/Boolean cases.

        BigInt specialization generates following speedup into simple
        benchmark:

                                  noSpec                 changes

        big-int-simple-div    10.6013+-0.4682    ^    8.4518+-0.0943   ^ definitely 1.2543x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeDivSafe):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupArithDiv):
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueDiv):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueDiv):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithDiv):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):

2018-12-13  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, build fix after r239153, part 2
        https://bugs.webkit.org/show_bug.cgi?id=190047

        * runtime/StructureRareDataInlines.h:
        (JSC::StructureRareData::cachedOwnKeys const):

2018-12-13  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, build fix after r239153
        https://bugs.webkit.org/show_bug.cgi?id=190047

        * runtime/StructureRareDataInlines.h:
        (JSC::StructureRareData::cachedOwnKeys const):

2018-12-10  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Optimize Object.keys by caching own keys results in StructureRareData
        https://bugs.webkit.org/show_bug.cgi?id=190047

        Reviewed by Keith Miller.

        Object.keys is one of the most frequently used function in web-tooling-benchmarks (WTB).
        Object.keys is dominant in lebab of WTB, and frequently called in babel and others.
        Since our Structure knows the shape of JSObject, we can cache the result of Object.keys
        in Structure (StructureRareData) as we cache JSPropertyNameEnumerator in StructureRareData.

        This patch caches the result of Object.keys in StructureRareData. The cached array is created
        as JSImmutableButterfly. And Object.keys creates CoW from this data. Currently, the lifetime
        strategy of this JSImmutableButterfly is the same to cached JSPropertyNameEnumerator. It is
        referenced from Structure, and collected when Structure is collected.

        This improves several benchmarks in SixSpeed.

                                        baseline                  patched

            object-assign.es5      350.1710+-3.6303     ^    226.0368+-4.7558        ^ definitely 1.5492x faster
            for-of-object.es6      269.1941+-3.3430     ^    127.9317+-2.3875        ^ definitely 2.1042x faster

        And it improves WTB lebab by 11.8%.

            Before: lebab:  6.10 runs/s
            After:  lebab:  6.82 runs/s

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToNewArrayBuffer):
        * dfg/DFGNode.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectKeys):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys):
        * runtime/Intrinsic.cpp:
        (JSC::intrinsicName):
        * runtime/Intrinsic.h:
        * runtime/JSImmutableButterfly.h:
        (JSC::JSImmutableButterfly::createSentinel):
        * runtime/ObjectConstructor.cpp:
        (JSC::ownPropertyKeys):
        * runtime/Structure.cpp:
        (JSC::Structure::canCachePropertyNameEnumerator const):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::setCachedOwnKeys):
        (JSC::Structure::cachedOwnKeys const):
        (JSC::Structure::canCacheOwnKeys const):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::visitChildren):
        (JSC::StructureRareData::cachedPropertyNameEnumerator const): Deleted.
        (JSC::StructureRareData::setCachedPropertyNameEnumerator): Deleted.
        * runtime/StructureRareData.h:
        * runtime/StructureRareDataInlines.h:
        (JSC::StructureRareData::cachedPropertyNameEnumerator const):
        (JSC::StructureRareData::setCachedPropertyNameEnumerator):
        (JSC::StructureRareData::cachedOwnKeys const):
        (JSC::StructureRareData::cachedOwnKeysConcurrently const):
        (JSC::StructureRareData::setCachedOwnKeys):
        (JSC::StructureRareData::previousID const): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2018-12-12  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [DFG][FTL] Add NewSymbol
        https://bugs.webkit.org/show_bug.cgi?id=192620

        Reviewed by Saam Barati.

        This patch introduces NewSymbol DFG node into DFG and FTL tiers. The main goal of this patch is not optimize
        NewSymbol code faster. Rather than that, this patch intends to offer SpecSymbol type information into DFG's
        data flow to optimize generated code in FTL backend.

        We add NewSymbol DFG node, which may take an argument. If an argument is not given, NewSymbol is for `Symbol()`.
        If an argument is given, ToString is emitted to this argument before passing it to NewSymbol. So NewSymbol node
        itself does not perform any type checks. ToString performs effects, but NewSymbol doesn't have any side observable
        effects. So we can decouple Symbol(description) call into NewSymbol(ToString(description)).

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGClobbersExitState.cpp:
        (JSC::DFG::clobbersExitState):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGMayExit.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewSymbol):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileNewSymbol):

2018-12-12  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [BigInt] Implement DFG/FTL typeof for BigInt
        https://bugs.webkit.org/show_bug.cgi?id=192619

        Reviewed by Keith Miller.

        This patch implements typeof for BigInt in DFG and FTL. Our DFG and FTL tiers now correctly consider about BigInt
        in the code generated for typeof.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::boolify): We add (SpecCell - SpecString) type filter for proven type since isString
        check is already performed here.
        (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf): We use (SpecCell - SpecObject - SpecString) type filter for proven type
        since String and Object are already checked here. If we know the proven type does not include Symbol type here, we
        can omit the code for Symbol type.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitTypeOf):

2018-12-11  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [BigInt] Simplify boolean context evaluation by leveraging JSString::offsetOfLength() == JSBigInt::offsetOfLength()
        https://bugs.webkit.org/show_bug.cgi?id=192615

        Reviewed by Saam Barati.

        JSString and JSBigInt have similar concept in terms of the implementation.
        Both are immutable, JSCells, and have length information. m_length is located
        just after JSCell header part, we can ensure `JSString::offsetOfLength() == JSBigInt::offsetOfLength()`,
        and it allows us to optimize the boolean context evaluation.

        This patch leverages the above information to reduce the code size for the boolean context evaluation.

        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitConvertValueToBoolean):
        (JSC::AssemblyHelpers::branchIfValue):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::JSBigInt):
        (JSC::JSBigInt::offsetOfLength): Deleted.
        * runtime/JSBigInt.h:

2018-12-11  Justin Michaud  <justin_michaud@apple.com>

        Implement feature flag for CSS Typed OM
        https://bugs.webkit.org/show_bug.cgi?id=192610

        Reviewed by Ryosuke Niwa.

        * Configurations/FeatureDefines.xcconfig:

2018-12-10  Don Olmstead  <don.olmstead@sony.com>

        Move ENABLE_RESOURCE_LOAD_STATISTICS to FeatureDefines.xcconfig
        https://bugs.webkit.org/show_bug.cgi?id=192573

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2018-12-10  Mark Lam  <mark.lam@apple.com>

        PropertyAttribute needs a CustomValue bit.
        https://bugs.webkit.org/show_bug.cgi?id=191993
        <rdar://problem/46264467>

        Reviewed by Saam Barati.

        This is because GetByIdStatus needs to distinguish CustomValue properties from
        other types, and its only means of doing so is via the property's attributes.
        Previously, there's nothing in the property's attributes that can indicate that
        the property is a CustomValue.

        We fix this by doing the following:

        1. Added a PropertyAttribute::CustomValue bit.
        2. Added a PropertyAttribute::CustomAccessorOrValue convenience bit mask that is
           CustomAccessor | CustomValue.

        3. Since CustomGetterSetter properties are only set via JSObject::putDirectCustomAccessor(),
           we added a check in JSObject::putDirectCustomAccessor() to see if the attributes
           bits include PropertyAttribute::CustomAccessor.  If not, then the property
           must be a CustomValue, and we'll add the PropertyAttribute::CustomValue bit
           to the attributes bits.

           This ensures that the property attributes is sufficient to tell us if the
           property contains a CustomGetterSetter.

        4. Updated all checks for PropertyAttribute::CustomAccessor to check for
           PropertyAttribute::CustomAccessorOrValue instead if their intent is to check
           for the presence of a CustomGetterSetter as opposed to checking specifically
           for one that is used as a CustomAccessor.

           This includes all the Structure transition code that needs to capture the
           attributes change when a CustomValue has been added.

        5. Filtered out the PropertyAttribute::CustomValue bit in PropertyDescriptor.
           The fact that we're using a CustomGetterSetter as a CustomValue should remain
           invisible to the descriptor.  This is because the descriptor should describe
           a CustomValue no differently from a plain value.

        6. Added some asserts to ensure that property attributes are as expected, and to
           document some invariants.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/InByIdStatus.cpp:
        (JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * runtime/JSFunction.cpp:
        (JSC::getCalculatedDisplayName):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectCustomAccessor):
        (JSC::JSObject::putDirectNonIndexAccessor):
        (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectIndex):
        (JSC::JSObject::fillCustomGetterPropertySlot):
        (JSC::JSObject::putDirect):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::putDirectInternal):
        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::setDescriptor):
        (JSC::PropertyDescriptor::setCustomDescriptor):
        (JSC::PropertyDescriptor::setAccessorDescriptor):
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::setCustomGetterSetter):

2018-12-10  Mark Lam  <mark.lam@apple.com>

        LinkBuffer::copyCompactAndLinkCode() needs to be aware of ENABLE(SEPARATED_WX_HEAP).
        https://bugs.webkit.org/show_bug.cgi?id=192569
        <rdar://problem/45615617>

        Reviewed by Saam Barati.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):

2018-12-10  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Add ValueMul into DFG
        https://bugs.webkit.org/show_bug.cgi?id=186175

        Reviewed by Yusuke Suzuki.

        This patch is adding a new DFG node called ValueMul. This node is
        responsible to handle multiplication operations that can result into
        non-number values. We emit such node during DFGByteCodeParser when the
        operands are not numbers. During FixupPhase, we change this
        operation to ArithMul if we can speculate Number/Boolean operands.

        The BigInt specialization shows a small progression:

                                noSpec                changes

        big-int-simple-mul  18.8090+-1.0435  ^  17.4305+-0.2673  ^ definitely 1.0791x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupMultiplication):
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueMul):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):

2018-12-08  Mark Lam  <mark.lam@apple.com>

        Reduce size of PropertySlot and PutPropertySlot.
        https://bugs.webkit.org/show_bug.cgi?id=192526

        Reviewed by Keith Miller.

        With some minor adjustments, we can reduce the size of PropertySlot from 80 bytes
        (19 padding bytes) to 64 bytes (3 padding bytes), and PutPropertySlot from 40
        bytes (4 padding bytes) to 32 bytes (0 padding bytes but with 6 unused bits).
        These measurements are for a 64-bit build.

        * runtime/PropertySlot.h:
        * runtime/PutPropertySlot.h:
        (JSC::PutPropertySlot::PutPropertySlot):

2018-12-08  Dominik Infuehr  <dinfuehr@igalia.com>

        Record right offset with aligned wide instructions
        https://bugs.webkit.org/show_bug.cgi?id=192006

        Reviewed by Yusuke Suzuki.

        Aligning bytecode instructions inserts nops into the instruction stream.
        Emitting an instruction did not record the actual start of the instruction with
        aligned instructions, but the nop just before the actual instruction. This was
        problematic with the StaticPropertyAnalyzer that used the wrong instruction offset.

        * bytecode/InstructionStream.h:
        (JSC::InstructionStream::MutableRef::clone):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::alignWideOpcode):
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitNewObject):
        * generator/Opcode.rb:

2018-12-07  Tadeu Zagallo  <tzagallo@apple.com>

        Align the metadata table on all platforms
        https://bugs.webkit.org/show_bug.cgi?id=192050
        <rdar://problem/46312674>

        Reviewed by Mark Lam.

        Although certain platforms don't require the metadata to be aligned,
        values were being concurrently read and written to ValueProfiles,
        which caused crashes since these operations are not atomic on unaligned
        addresses.

        * bytecode/Opcode.cpp:
        (JSC::metadataAlignment):
        * bytecode/Opcode.h:
        * bytecode/UnlinkedMetadataTableInlines.h:
        (JSC::UnlinkedMetadataTable::finalize):

2018-12-05  Mark Lam  <mark.lam@apple.com>

        speculationFromCell() should speculate non-Identifier strings as SpecString instead of SpecStringVar.
        https://bugs.webkit.org/show_bug.cgi?id=192441
        <rdar://problem/46480355>

        Reviewed by Saam Barati.

        This is because a regular String (non-Identifier) can be converted into an
        Identifier.  During DFG/FTL compilation, AbstractValue::checkConsistency() may
        expect a value to be of type SpecStringVar, but the mutator thread may have
        converted the string into an Identifier.  This creates a race where
        AbstractValue::checkConsistency() may fail because it sees a SpecStringIdent when
        it expects the a SpecStringVar.  

        The fix is to speculate non-Identifier strings as type SpecString which allows it
        to be SpecStringVar or SpecStringIndent.

        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromCell):

2018-12-04  Mark Lam  <mark.lam@apple.com>

        DFG's StrengthReduction phase should not reduce Construct into DirectContruct when the executable does not have constructAbility.
        https://bugs.webkit.org/show_bug.cgi?id=192386
        <rdar://problem/46445516>

        Reviewed by Saam Barati.

        This violates an invariant documented by a RELEASE_ASSERT in operationLinkDirectCall().

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

2018-12-04  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Support logic operations
        https://bugs.webkit.org/show_bug.cgi?id=179903

        Reviewed by Yusuke Suzuki.

        We are introducing in this patch the ToBoolean support for JSBigInt.
        With this change, we can implement the correct behavior of BigInt as
        operand of logical opertions. During JIT genertion into DFG and FTL,
        we are using JSBigInt::m_length to verify if the number is 0n or not,
        following the same approach used by JSString. This is also safe in the case
        of BigInt, because only 0n has m_length == 0.

        We are not including BigInt speculation into Branch nodes in this
        patch, but the plan is to implement it in further patches.

        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::isBigInt):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitConvertValueToBoolean):
        (JSC::AssemblyHelpers::branchIfValue):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::isZero const):
        (JSC::JSBigInt::offsetOfLength):
        (JSC::JSBigInt::toBoolean const):
        (JSC::JSBigInt::isZero): Deleted.
        * runtime/JSBigInt.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::toBoolean const):
        (JSC::JSCell::pureToBoolean const):

2018-12-04  Devin Rousso  <drousso@apple.com>

        Web Inspector: Audit: tests should support async operations
        https://bugs.webkit.org/show_bug.cgi?id=192171
        <rdar://problem/46423562>

        Reviewed by Joseph Pecoraro.

        Add `awaitPromise` command for executing a callback when a Promise gets settled.

        Drive-by: allow `wasThrown` to be optional, instead of expecting it to always have a value.

        * inspector/protocol/Runtime.json:

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype.awaitPromise): Added.

        * inspector/InjectedScript.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::evaluate):
        (Inspector::InjectedScript::awaitPromise): Added.
        (Inspector::InjectedScript::callFunctionOn):
        (Inspector::InjectedScript::evaluateOnCallFrame):

        * inspector/InjectedScriptBase.h:
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeEvalCall):
        (Inspector::InjectedScriptBase::makeAsyncCall): Added.
        (Inspector::InjcetedScriptBase::checkCallResult): Added.
        (Inspector::InjcetedScriptBase::checkAsyncCallResult): Added.

        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::evaluate):
        (Inspector::InspectorRuntimeAgent::awaitPromise):
        (Inspector::InspectorRuntimeAgent::callFunctionOn):

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):

2018-12-03  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r238833.

        Breaks macOS and iOS debug builds.

        Reverted changeset:

        "[ESNext][BigInt] Support logic operations"
        https://bugs.webkit.org/show_bug.cgi?id=179903
        https://trac.webkit.org/changeset/238833

2018-12-03  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Support logic operations
        https://bugs.webkit.org/show_bug.cgi?id=179903

        Reviewed by Yusuke Suzuki.

        We are introducing in this patch the ToBoolean support for JSBigInt.
        With this change, we can implement the correct behavior of BigInt as
        operand of logical opertions. During JIT genertion into DFG and FTL,
        we are using JSBigInt::m_length to verify if the number is 0n or not,
        following the same approach used by JSString. This is also safe in the case
        of BigInt, because only 0n has m_length == 0.

        We are not including BigInt speculation into Branch nodes in this
        patch, but the plan is to implement it in further patches.

        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::boolify):
        (JSC::FTL::DFG::LowerDFGToB3::isBigInt):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitConvertValueToBoolean):
        (JSC::AssemblyHelpers::branchIfValue):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::isZero const):
        (JSC::JSBigInt::offsetOfLength):
        (JSC::JSBigInt::toBoolean const):
        (JSC::JSBigInt::isZero): Deleted.
        * runtime/JSBigInt.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::toBoolean const):
        (JSC::JSCell::pureToBoolean const):

2018-12-03  Keith Rollin  <krollin@apple.com>

        Add .xcfilelist files
        https://bugs.webkit.org/show_bug.cgi?id=192082
        <rdar://problem/46312533>

        Reviewed by Brent Fulgham.

        Add .xcfilelist files for Generate Derived Sources and Generate
        Unified Sources build phases in Xcode. These are just being staged for
        now; they'll be added to the Xcode projects later.

        * DerivedSources-input.xcfilelist: Added.
        * DerivedSources-output.xcfilelist: Added.
        * UnifiedSources-input.xcfilelist: Added.
        * UnifiedSources-output.xcfilelist: Added.

2018-12-03  Mark Lam  <mark.lam@apple.com>

        Fix the bytecode code generator scripts to pretty print BytecodeStructs.h and BytecodeIndices.h.
        https://bugs.webkit.org/show_bug.cgi?id=192271

        Reviewed by Keith Miller.

        This makes the generated code style compliant and human readable.

        * generator/Argument.rb:
        * generator/DSL.rb:
        * generator/Fits.rb:
        * generator/Metadata.rb:
        * generator/Opcode.rb:

2018-12-02  Zalan Bujtas  <zalan@apple.com>

        Add a runtime feature flag for LayoutFormattingContext.
        https://bugs.webkit.org/show_bug.cgi?id=192280

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2018-12-02  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Implement support for "<<" and ">>"
        https://bugs.webkit.org/show_bug.cgi?id=186233

        Reviewed by Yusuke Suzuki.

        This patch is introducing the support for BigInt into lshift and
        rshift into LLint and Baseline layers.

        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::createWithLength):
        (JSC::JSBigInt::leftShift):
        (JSC::JSBigInt::signedRightShift):
        (JSC::JSBigInt::leftShiftByAbsolute):
        (JSC::JSBigInt::rightShiftByAbsolute):
        (JSC::JSBigInt::rightShiftByMaximum):
        (JSC::JSBigInt::toShiftAmount):
        * runtime/JSBigInt.h:

2018-12-01  Simon Fraser  <simon.fraser@apple.com>

        Heap.h refers to the non-existent HeapStatistics
        https://bugs.webkit.org/show_bug.cgi?id=187882

        Reviewed by Keith Miller.
        
        Just remove the "friend class HeapStatistics".

        * heap/Heap.h:

2018-11-29  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Keep TypeMaybeBigInt small
        https://bugs.webkit.org/show_bug.cgi?id=192203

        Reviewed by Saam Barati.

        As BigInt is being implemented, more and more bytecodes start returning BigInt.
        It means that ResultType of these bytecodes include TypeMaybeBigInt. However,
        TypeMaybeBigInt was large number 0x20, leading to wide instruction since ResultType
        easily becomes larger than 32 (e.g. TypeInt32 | TypeMaybeBigInt == 33).

        This patch sorts the numbers of TypeMaybeXXX based on the frequency of appearance in
        the code.

        * parser/ResultType.h:

2018-11-30  Dean Jackson  <dino@apple.com>

        Try to fix Windows build by using strcmp instead of strcasecmp.

        * jsc.cpp:
        (isMJSFile):

2018-11-30  Mark Lam  <mark.lam@apple.com>

        Fix the bytecode code generator scripts to pretty print Bytecodes.h.
        https://bugs.webkit.org/show_bug.cgi?id=192258

        Reviewed by Keith Miller.

        This makes Bytecodes.h more human readable.

        * generator/DSL.rb:
        * generator/Section.rb:

2018-11-30  Mark Lam  <mark.lam@apple.com>

        Add the generator directory to the Xcode project.
        https://bugs.webkit.org/show_bug.cgi?id=192252

        Reviewed by Michael Saboff.

        This is so that we can work with these bytecode class generator files easily in Xcode.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2018-11-30  Don Olmstead  <don.olmstead@sony.com>

        Rename ENABLE_SUBTLE_CRYPTO to ENABLE_WEB_CRYPTO
        https://bugs.webkit.org/show_bug.cgi?id=192197

        Reviewed by Jiewen Tan.

        * Configurations/FeatureDefines.xcconfig:

2018-11-30  Dean Jackson  <dino@apple.com>

        Add first-class support for .mjs files in jsc binary
        https://bugs.webkit.org/show_bug.cgi?id=192190
        <rdar://problem/46375715>

        Reviewed by Keith Miller.

        Treat files with a .mjs extension as a module, regardless
        of whether or not the --module-file argument was given.

        * jsc.cpp:
        (printUsageStatement): Update usage.
        (isMJSFile): Helper to look for .mjs extensions.
        (CommandLine::parseArguments): Pick the appropriate script type.

2018-11-30  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Implement ValueBitXor into DFG
        https://bugs.webkit.org/show_bug.cgi?id=190264

        Reviewed by Yusuke Suzuki.

        This patch is splitting the BitXor node into ArithBitXor and
        ValueBitXor. This is necessary due the introduction of
        BigInt, since BitXor operations now can result into Int32 or BigInt.
        In such case, we use ArithBitXor when operands are Int and fallback to
        ValueBitXor when operands are anything else. In the case of
        ValueBitXor, we speculate BigInt when op1 and op2 are predicted as
        BigInt as well. BigInt specialization consist into call
        `operationBigIntBitXor` function, that calls JSBigInt::bitXor.

        * bytecode/BytecodeList.rb:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::arithProfileForPC):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
        (JSC::DFG::SpeculativeJIT::compileBitwiseOp):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::bitOp):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueBitXor):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithBitXor):
        (JSC::FTL::DFG::LowerDFGToB3::compileBitXor): Deleted.
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_bitxor):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2018-11-29  Justin Michaud  <justin_michaud@apple.com>

        CSS Painting API should pass 'this' correctly to paint callback, and repaint when properties change.
        https://bugs.webkit.org/show_bug.cgi?id=191443

        Reviewed by Dean Jackson.

        Export the simpler construct() method for use in WebCore.

        * runtime/ConstructData.h:

2018-11-28  Mark Lam  <mark.lam@apple.com>

        ENABLE_SEPARATED_WX_HEAP needs to be defined in Platform.h.
        https://bugs.webkit.org/show_bug.cgi?id=192110
        <rdar://problem/46317746>

        Reviewed by Saam Barati.

        * config.h:

2018-11-28  Keith Rollin  <krollin@apple.com>

        Update generate-{derived,unified}-sources scripts to support generating .xcfilelist files
        https://bugs.webkit.org/show_bug.cgi?id=192031
        <rdar://problem/46286816>

        Reviewed by Alex Christensen.

        The Generate Derived Sources and Generate Unified Sources build phases
        in Xcode need to have their inputs and outputs specified. This
        specification will come in the form of .xcfilelist files that will be
        attached to these build phases. There is one .xcfilelist file that
        lists the input file and one that lists the output files. As part of
        this work, the various generate-{derived,unified}-sources scripts that
        are executed in these Generate build phases are modified to help in
        the creation of these .xcfilelist files. In particular, they can now
        be invoked with command-line parameters. These parameters are then
        used to alter the normal execution of these scripts, causing them to
        produce the .xcfilelist files as opposed to actually generating the
        files that are listed in those files.

        * Scripts/generate-derived-sources.sh:
        * Scripts/generate-unified-sources.sh:

2018-11-28  Keith Rollin  <krollin@apple.com>

        Revert print_all_generated_files work in r238008; tighten up target specifications
        https://bugs.webkit.org/show_bug.cgi?id=192025
        <rdar://problem/46284301>

        Reviewed by Alex Christensen.

        In r238008, I added a facility for DerivedSources.make makefiles to
        print out the list of files that they generate. This output was used
        in the generation of .xcfilelist files used to specify the output of
        the associated Generate Derived Sources build phases in Xcode. This
        approach worked, but it meant that people would need to follow a
        specific convention to keep this mechanism working.

        Instead of continuing this approach, I'm going to implement a new
        facility based on the output of `make` when passed the -d flag (which
        prints dependency information). This new mechanism is completely
        automatic and doesn't need maintainers to follow a convention. To that
        end, remove most of the work performed in r238008 that supports the
        print_all_generated_files target.

        At the same time, it's important for the sets of targets and their
        dependencies to be complete and correct. Therefore, also include
        changes to bring those up-to-date. As part of that, you'll see
        prevalent use of a particular technique. Here's an example:

            BYTECODE_FILES = \
                Bytecodes.h \
                BytecodeIndices.h \
                BytecodeStructs.h \
                InitBytecodes.asm \
            #
            BYTECODE_FILES_PATTERNS = $(subst .,%,$(BYTECODE_FILES))

            all : $(BYTECODE_FILES)

            $(BYTECODE_FILES_PATTERNS): $(wildcard $(JavaScriptCore)/generator/*.rb) $(JavaScriptCore)/bytecode/BytecodeList.rb
                ...

        These lines indicate a set of generated files (those specified in
        BYTECODE_FILES). These files are generated by the BytecodeList.rb
        tool. But, as opposed to the normal rule where a single foo.output is
        generated by foo.input plus some additional dependencies, this rule
        produces multiple output files from a tool whose connection to the
        output files is not immediately clear. A special approach is needed
        where a single rule produces multiple output files. The normal way to
        implement this is to use an .INTERMEDIATE target. However, we used
        this approach in the past and ran into a problem with it, addressing
        it with an alternate approach in r210507. The above example shows this
        approach. The .'s in the list of target files are replaced with %'s,
        and the result is used as the left side of the dependency rule.

        * DerivedSources.make:

2018-11-28  Keith Rollin  <krollin@apple.com>

        Remove Postprocess Headers dependencies
        https://bugs.webkit.org/show_bug.cgi?id=192023
        <rdar://problem/46283377>

        Reviewed by Mark Lam.

        JavaScriptCore's Xcode Postprocess Headers build phase used to have a
        dependency on a specific handful of files. In r234227, the script used
        in this phase (postprocess-headers.sh) was completely rewritten to
        operate on *all* files in JSC's Public and Private headers directories
        instead of just this handful. This rewrite makes the previous
        dependency specification insufficient, leading to incorrect
        incremental builds if the right files weren't touched. Address this by
        removing the dependencies completely. This will cause
        postprocess-headers.sh to always be executed, even when none of its
        files are touch. Running this script all the time is OK, since it has
        built-in protections against unnecessarily touching files that haven't
        changed.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2018-11-27  Mark Lam  <mark.lam@apple.com>

        ENABLE_FAST_JIT_PERMISSIONS should be false for iosmac.
        https://bugs.webkit.org/show_bug.cgi?id=192055
        <rdar://problem/46288783>

        Reviewed by Saam Barati.

        * Configurations/FeatureDefines.xcconfig:

2018-11-27  Saam barati  <sbarati@apple.com>

        r238510 broke scopes of size zero
        https://bugs.webkit.org/show_bug.cgi?id=192033
        <rdar://problem/46281734>

        Reviewed by Keith Miller.

        In r238510, I wrote the loop like this: 
        `for (ScopeOffset offset { 0 }; offset <= symbolTable->maxScopeOffset(); offset += 1)`
        
        This breaks for scopes of size zero because maxScopeOffset() will be UINT_MAX.
        
        This patch fixes this by writing the loop as:
        `for (unsigned offset = 0; offset < symbolTable->scopeSize(); ++offset)`

        * dfg/DFGObjectAllocationSinkingPhase.cpp:

2018-11-27  Mark Lam  <mark.lam@apple.com>

        ASSERTION FAILED: capacity && isPageAligned(capacity) in JSC::CLoopStack::CLoopStack(JSC::VM&).
        https://bugs.webkit.org/show_bug.cgi?id=192018

        Reviewed by Saam Barati.

        This assertion failed because the regress-191579.js test was specifying
        --maxPerThreadStackUsage=400000 i.e. it was running with a stack size that is not
        page aligned.  Given that the user can specify any arbitrary stack size, and the
        CLoop stack expects to be page aligned, we'll just round up the requested capacity
        to the next page alignment.

        * interpreter/CLoopStack.cpp:
        (JSC::CLoopStack::CLoopStack):

2018-11-27  Mark Lam  <mark.lam@apple.com>

        [Re-landing] NaNs read from Wasm code needs to be be purified.
        https://bugs.webkit.org/show_bug.cgi?id=191056
        <rdar://problem/45660341>

        Reviewed by Filip Pizlo.

        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):

2018-11-27  Timothy Hatcher  <timothy@apple.com>

        Web Inspector: Add support for forcing color scheme appearance in DOM tree.
        https://bugs.webkit.org/show_bug.cgi?id=191820
        rdar://problem/46153172

        Reviewed by Devin Rousso.

        * inspector/protocol/Page.json: Added setForcedAppearance.
        Also added the defaultAppearanceDidChange event and Appearance enum.

2018-11-27  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r238509.

        Causes JSC tests to fail on iOS.

        Reverted changeset:

        "NaNs read from Wasm code needs to be be purified."
        https://bugs.webkit.org/show_bug.cgi?id=191056
        https://trac.webkit.org/changeset/238509

2018-11-27  Mark Lam  <mark.lam@apple.com>

        Introducing a ENABLE_SEPARATED_WX_HEAP macro.
        https://bugs.webkit.org/show_bug.cgi?id=192013
        <rdar://problem/45494310>

        Reviewed by Keith Miller.

        This makes the code a little more readable.

        I put the definition of ENABLE_SEPARATED_WX_HEAP in JSC's config.h instead of
        Platform.h because ENABLE_SEPARATED_WX_HEAP is only needed inside JSC.  Also,
        ENABLE_SEPARATED_WX_HEAP depends on ENABLE(FAST_JIT_PERMISSIONS), which is only
        defined for JSC.

        * config.h:
        * jit/ExecutableAllocator.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2018-11-26  Caio Lima  <ticaiolima@gmail.com>

        Re-introduce op_bitnot
        https://bugs.webkit.org/show_bug.cgi?id=190923

        Reviewed by Yusuke Suzuki.

        With the introduction of BigInt as a new type, we can't emit bitwise
        not as `x ^ -1` anymore, because this is incompatible with the new type.
        Based on that, this Patch is adding `op_bitnot` as a new operation
        into LLInt, as well as introducing ArithBitNot node into DFG to support
        JIT compilation of such opcode. We will use the ValueProfile of this
        intruction in the future to generate better code when its operand
        is not Int32.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::not32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::not32):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::not32):
        * bytecode/BytecodeList.rb:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitUnaryOp):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::UnaryPlusNode::emitBytecode):
        (JSC::BitwiseNotNode::emitBytecode): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileBitwiseNot):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_bitnot):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/cloop.rb:
        * parser/NodeConstructors.h:
        (JSC::BitwiseNotNode::BitwiseNotNode):
        * parser/Nodes.h:
        * parser/ResultType.h:
        (JSC::ResultType::bigIntOrInt32Type):
        (JSC::ResultType::forBitOp):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:

2018-11-26  Saam barati  <sbarati@apple.com>

        InPlaceAbstractState::endBasicBlock rule for SetLocal should filter the value based on the flush format
        https://bugs.webkit.org/show_bug.cgi?id=191956
        <rdar://problem/45665806>

        Reviewed by Yusuke Suzuki.

        This is a similar bug to what Keith fixed in r232134. The issue is if we have
        a program like this:
        
        a: JSConstant(jsNumber(0))
        b: SetLocal(Int32:@a, loc1, FlushedInt32)
        c: ArrayifyToStructure(Cell:@a)
        d: Jump(...)
        
        At the point in the program right after the Jump, a GetLocal for loc1
        would return whatever the ArrayifyToStructure resulting type is. This breaks
        the invariant that a GetLocal must return a value that is a subtype of its
        FlushFormat. InPlaceAbstractState::endBasicBlock will know if a SetLocal is
        the final node touching a local slot. If so, it'll see if any nodes later
        in the block may have refined the type of the value stored in that slot. If
        so, endBasicBlock() further refines the type to ensure that any GetLocals
        loading from the same slot will result in having this more refined type.
        However, we must ensure that this logic only considers types within the
        hierarchy of the variable access data's FlushFormat, otherwise, we may
        break the invariant that a GetLocal's type is a subtype of its FlushFormat.

        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):

2018-11-26  Saam barati  <sbarati@apple.com>

        Object allocation sinking phase needs to iterate each scope offset instead of just iterating the symbol table's hashmap when handling an activation
        https://bugs.webkit.org/show_bug.cgi?id=191958
        <rdar://problem/46221877>

        Reviewed by Yusuke Suzuki.

        There may be more entries in an activation than unique variables
        in a symbol table's hashmap. For example, if you have two parameters
        to a function, and they both are the same name, and the function
        uses eval, we'll end up with two scope slots, but only a single
        entry in the hashmap in the symbol table. Object allocation sinking
        phase was previously iterating over the hashmap, assuming these
        values were equivalent. This is wrong in the above case. Instead,
        we need to iterate over each scope offset.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * runtime/GenericOffset.h:
        (JSC::GenericOffset::operator+=):
        (JSC::GenericOffset::operator-=):

2018-11-26  Mark Lam  <mark.lam@apple.com>

        NaNs read from Wasm code needs to be be purified.
        https://bugs.webkit.org/show_bug.cgi?id=191056
        <rdar://problem/45660341>

        Reviewed by Filip Pizlo.

        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):

2018-11-26  Tadeu Zagallo  <tzagallo@apple.com>

        ASSERTION FAILED: m_outOfLineJumpTargets.contains(bytecodeOffset)
        https://bugs.webkit.org/show_bug.cgi?id=191716
        <rdar://problem/45723878>

        Reviewed by Saam Barati.

        After https://bugs.webkit.org/show_bug.cgi?id=187373, when updating
        jump targets during generatorification, we only stored the new jump
        target when it changed. However, the out-of-line jump targets are
        cleared at the beginning of the pass, so we need to store it
        unconditionally.

        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::extractStoredJumpTargetsForInstruction):
        (JSC::updateStoredJumpTargetsForInstruction):

2018-11-23  Wenson Hsieh  <wenson_hsieh@apple.com>

        Enable drag and drop support for iOSMac
        https://bugs.webkit.org/show_bug.cgi?id=191818
        <rdar://problem/43907454>

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig:

2018-11-22  Mark Lam  <mark.lam@apple.com>

        Make the jsc shell's dumpException() more robust against long exception strings.
        https://bugs.webkit.org/show_bug.cgi?id=191910
        <rdar://problem/46212980>

        Reviewed by Michael Saboff.

        This only affects the dumping of the exception string in the jsc shell due to
        unhandled exceptions or exceptions at shell boot time before any JS code is
        running.

        * jsc.cpp:
        (dumpException):

2018-11-21  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Drop ARM_TRADITIONAL support in LLInt, baseline JIT, and DFG
        https://bugs.webkit.org/show_bug.cgi?id=191675

        Reviewed by Mark Lam.

        We no longer maintain ARM_TRADITIONAL LLInt and JIT in JSC. This architecture will use
        CLoop instead. This patch removes ARM_TRADITIONAL support in LLInt and JIT.

        Discussed in https://lists.webkit.org/pipermail/webkit-dev/2018-October/030220.html.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/ARMAssembler.cpp: Removed.
        * assembler/ARMAssembler.h: Removed.
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::linkCode):
        (JSC::LinkBuffer::dumpCode):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::patchableBranch32):
        * assembler/MacroAssemblerARM.cpp: Removed.
        * assembler/MacroAssemblerARM.h: Removed.
        * assembler/PerfLog.cpp:
        * assembler/PerfLog.h:
        * assembler/ProbeContext.h:
        (JSC::Probe::CPUState::pc):
        (JSC::Probe::CPUState::fp):
        (JSC::Probe::CPUState::sp):
        * assembler/testmasm.cpp:
        (JSC::isPC):
        (JSC::testProbeModifiesStackPointer):
        (JSC::testProbeModifiesStackValues):
        * bytecode/InlineAccess.h:
        (JSC::InlineAccess::sizeForPropertyAccess):
        (JSC::InlineAccess::sizeForPropertyReplace):
        (JSC::InlineAccess::sizeForLengthAccess):
        * dfg/DFGSpeculativeJIT.h:
        * disassembler/CapstoneDisassembler.cpp:
        (JSC::tryToDisassemble):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::debugCall):
        * jit/AssemblyHelpers.h:
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsImpl):
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::prepareForTailCall):
        * jit/HostCallReturnValue.cpp:
        * jit/JITMathIC.h:
        (JSC::isProfileEmpty):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::reservedHardwareRegisters):
        (JSC::RegisterSet::calleeSaveRegisters):
        (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
        (JSC::RegisterSet::dfgCalleeSaveRegisters):
        * jit/Repatch.cpp:
        (JSC::forceICFailure):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * offlineasm/arm.rb:
        * offlineasm/backends.rb:
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::generateEnter):
        (JSC::Yarr::YarrGenerator::generateReturn):

2018-11-21  Saam barati  <sbarati@apple.com>

        DFGSpeculativeJIT should not &= exitOK with mayExit(node)
        https://bugs.webkit.org/show_bug.cgi?id=191897
        <rdar://problem/45871998>

        Reviewed by Mark Lam.

        exitOK is a statement about it being legal to exit. mayExit() is about being
        conservative and returning false only if an OSR exit *could never* happen.
        mayExit() tries to be as smart as possible to see if it can return false.
        It can't return false if a runtime exit *could* happen. However, there is
        code in the compiler where mayExit() returns false (because it uses data
        generated from AI about type checks being proved), but the code we emit in the
        compiler backend unconditionally generates an OSR exit, even if that exit may
        never execute. For example, let's say we have this IR:
        
        SomeNode(Boolean:@input)
        
        And we always emit code like this as a way of emitting a boolean type check:
        
        jump L1 if input == true
        jump L1 if input == false
        emit an OSR exit
        
        In such a program, when we generate the above OSR exit, in a validationEnabled()
        build, and if @input is proved to be a boolean, we'll end up crashing because we
        have the bogus assertion saying !exitOK. This is one reason why things are cleaner
        if we don't conflate mayExit() with exitOK.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):

2018-11-21  Saam barati  <sbarati@apple.com>

        Fix assertion in KnownCellUse inside SpeculativeJIT::speculate
        https://bugs.webkit.org/show_bug.cgi?id=191895
        <rdar://problem/46167406>

        Reviewed by Mark Lam.

        We were asserting that the input edge should have type SpecCell but it should
        really be SpecCellCheck since the type filter for KnownCellUse is SpecCellCheck.
        
        This patch cleans up that assertion code by joining a bunch of cases into a
        single function call which grabs the type filter for the edge UseKind and
        asserts that the incoming edge meets the type filter criteria.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculate):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::speculate):

2018-11-21  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Use ProtoCallFrame::numberOfRegisters instead of raw number `4`
        https://bugs.webkit.org/show_bug.cgi?id=191877

        Reviewed by Sam Weinig.

        Instead of hard-coding `4` into LowLevelInterpreter, use ProtoCallFrame::numberOfRegisters.

        * interpreter/ProtoCallFrame.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2018-11-21  Mark Lam  <mark.lam@apple.com>

        Creating a wasm memory that is bigger than the ArrayBuffer limit but smaller than the spec limit should throw OOME not RangeError.
        https://bugs.webkit.org/show_bug.cgi?id=191776
        <rdar://problem/46152851>

        Reviewed by Saam Barati.

        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::tryCreate):
        - return nullptr if the requested bytes exceed MAX_ARRAY_BUFFER_SIZE.
          The clients will already do a null check and throw an OutOfMemoryError if needed.
        (JSC::Wasm::Memory::grow):
        - throw OOME if newPageCount.bytes() > MAX_ARRAY_BUFFER_SIZE.
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        - throw OOME if newPageCount.bytes() > MAX_ARRAY_BUFFER_SIZE.

2018-11-21  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength
        https://bugs.webkit.org/show_bug.cgi?id=190836

        Reviewed by Saam Barati and Yusuke Suzuki.

        In this patch we are creating a new method called `JSBigInt::createWithLengthUnchecked`
        where we allocate a BigInt trusting the length received as argument.
        With this additional method, we now check if length passed to
        `JSBigInt::tryCreateWithLength` is not greater than JSBigInt::maxLength.
        When the length is greater than JSBigInt::maxLength, we then throw OOM
        exception.
        This required us to change the interface of some JSBigInt operations to
        receive `ExecState*` instead of `VM&`. We changed only operations that
        can throw because of OOM.
        We beleive that this approach of throwing instead of finishing the
        execution abruptly is better because JS programs can catch such
        exception and handle this issue properly.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::createZero):
        (JSC::JSBigInt::tryCreateWithLength):
        (JSC::JSBigInt::createWithLengthUnchecked):
        (JSC::JSBigInt::createFrom):
        (JSC::JSBigInt::multiply):
        (JSC::JSBigInt::divide):
        (JSC::JSBigInt::copy):
        (JSC::JSBigInt::unaryMinus):
        (JSC::JSBigInt::remainder):
        (JSC::JSBigInt::add):
        (JSC::JSBigInt::sub):
        (JSC::JSBigInt::bitwiseAnd):
        (JSC::JSBigInt::bitwiseOr):
        (JSC::JSBigInt::bitwiseXor):
        (JSC::JSBigInt::absoluteAdd):
        (JSC::JSBigInt::absoluteSub):
        (JSC::JSBigInt::absoluteDivWithDigitDivisor):
        (JSC::JSBigInt::absoluteDivWithBigIntDivisor):
        (JSC::JSBigInt::absoluteLeftShiftAlwaysCopy):
        (JSC::JSBigInt::absoluteBitwiseOp):
        (JSC::JSBigInt::absoluteAddOne):
        (JSC::JSBigInt::absoluteSubOne):
        (JSC::JSBigInt::toStringGeneric):
        (JSC::JSBigInt::rightTrim):
        (JSC::JSBigInt::allocateFor):
        (JSC::JSBigInt::createWithLength): Deleted.
        * runtime/JSBigInt.h:
        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):
        * runtime/Operations.h:
        (JSC::jsSub):
        (JSC::jsMul):

2018-11-20  Mark Lam  <mark.lam@apple.com>

        Remove invalid assertion in VMTraps::SignalSender's SignalAction.
        https://bugs.webkit.org/show_bug.cgi?id=191856
        <rdar://problem/46089992>

        Reviewed by Yusuke Suzuki.

        The ASSERT(vm.traps().needTrapHandling()) assertion in SignalSender's SigAction
        function is invalid because we can't be sure that the trap has been handled yet
        by the time the trap fires.  This is because the main thread may also check traps
        (in LLInt, baseline JIT and VM runtime code).  There's a race to handle the trap.
        Hence, the SigAction cannot assume that the trap still needs handling by the time
        it is executed.  This patch removed the invalid assertion.

        Also renamed m_trapSet to m_condition because it is a AutomaticThreadCondition,
        and all the ways it is used is as a condvar.  The m_trapSet name doesn't seem
        appropriate nor meaningful.

        * runtime/VMTraps.cpp:
        (JSC::VMTraps::tryInstallTrapBreakpoints):
        - Added a !needTrapHandling() check as an optimization: there's no need to install
          VMTrap breakpoints if someone already beat us to handling the trap (remember,
          the main thread is racing against the VMTraps signalling thread to handle the
          trap too).  We only need to install the VMTraps breakpoints if we need DFG/FTL
          compiled code to deopt so that they can check and handle pending traps.  If the
          trap has already been handled, it's better to not deopt any DFG/FTL functions.

        (JSC::VMTraps::willDestroyVM):
        (JSC::VMTraps::fireTrap):
        (JSC::VMTraps::VMTraps):
        * runtime/VMTraps.h:

2018-11-21  Dominik Infuehr  <dinfuehr@igalia.com>

        Enable JIT on ARM/Linux
        https://bugs.webkit.org/show_bug.cgi?id=191548

        Reviewed by Yusuke Suzuki.

        Enable JIT by default on ARMv7/Linux after it was disabled with
        recent bytcode format change.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::getICStatusMap):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::metadata):
        * bytecode/InByIdStatus.cpp:
        (JSC::InByIdStatus::computeFor):
        * bytecode/Instruction.h:
        (JSC::Instruction::cast):
        * bytecode/MetadataTable.h:
        (JSC::MetadataTable::forEach):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        (JSC::PutByIdStatus::hasExitSite): Deleted.
        * bytecode/PutByIdStatus.h:
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * generator/Argument.rb:
        * generator/Opcode.rb:
        * jit/GPRInfo.h:
        * jit/JIT.h:
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_unsigned):
        (JSC::JIT::emit_op_inc):
        (JSC::JIT::emit_op_dec):
        (JSC::JIT::emitBinaryDoubleOp):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::emitSlow_op_mod):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitPutCallResult):
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        (JSC::JIT::emitSlow_op_construct_varargs):
        (JSC::JIT::emitSlow_op_construct):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::emit_op_construct):
        (JSC::JIT::compileSetupFrame):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::compileSetupVarargsFrame): Deleted.
        * jit/JITInlines.h:
        (JSC::JIT::updateTopCallFrame):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emitSlow_op_loop_hint):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_mov):
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_jmp):
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emit_op_instanceof_custom):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_is_empty):
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_is_boolean):
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_is_cell_with_type):
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::emit_op_set_function_name):
        (JSC::JIT::emit_op_not):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emit_op_jeq):
        (JSC::JIT::emitSlow_op_jeq):
        (JSC::JIT::emit_op_neq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::emit_op_jneq):
        (JSC::JIT::emitSlow_op_jneq):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::emit_op_stricteq):
        (JSC::JIT::emit_op_nstricteq):
        (JSC::JIT::compileOpStrictEqJump):
        (JSC::JIT::emit_op_jstricteq):
        (JSC::JIT::emit_op_jnstricteq):
        (JSC::JIT::emitSlow_op_jstricteq):
        (JSC::JIT::emitSlow_op_jnstricteq):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_to_number):
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emit_op_to_object):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_identity_with_profile):
        (JSC::JIT::emit_op_get_parent_scope):
        (JSC::JIT::emit_op_switch_imm):
        (JSC::JIT::emit_op_switch_char):
        (JSC::JIT::emit_op_switch_string):
        (JSC::JIT::emit_op_debug):
        (JSC::JIT::emit_op_enter):
        (JSC::JIT::emit_op_get_scope):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_to_this):
        (JSC::JIT::emit_op_check_tdz):
        (JSC::JIT::emit_op_has_structure_property):
        (JSC::JIT::privateCompileHasIndexedProperty):
        (JSC::JIT::emit_op_has_indexed_property):
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_by_val):
        (JSC::JIT::emit_op_put_setter_by_val):
        (JSC::JIT::emit_op_del_by_id):
        (JSC::JIT::emit_op_del_by_val):
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val_direct):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id_direct):
        (JSC::JIT::emitSlow_op_get_by_id_direct):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emit_op_in_by_id):
        (JSC::JIT::emitSlow_op_in_by_id):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::vmCalleeSaveRegisters):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * runtime/SamplingProfiler.cpp:
        (JSC::tryGetBytecodeIndex):

2018-11-20  Saam barati  <sbarati@apple.com>

        Merging an IC variant may lead to the IC status containing overlapping structure sets
        https://bugs.webkit.org/show_bug.cgi?id=191869
        <rdar://problem/45403453>

        Reviewed by Mark Lam.

        When merging two IC variant lists, we may end up in a world where we have
        overlapping structure sets. We defend against this when we append a new
        variant, but we should also defend against it once we merge in a new variant.
        
        Consider this case with MultiPutByOffset, where we merge two PutByIdStatuses
        together, P1 and P2.
        
        Let's consider these structures:
        s1 = {}
        s2 = {p: 0}
        s3 = {p: 0, p2: 1}
        
        P1 contains these variants:
        Transition: [s1 => s2]
        Replace: [s2, s3]
        
        P2 contains:
        Replace: [s2]
        
        Because of the ordering of the variants, we may end up combining
        P2's replace into P1's transition, forming this new list:
        Transition: [(s1, s2) => s2]
        Replace: [s2, s3]
        
        Obviously the ideal thing here is to have some ordering when we merge
        in variants to choose the most ideal option. It'd be ideal for P2's
        Replace to be merged into P1's replace.
        
        If we notice that this is super important, we can implement some kind
        of ordering. None of our tests (until this patch) stress this. This patch
        just makes it so we defend against this crazy scenario by falling back
        to the slow path gracefully. This prevents us from emitting invalid
        IR in FTL->B3 lowering by creating a switch with two case labels being
        identical values.

        * bytecode/ICStatusUtils.h:
        (JSC::appendICStatusVariant):

2018-11-20  Fujii Hironori  <Hironori.Fujii@sony.com>

        REGRESSION(r238039) WebCore::JSDOMGlobalObject::createStructure is using JSC::Structure::create without including StructureInlines.h
        https://bugs.webkit.org/show_bug.cgi?id=191626
        <rdar://problem/46161064>

        Unreviewed adding comment for my change r238366.

        * runtime/Structure.h: Added a comment for Structure::create.

2018-11-19  Mark Lam  <mark.lam@apple.com>

        globalFuncImportModule() should return a promise when it clears exceptions.
        https://bugs.webkit.org/show_bug.cgi?id=191792
        <rdar://problem/46090763>

        Reviewed by Michael Saboff.

        If we're clearing the exceptions in a CatchScope, then it means that we've handled
        the exception, and is able to proceed in a normal manner.  Hence, we should not
        return the empty JSValue in this case: instead, we should return a Promise as
        expected by import's API.

        The only time when we can't return a promise is when we fail to create a Promise.
        In that case, we should be propagating the exception.

        Hence, globalFuncImportModule() contains a ThrowScope (for propagating the
        exception that arises from failure to create the Promise) wrapping a CatchScope
        (for catching any exception that arises from failure to execute the import).

        Also fixed similar issues, and some exception check issues in JSModuleLoader and
        the jsc shell.

        * jsc.cpp:
        (GlobalObject::moduleLoaderImportModule):
        (GlobalObject::moduleLoaderFetch):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncImportModule):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::requestImportModule):
        (JSC::JSModuleLoader::importModule):
        (JSC::JSModuleLoader::resolve):
        (JSC::JSModuleLoader::fetch):
        (JSC::moduleLoaderParseModule):
        (JSC::moduleLoaderResolveSync):

2018-11-19  Alex Christensen  <achristensen@webkit.org>

        Add SPI to disable JIT in a WKWebView
        https://bugs.webkit.org/show_bug.cgi?id=191822
        <rdar://problem/28119360>

        Reviewed by Geoffrey Garen.

        * jit/ExecutableAllocator.cpp:
        (JSC::jitDisabled):
        (JSC::allowJIT):
        (JSC::ExecutableAllocator::setJITEnabled):
        * jit/ExecutableAllocator.h:
        (JSC::ExecutableAllocator::setJITEnabled):

2018-11-19  Fujii Hironori  <Hironori.Fujii@sony.com>

        [MSVC] X86Assembler.h(108): error C2666: 'WebCore::operator -': 7 overloads have similar conversions
        https://bugs.webkit.org/show_bug.cgi?id=189467
        <rdar://problem/44290945>

        Reviewed by Mark Lam.

        This issue has happened several times. And, it seems that it will
        take more time for Microsoft to fix the MSVC bug. We need a
        effective workaround not to repeat this issue until they fix MSVC.

        Remove ": int8_t" of RegisterID only for COMPILER(MSVC).

        * assembler/X86Assembler.h: Added JSC_X86_ASM_REGISTER_ID_ENUM_BASE_TYPE macro.

2018-11-19  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [WebAssembly] I64 arguments / return value check should be moved from callWebAssemblyFunction to JSToWasm wrapper
        https://bugs.webkit.org/show_bug.cgi?id=190512

        Reviewed by Keith Miller.

        This patch moves I64 arguments / return value check from callWebAssemblyFunction to JSToWasm wrapper. Since this
        check can be done when compiling the function, we should encode the result into the generated wrapper instead of
        checking every time we call callWebAssemblyFunction. This change is also one of the steps removing callWebAssemblyFunction
        entirely.

        * wasm/WasmExceptionType.h:
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::callWebAssemblyWrapperFunction):

2018-11-12  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Consider removing double load for accessing the instructions from LLInt
        https://bugs.webkit.org/show_bug.cgi?id=190932

        Reviewed by Mark Lam.

        Changing InstructionStream to RefCountedArray like structure involves so much changes
        including BytecodeGraph, PreciseJumpTargets etc. Instead, CodeBlock simply hold a raw
        pointer to the InstructionStream's data. Since InstructionStream is not changed
        anymore, this pointer is valid while CodeBlock is live.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        * bytecode/InstructionStream.h:
        (JSC::InstructionStream::rawPointer const):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2018-11-18  Fujii Hironori  <Hironori.Fujii@sony.com>

        REGRESSION(r238039) WebCore::JSDOMGlobalObject::createStructure is using JSC::Structure::create without including StructureInlines.h
        https://bugs.webkit.org/show_bug.cgi?id=191626

        Reviewed by Yusuke Suzuki.

        JSC::Structure::create is used everywhere. It should be defined in
        Structure.h, not in StructureInlines.h.

        * runtime/Structure.h:
        (JSC::Structure::create): Moved.
        * runtime/StructureInlines.h: Moved JSC::Structure::create.

2018-11-18  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, rolling in the rest of r237254
        https://bugs.webkit.org/show_bug.cgi?id=190340

        * parser/ParserModes.h:
        * parser/ParserTokens.h:
        (JSC::JSTextPosition::JSTextPosition):
        (JSC::JSTokenLocation::JSTokenLocation): Deleted.
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):

2018-11-17  Devin Rousso  <drousso@apple.com>

        Web Inspector: Network: add button to show system certificate dialog
        https://bugs.webkit.org/show_bug.cgi?id=191458
        <rdar://problem/45977019>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Network.json:
        Add `getSerializedCertificate` command.

2018-11-17  Dominik Infuehr  <dinfuehr@igalia.com>

        Fix build with disabled DFG/FTL
        https://bugs.webkit.org/show_bug.cgi?id=191256

        Reviewed by Yusuke Suzuki.

        Fix compilation errors and warnings with both DFG and FTL
        disabled at compile-time.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::getICStatusMap):
        * bytecode/InByIdStatus.cpp:
        (JSC::InByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        (JSC::PutByIdStatus::hasExitSite): Deleted.
        * bytecode/PutByIdStatus.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):

2018-11-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Keep Web Inspector window alive across process swaps (PSON) (Local Inspector)
        https://bugs.webkit.org/show_bug.cgi?id=191740
        <rdar://problem/45470897>

        Reviewed by Timothy Hatcher.

        * inspector/InspectorFrontendChannel.h:
        Expose EnumTraits for ConnectionType for WebKit IPC messages.

2018-11-16  Filip Pizlo  <fpizlo@apple.com>

        All users of ArrayBuffer should agree on the same max size
        https://bugs.webkit.org/show_bug.cgi?id=191771

        Reviewed by Mark Lam.

        Array buffers cannot be larger than 0x7fffffff, because otherwise loading typedArray.length in the DFG/FTL would produce
        a uint32 or would require a signedness check, neither of which sounds reasonable. It's better to just bound their max size
        instead.

        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBufferContents::ArrayBufferContents):
        (JSC::ArrayBufferContents::tryAllocate):
        (JSC::ArrayBufferContents::transferTo):
        (JSC::ArrayBufferContents::copyTo):
        (JSC::ArrayBufferContents::shareWith):
        * runtime/ArrayBuffer.h:
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::tryCreate):
        (JSC::Wasm::Memory::grow):
        * wasm/WasmPageCount.h:

2018-11-16  Saam Barati  <sbarati@apple.com>

        KnownCellUse should also have SpecCellCheck as its type filter
        https://bugs.webkit.org/show_bug.cgi?id=191729
        <rdar://problem/45872852>

        Reviewed by Filip Pizlo.

        We write transformations in the compiler like this where we emit edges with
        KnownCellUse if we know we're inserting code at a point where we're dominated
        by a Cell check:
        
        a: SomeValue
        b: Something(Cell:@a)
        c: SomethingElse(@b)
        d: CheckNotEmpty(@a)
        
        =>
        
        a: SomeValue
        b: Something(Cell:@a)
        e: RandomOtherThing(KnownCellUse:@a)
        c: SomethingElse(@b)
        d: CheckNotEmpty(@a)
        
        However, doing this used to lead to subtly incorrect programs since KnownCellUse
        did not allow the empty value to flow through it. We used to end up incorrectly
        deleting @d in the above program. We fix this, we make KnownCellUse allow the empty
        value to flow through.

        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):

2018-11-16  Tadeu Zagallo  <tzagallo@apple.com>

        Fix assertion failure on BytecodeGenerator::recordOpcode
        https://bugs.webkit.org/show_bug.cgi?id=191724
        <rdar://problem/45724395>

        Reviewed by Saam Barati.

        Since https://bugs.webkit.org/show_bug.cgi?id=187373, we were not
        restoring m_lastInstruction after patching the bytecode when
        finalizing StructureForInContexts, only m_lastOpcodeID, which led to
        the assertion failure.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::StructureForInContext::finalize):

2018-11-15  Mark Lam  <mark.lam@apple.com>

        RegExpObject's collectMatches should not be using JSArray::push to fill in its match results.
        https://bugs.webkit.org/show_bug.cgi?id=191730
        <rdar://problem/46048517>

        Reviewed by Saam Barati.

        According to the spec https://www.ecma-international.org/ecma-262/9.0/index.html#sec-regexp.prototype-@@match,
        the RegExp match results are filled in using the spec's CreateDataProperty()
        function which does not consult the prototype for setters.  JSArray:push()
        consults the prototype for setters.  We should be using putDirectIndex() instead.

        * runtime/RegExpObjectInlines.h:
        (JSC::collectMatches):

2018-11-15  Mark Lam  <mark.lam@apple.com>

        RegExp operations should not take fast patch if lastIndex is not numeric.
        https://bugs.webkit.org/show_bug.cgi?id=191731
        <rdar://problem/46017305>

        Reviewed by Saam Barati.

        This is because if lastIndex is an object with a valueOf() method, it can execute
        arbitrary code which may have side effects, and side effects are not permitted by
        the RegExp fast paths.

        * builtins/RegExpPrototype.js:
        (globalPrivate.hasObservableSideEffectsForRegExpMatch):
        (overriddenName.string_appeared_here.search):
        (globalPrivate.hasObservableSideEffectsForRegExpSplit):
        (intrinsic.RegExpTestIntrinsic.test):
        * builtins/StringPrototype.js:
        (globalPrivate.hasObservableSideEffectsForStringReplace):

2018-11-15  Keith Rollin  <krollin@apple.com>

        Delete old .xcfilelist files
        https://bugs.webkit.org/show_bug.cgi?id=191669
        <rdar://problem/46081994>

        Reviewed by Chris Dumez.

        .xcfilelist files were created and added to the Xcode project files in
        https://trac.webkit.org/changeset/238008/webkit. However, they caused
        build issues and they were removed from the Xcode projects in
        https://trac.webkit.org/changeset/238055/webkit. This check-in removes
        the files from the repository altogether. They'll ultimately be
        replaced with new files with names that indicate whether the
        associated files are inputs to the Run Script phase or are files
        created by the Run Script phase.

        * DerivedSources.xcfilelist: Removed.
        * UnifiedSources.xcfilelist: Removed.

2018-11-14  Keith Rollin  <krollin@apple.com>

        Move scripts for Derived and Unified Sources to external files
        https://bugs.webkit.org/show_bug.cgi?id=191670
        <rdar://problem/46082278>

        Reviewed by Keith Miller.

        Move the scripts in the Generate Derived Sources and Generate Unified
        Sources Run Script phases from the Xcode projects to external shell
        script files. Then invoke those scripts from the Run Script phases.
        This refactoring is being performed to support later work that will
        invoke these scripts in other contexts.

        The scripts were maintained as-is when making the move. I did a little
        reformatting and added 'set -e' to the top of each file, but that's
        it.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Scripts/generate-derived-sources.sh: Added.
        * Scripts/generate-unified-sources.sh: Added.

2018-11-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Pass Inspector::FrontendChannel as a reference connect/disconnect methods
        https://bugs.webkit.org/show_bug.cgi?id=191612

        Reviewed by Matt Baker.

        * inspector/InspectorFrontendRouter.cpp:
        (Inspector::FrontendRouter::connectFrontend):
        (Inspector::FrontendRouter::disconnectFrontend):
        * inspector/InspectorFrontendRouter.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/remote/RemoteControllableTarget.h:
        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::close):
        * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::close):
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::connect):
        (JSC::JSGlobalObjectDebuggable::disconnect):
        * runtime/JSGlobalObjectDebuggable.h:

2018-11-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Keep Web Inspector window alive across process swaps (PSON) (Remote Inspector)
        https://bugs.webkit.org/show_bug.cgi?id=191494
        <rdar://problem/45469854>

        Reviewed by Devin Rousso.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        New domain and resources.

        * inspector/protocol/Target.json: Added.
        New protocol domain, modeled after Worker.json, to allow for
        multiplexing between different targets.

        * inspector/InspectorTarget.h:
        Each target will instantiate an InspectorTarget and must
        provide an identifier, type, and means of connecting/disconnecting
        to a frontend channel.

        * inspector/agents/InspectorTargetAgent.cpp: Added.
        (Inspector::InspectorTargetAgent::InspectorTargetAgent):
        (Inspector::InspectorTargetAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorTargetAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorTargetAgent::exists):
        (Inspector::InspectorTargetAgent::initialized):
        (Inspector::InspectorTargetAgent::sendMessageToTarget):
        (Inspector::InspectorTargetAgent::sendMessageFromTargetToFrontend):
        (Inspector::targetTypeToProtocolType):
        (Inspector::buildTargetInfoObject):
        (Inspector::InspectorTargetAgent::targetCreated):
        (Inspector::InspectorTargetAgent::targetTerminated):
        (Inspector::InspectorTargetAgent::connectToTargets):
        (Inspector::InspectorTargetAgent::disconnectFromTargets):
        * inspector/agents/InspectorTargetAgent.h: Added.
        TargetAgent holds a list of targets, and connects/disconnects to each
        of the targets when a frontend connects/disconnects.

        * inspector/scripts/codegen/generator.py:
        Better enum casing of ServiceWorker.

2018-11-14  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, rolling in CodeCache in r237254
        https://bugs.webkit.org/show_bug.cgi?id=190340

        Land the CodeCache part without adding an additional hash value.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator== const):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/CodeCache.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/FunctionExecutable.h:

2018-11-13  Saam Barati  <sbarati@apple.com>

        ProxyObject should check for VMInquiry and return early before throwing a stack overflow exception
        https://bugs.webkit.org/show_bug.cgi?id=191601

        Reviewed by Mark Lam.

        This doesn't fix any bugs today, but it may reduce future bugs. It was
        always weird that ProxyObject::getOwnPropertySlot with VMInquiry might
        throw a stack overflow error instead of just returning false like it
        normally does when VMInquiry is passed in.

        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::getOwnPropertySlotCommon):

2018-11-13  Saam Barati  <sbarati@apple.com>

        TypeProfileLog::processLogEntries should stash away any pending exceptions and re-apply them to the VM
        https://bugs.webkit.org/show_bug.cgi?id=191600

        Reviewed by Mark Lam.

        processLogEntries will call into calculatedClassName, which will clear
        any exceptions it encounters (it assumes that they're stack overflow exceptions).
        However, this code may be called when an exception is already pending on the 
        VM (e.g, when we throw an exception in the DFG, we compile an OSR exit
        offramp, which may compile a baseline codeblock, which will process
        the type profiler log). To get around this, processLogEntires should stash
        away and re-apply any pending exceptions.

        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGOperations.cpp:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        * jit/JIT.cpp:
        (JSC::JIT::doMainThreadPreparationBeforeCompile):
        * jit/JITOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/TypeProfilerLog.h:
        * runtime/VM.cpp:
        (JSC::VM::dumpTypeProfilerData):
        * runtime/VM.h:
        (JSC::VM::DeferExceptionScope::DeferExceptionScope):
        * tools/JSDollarVM.cpp:
        (JSC::functionFindTypeForExpression):
        (JSC::functionReturnTypeFor):

2018-11-13  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r238132.

        The test added with this change is timing out on Debug JSC
        bots.

        Reverted changeset:

        "[BigInt] JSBigInt::createWithLength should throw when length
        is greater than JSBigInt::maxLength"
        https://bugs.webkit.org/show_bug.cgi?id=190836
        https://trac.webkit.org/changeset/238132

2018-11-12  Mark Lam  <mark.lam@apple.com>

        Add OOM detection to StringPrototype's substituteBackreferences().
        https://bugs.webkit.org/show_bug.cgi?id=191563
        <rdar://problem/45720428>

        Reviewed by Saam Barati.

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * runtime/StringPrototype.cpp:
        (JSC::substituteBackreferencesSlow):
        (JSC::substituteBackreferencesInline):
        (JSC::substituteBackreferences):
        (JSC::replaceUsingRegExpSearch):
        (JSC::replaceUsingStringSearch):
        * runtime/StringPrototype.h:

2018-11-13  Mark Lam  <mark.lam@apple.com>

        LLIntSlowPath's llint_loop_osr and llint_replace should set the topCallFrame.
        https://bugs.webkit.org/show_bug.cgi?id=191579
        <rdar://problem/45942472>

        Reviewed by Saam Barati.

        Both of these functions do a lot of work.  It would be good for the topCallFrame
        to be correct should we need to throw an exception.

        For example, we've observed the following crash trace:

          * frame #0: WTFCrash() at Assertions.cpp:253
            frame #1: ...
            frame #2: JSC::StructureIDTable::get(this=0x00006040000162f0, structureID=1874583248) at StructureIDTable.h:129
            frame #3: JSC::VM::getStructure(this=0x0000604000016210, id=4022066896) at VM.h:705
            frame #4: JSC::JSCell::structure(this=0x00007ffeefbbde30, vm=0x0000604000016210) const at JSCellInlines.h:125
            frame #5: JSC::JSCell::classInfo(this=0x00007ffeefbbde30, vm=0x0000604000016210) const at JSCellInlines.h:335
            frame #6: JSC::JSCell::inherits(this=0x00007ffeefbbde30, vm=0x0000604000016210, info=0x0000000105eaf020) const at JSCellInlines.h:302
            frame #7: JSC::JSObject* JSC::jsCast<JSC::JSObject*, JSC::JSCell>(from=0x00007ffeefbbde30) at JSCast.h:36
            frame #8: JSC::asObject(cell=0x00007ffeefbbde30) at JSObject.h:1299
            frame #9: JSC::asObject(value=JSValue @ 0x00007ffeefbba380) at JSObject.h:1304
            frame #10: JSC::Register::object(this=0x00007ffeefbbdd58) const at JSObject.h:1514
            frame #11: JSC::ExecState::jsCallee(this=0x00007ffeefbbdd40) const at CallFrame.h:107
            frame #12: JSC::ExecState::isStackOverflowFrame(this=0x00007ffeefbbdd40) const at CallFrameInlines.h:36
            frame #13: JSC::StackVisitor::StackVisitor(this=0x00007ffeefbba860, startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800) at StackVisitor.cpp:52
            frame #14: JSC::StackVisitor::StackVisitor(this=0x00007ffeefbba860, startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800) at StackVisitor.cpp:41
            frame #15: void JSC::StackVisitor::visit<(JSC::StackVisitor::EmptyEntryFrameAction)0, JSC::Interpreter::getStackTrace(JSC::JSCell*, WTF::Vector<JSC::StackFrame, 0ul, WTF::CrashOnOverflow, 16ul>&, unsigned long, unsigned long)::$_3>(startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800, functor=0x00007ffeefbbaa60)::$_3 const&) at StackVisitor.h:147
            frame #16: JSC::Interpreter::getStackTrace(this=0x0000602000005db0, owner=0x000062d00020cbe0, results=0x00006020000249d0, framesToSkip=0, maxStackSize=1) at Interpreter.cpp:437
            frame #17: JSC::getStackTrace(exec=0x000062d00002c048, vm=0x0000631000000800, obj=0x000062d00020cbe0, useCurrentFrame=true) at Error.cpp:170
            frame #18: JSC::ErrorInstance::finishCreation(this=0x000062d00020cbe0, exec=0x000062d00002c048, vm=0x0000631000000800, message=0x00007ffeefbbb800, useCurrentFrame=true) at ErrorInstance.cpp:119
            frame #19: JSC::ErrorInstance::create(exec=0x000062d00002c048, vm=0x0000631000000800, structure=0x000062d0000f5730, message=0x00007ffeefbbb800, appender=0x0000000000000000, type=TypeNothing, useCurrentFrame=true)(WTF::String const&, WTF::String const&, JSC::RuntimeType, JSC::ErrorInstance::SourceTextWhereErrorOccurred), JSC::RuntimeType, bool) at ErrorInstance.h:49
            frame #20: JSC::createRangeError(exec=0x000062d00002c048, globalObject=0x000062d00002c000, message=0x00007ffeefbbb800, appender=0x0000000000000000)(WTF::String const&, WTF::String const&, JSC::RuntimeType, JSC::ErrorInstance::SourceTextWhereErrorOccurred)) at Error.cpp:68
            frame #21: JSC::createRangeError(exec=0x000062d00002c048, globalObject=0x000062d00002c000, message=0x00007ffeefbbb800) at Error.cpp:316
            frame #22: JSC::createStackOverflowError(exec=0x000062d00002c048, globalObject=0x000062d00002c000) at ExceptionHelpers.cpp:77
            frame #23: JSC::createStackOverflowError(exec=0x000062d00002c048) at ExceptionHelpers.cpp:72
            frame #24: JSC::throwStackOverflowError(exec=0x000062d00002c048, scope=0x00007ffeefbbbaa0) at ExceptionHelpers.cpp:335
            frame #25: JSC::ProxyObject::getOwnPropertySlotCommon(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbba80, slot=0x00007ffeefbbc720) at ProxyObject.cpp:372
            frame #26: JSC::ProxyObject::getOwnPropertySlot(object=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbbd40, slot=0x00007ffeefbbc720) at ProxyObject.cpp:395
            frame #27: JSC::JSObject::getNonIndexPropertySlot(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbbea0, slot=0x00007ffeefbbc720) at JSObjectInlines.h:150
            frame #28: bool JSC::JSObject::getPropertySlot<false>(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbc320, slot=0x00007ffeefbbc720) at JSObject.h:1424
            frame #29: JSC::JSObject::calculatedClassName(object=0x000062d000200e40) at JSObject.cpp:535
            frame #30: JSC::Structure::toStructureShape(this=0x000062d000007410, value=JSValue @ 0x00007ffeefbbcae0, sawPolyProtoStructure=0x00007ffeefbbcf60) at Structure.cpp:1142
            frame #31: JSC::TypeProfilerLog::processLogEntries(this=0x000060400000a950, reason=0x00007ffeefbbd5c0) at TypeProfilerLog.cpp:89
            frame #32: JSC::JIT::doMainThreadPreparationBeforeCompile(this=0x0000619000034da0) at JIT.cpp:951
            frame #33: JSC::JITWorklist::Plan::Plan(this=0x0000619000034d80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:43
            frame #34: JSC::JITWorklist::Plan::Plan(this=0x0000619000034d80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:42
            frame #35: JSC::JITWorklist::compileLater(this=0x0000616000001b80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:256
            frame #36: JSC::LLInt::jitCompileAndSetHeuristics(codeBlock=0x000062d0001d88c0, exec=0x00007ffeefbbde30, loopOSREntryBytecodeOffset=0) at LLIntSlowPaths.cpp:391
            frame #37: llint_replace(exec=0x00007ffeefbbde30, pc=0x00006040000161ba) at LLIntSlowPaths.cpp:516
            frame #38: llint_entry at LowLevelInterpreter64.asm:98
            frame #39: vmEntryToJavaScript at LowLevelInterpreter64.asm:296
            ...

        This crash occurred because StackVisitor was seeing an invalid topCallFrame while
        trying to capture the Error stack while throwing a StackOverflowError below
        llint_replace.  While in this specific example, it is questionable whether we
        should be executing JS code below TypeProfilerLog::processLogEntries(), it is
        correct to have set the topCallFrame in llint_replace.  We do this by calling
        LLINT_BEGIN_NO_SET_PC() at the top of llint_replace.

        We also do the same for llint_osr.
        
        Note: both of these LLInt slow path functions are called with a fully initialized
        CallFrame.  Hence, there's no issue with setting topCallFrame to their CallFrames
        for these functions.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

2018-11-13  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength
        https://bugs.webkit.org/show_bug.cgi?id=190836

        Reviewed by Saam Barati.

        In this patch we are creating a new method called `JSBigInt::createWithLengthUnchecked`
        where we allocate a BigInt trusting the length received as argument.
        With this additional method, we now check if length passed to
        `JSBigInt::createWithLength` is not greater than JSBigInt::maxLength.
        When the length is greater than maxLength, we then throw OOM
        exception.
        This required change the interface of some JSBigInt operations to
        receive `ExecState*` instead of `VM&`. We changed only operations that
        can throw because of OOM.
        We beleive that this approach of throwing instead of finishing the
        execution abruptly is better because JS programs can catch such
        exception and handle this issue properly.

        * dfg/DFGOperations.cpp:
        * jit/JITOperations.cpp:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::createZero):
        (JSC::JSBigInt::tryCreateWithLength):
        (JSC::JSBigInt::createWithLengthUnchecked):
        (JSC::JSBigInt::createFrom):
        (JSC::JSBigInt::multiply):
        (JSC::JSBigInt::divide):
        (JSC::JSBigInt::copy):
        (JSC::JSBigInt::unaryMinus):
        (JSC::JSBigInt::remainder):
        (JSC::JSBigInt::add):
        (JSC::JSBigInt::sub):
        (JSC::JSBigInt::bitwiseAnd):
        (JSC::JSBigInt::bitwiseOr):
        (JSC::JSBigInt::bitwiseXor):
        (JSC::JSBigInt::absoluteAdd):
        (JSC::JSBigInt::absoluteSub):
        (JSC::JSBigInt::absoluteDivWithDigitDivisor):
        (JSC::JSBigInt::absoluteDivWithBigIntDivisor):
        (JSC::JSBigInt::absoluteLeftShiftAlwaysCopy):
        (JSC::JSBigInt::absoluteBitwiseOp):
        (JSC::JSBigInt::absoluteAddOne):
        (JSC::JSBigInt::absoluteSubOne):
        (JSC::JSBigInt::toStringGeneric):
        (JSC::JSBigInt::rightTrim):
        (JSC::JSBigInt::allocateFor):
        (JSC::JSBigInt::createWithLength): Deleted.
        * runtime/JSBigInt.h:
        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):
        * runtime/Operations.h:
        (JSC::jsSub):
        (JSC::jsMul):

2018-11-12  Devin Rousso  <drousso@apple.com>

        Web Inspector: Network: show secure certificate details per-request
        https://bugs.webkit.org/show_bug.cgi?id=191447
        <rdar://problem/30019476>

        Reviewed by Joseph Pecoraro.

        Add Security domain to hold security related protocol types.

        * CMakeLists.txt:
        * DerivedSources.make:
        * inspector/protocol/Network.json:
        * inspector/protocol/Security.json: Added.
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator):

2018-11-12  Saam barati  <sbarati@apple.com>

        Unreviewed. Rollout 238026: It caused ~8% JetStream 2 regressions on some iOS devices
        https://bugs.webkit.org/show_bug.cgi?id=191555

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator== const):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/CodeCache.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/FunctionExecutable.h:

2018-11-11  Benjamin Poulain  <benjamin@webkit.org>

        Fix a fixme: rename wtfObjcMsgSend to wtfObjCMsgSend
        https://bugs.webkit.org/show_bug.cgi?id=191492

        Reviewed by Alex Christensen.

        Rename file.

        * API/JSValue.mm:

2018-11-10  Benjamin Poulain  <benjamin@webkit.org>

        Fix a fixme: rename wtfObjcMsgSend to wtfObjCMsgSend
        https://bugs.webkit.org/show_bug.cgi?id=191492

        Reviewed by Alex Christensen.

        * API/JSValue.mm:

2018-11-10  Michael Catanzaro  <mcatanzaro@igalia.com>

        Unreviewed, silence -Wunused-variable warning

        * bytecode/Opcode.h:
        (JSC::padOpcodeName):

2018-11-09  Keith Rollin  <krollin@apple.com>

        Unreviewed build fix after https://bugs.webkit.org/show_bug.cgi?id=191324

        Remove the use of .xcfilelists until their side-effects are better
        understood.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2018-11-09  Keith Miller  <keith_miller@apple.com>

        LLInt VectorSizeOffset should be based on offset extraction
        https://bugs.webkit.org/show_bug.cgi?id=191468

        Reviewed by Yusuke Suzuki.

        This patch also adds some usings to LLIntOffsetsExtractor that
        make it possible to use the bare names of Vector/RefCountedArray
        in offsets extraction.

        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LowLevelInterpreter.asm:

2018-11-09  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, rolling in CodeCache in r237254
        https://bugs.webkit.org/show_bug.cgi?id=190340

        Land the CodeCache part, which uses DefaultHash<>::Hash instead of computeHash.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator== const):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/CodeCache.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/FunctionExecutable.h:

2018-11-08  Keith Miller  <keith_miller@apple.com>

        put_by_val opcodes need to add the number tag as a 64-bit register
        https://bugs.webkit.org/show_bug.cgi?id=191456

        Reviewed by Saam Barati.

        Previously the LLInt would add it as a pointer sized value. That is
        wrong if pointer size is less 64-bits.

        * llint/LowLevelInterpreter64.asm:

2018-11-08  Ross Kirsling  <ross.kirsling@sony.com>

        [JSC] isStrWhiteSpace seems redundant with Lexer<UChar>::isWhiteSpace
        https://bugs.webkit.org/show_bug.cgi?id=191439

        Reviewed by Saam Barati.

        * CMakeLists.txt:
        * runtime/ParseInt.h:
        (JSC::isStrWhiteSpace):
        Define isStrWhiteSpace in terms of isWhiteSpace and isLineTerminator.

2018-11-08  Michael Saboff  <msaboff@apple.com>

        Options::useRegExpJIT() should use jitEnabledByDefault() just like useJIT()
        https://bugs.webkit.org/show_bug.cgi?id=191444

        Reviewed by Saam Barati.

        * runtime/Options.h:

2018-11-08  Fujii Hironori  <Hironori.Fujii@sony.com>

        [Win] UDis86Disassembler.cpp: warning: format specifies type 'unsigned long' but the argument has type 'uintptr_t' (aka 'unsigned long long')
        https://bugs.webkit.org/show_bug.cgi?id=191416

        Reviewed by Saam Barati.

        * disassembler/UDis86Disassembler.cpp:
        (JSC::tryToDisassembleWithUDis86): Use PRIxPTR for uintptr_t.

2018-11-08  Keith Rollin  <krollin@apple.com>

        Create .xcfilelist files
        https://bugs.webkit.org/show_bug.cgi?id=191324
        <rdar://problem/45852819>

        Reviewed by Alex Christensen.

        As part of preparing for enabling XCBuild, create and use .xcfilelist
        files. These files are using during Run Script build phases in an
        Xcode project. If a Run Script build phase produces new files that are
        used later as inputs to subsequent build phases, XCBuild needs to know
        about these files. These files can be either specified in an "output
        files" section of the Run Script phase editor, or in .xcfilelist files
        that are associated with the Run Script build phase.

        This patch takes the second approach. It consists of three sets of changes:

        - Modify the DerivedSources.make files to have a
          'print_all_generated_files" target that produces a list of the files
          they create.

        - Create a shell script that produces .xcfilelist files from the
          output of the previous step, as well as for the files created in the
          Generate Unified Sources build steps.

        - Add the new .xcfilelist files to the associated projects.

        Note that, with these changes, the Xcode workspace and projects can no
        longer be fully loaded into Xcode 9. Xcode will attempt to load the
        projects that have .xcfilelist files associated with them, but will
        fail and display a placeholder for those projects instead. It's
        expected that all developers are using Xcode 10 by now and that not
        being able to load into Xcode 9 is not a practical issue. Keep in mind
        that this is strictly an IDE issue, and that the projects can still be
        built with `xcodebuild`.

        Also note that the shell script that creates the .xcfilelist files can
        also be used to verify that the set of files that's currently checked
        in is up-to-date. This checking can be used as part of a check-in hook
        or part of check-webkit-style to sooner catch cases where the
        .xcfilelist files need to be regenerated.

        * DerivedSources.make:
        * DerivedSources.xcfilelist: Added.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * UnifiedSources.xcfilelist: Added.

2018-11-08  Ross Kirsling  <ross.kirsling@sony.com>

        U+180E is no longer a whitespace character
        https://bugs.webkit.org/show_bug.cgi?id=191415

        Reviewed by Saam Barati.

        Mongolian Vowel Separator stopped being a valid whitespace character as of ES2016.
        (https://github.com/tc39/ecma262/pull/300)

        * parser/Lexer.h:
        (JSC::Lexer<UChar>::isWhiteSpace):
        * runtime/ParseInt.h:
        (JSC::isStrWhiteSpace):
        * yarr/create_regex_tables:

2018-11-08  Keith Miller  <keith_miller@apple.com>

        jitEnabledByDefault() should be on useJIT not useBaselineJIT
        https://bugs.webkit.org/show_bug.cgi?id=191434

        Reviewed by Saam Barati.

        * runtime/Options.h:

2018-11-08  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Restrict domains at the target level instead of only at the window level
        https://bugs.webkit.org/show_bug.cgi?id=191344

        Reviewed by Devin Rousso.

        * inspector/protocol/Console.json:
        * inspector/protocol/Debugger.json:
        * inspector/protocol/Heap.json:
        * inspector/protocol/Runtime.json:
        Remove workerSupported as it is now no longer necessary. It is implied
        by availability being empty (meaning it is supported everywhere).

        * inspector/protocol/Inspector.json:
        * inspector/protocol/ScriptProfiler.json:
        Restrict to "javascript" and "web" debuggables, not available in workers.

        * inspector/protocol/Worker.json:
        Cleanup, remove empty types list.
        
        * inspector/protocol/Recording.json:
        Cleanup, only expose this in the "web" domain for now.

        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.generate_domain):
        * inspector/scripts/codegen/models.py:
        (Protocol.parse_domain):
        Allow a list of debuggable types. Add "worker" even though it is unused
        since that is a type we would want to allow or consider.

        (Domain.__init__):
        (Domains):
        Remove now unnecessary workerSupported code.
        Allow availability on a domain with only types.

        * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: Removed.
        * inspector/scripts/tests/generic/worker-supported-domains.json: Removed.

2018-11-07  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Consider removing double load for accessing the MetadataTable from LLInt
        https://bugs.webkit.org/show_bug.cgi?id=190933

        Reviewed by Keith Miller.

        This patch removes double load for accesses to MetadataTable from LLInt.
        MetadataTable is now specially RefCounted class, which has interesting memory layout.
        When refcount becomes 0, MetadataTable asks UnlinkedMetadataTable to destroy itself.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::estimatedSize):
        (JSC::CodeBlock::visitChildren):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::metadata):
        * bytecode/CodeBlockInlines.h:
        (JSC::CodeBlock::forEachValueProfile):
        (JSC::CodeBlock::forEachArrayProfile):
        (JSC::CodeBlock::forEachArrayAllocationProfile):
        (JSC::CodeBlock::forEachObjectAllocationProfile):
        (JSC::CodeBlock::forEachLLIntCallLinkInfo):
        * bytecode/MetadataTable.cpp:
        (JSC::MetadataTable::MetadataTable):
        (JSC::MetadataTable::~MetadataTable):
        (JSC::MetadataTable::sizeInBytes):
        * bytecode/MetadataTable.h:
        (JSC::MetadataTable::get):
        (JSC::MetadataTable::forEach):
        (JSC::MetadataTable::ref const):
        (JSC::MetadataTable::deref const):
        (JSC::MetadataTable::refCount const):
        (JSC::MetadataTable::hasOneRef const):
        (JSC::MetadataTable::buffer):
        (JSC::MetadataTable::linkingData const):
        (JSC::MetadataTable::getImpl):
        * bytecode/UnlinkedMetadataTable.h:
        (JSC::UnlinkedMetadataTable::buffer const):
        * bytecode/UnlinkedMetadataTableInlines.h:
        (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
        (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
        (JSC::UnlinkedMetadataTable::addEntry):
        (JSC::UnlinkedMetadataTable::sizeInBytes):
        (JSC::UnlinkedMetadataTable::finalize):
        (JSC::UnlinkedMetadataTable::link):
        (JSC::UnlinkedMetadataTable::unlink):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:

2018-11-07  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Add support to BigInt into ValueAdd
        https://bugs.webkit.org/show_bug.cgi?id=186177

        Reviewed by Keith Miller.

        We are adding a very primitive specialization case of BigInts into ValueAdd.
        When compiling a speculated version of this node to BigInt, we are currently
        calling 'operationAddBigInt', a function that expects only BigInts as
        parameter and effectly add numbers using JSBigInt::add. To properly
        speculate BigInt operands, we changed ArithProfile to observe when
        its result is a BigInt. With this new observation, we are able to identify
        when ValueAdd results into a String or BigInt.

        Here are some numbers for this specialization running
        microbenchmarks:

        big-int-simple-add                   21.5411+-1.1096  ^  15.3502+-0.7027  ^ definitely 1.4033x faster
        big-int-add-prediction-propagation   13.7762+-0.5578  ^  10.8117+-0.5330  ^ definitely 1.2742x faster

        * bytecode/ArithProfile.cpp:
        (JSC::ArithProfile::emitObserveResult):
        (JSC::ArithProfile::shouldEmitSetNonNumeric const):
        (JSC::ArithProfile::shouldEmitSetBigInt const):
        (JSC::ArithProfile::emitSetNonNumeric const):
        (JSC::ArithProfile::emitSetBigInt const):
        (WTF::printInternal):
        (JSC::ArithProfile::shouldEmitSetNonNumber const): Deleted.
        (JSC::ArithProfile::emitSetNonNumber const): Deleted.
        * bytecode/ArithProfile.h:
        (JSC::ArithProfile::observedUnaryInt):
        (JSC::ArithProfile::observedUnaryNumber):
        (JSC::ArithProfile::observedBinaryIntInt):
        (JSC::ArithProfile::observedBinaryNumberInt):
        (JSC::ArithProfile::observedBinaryIntNumber):
        (JSC::ArithProfile::observedBinaryNumberNumber):
        (JSC::ArithProfile::didObserveNonInt32 const):
        (JSC::ArithProfile::didObserveNonNumeric const):
        (JSC::ArithProfile::didObserveBigInt const):
        (JSC::ArithProfile::setObservedNonNumeric):
        (JSC::ArithProfile::setObservedBigInt):
        (JSC::ArithProfile::observeResult):
        (JSC::ArithProfile::didObserveNonNumber const): Deleted.
        (JSC::ArithProfile::setObservedNonNumber): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::makeSafe):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::mayHaveNonNumericResult):
        (JSC::DFG::Node::mayHaveBigIntResult):
        (JSC::DFG::Node::mayHaveNonNumberResult): Deleted.
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags):
        * dfg/DFGNodeFlags.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        * runtime/CommonSlowPaths.cpp:
        (JSC::updateArithProfileForUnaryArithOp):
        (JSC::updateArithProfileForBinaryArithOp):

2018-11-07  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Fix "Javascript" => "JavaScript" enum in protocol generated objects
        https://bugs.webkit.org/show_bug.cgi?id=191340

        Reviewed by Devin Rousso.

        * inspector/ConsoleMessage.cpp:
        (Inspector::messageSourceValue):
        Use new enum name.

        * inspector/scripts/codegen/generator.py:
        Correct the casing of "JavaScript".

2018-11-07  Tadeu Zagallo  <tzagallo@apple.com>

        Align wide opcodes in the instruction stream
        https://bugs.webkit.org/show_bug.cgi?id=191254

        Reviewed by Keith Miller.

        Pad the bytecode with nops to ensure that wide opcodes are 4-byte
        aligned on platforms that don't like unaligned memory access.

        For that, add a new type to represent jump targets, BoundLabel, which
        delays computing the offset in case we need to emit nops for padding.
        Extra padding is also emitted before op_yield and at the of each
        BytecodeWriter fragment, to ensure that the bytecode remains aligned
        after the rewriting.

        As a side effect, we can longer guarantee that the point immediately
        before emitting an opcode is the start of that opcode, since nops
        might be emitted in between if the opcode needs to be wide. To fix
        that, we only take the offset of opcodes after they have been emitted,
        using `m_lastInstruction.offset()`.

        * bytecode/BytecodeDumper.h:
        (JSC::BytecodeDumper::dumpValue):
        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::run):
        * bytecode/BytecodeList.rb:
        * bytecode/BytecodeRewriter.h:
        (JSC::BytecodeRewriter::Fragment::align):
        (JSC::BytecodeRewriter::insertFragmentBefore):
        (JSC::BytecodeRewriter::insertFragmentAfter):
        * bytecode/Fits.h:
        * bytecode/InstructionStream.h:
        (JSC::InstructionStreamWriter::ref):
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::updateStoredJumpTargetsForInstruction):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::Label::setLocation):
        (JSC::BoundLabel::target):
        (JSC::BoundLabel::saveTarget):
        (JSC::BoundLabel::commitTarget):
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::recordOpcode):
        (JSC::BytecodeGenerator::alignWideOpcode):
        (JSC::BytecodeGenerator::emitProfileControlFlow):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitGetFromScope):
        (JSC::BytecodeGenerator::emitPutToScope):
        (JSC::BytecodeGenerator::emitGetById):
        (JSC::BytecodeGenerator::emitDirectGetById):
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::beginSwitch):
        (JSC::BytecodeGenerator::endSwitch):
        (JSC::BytecodeGenerator::emitRequireObjectCoercible):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitToThis):
        (JSC::Label::bind): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::recordOpcode): Deleted.
        * bytecompiler/Label.h:
        (JSC::BoundLabel::BoundLabel):
        (JSC::BoundLabel::operator int):
        (JSC::Label::bind):
        * generator/Opcode.rb:

2018-11-07  Tadeu Zagallo  <tzagallo@apple.com>

        REGRESSION(r237547): Test failures on 32-bit JSC since the JIT was disabled
        https://bugs.webkit.org/show_bug.cgi?id=191184

        Reviewed by Saam Barati.

        Fix API test on CLoop: we can only disable the LLInt when the JIT is enabled.

        * API/tests/PingPongStackOverflowTest.cpp:
        (testPingPongStackOverflow):

2018-11-06  Justin Fan  <justin_fan@apple.com>

        [WebGPU] Experimental prototype for WebGPURenderPipeline and WebGPUSwapChain
        https://bugs.webkit.org/show_bug.cgi?id=191291

        Reviewed by Myles Maxfield.

        Properly disable WEBGPU on all non-Metal platforms for now.

        * Configurations/FeatureDefines.xcconfig:

2018-11-06  Keith Rollin  <krollin@apple.com>

        Adjust handling of Include paths that need quoting
        https://bugs.webkit.org/show_bug.cgi?id=191314
        <rdar://problem/45849143>

        Reviewed by Dan Bernstein.

        There are several places in the JavaScriptCore Xcode project where the
        paths defined in HEADER_SEARCH_PATHS are quoted. That is, the
        definitions look like:

            HEADER_SEARCH_PATHS = (
                "\"${BUILT_PRODUCTS_DIR}/DerivedSources/JavaScriptCore\"",
                "\"${BUILT_PRODUCTS_DIR}/LLIntOffsets/${ARCHS}\"",
                "\"$(JAVASCRIPTCORE_FRAMEWORKS_DIR)/JavaScriptCore.framework/PrivateHeaders\"",
                "$(inherited)",
            );

        The idea here is presumably to have the resulting $(CPP) command have
        -I options where the associated paths are themselves quoted,
        protecting against space characters in the paths.

        This approach to quote management can break under Xcode 9. If
        .xcfilelist files are added to the project, the 'objectVersion' value
        in the Xcode project file is changed from 46 to 51. If a project with
        objectVersion=51 is presented to Xcode 9 (as can happen when we build
        for older OS's), it produces build lines where the quotes are escaped,
        thereby becoming part of the path. The build then fails because a
        search for a file normally found in a directory called "Foo" will be
        looked for in "\"Foo\"", which doesn't exist.

        Simply removing the escaped quotes from the HEADER_SEARCH_PATHS
        definition doesn't work, leading to paths that need quoting due to
        space characters but that don't get this quoting (the part of the path
        after the space appears to simply go missing).

        Removing the escaped quotes from the HEADER_SEARCH_PATHS and moving
        the definitions to the .xcconfig fixes this problem.

        * Configurations/ToolExecutable.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2018-11-06  Michael Saboff  <msaboff@apple.com>

        Multiple stress/regexp-compile-oom.js tests are failing on High Sierra Debug and Release JSC testers.
        https://bugs.webkit.org/show_bug.cgi?id=191271

        Reviewed by Saam Barati.

        Fixed use of ThrowScope my adding release() calls.  Found a few places where we needed
        RETURN_IF_EXCEPTION().  After some code inspections determined that we need to cover the
        exception bubbling for String.match() with a global RegExp as well as String.replace()
        and String.search().

        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::matchInline):
        (JSC::collectMatches):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncSearchFast):
        * runtime/StringPrototype.cpp:
        (JSC::removeUsingRegExpSearch):
        (JSC::replaceUsingRegExpSearch):

2018-11-05  Don Olmstead  <don.olmstead@sony.com>

        Fix typos in closing ENABLE guards
        https://bugs.webkit.org/show_bug.cgi?id=191273

        Reviewed by Keith Miller.

        * ftl/FTLForOSREntryJITCode.h:
        * ftl/FTLJITCode.h:
        * jsc.cpp:
        * wasm/WasmMemoryInformation.h:
        * wasm/WasmPageCount.h:

2018-11-05  Keith Miller  <keith_miller@apple.com>

        Make static_asserts in APICast into bitwise_cast
        https://bugs.webkit.org/show_bug.cgi?id=191272

        Reviewed by Filip Pizlo.

        * API/APICast.h:
        (toJS):
        (toJSForGC):
        (toRef):

2018-11-05  Dominik Infuehr  <dinfuehr@igalia.com>

        Enable LLInt on ARMv7/Linux
        https://bugs.webkit.org/show_bug.cgi?id=191190

        Reviewed by Yusuke Suzuki.

        After enabling the new bytecode format in r237547, C_LOOP was
        forced on all 32-bit platforms. Now enable LLInt again on
        ARMv7-Thumb2/Linux.

        This adds a callee-saved register in ARMv7/Linux for the metadataTable and
        stores/restores it on LLInt function calls. It also introduces the globaladdr-
        instruction for the ARM-offlineasm to access the opcode-table.

        * jit/GPRInfo.h:
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * offlineasm/arm.rb:
        * offlineasm/asm.rb:
        * offlineasm/instructions.rb:

2018-11-05  Fujii Hironori  <Hironori.Fujii@sony.com>

        [Win][Clang][JSC] JIT::is64BitType reports "warning: explicit specialization cannot have a storage class"
        https://bugs.webkit.org/show_bug.cgi?id=191146

        Reviewed by Yusuke Suzuki.

        * jit/JIT.h: Changed is64BitType from a template class method to a
        template inner class.

2018-11-02  Keith Miller  <keith_miller@apple.com>

        Assert JSValues can fit into a pointer when API casting
        https://bugs.webkit.org/show_bug.cgi?id=191220

        Reviewed by Michael Saboff.

        * API/APICast.h:
        (toJS):
        (toJSForGC):
        (toRef):

2018-11-02  Michael Saboff  <msaboff@apple.com>

        Rolling in r237753 with unreviewed build fix.

        Fixed issues with DECLARE_THROW_SCOPE placement.

2018-11-02  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r237753.

        Introduced JSC test failures

        Reverted changeset:

        "Running out of stack space not properly handled in
        RegExp::compile() and its callers"
        https://bugs.webkit.org/show_bug.cgi?id=191206
        https://trac.webkit.org/changeset/237753

2018-11-02  Michael Saboff  <msaboff@apple.com>

        Running out of stack space not properly handled in RegExp::compile() and its callers
        https://bugs.webkit.org/show_bug.cgi?id=191206

        Reviewed by Filip Pizlo.

        Eliminated two RELEASE_ASSERT_NOT_REACHED() for errors returned by Yarr parsing code.  Bubbled those errors
        up to where they are turned into the appropriate exceptions in matchInline().  If the errors are not due
        to syntax, we reset the RegExp state in case the parsing is tried with a smaller stack.

        * runtime/RegExp.cpp:
        (JSC::RegExp::compile):
        (JSC::RegExp::compileMatchOnly):
        * runtime/RegExp.h:
        * runtime/RegExpInlines.h:
        (JSC::RegExp::compileIfNecessary):
        (JSC::RegExp::matchInline):
        (JSC::RegExp::compileIfNecessaryMatchOnly):
        * runtime/RegExpObjectInlines.h:
        (JSC::RegExpObject::execInline):
        * yarr/YarrErrorCode.h:
        (JSC::Yarr::hasHardError):

2018-11-02  Keith Miller  <keith_miller@apple.com>

        API should use wrapper object if address is 32-bit
        https://bugs.webkit.org/show_bug.cgi?id=191203

        Reviewed by Filip Pizlo.

        * API/APICast.h:
        (toJS):
        (toJSForGC):
        (toRef):

2018-11-02  Tadeu Zagallo  <tzagallo@apple.com>

        Metadata should not be copyable
        https://bugs.webkit.org/show_bug.cgi?id=191193

        Reviewed by Keith Miller.

        We should only ever hold references to the entry in the metadata table.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * generator/Metadata.rb:

2018-11-02  Tadeu Zagallo  <tzagallo@apple.com>

        REGRESSION(r237547): Exception handlers should be aware of wide opcodes when JIT is disabled
        https://bugs.webkit.org/show_bug.cgi?id=191175

        Reviewed by Keith Miller.

        https://bugs.webkit.org/show_bug.cgi?id=191108 did not handle the case where JIT is not enabled

        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * llint/LLIntData.h:
        (JSC::LLInt::getWideCodePtr):

2018-11-01  Fujii Hironori  <Hironori.Fujii@sony.com>

        Rename <wtf/unicode/UTF8.h> to <wtf/unicode/UTF8Conversion.h> in order to avoid conflicting with ICU's unicode/utf8.h
        https://bugs.webkit.org/show_bug.cgi?id=189693

        Reviewed by Yusuke Suzuki.

        * API/JSClassRef.cpp: Replaced <wtf/unicode/UTF8.h> with <wtf/unicode/UTF8Conversion.h>.
        * API/JSStringRef.cpp: Ditto.
        * runtime/JSGlobalObjectFunctions.cpp: Ditto.
        * wasm/WasmParser.h: Ditto.

2018-11-01  Keith Miller  <keith_miller@apple.com>

        Unreviewed, JavaScriptCore should only guarantee to produce a
        modulemap if we are building for iOSMac.

        * Configurations/JavaScriptCore.xcconfig:

2018-10-31  Devin Rousso  <drousso@apple.com>

        Web Inspector: Canvas: create a setting for auto-recording newly created contexts
        https://bugs.webkit.org/show_bug.cgi?id=190856

        Reviewed by Brian Burg.

        * inspector/protocol/Canvas.json:
        Add `setRecordingAutoCaptureFrameCount` command for setting the number of frames to record
        immediately after a context is created.

        * inspector/protocol/Recording.json:
        Add `creation` value for `Initiator` enum.

2018-10-31  Devin Rousso  <drousso@apple.com>

        Web Inspector: display low-power enter/exit events in Timelines and Network node waterfalls
        https://bugs.webkit.org/show_bug.cgi?id=190641
        <rdar://problem/45319049>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:
        Add `videoLowPowerChanged` event that is fired when `InspectorDOMAgent` is able to determine
        whether a video element's low power state has changed.

2018-10-31  Tadeu Zagallo  <tzagallo@apple.com>

        Adjust inlining threshold for new bytecode format
        https://bugs.webkit.org/show_bug.cgi?id=191115

        Reviewed by Saam Barati.

        The new format reduced the number of operands for many opcodes, which
        changed inlining decisions and impacted performance negatively.

        * runtime/Options.h:

2018-10-31  Tadeu Zagallo  <tzagallo@apple.com>

        REGRESSION(r237547): Exception handlers should be aware of wide opcodes
        https://bugs.webkit.org/show_bug.cgi?id=191108
        <rdar://problem/45690700>

        Reviewed by Saam Barati.

        When linking the handler, we need to check whether the target op_catch is
        wide or narrow in order to chose the right code pointer for the handler.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):

2018-10-31  Dominik Infuehr  <dinfuehr@igalia.com>

        Align entries in metadata table
        https://bugs.webkit.org/show_bug.cgi?id=191062

        Reviewed by Filip Pizlo.

        Entries in the metadata table need to be aligned on some 32-bit
        architectures.

        * bytecode/MetadataTable.h:
        (JSC::MetadataTable::forEach):
        * bytecode/Opcode.cpp:
        (JSC::metadataAlignment):
        * bytecode/Opcode.h:
        * bytecode/UnlinkedMetadataTableInlines.h:
        (JSC::UnlinkedMetadataTable::finalize):
        * generator/Section.rb:

2018-10-31  Jim Mason  <jmason@ibinx.com>

        Static global 'fastHandlerInstalled' conditionally declared in WasmFaultSignalHandler.cpp
        https://bugs.webkit.org/show_bug.cgi?id=191063

        Reviewed by Yusuke Suzuki.

        * wasm/WasmFaultSignalHandler.cpp:

2018-10-30  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC][LLInt] Compact LLInt ASM code by removing unnecessary instructions
        https://bugs.webkit.org/show_bug.cgi?id=191092

        Reviewed by Saam Barati.

        Looking through LLIntAssembly.h, we can find several inefficiencies. This patch fixes the
        following things to tighten LLInt ASM code.

        1. Remove unnecessary load instructions. Use jmp with BaseIndex directly.
        2. Introduce strength reduction for mul instructions in offlineasm layer. This is now critical
        since mul instruction is executed in `metadata` operation in LLInt. If the given immediate is
        a power of two, we convert it to lshift instruction.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm64.rb:
        * offlineasm/instructions.rb:
        * offlineasm/x86.rb:

2018-10-30  Don Olmstead  <don.olmstead@sony.com>

        [PlayStation] Enable JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=191072

        Reviewed by Brent Fulgham.

        Add platform files for the PlayStation port.

        * PlatformPlayStation.cmake: Added.

2018-10-30  Alexey Proskuryakov  <ap@apple.com>

        Clean up some obsolete MAX_ALLOWED macros
        https://bugs.webkit.org/show_bug.cgi?id=190916

        Reviewed by Tim Horton.

        * API/JSManagedValue.mm:
        * API/JSVirtualMachine.mm:
        * API/JSWrapperMap.mm:

2018-10-30  Ross Kirsling  <ross.kirsling@sony.com>

        useProbeOSRExit causes failures for Win64 DFG JIT
        https://bugs.webkit.org/show_bug.cgi?id=190656

        Reviewed by Keith Miller.

        * assembler/ProbeContext.cpp:
        (JSC::Probe::executeProbe):
        If lowWatermark is expected to equal lowWatermarkFromVisitingDirtyPages *regardless* of the input param,
        then let's just call lowWatermarkFromVisitingDirtyPages instead.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        The result of VariableEventStream::reconstruct appears to be inappropriate for direct use as a stack pointer offset;
        mimic the non-probe case and use requiredRegisterCountForExit from DFGCommonData instead.
        (Also, stop redundantly setting the stack pointer twice in a row.)

2018-10-30  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        "Unreviewed, partial rolling in r237254"
        https://bugs.webkit.org/show_bug.cgi?id=190340

        This only adds Parser.{cpp,h}. And it is not used in this patch.
        It examines that the regression is related to exact Parser changes.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseSingleFunction):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        (JSC::parse):
        (JSC::parseFunctionForFunctionConstructor):

2018-10-29  Mark Lam  <mark.lam@apple.com>

        Correctly detect string overflow when using the 'Function' constructor.
        https://bugs.webkit.org/show_bug.cgi?id=184883
        <rdar://problem/36320331>

        Reviewed by Saam Barati.

        Added StringBuilder::hasOverflowed() checks, and throwing OutOfMemoryErrors if
        we detect an overflow.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode):
        (JSC::decode):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::stringify):
        (JSC::Stringifier::appendStringifiedValue):

2018-10-29  Tadeu Zagallo  <tzagallo@apple.com>

        Unreviewed, fix JSC on arm64e after r237547
        https://bugs.webkit.org/show_bug.cgi?id=187373

        Unreviewed.

        Remove unused move guarded by POINTER_PROFILING that was trashing the
        metadata on arm64e.

        * llint/LowLevelInterpreter64.asm:

2018-10-29  Keith Miller  <keith_miller@apple.com>

        JSC should explicitly list its modulemap file
        https://bugs.webkit.org/show_bug.cgi?id=191032

        Reviewed by Saam Barati.

        The automagically generated module map file for JSC will
        include headers where they may not work out of the box.
        This patch makes it so we now export the same modulemap
        that used to be provided via the legacy system.

        * Configurations/JavaScriptCore.xcconfig:
        * JavaScriptCore.modulemap: Added.
        * JavaScriptCore.xcodeproj/project.pbxproj:

2018-10-29  Tim Horton  <timothy_horton@apple.com>

        Modernize WebKit nibs and lprojs for localization's sake
        https://bugs.webkit.org/show_bug.cgi?id=190911
        <rdar://problem/45349466>

        Reviewed by Dan Bernstein.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        English->en

2018-10-29  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r237492.
        https://bugs.webkit.org/show_bug.cgi?id=191035

        "It regresses JetStream 2 by 5% on some iOS devices"
        (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "Unreviewed, partial rolling in r237254"
        https://bugs.webkit.org/show_bug.cgi?id=190340
        https://trac.webkit.org/changeset/237492

2018-10-29  Tadeu Zagallo  <tzagallo@apple.com>

        Add support for GetStack FlushedDouble
        https://bugs.webkit.org/show_bug.cgi?id=191012
        <rdar://problem/45265141>

        Reviewed by Saam Barati.

        LowerDFGToB3::compileGetStack assumed that we would not emit GetStack
        for doubles, but it turns out it may arise from the PutStack sinking
        phase: if we sink a PutStack into a successor block, other predecessors
        will emit a GetStack followed by a Upsilon.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):

2018-10-29  Tadeu Zagallo  <tzagallo@apple.com>

        New bytecode format for JSC
        https://bugs.webkit.org/show_bug.cgi?id=187373
        <rdar://problem/44186758>

        Reviewed by Filip Pizlo.

        Replace unlinked and linked bytecode with a new immutable bytecode that does not embed
        any addresses. Instructions can be encoded as narrow (1-byte operands) or wide (4-byte
        operands) and might contain an extra operand, the metadataID. The metadataID is used to
        access the instruction's mutable data in a side table in the CodeBlock (the MetadataTable).

        Bytecodes now must be structs declared in the new BytecodeList.rb. All bytecodes give names
        and types to all its operands. Additionally, reading a bytecode from the instruction stream
        requires decoding the whole bytecode, i.e. it's no longer possible to access arbitrary
        operands directly from the stream.


        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::ReturnAddressPtr::ReturnAddressPtr):
        (JSC::ReturnAddressPtr::value const):
        (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
        * bytecode/ArithProfile.h:
        (JSC::ArithProfile::ArithProfile):
        * bytecode/ArrayAllocationProfile.h:
        (JSC::ArrayAllocationProfile::ArrayAllocationProfile):
        * bytecode/ArrayProfile.h:
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isJumpTarget):
        (JSC::BytecodeBasicBlock::computeImpl):
        (JSC::BytecodeBasicBlock::compute):
        * bytecode/BytecodeBasicBlock.h:
        (JSC::BytecodeBasicBlock::leaderOffset const):
        (JSC::BytecodeBasicBlock::totalLength const):
        (JSC::BytecodeBasicBlock::offsets const):
        (JSC::BytecodeBasicBlock::BytecodeBasicBlock):
        (JSC::BytecodeBasicBlock::addLength):
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printLocationAndOp):
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        (JSC::BytecodeDumper<Block>::dumpIdentifiers):
        (JSC::BytecodeDumper<Block>::dumpConstants):
        (JSC::BytecodeDumper<Block>::dumpExceptionHandlers):
        (JSC::BytecodeDumper<Block>::dumpSwitchJumpTables):
        (JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables):
        (JSC::BytecodeDumper<Block>::dumpBlock):
        * bytecode/BytecodeDumper.h:
        (JSC::BytecodeDumper::dumpOperand):
        (JSC::BytecodeDumper::dumpValue):
        (JSC::BytecodeDumper::BytecodeDumper):
        (JSC::BytecodeDumper::block const):
        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
        (JSC::BytecodeGeneratorification::enterPoint const):
        (JSC::BytecodeGeneratorification::instructions const):
        (JSC::GeneratorLivenessAnalysis::run):
        (JSC::BytecodeGeneratorification::run):
        (JSC::performGeneratorification):
        * bytecode/BytecodeGeneratorification.h:
        * bytecode/BytecodeGraph.h:
        (JSC::BytecodeGraph::blockContainsBytecodeOffset):
        (JSC::BytecodeGraph::findBasicBlockForBytecodeOffset):
        (JSC::BytecodeGraph::findBasicBlockWithLeaderOffset):
        (JSC::BytecodeGraph::BytecodeGraph):
        * bytecode/BytecodeKills.h:
        * bytecode/BytecodeList.json: Removed.
        * bytecode/BytecodeList.rb: Added.
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        * bytecode/BytecodeLivenessAnalysis.h:
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::isValidRegisterForLiveness):
        (JSC::BytecodeLivenessPropagation::stepOverInstruction):
        * bytecode/BytecodeRewriter.cpp:
        (JSC::BytecodeRewriter::applyModification):
        (JSC::BytecodeRewriter::execute):
        (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
        (JSC::BytecodeRewriter::insertImpl):
        (JSC::BytecodeRewriter::adjustJumpTarget):
        (JSC::BytecodeRewriter::adjustJumpTargets):
        * bytecode/BytecodeRewriter.h:
        (JSC::BytecodeRewriter::InsertionPoint::InsertionPoint):
        (JSC::BytecodeRewriter::Fragment::Fragment):
        (JSC::BytecodeRewriter::Fragment::appendInstruction):
        (JSC::BytecodeRewriter::BytecodeRewriter):
        (JSC::BytecodeRewriter::insertFragmentBefore):
        (JSC::BytecodeRewriter::insertFragmentAfter):
        (JSC::BytecodeRewriter::removeBytecode):
        (JSC::BytecodeRewriter::adjustAbsoluteOffset):
        (JSC::BytecodeRewriter::adjustJumpTarget):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::estimatedSize):
        (JSC::CodeBlock::visitChildren):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::addJITAddIC):
        (JSC::CodeBlock::addJITMulIC):
        (JSC::CodeBlock::addJITSubIC):
        (JSC::CodeBlock::addJITNegIC):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
        (JSC::CodeBlock::hasOpDebugForLineAndColumn):
        (JSC::CodeBlock::getArrayProfile):
        (JSC::CodeBlock::updateAllArrayPredictions):
        (JSC::CodeBlock::predictedMachineCodeSize):
        (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
        (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
        (JSC::CodeBlock::valueProfileForBytecodeOffset):
        (JSC::CodeBlock::validate):
        (JSC::CodeBlock::outOfLineJumpOffset):
        (JSC::CodeBlock::outOfLineJumpTarget):
        (JSC::CodeBlock::arithProfileForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForPC):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addMathIC):
        (JSC::CodeBlock::outOfLineJumpOffset):
        (JSC::CodeBlock::bytecodeOffset):
        (JSC::CodeBlock::instructions const):
        (JSC::CodeBlock::instructionCount const):
        (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::metadata):
        (JSC::CodeBlock::metadataSizeInBytes):
        (JSC::CodeBlock::numberOfNonArgumentValueProfiles):
        (JSC::CodeBlock::totalNumberOfValueProfiles):
        * bytecode/CodeBlockInlines.h: Added.
        (JSC::CodeBlock::forEachValueProfile):
        (JSC::CodeBlock::forEachArrayProfile):
        (JSC::CodeBlock::forEachArrayAllocationProfile):
        (JSC::CodeBlock::forEachObjectAllocationProfile):
        (JSC::CodeBlock::forEachLLIntCallLinkInfo):
        * bytecode/Fits.h: Added.
        * bytecode/GetByIdMetadata.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        (JSC::Instruction::Impl::opcodeID const):
        (JSC::Instruction::opcodeID const):
        (JSC::Instruction::name const):
        (JSC::Instruction::isWide const):
        (JSC::Instruction::size const):
        (JSC::Instruction::is const):
        (JSC::Instruction::as const):
        (JSC::Instruction::cast):
        (JSC::Instruction::cast const):
        (JSC::Instruction::narrow const):
        (JSC::Instruction::wide const):
        * bytecode/InstructionStream.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        (JSC::InstructionStream::InstructionStream):
        (JSC::InstructionStream::sizeInBytes const):
        * bytecode/InstructionStream.h: Added.
        (JSC::InstructionStream::BaseRef::BaseRef):
        (JSC::InstructionStream::BaseRef::operator=):
        (JSC::InstructionStream::BaseRef::operator-> const):
        (JSC::InstructionStream::BaseRef::ptr const):
        (JSC::InstructionStream::BaseRef::operator!= const):
        (JSC::InstructionStream::BaseRef::next const):
        (JSC::InstructionStream::BaseRef::offset const):
        (JSC::InstructionStream::BaseRef::isValid const):
        (JSC::InstructionStream::BaseRef::unwrap const):
        (JSC::InstructionStream::MutableRef::freeze const):
        (JSC::InstructionStream::MutableRef::operator->):
        (JSC::InstructionStream::MutableRef::ptr):
        (JSC::InstructionStream::MutableRef::operator Ref):
        (JSC::InstructionStream::MutableRef::unwrap):
        (JSC::InstructionStream::iterator::operator*):
        (JSC::InstructionStream::iterator::operator++):
        (JSC::InstructionStream::begin const):
        (JSC::InstructionStream::end const):
        (JSC::InstructionStream::at const):
        (JSC::InstructionStream::size const):
        (JSC::InstructionStreamWriter::InstructionStreamWriter):
        (JSC::InstructionStreamWriter::ref):
        (JSC::InstructionStreamWriter::seek):
        (JSC::InstructionStreamWriter::position):
        (JSC::InstructionStreamWriter::write):
        (JSC::InstructionStreamWriter::rewind):
        (JSC::InstructionStreamWriter::finalize):
        (JSC::InstructionStreamWriter::swap):
        (JSC::InstructionStreamWriter::iterator::operator*):
        (JSC::InstructionStreamWriter::iterator::operator++):
        (JSC::InstructionStreamWriter::begin):
        (JSC::InstructionStreamWriter::end):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
        * bytecode/MetadataTable.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        (JSC::MetadataTable::MetadataTable):
        (JSC::DeallocTable::withOpcodeType):
        (JSC::MetadataTable::~MetadataTable):
        (JSC::MetadataTable::sizeInBytes):
        * bytecode/MetadataTable.h: Copied from Source/JavaScriptCore/runtime/Watchdog.h.
        (JSC::MetadataTable::get):
        (JSC::MetadataTable::forEach):
        (JSC::MetadataTable::getImpl):
        * bytecode/Opcode.cpp:
        (JSC::metadataSize):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecode/OpcodeInlines.h:
        (JSC::isOpcodeShape):
        (JSC::getOpcodeType):
        * bytecode/OpcodeSize.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForInstruction):
        (JSC::computePreciseJumpTargetsInternal):
        (JSC::computePreciseJumpTargets):
        (JSC::recomputePreciseJumpTargets):
        (JSC::findJumpTargetsForInstruction):
        * bytecode/PreciseJumpTargets.h:
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::jumpTargetForInstruction):
        (JSC::extractStoredJumpTargetsForInstruction):
        (JSC::updateStoredJumpTargetsForInstruction):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        * bytecode/SpecialPointer.cpp:
        (WTF::printInternal):
        * bytecode/SpecialPointer.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::UnlinkedCodeBlock::visitChildren):
        (JSC::UnlinkedCodeBlock::estimatedSize):
        (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
        (JSC::dumpLineColumnEntry):
        (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset const):
        (JSC::UnlinkedCodeBlock::setInstructions):
        (JSC::UnlinkedCodeBlock::instructions const):
        (JSC::UnlinkedCodeBlock::applyModification):
        (JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget):
        (JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
        (JSC::UnlinkedCodeBlock::propertyAccessInstructions const):
        (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
        (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const):
        (JSC::UnlinkedCodeBlock::metadata):
        (JSC::UnlinkedCodeBlock::metadataSizeInBytes):
        (JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
        (JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets):
        * bytecode/UnlinkedInstructionStream.cpp: Removed.
        * bytecode/UnlinkedInstructionStream.h: Removed.
        * bytecode/UnlinkedMetadataTable.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
        * bytecode/UnlinkedMetadataTableInlines.h: Added.
        (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
        (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
        (JSC::UnlinkedMetadataTable::addEntry):
        (JSC::UnlinkedMetadataTable::sizeInBytes):
        (JSC::UnlinkedMetadataTable::finalize):
        (JSC::UnlinkedMetadataTable::link):
        (JSC::UnlinkedMetadataTable::unlink):
        * bytecode/VirtualRegister.cpp:
        (JSC::VirtualRegister::VirtualRegister):
        * bytecode/VirtualRegister.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::Label::setLocation):
        (JSC::Label::bind):
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
        (JSC::BytecodeGenerator::emitEnter):
        (JSC::BytecodeGenerator::emitLoopHint):
        (JSC::BytecodeGenerator::emitJump):
        (JSC::BytecodeGenerator::emitCheckTraps):
        (JSC::BytecodeGenerator::rewind):
        (JSC::BytecodeGenerator::fuseCompareAndJump):
        (JSC::BytecodeGenerator::fuseTestAndJmp):
        (JSC::BytecodeGenerator::emitJumpIfTrue):
        (JSC::BytecodeGenerator::emitJumpIfFalse):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
        (JSC::BytecodeGenerator::moveLinkTimeConstant):
        (JSC::BytecodeGenerator::moveEmptyValue):
        (JSC::BytecodeGenerator::emitMove):
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::emitBinaryOp):
        (JSC::BytecodeGenerator::emitToObject):
        (JSC::BytecodeGenerator::emitToNumber):
        (JSC::BytecodeGenerator::emitToString):
        (JSC::BytecodeGenerator::emitTypeOf):
        (JSC::BytecodeGenerator::emitInc):
        (JSC::BytecodeGenerator::emitDec):
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::emitProfileType):
        (JSC::BytecodeGenerator::emitProfileControlFlow):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::emitOverridesHasInstance):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitGetFromScope):
        (JSC::BytecodeGenerator::emitPutToScope):
        (JSC::BytecodeGenerator::emitInstanceOf):
        (JSC::BytecodeGenerator::emitInstanceOfCustom):
        (JSC::BytecodeGenerator::emitInByVal):
        (JSC::BytecodeGenerator::emitInById):
        (JSC::BytecodeGenerator::emitTryGetById):
        (JSC::BytecodeGenerator::emitGetById):
        (JSC::BytecodeGenerator::emitDirectGetById):
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        (JSC::BytecodeGenerator::emitPutGetterById):
        (JSC::BytecodeGenerator::emitPutSetterById):
        (JSC::BytecodeGenerator::emitPutGetterSetter):
        (JSC::BytecodeGenerator::emitPutGetterByVal):
        (JSC::BytecodeGenerator::emitPutSetterByVal):
        (JSC::BytecodeGenerator::emitDeleteById):
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::emitPutByVal):
        (JSC::BytecodeGenerator::emitDirectPutByVal):
        (JSC::BytecodeGenerator::emitDeleteByVal):
        (JSC::BytecodeGenerator::emitSuperSamplerBegin):
        (JSC::BytecodeGenerator::emitSuperSamplerEnd):
        (JSC::BytecodeGenerator::emitIdWithProfile):
        (JSC::BytecodeGenerator::emitUnreachable):
        (JSC::BytecodeGenerator::emitGetArgument):
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitTDZCheck):
        (JSC::BytecodeGenerator::emitNewObject):
        (JSC::BytecodeGenerator::emitNewArrayBuffer):
        (JSC::BytecodeGenerator::emitNewArray):
        (JSC::BytecodeGenerator::emitNewArrayWithSpread):
        (JSC::BytecodeGenerator::emitNewArrayWithSize):
        (JSC::BytecodeGenerator::emitNewRegExp):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewDefaultConstructor):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        (JSC::BytecodeGenerator::emitCallEval):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
        (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
        (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
        (JSC::BytecodeGenerator::emitCallDefineProperty):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitEnd):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::emitStrcat):
        (JSC::BytecodeGenerator::emitToPrimitive):
        (JSC::BytecodeGenerator::emitGetScope):
        (JSC::BytecodeGenerator::emitPushWithScope):
        (JSC::BytecodeGenerator::emitGetParentScope):
        (JSC::BytecodeGenerator::emitDebugHook):
        (JSC::BytecodeGenerator::emitCatch):
        (JSC::BytecodeGenerator::emitThrow):
        (JSC::BytecodeGenerator::emitArgumentCount):
        (JSC::BytecodeGenerator::emitThrowStaticError):
        (JSC::BytecodeGenerator::beginSwitch):
        (JSC::prepareJumpTableForSwitch):
        (JSC::prepareJumpTableForStringSwitch):
        (JSC::BytecodeGenerator::endSwitch):
        (JSC::BytecodeGenerator::emitGetEnumerableLength):
        (JSC::BytecodeGenerator::emitHasGenericProperty):
        (JSC::BytecodeGenerator::emitHasIndexedProperty):
        (JSC::BytecodeGenerator::emitHasStructureProperty):
        (JSC::BytecodeGenerator::emitGetPropertyEnumerator):
        (JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
        (JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
        (JSC::BytecodeGenerator::emitToIndexString):
        (JSC::BytecodeGenerator::emitIsCellWithType):
        (JSC::BytecodeGenerator::emitIsObject):
        (JSC::BytecodeGenerator::emitIsNumber):
        (JSC::BytecodeGenerator::emitIsUndefined):
        (JSC::BytecodeGenerator::emitIsEmpty):
        (JSC::BytecodeGenerator::emitRestParameter):
        (JSC::BytecodeGenerator::emitRequireObjectCoercible):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitGetAsyncIterator):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        (JSC::BytecodeGenerator::emitJumpIf):
        (JSC::ForInContext::finalize):
        (JSC::StructureForInContext::finalize):
        (JSC::IndexedForInContext::finalize):
        (JSC::StaticPropertyAnalysis::record):
        (JSC::BytecodeGenerator::emitToThis):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::StructureForInContext::addGetInst):
        (JSC::BytecodeGenerator::recordOpcode):
        (JSC::BytecodeGenerator::addMetadataFor):
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::kill):
        (JSC::BytecodeGenerator::instructions const):
        (JSC::BytecodeGenerator::write):
        (JSC::BytecodeGenerator::withWriter):
        * bytecompiler/Label.h:
        (JSC::Label::Label):
        (JSC::Label::bind):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::emitBytecode):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::BitwiseNotNode::emitBytecode):
        (JSC::BinaryOpNode::emitBytecode):
        (JSC::EqualNode::emitBytecode):
        (JSC::StrictEqualNode::emitBytecode):
        (JSC::emitReadModifyAssignment):
        (JSC::ForInNode::emitBytecode):
        (JSC::CaseBlockNode::emitBytecodeForBlock):
        (JSC::FunctionNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        * bytecompiler/ProfileTypeBytecodeFlag.cpp: Copied from Source/JavaScriptCore/bytecode/VirtualRegister.cpp.
        (WTF::printInternal):
        * bytecompiler/ProfileTypeBytecodeFlag.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        * bytecompiler/RegisterID.h:
        * bytecompiler/StaticPropertyAnalysis.h:
        (JSC::StaticPropertyAnalysis::create):
        (JSC::StaticPropertyAnalysis::StaticPropertyAnalysis):
        * bytecompiler/StaticPropertyAnalyzer.h:
        (JSC::StaticPropertyAnalyzer::createThis):
        (JSC::StaticPropertyAnalyzer::newObject):
        (JSC::StaticPropertyAnalyzer::putById):
        (JSC::StaticPropertyAnalyzer::mov):
        (JSC::StaticPropertyAnalyzer::kill):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleCallVariant):
        (JSC::DFG::ByteCodeParser::handleVarargsInlining):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleMinMax):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleDOMJITCall):
        (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
        (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
        (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        (JSC::DFG::ByteCodeParser::handlePutByVal):
        (JSC::DFG::ByteCodeParser::handlePutAccessorById):
        (JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
        (JSC::DFG::ByteCodeParser::handleNewFunc):
        (JSC::DFG::ByteCodeParser::handleNewFuncExp):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareCatchOSREntry):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileValueSub):
        (JSC::DFG::SpeculativeJIT::compileValueNegate):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * generate-bytecode-files: Removed.
        * generator/Argument.rb: Added.
        * generator/Assertion.rb: Added.
        * generator/DSL.rb: Added.
        * generator/Fits.rb: Added.
        * generator/GeneratedFile.rb: Added.
        * generator/Metadata.rb: Added.
        * generator/Opcode.rb: Added.
        * generator/OpcodeGroup.rb: Added.
        * generator/Options.rb: Added.
        * generator/Section.rb: Added.
        * generator/Template.rb: Added.
        * generator/Type.rb: Added.
        * generator/main.rb: Added.
        * interpreter/AbstractPC.h:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::currentVPC const):
        (JSC::CallFrame::setCurrentVPC):
        * interpreter/CallFrame.h:
        (JSC::CallSiteIndex::CallSiteIndex):
        (JSC::ExecState::setReturnPC):
        * interpreter/Interpreter.cpp:
        (WTF::printInternal):
        * interpreter/Interpreter.h:
        * interpreter/InterpreterInlines.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::dump const):
        * interpreter/VMEntryRecord.h:
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::emitSlowCaseCall):
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::link):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_jless):
        (JSC::JIT::emit_op_jlesseq):
        (JSC::JIT::emit_op_jgreater):
        (JSC::JIT::emit_op_jgreatereq):
        (JSC::JIT::emit_op_jnless):
        (JSC::JIT::emit_op_jnlesseq):
        (JSC::JIT::emit_op_jngreater):
        (JSC::JIT::emit_op_jngreatereq):
        (JSC::JIT::emitSlow_op_jless):
        (JSC::JIT::emitSlow_op_jlesseq):
        (JSC::JIT::emitSlow_op_jgreater):
        (JSC::JIT::emitSlow_op_jgreatereq):
        (JSC::JIT::emitSlow_op_jnless):
        (JSC::JIT::emitSlow_op_jnlesseq):
        (JSC::JIT::emitSlow_op_jngreater):
        (JSC::JIT::emitSlow_op_jngreatereq):
        (JSC::JIT::emit_op_below):
        (JSC::JIT::emit_op_beloweq):
        (JSC::JIT::emit_op_jbelow):
        (JSC::JIT::emit_op_jbeloweq):
        (JSC::JIT::emit_op_unsigned):
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_inc):
        (JSC::JIT::emit_op_dec):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::emitSlow_op_mod):
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitBitBinaryOpFastPath):
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::emit_op_bitor):
        (JSC::JIT::emit_op_bitxor):
        (JSC::JIT::emit_op_lshift):
        (JSC::JIT::emitRightShiftFastPath):
        (JSC::JIT::emit_op_rshift):
        (JSC::JIT::emit_op_urshift):
        (JSC::getOperandTypes):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITCall.cpp:
        (JSC::JIT::emitPutCallResult):
        (JSC::JIT::compileSetupFrame):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileTailCall):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::emit_op_construct):
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        (JSC::JIT::emitSlow_op_construct_varargs):
        (JSC::JIT::emitSlow_op_construct):
        * jit/JITDisassembler.cpp:
        (JSC::JITDisassembler::JITDisassembler):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITInlines.h:
        (JSC::JIT::emitDoubleGetByVal):
        (JSC::JIT::emitLoadForArrayMode):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
        (JSC::JIT::sampleInstruction):
        (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
        (JSC::JIT::emitValueProfilingSite):
        (JSC::JIT::jumpTarget):
        (JSC::JIT::copiedGetPutInfo):
        (JSC::JIT::copiedArithProfile):
        * jit/JITMathIC.h:
        (JSC::isProfileEmpty):
        (JSC::JITBinaryMathIC::JITBinaryMathIC):
        (JSC::JITUnaryMathIC::JITUnaryMathIC):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_mov):
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_jmp):
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emit_op_instanceof_custom):
        (JSC::JIT::emit_op_is_empty):
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_is_boolean):
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_is_cell_with_type):
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::emit_op_set_function_name):
        (JSC::JIT::emit_op_not):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        (JSC::JIT::emit_op_jeq):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_neq):
        (JSC::JIT::emit_op_jneq):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::emit_op_stricteq):
        (JSC::JIT::emit_op_nstricteq):
        (JSC::JIT::compileOpStrictEqJump):
        (JSC::JIT::emit_op_jstricteq):
        (JSC::JIT::emit_op_jnstricteq):
        (JSC::JIT::emitSlow_op_jstricteq):
        (JSC::JIT::emitSlow_op_jnstricteq):
        (JSC::JIT::emit_op_to_number):
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emit_op_to_object):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_identity_with_profile):
        (JSC::JIT::emit_op_get_parent_scope):
        (JSC::JIT::emit_op_switch_imm):
        (JSC::JIT::emit_op_switch_char):
        (JSC::JIT::emit_op_switch_string):
        (JSC::JIT::emit_op_debug):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emit_op_enter):
        (JSC::JIT::emit_op_get_scope):
        (JSC::JIT::emit_op_to_this):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_check_tdz):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::emitSlow_op_jeq):
        (JSC::JIT::emitSlow_op_jneq):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_loop_hint):
        (JSC::JIT::emitSlow_op_loop_hint):
        (JSC::JIT::emit_op_check_traps):
        (JSC::JIT::emit_op_nop):
        (JSC::JIT::emit_op_super_sampler_begin):
        (JSC::JIT::emit_op_super_sampler_end):
        (JSC::JIT::emitSlow_op_check_traps):
        (JSC::JIT::emit_op_new_regexp):
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_new_generator_func):
        (JSC::JIT::emit_op_new_async_generator_func):
        (JSC::JIT::emit_op_new_async_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emit_op_new_generator_func_exp):
        (JSC::JIT::emit_op_new_async_func_exp):
        (JSC::JIT::emit_op_new_async_generator_func_exp):
        (JSC::JIT::emit_op_new_array):
        (JSC::JIT::emit_op_new_array_with_size):
        (JSC::JIT::emit_op_has_structure_property):
        (JSC::JIT::privateCompileHasIndexedProperty):
        (JSC::JIT::emit_op_has_indexed_property):
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        (JSC::JIT::emit_op_profile_control_flow):
        (JSC::JIT::emit_op_argument_count):
        (JSC::JIT::emit_op_get_rest_length):
        (JSC::JIT::emit_op_get_argument):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_this):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val_direct):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_by_val):
        (JSC::JIT::emit_op_put_setter_by_val):
        (JSC::JIT::emit_op_del_by_id):
        (JSC::JIT::emit_op_del_by_val):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id_direct):
        (JSC::JIT::emitSlow_op_get_by_id_direct):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emit_op_in_by_id):
        (JSC::JIT::emitSlow_op_in_by_id):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompileGetByValWithCachedId):
        (JSC::JIT::privateCompilePutByVal):
        (JSC::JIT::privateCompilePutByValWithCachedId):
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        (JSC::JIT::emitDirectArgumentsGetByVal):
        (JSC::JIT::emitScopedArgumentsGetByVal):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::JITSlowPathCall):
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntData.h:
        (JSC::LLInt::exceptionInstructions):
        (JSC::LLInt::opcodeMap):
        (JSC::LLInt::opcodeMapWide):
        (JSC::LLInt::getOpcode):
        (JSC::LLInt::getOpcodeWide):
        (JSC::LLInt::getWideCodePtr):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_trace_operand):
        (JSC::LLInt::llint_trace_value):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::getByVal):
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        (JSC::LLInt::genericCall):
        (JSC::LLInt::varargsSetup):
        (JSC::LLInt::commonCallEval):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoopRegister::operator const Instruction*):
        (JSC::CLoop::execute):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm64.rb:
        * offlineasm/asm.rb:
        * offlineasm/ast.rb:
        * offlineasm/cloop.rb:
        * offlineasm/generate_offset_extractor.rb:
        * offlineasm/instructions.rb:
        * offlineasm/offsets.rb:
        * offlineasm/parser.rb:
        * offlineasm/transform.rb:
        * offlineasm/x86.rb:
        * parser/ResultType.h:
        (JSC::ResultType::dump const):
        (JSC::OperandTypes::first const):
        (JSC::OperandTypes::second const):
        (JSC::OperandTypes::dump const):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::BytecodeSequence):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        (JSC::updateArithProfileForUnaryArithOp):
        (JSC::updateArithProfileForBinaryArithOp):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/ExceptionFuzz.cpp:
        (JSC::doExceptionFuzzing):
        * runtime/ExceptionFuzz.h:
        (JSC::doExceptionFuzzingIfEnabled):
        * runtime/GetPutInfo.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        (JSC::GetPutInfo::dump const):
        (WTF::printInternal):
        * runtime/GetPutInfo.h:
        (JSC::GetPutInfo::operand const):
        * runtime/JSCPoison.h:
        * runtime/JSType.cpp: Added.
        (WTF::printInternal):
        * runtime/JSType.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::displayName):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
        * runtime/SlowPathReturnType.h:
        (JSC::encodeResult):
        (JSC::decodeResult):
        * runtime/VM.h:
        * runtime/Watchdog.h:
        * tools/HeapVerifier.cpp:

2018-10-27  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, partial rolling in r237254
        https://bugs.webkit.org/show_bug.cgi?id=190340

        We do not use the added function right now to investigate what is the reason of the regression.
        It also does not include any Parser.{h,cpp} changes to ensure that Parser.cpp's inlining decision
        seems culprit of the regression on iOS devices.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator== const):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/CodeCache.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/FunctionExecutable.h:

2018-10-26  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r237479 and r237484.
        https://bugs.webkit.org/show_bug.cgi?id=190978

        broke JSC on iOS (Requested by tadeuzagallo on #webkit).

        Reverted changesets:

        "New bytecode format for JSC"
        https://bugs.webkit.org/show_bug.cgi?id=187373
        https://trac.webkit.org/changeset/237479

        "Gardening: Build fix after r237479."
        https://bugs.webkit.org/show_bug.cgi?id=187373
        https://trac.webkit.org/changeset/237484

2018-10-26  Tadeu Zagallo  <tzagallo@apple.com>

        Gardening: Build fix after r237479.
        https://bugs.webkit.org/show_bug.cgi?id=187373

        Unreviewed.

        * Configurations/JSC.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):

2018-10-26  Tadeu Zagallo  <tzagallo@apple.com>

        New bytecode format for JSC
        https://bugs.webkit.org/show_bug.cgi?id=187373
        <rdar://problem/44186758>

        Reviewed by Filip Pizlo.

        Replace unlinked and linked bytecode with a new immutable bytecode that does not embed
        any addresses. Instructions can be encoded as narrow (1-byte operands) or wide (4-byte
        operands) and might contain an extra operand, the metadataID. The metadataID is used to
        access the instruction's mutable data in a side table in the CodeBlock (the MetadataTable).

        Bytecodes now must be structs declared in the new BytecodeList.rb. All bytecodes give names
        and types to all its operands. Additionally, reading a bytecode from the instruction stream
        requires decoding the whole bytecode, i.e. it's no longer possible to access arbitrary
        operands directly from the stream.


        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::ReturnAddressPtr::ReturnAddressPtr):
        (JSC::ReturnAddressPtr::value const):
        (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
        * bytecode/ArithProfile.h:
        (JSC::ArithProfile::ArithProfile):
        * bytecode/ArrayAllocationProfile.h:
        (JSC::ArrayAllocationProfile::ArrayAllocationProfile):
        * bytecode/ArrayProfile.h:
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isJumpTarget):
        (JSC::BytecodeBasicBlock::computeImpl):
        (JSC::BytecodeBasicBlock::compute):
        * bytecode/BytecodeBasicBlock.h:
        (JSC::BytecodeBasicBlock::leaderOffset const):
        (JSC::BytecodeBasicBlock::totalLength const):
        (JSC::BytecodeBasicBlock::offsets const):
        (JSC::BytecodeBasicBlock::BytecodeBasicBlock):
        (JSC::BytecodeBasicBlock::addLength):
        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::printLocationAndOp):
        (JSC::BytecodeDumper<Block>::dumpBytecode):
        (JSC::BytecodeDumper<Block>::dumpIdentifiers):
        (JSC::BytecodeDumper<Block>::dumpConstants):
        (JSC::BytecodeDumper<Block>::dumpExceptionHandlers):
        (JSC::BytecodeDumper<Block>::dumpSwitchJumpTables):
        (JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables):
        (JSC::BytecodeDumper<Block>::dumpBlock):
        * bytecode/BytecodeDumper.h:
        (JSC::BytecodeDumper::dumpOperand):
        (JSC::BytecodeDumper::dumpValue):
        (JSC::BytecodeDumper::BytecodeDumper):
        (JSC::BytecodeDumper::block const):
        * bytecode/BytecodeGeneratorification.cpp:
        (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
        (JSC::BytecodeGeneratorification::enterPoint const):
        (JSC::BytecodeGeneratorification::instructions const):
        (JSC::GeneratorLivenessAnalysis::run):
        (JSC::BytecodeGeneratorification::run):
        (JSC::performGeneratorification):
        * bytecode/BytecodeGeneratorification.h:
        * bytecode/BytecodeGraph.h:
        (JSC::BytecodeGraph::blockContainsBytecodeOffset):
        (JSC::BytecodeGraph::findBasicBlockForBytecodeOffset):
        (JSC::BytecodeGraph::findBasicBlockWithLeaderOffset):
        (JSC::BytecodeGraph::BytecodeGraph):
        * bytecode/BytecodeKills.h:
        * bytecode/BytecodeList.json: Removed.
        * bytecode/BytecodeList.rb: Added.
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::BytecodeLivenessAnalysis::dumpResults):
        * bytecode/BytecodeLivenessAnalysis.h:
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::isValidRegisterForLiveness):
        (JSC::BytecodeLivenessPropagation::stepOverInstruction):
        * bytecode/BytecodeRewriter.cpp:
        (JSC::BytecodeRewriter::applyModification):
        (JSC::BytecodeRewriter::execute):
        (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
        (JSC::BytecodeRewriter::insertImpl):
        (JSC::BytecodeRewriter::adjustJumpTarget):
        (JSC::BytecodeRewriter::adjustJumpTargets):
        * bytecode/BytecodeRewriter.h:
        (JSC::BytecodeRewriter::InsertionPoint::InsertionPoint):
        (JSC::BytecodeRewriter::Fragment::Fragment):
        (JSC::BytecodeRewriter::Fragment::appendInstruction):
        (JSC::BytecodeRewriter::BytecodeRewriter):
        (JSC::BytecodeRewriter::insertFragmentBefore):
        (JSC::BytecodeRewriter::insertFragmentAfter):
        (JSC::BytecodeRewriter::removeBytecode):
        (JSC::BytecodeRewriter::adjustAbsoluteOffset):
        (JSC::BytecodeRewriter::adjustJumpTarget):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::estimatedSize):
        (JSC::CodeBlock::visitChildren):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::addJITAddIC):
        (JSC::CodeBlock::addJITMulIC):
        (JSC::CodeBlock::addJITSubIC):
        (JSC::CodeBlock::addJITNegIC):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset):
        (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
        (JSC::CodeBlock::hasOpDebugForLineAndColumn):
        (JSC::CodeBlock::getArrayProfile):
        (JSC::CodeBlock::updateAllArrayPredictions):
        (JSC::CodeBlock::predictedMachineCodeSize):
        (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset):
        (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
        (JSC::CodeBlock::valueProfileForBytecodeOffset):
        (JSC::CodeBlock::validate):
        (JSC::CodeBlock::outOfLineJumpOffset):
        (JSC::CodeBlock::outOfLineJumpTarget):
        (JSC::CodeBlock::arithProfileForBytecodeOffset):
        (JSC::CodeBlock::arithProfileForPC):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addMathIC):
        (JSC::CodeBlock::outOfLineJumpOffset):
        (JSC::CodeBlock::bytecodeOffset):
        (JSC::CodeBlock::instructions const):
        (JSC::CodeBlock::instructionCount const):
        (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::metadata):
        (JSC::CodeBlock::metadataSizeInBytes):
        (JSC::CodeBlock::numberOfNonArgumentValueProfiles):
        (JSC::CodeBlock::totalNumberOfValueProfiles):
        * bytecode/CodeBlockInlines.h: Added.
        (JSC::CodeBlock::forEachValueProfile):
        (JSC::CodeBlock::forEachArrayProfile):
        (JSC::CodeBlock::forEachArrayAllocationProfile):
        (JSC::CodeBlock::forEachObjectAllocationProfile):
        (JSC::CodeBlock::forEachLLIntCallLinkInfo):
        * bytecode/Fits.h: Added.
        * bytecode/GetByIdMetadata.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        (JSC::Instruction::Impl::opcodeID const):
        (JSC::Instruction::opcodeID const):
        (JSC::Instruction::name const):
        (JSC::Instruction::isWide const):
        (JSC::Instruction::size const):
        (JSC::Instruction::is const):
        (JSC::Instruction::as const):
        (JSC::Instruction::cast):
        (JSC::Instruction::cast const):
        (JSC::Instruction::narrow const):
        (JSC::Instruction::wide const):
        * bytecode/InstructionStream.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        (JSC::InstructionStream::InstructionStream):
        (JSC::InstructionStream::sizeInBytes const):
        * bytecode/InstructionStream.h: Added.
        (JSC::InstructionStream::BaseRef::BaseRef):
        (JSC::InstructionStream::BaseRef::operator=):
        (JSC::InstructionStream::BaseRef::operator-> const):
        (JSC::InstructionStream::BaseRef::ptr const):
        (JSC::InstructionStream::BaseRef::operator!= const):
        (JSC::InstructionStream::BaseRef::next const):
        (JSC::InstructionStream::BaseRef::offset const):
        (JSC::InstructionStream::BaseRef::isValid const):
        (JSC::InstructionStream::BaseRef::unwrap const):
        (JSC::InstructionStream::MutableRef::freeze const):
        (JSC::InstructionStream::MutableRef::operator->):
        (JSC::InstructionStream::MutableRef::ptr):
        (JSC::InstructionStream::MutableRef::operator Ref):
        (JSC::InstructionStream::MutableRef::unwrap):
        (JSC::InstructionStream::iterator::operator*):
        (JSC::InstructionStream::iterator::operator++):
        (JSC::InstructionStream::begin const):
        (JSC::InstructionStream::end const):
        (JSC::InstructionStream::at const):
        (JSC::InstructionStream::size const):
        (JSC::InstructionStreamWriter::InstructionStreamWriter):
        (JSC::InstructionStreamWriter::ref):
        (JSC::InstructionStreamWriter::seek):
        (JSC::InstructionStreamWriter::position):
        (JSC::InstructionStreamWriter::write):
        (JSC::InstructionStreamWriter::rewind):
        (JSC::InstructionStreamWriter::finalize):
        (JSC::InstructionStreamWriter::swap):
        (JSC::InstructionStreamWriter::iterator::operator*):
        (JSC::InstructionStreamWriter::iterator::operator++):
        (JSC::InstructionStreamWriter::begin):
        (JSC::InstructionStreamWriter::end):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
        (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
        * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
        * bytecode/MetadataTable.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        (JSC::MetadataTable::MetadataTable):
        (JSC::DeallocTable::withOpcodeType):
        (JSC::MetadataTable::~MetadataTable):
        (JSC::MetadataTable::sizeInBytes):
        * bytecode/MetadataTable.h: Copied from Source/JavaScriptCore/runtime/Watchdog.h.
        (JSC::MetadataTable::get):
        (JSC::MetadataTable::forEach):
        (JSC::MetadataTable::getImpl):
        * bytecode/Opcode.cpp:
        (JSC::metadataSize):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecode/OpcodeInlines.h:
        (JSC::isOpcodeShape):
        (JSC::getOpcodeType):
        * bytecode/OpcodeSize.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForInstruction):
        (JSC::computePreciseJumpTargetsInternal):
        (JSC::computePreciseJumpTargets):
        (JSC::recomputePreciseJumpTargets):
        (JSC::findJumpTargetsForInstruction):
        * bytecode/PreciseJumpTargets.h:
        * bytecode/PreciseJumpTargetsInlines.h:
        (JSC::jumpTargetForInstruction):
        (JSC::extractStoredJumpTargetsForInstruction):
        (JSC::updateStoredJumpTargetsForInstruction):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        * bytecode/SpecialPointer.cpp:
        (WTF::printInternal):
        * bytecode/SpecialPointer.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        (JSC::UnlinkedCodeBlock::visitChildren):
        (JSC::UnlinkedCodeBlock::estimatedSize):
        (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
        (JSC::dumpLineColumnEntry):
        (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset const):
        (JSC::UnlinkedCodeBlock::setInstructions):
        (JSC::UnlinkedCodeBlock::instructions const):
        (JSC::UnlinkedCodeBlock::applyModification):
        (JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget):
        (JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
        (JSC::UnlinkedCodeBlock::propertyAccessInstructions const):
        (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
        (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const):
        (JSC::UnlinkedCodeBlock::metadata):
        (JSC::UnlinkedCodeBlock::metadataSizeInBytes):
        (JSC::UnlinkedCodeBlock::outOfLineJumpOffset):
        (JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets):
        * bytecode/UnlinkedInstructionStream.cpp: Removed.
        * bytecode/UnlinkedInstructionStream.h: Removed.
        * bytecode/UnlinkedMetadataTable.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h.
        * bytecode/UnlinkedMetadataTableInlines.h: Added.
        (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
        (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable):
        (JSC::UnlinkedMetadataTable::addEntry):
        (JSC::UnlinkedMetadataTable::sizeInBytes):
        (JSC::UnlinkedMetadataTable::finalize):
        (JSC::UnlinkedMetadataTable::link):
        (JSC::UnlinkedMetadataTable::unlink):
        * bytecode/VirtualRegister.cpp:
        (JSC::VirtualRegister::VirtualRegister):
        * bytecode/VirtualRegister.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::Label::setLocation):
        (JSC::Label::bind):
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
        (JSC::BytecodeGenerator::emitEnter):
        (JSC::BytecodeGenerator::emitLoopHint):
        (JSC::BytecodeGenerator::emitJump):
        (JSC::BytecodeGenerator::emitCheckTraps):
        (JSC::BytecodeGenerator::rewind):
        (JSC::BytecodeGenerator::fuseCompareAndJump):
        (JSC::BytecodeGenerator::fuseTestAndJmp):
        (JSC::BytecodeGenerator::emitJumpIfTrue):
        (JSC::BytecodeGenerator::emitJumpIfFalse):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
        (JSC::BytecodeGenerator::moveLinkTimeConstant):
        (JSC::BytecodeGenerator::moveEmptyValue):
        (JSC::BytecodeGenerator::emitMove):
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::emitBinaryOp):
        (JSC::BytecodeGenerator::emitToObject):
        (JSC::BytecodeGenerator::emitToNumber):
        (JSC::BytecodeGenerator::emitToString):
        (JSC::BytecodeGenerator::emitTypeOf):
        (JSC::BytecodeGenerator::emitInc):
        (JSC::BytecodeGenerator::emitDec):
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::emitProfileType):
        (JSC::BytecodeGenerator::emitProfileControlFlow):
        (JSC::BytecodeGenerator::pushLexicalScopeInternal):
        (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
        (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
        (JSC::BytecodeGenerator::emitOverridesHasInstance):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitGetFromScope):
        (JSC::BytecodeGenerator::emitPutToScope):
        (JSC::BytecodeGenerator::emitInstanceOf):
        (JSC::BytecodeGenerator::emitInstanceOfCustom):
        (JSC::BytecodeGenerator::emitInByVal):
        (JSC::BytecodeGenerator::emitInById):
        (JSC::BytecodeGenerator::emitTryGetById):
        (JSC::BytecodeGenerator::emitGetById):
        (JSC::BytecodeGenerator::emitDirectGetById):
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        (JSC::BytecodeGenerator::emitPutGetterById):
        (JSC::BytecodeGenerator::emitPutSetterById):
        (JSC::BytecodeGenerator::emitPutGetterSetter):
        (JSC::BytecodeGenerator::emitPutGetterByVal):
        (JSC::BytecodeGenerator::emitPutSetterByVal):
        (JSC::BytecodeGenerator::emitDeleteById):
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::emitPutByVal):
        (JSC::BytecodeGenerator::emitDirectPutByVal):
        (JSC::BytecodeGenerator::emitDeleteByVal):
        (JSC::BytecodeGenerator::emitSuperSamplerBegin):
        (JSC::BytecodeGenerator::emitSuperSamplerEnd):
        (JSC::BytecodeGenerator::emitIdWithProfile):
        (JSC::BytecodeGenerator::emitUnreachable):
        (JSC::BytecodeGenerator::emitGetArgument):
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitTDZCheck):
        (JSC::BytecodeGenerator::emitNewObject):
        (JSC::BytecodeGenerator::emitNewArrayBuffer):
        (JSC::BytecodeGenerator::emitNewArray):
        (JSC::BytecodeGenerator::emitNewArrayWithSpread):
        (JSC::BytecodeGenerator::emitNewArrayWithSize):
        (JSC::BytecodeGenerator::emitNewRegExp):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewDefaultConstructor):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        (JSC::BytecodeGenerator::emitCallEval):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
        (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
        (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
        (JSC::BytecodeGenerator::emitCallDefineProperty):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitEnd):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::emitStrcat):
        (JSC::BytecodeGenerator::emitToPrimitive):
        (JSC::BytecodeGenerator::emitGetScope):
        (JSC::BytecodeGenerator::emitPushWithScope):
        (JSC::BytecodeGenerator::emitGetParentScope):
        (JSC::BytecodeGenerator::emitDebugHook):
        (JSC::BytecodeGenerator::emitCatch):
        (JSC::BytecodeGenerator::emitThrow):
        (JSC::BytecodeGenerator::emitArgumentCount):
        (JSC::BytecodeGenerator::emitThrowStaticError):
        (JSC::BytecodeGenerator::beginSwitch):
        (JSC::prepareJumpTableForSwitch):
        (JSC::prepareJumpTableForStringSwitch):
        (JSC::BytecodeGenerator::endSwitch):
        (JSC::BytecodeGenerator::emitGetEnumerableLength):
        (JSC::BytecodeGenerator::emitHasGenericProperty):
        (JSC::BytecodeGenerator::emitHasIndexedProperty):
        (JSC::BytecodeGenerator::emitHasStructureProperty):
        (JSC::BytecodeGenerator::emitGetPropertyEnumerator):
        (JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
        (JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
        (JSC::BytecodeGenerator::emitToIndexString):
        (JSC::BytecodeGenerator::emitIsCellWithType):
        (JSC::BytecodeGenerator::emitIsObject):
        (JSC::BytecodeGenerator::emitIsNumber):
        (JSC::BytecodeGenerator::emitIsUndefined):
        (JSC::BytecodeGenerator::emitIsEmpty):
        (JSC::BytecodeGenerator::emitRestParameter):
        (JSC::BytecodeGenerator::emitRequireObjectCoercible):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitGetAsyncIterator):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitFinallyCompletion):
        (JSC::BytecodeGenerator::emitJumpIf):
        (JSC::ForInContext::finalize):
        (JSC::StructureForInContext::finalize):
        (JSC::IndexedForInContext::finalize):
        (JSC::StaticPropertyAnalysis::record):
        (JSC::BytecodeGenerator::emitToThis):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::StructureForInContext::addGetInst):
        (JSC::BytecodeGenerator::recordOpcode):
        (JSC::BytecodeGenerator::addMetadataFor):
        (JSC::BytecodeGenerator::emitUnaryOp):
        (JSC::BytecodeGenerator::kill):
        (JSC::BytecodeGenerator::instructions const):
        (JSC::BytecodeGenerator::write):
        (JSC::BytecodeGenerator::withWriter):
        * bytecompiler/Label.h:
        (JSC::Label::Label):
        (JSC::Label::bind):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::emitBytecode):
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::BitwiseNotNode::emitBytecode):
        (JSC::BinaryOpNode::emitBytecode):
        (JSC::EqualNode::emitBytecode):
        (JSC::StrictEqualNode::emitBytecode):
        (JSC::emitReadModifyAssignment):
        (JSC::ForInNode::emitBytecode):
        (JSC::CaseBlockNode::emitBytecodeForBlock):
        (JSC::FunctionNode::emitBytecode):
        (JSC::ClassExprNode::emitBytecode):
        * bytecompiler/ProfileTypeBytecodeFlag.cpp: Copied from Source/JavaScriptCore/bytecode/VirtualRegister.cpp.
        (WTF::printInternal):
        * bytecompiler/ProfileTypeBytecodeFlag.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        * bytecompiler/RegisterID.h:
        * bytecompiler/StaticPropertyAnalysis.h:
        (JSC::StaticPropertyAnalysis::create):
        (JSC::StaticPropertyAnalysis::StaticPropertyAnalysis):
        * bytecompiler/StaticPropertyAnalyzer.h:
        (JSC::StaticPropertyAnalyzer::createThis):
        (JSC::StaticPropertyAnalyzer::newObject):
        (JSC::StaticPropertyAnalyzer::putById):
        (JSC::StaticPropertyAnalyzer::mov):
        (JSC::StaticPropertyAnalyzer::kill):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleCallVariant):
        (JSC::DFG::ByteCodeParser::handleVarargsInlining):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleMinMax):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleDOMJITCall):
        (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
        (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
        (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parseGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        (JSC::DFG::ByteCodeParser::handlePutByVal):
        (JSC::DFG::ByteCodeParser::handlePutAccessorById):
        (JSC::DFG::ByteCodeParser::handlePutAccessorByVal):
        (JSC::DFG::ByteCodeParser::handleNewFunc):
        (JSC::DFG::ByteCodeParser::handleNewFuncExp):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareCatchOSREntry):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileValueSub):
        (JSC::DFG::SpeculativeJIT::compileValueNegate):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * generate-bytecode-files: Removed.
        * generator/Argument.rb: Added.
        * generator/Assertion.rb: Added.
        * generator/DSL.rb: Added.
        * generator/Fits.rb: Added.
        * generator/GeneratedFile.rb: Added.
        * generator/Metadata.rb: Added.
        * generator/Opcode.rb: Added.
        * generator/OpcodeGroup.rb: Added.
        * generator/Options.rb: Added.
        * generator/Section.rb: Added.
        * generator/Template.rb: Added.
        * generator/Type.rb: Added.
        * generator/main.rb: Added.
        * interpreter/AbstractPC.h:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::currentVPC const):
        (JSC::CallFrame::setCurrentVPC):
        * interpreter/CallFrame.h:
        (JSC::CallSiteIndex::CallSiteIndex):
        (JSC::ExecState::setReturnPC):
        * interpreter/Interpreter.cpp:
        (WTF::printInternal):
        * interpreter/Interpreter.h:
        * interpreter/InterpreterInlines.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::dump const):
        * interpreter/VMEntryRecord.h:
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::emitSlowCaseCall):
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::compileWithoutLinking):
        (JSC::JIT::link):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_jless):
        (JSC::JIT::emit_op_jlesseq):
        (JSC::JIT::emit_op_jgreater):
        (JSC::JIT::emit_op_jgreatereq):
        (JSC::JIT::emit_op_jnless):
        (JSC::JIT::emit_op_jnlesseq):
        (JSC::JIT::emit_op_jngreater):
        (JSC::JIT::emit_op_jngreatereq):
        (JSC::JIT::emitSlow_op_jless):
        (JSC::JIT::emitSlow_op_jlesseq):
        (JSC::JIT::emitSlow_op_jgreater):
        (JSC::JIT::emitSlow_op_jgreatereq):
        (JSC::JIT::emitSlow_op_jnless):
        (JSC::JIT::emitSlow_op_jnlesseq):
        (JSC::JIT::emitSlow_op_jngreater):
        (JSC::JIT::emitSlow_op_jngreatereq):
        (JSC::JIT::emit_op_below):
        (JSC::JIT::emit_op_beloweq):
        (JSC::JIT::emit_op_jbelow):
        (JSC::JIT::emit_op_jbeloweq):
        (JSC::JIT::emit_op_unsigned):
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareUnsignedAndJump):
        (JSC::JIT::emit_compareUnsigned):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_inc):
        (JSC::JIT::emit_op_dec):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::emitSlow_op_mod):
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitBitBinaryOpFastPath):
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::emit_op_bitor):
        (JSC::JIT::emit_op_bitxor):
        (JSC::JIT::emit_op_lshift):
        (JSC::JIT::emitRightShiftFastPath):
        (JSC::JIT::emit_op_rshift):
        (JSC::JIT::emit_op_urshift):
        (JSC::getOperandTypes):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitMathICFast):
        (JSC::JIT::emitMathICSlow):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITCall.cpp:
        (JSC::JIT::emitPutCallResult):
        (JSC::JIT::compileSetupFrame):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileTailCall):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_tail_call_forward_arguments):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::emit_op_construct):
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
        (JSC::JIT::emitSlow_op_construct_varargs):
        (JSC::JIT::emitSlow_op_construct):
        * jit/JITDisassembler.cpp:
        (JSC::JITDisassembler::JITDisassembler):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITInlines.h:
        (JSC::JIT::emitDoubleGetByVal):
        (JSC::JIT::emitLoadForArrayMode):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
        (JSC::JIT::sampleInstruction):
        (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
        (JSC::JIT::emitValueProfilingSite):
        (JSC::JIT::jumpTarget):
        (JSC::JIT::copiedGetPutInfo):
        (JSC::JIT::copiedArithProfile):
        * jit/JITMathIC.h:
        (JSC::isProfileEmpty):
        (JSC::JITBinaryMathIC::JITBinaryMathIC):
        (JSC::JITUnaryMathIC::JITUnaryMathIC):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_mov):
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_jmp):
        (JSC::JIT::emit_op_new_object):
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_overrides_has_instance):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        (JSC::JIT::emit_op_instanceof_custom):
        (JSC::JIT::emit_op_is_empty):
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_is_boolean):
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_is_cell_with_type):
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::emit_op_set_function_name):
        (JSC::JIT::emit_op_not):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jneq_ptr):
        (JSC::JIT::emit_op_eq):
        (JSC::JIT::emit_op_jeq):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_neq):
        (JSC::JIT::emit_op_jneq):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::emit_op_stricteq):
        (JSC::JIT::emit_op_nstricteq):
        (JSC::JIT::compileOpStrictEqJump):
        (JSC::JIT::emit_op_jstricteq):
        (JSC::JIT::emit_op_jnstricteq):
        (JSC::JIT::emitSlow_op_jstricteq):
        (JSC::JIT::emitSlow_op_jnstricteq):
        (JSC::JIT::emit_op_to_number):
        (JSC::JIT::emit_op_to_string):
        (JSC::JIT::emit_op_to_object):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_identity_with_profile):
        (JSC::JIT::emit_op_get_parent_scope):
        (JSC::JIT::emit_op_switch_imm):
        (JSC::JIT::emit_op_switch_char):
        (JSC::JIT::emit_op_switch_string):
        (JSC::JIT::emit_op_debug):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emit_op_enter):
        (JSC::JIT::emit_op_get_scope):
        (JSC::JIT::emit_op_to_this):
        (JSC::JIT::emit_op_create_this):
        (JSC::JIT::emit_op_check_tdz):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::emitSlow_op_jeq):
        (JSC::JIT::emitSlow_op_jneq):
        (JSC::JIT::emitSlow_op_instanceof_custom):
        (JSC::JIT::emit_op_loop_hint):
        (JSC::JIT::emitSlow_op_loop_hint):
        (JSC::JIT::emit_op_check_traps):
        (JSC::JIT::emit_op_nop):
        (JSC::JIT::emit_op_super_sampler_begin):
        (JSC::JIT::emit_op_super_sampler_end):
        (JSC::JIT::emitSlow_op_check_traps):
        (JSC::JIT::emit_op_new_regexp):
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_new_generator_func):
        (JSC::JIT::emit_op_new_async_generator_func):
        (JSC::JIT::emit_op_new_async_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emit_op_new_generator_func_exp):
        (JSC::JIT::emit_op_new_async_func_exp):
        (JSC::JIT::emit_op_new_async_generator_func_exp):
        (JSC::JIT::emit_op_new_array):
        (JSC::JIT::emit_op_new_array_with_size):
        (JSC::JIT::emit_op_has_structure_property):
        (JSC::JIT::privateCompileHasIndexedProperty):
        (JSC::JIT::emit_op_has_indexed_property):
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_profile_type):
        (JSC::JIT::emit_op_log_shadow_chicken_prologue):
        (JSC::JIT::emit_op_log_shadow_chicken_tail):
        (JSC::JIT::emit_op_profile_control_flow):
        (JSC::JIT::emit_op_argument_count):
        (JSC::JIT::emit_op_get_rest_length):
        (JSC::JIT::emit_op_get_argument):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_this):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val_direct):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_by_val):
        (JSC::JIT::emit_op_put_setter_by_val):
        (JSC::JIT::emit_op_del_by_id):
        (JSC::JIT::emit_op_del_by_val):
        (JSC::JIT::emit_op_try_get_by_id):
        (JSC::JIT::emitSlow_op_try_get_by_id):
        (JSC::JIT::emit_op_get_by_id_direct):
        (JSC::JIT::emitSlow_op_get_by_id_direct):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_get_by_id_with_this):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id_with_this):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emit_op_in_by_id):
        (JSC::JIT::emitSlow_op_in_by_id):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompileGetByValWithCachedId):
        (JSC::JIT::privateCompilePutByVal):
        (JSC::JIT::privateCompilePutByValWithCachedId):
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        (JSC::JIT::emitDirectArgumentsGetByVal):
        (JSC::JIT::emitScopedArgumentsGetByVal):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::JITSlowPathCall):
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntData.h:
        (JSC::LLInt::exceptionInstructions):
        (JSC::LLInt::opcodeMap):
        (JSC::LLInt::opcodeMapWide):
        (JSC::LLInt::getOpcode):
        (JSC::LLInt::getOpcodeWide):
        (JSC::LLInt::getWideCodePtr):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_trace_operand):
        (JSC::LLInt::llint_trace_value):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::setupGetByIdPrototypeCache):
        (JSC::LLInt::getByVal):
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        (JSC::LLInt::genericCall):
        (JSC::LLInt::varargsSetup):
        (JSC::LLInt::commonCallEval):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoopRegister::operator const Instruction*):
        (JSC::CLoop::execute):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm64.rb:
        * offlineasm/asm.rb:
        * offlineasm/ast.rb:
        * offlineasm/cloop.rb:
        * offlineasm/generate_offset_extractor.rb:
        * offlineasm/instructions.rb:
        * offlineasm/offsets.rb:
        * offlineasm/parser.rb:
        * offlineasm/transform.rb:
        * offlineasm/x86.rb:
        * parser/ResultType.h:
        (JSC::ResultType::dump const):
        (JSC::OperandTypes::first const):
        (JSC::OperandTypes::second const):
        (JSC::OperandTypes::dump const):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::BytecodeSequence):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        (JSC::updateArithProfileForUnaryArithOp):
        (JSC::updateArithProfileForBinaryArithOp):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/ExceptionFuzz.cpp:
        (JSC::doExceptionFuzzing):
        * runtime/ExceptionFuzz.h:
        (JSC::doExceptionFuzzingIfEnabled):
        * runtime/GetPutInfo.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp.
        (JSC::GetPutInfo::dump const):
        (WTF::printInternal):
        * runtime/GetPutInfo.h:
        (JSC::GetPutInfo::operand const):
        * runtime/JSCPoison.h:
        * runtime/JSType.cpp: Added.
        (WTF::printInternal):
        * runtime/JSType.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::StackFrame::displayName):
        * runtime/SamplingProfiler.h:
        (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
        * runtime/SlowPathReturnType.h:
        (JSC::encodeResult):
        (JSC::decodeResult):
        * runtime/VM.h:
        * runtime/Watchdog.h:
        * tools/HeapVerifier.cpp:

2018-10-26  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r237445.
        https://bugs.webkit.org/show_bug.cgi?id=190972

        Cause performance regression on iOS devices (Requested by
        yusukesuzuki on #webkit).

        Reverted changeset:

        "Unreviewed, partial rolling in r237254"
        https://bugs.webkit.org/show_bug.cgi?id=190340
        https://trac.webkit.org/changeset/237445

2018-10-26  Mark Lam  <mark.lam@apple.com>

        Fix missing edge cases with JSGlobalObjects having a bad time.
        https://bugs.webkit.org/show_bug.cgi?id=189028
        <rdar://problem/45204939>

        Reviewed by Saam Barati.

        Consider the following scenario:

            let object O1 (of global G1) have an indexing type that is not SlowPut.
            let global G2 have a bad time.
            let object O2 (of global G2) be set as the prototype of O1.
            let object O3 (of global G2) have indexed accessors.

        In the existing code, if we set O3 as O2's prototype, we'll have a bug where
        O1 will not be made aware that that there are indexed accessors in its prototype
        chain.

        In this patch, we solve this issue by introducing a new invariant:

            A prototype chain is considered to possibly have indexed accessors if any
            object in the chain belongs to a global object that is having a bad time.

        We apply this invariant as follows:

        1. Enhance JSGlobalObject::haveABadTime() to also check if other global objects are
           affected by it having a bad time.  If so, it also ensures that those affected
           global objects have a bad time.

           The original code for JSGlobalObject::haveABadTime() uses a ObjectsWithBrokenIndexingFinder
           to find all objects affected by the global object having a bad time.  We enhance
           ObjectsWithBrokenIndexingFinder to also check for the possibility that any global
           objects may be affected by other global objects having a bad time i.e.

                let g1 = global1
                let g2 = global2
                let o1 = an object in g1
                let o2 = an object in g2

                let g1 have a bad time
                g2 is affected if
                    o1 is in the prototype chain of o2,
                    and o2 may be a prototype.

           If the ObjectsWithBrokenIndexingFinder does find the possibility of other global
           objects being affected, it will abort its heap scan and let haveABadTime() take
           a slow path to do a more complete multi global object scan.

           The slow path works as follows:

           1. Iterate the heap and record the graph of all global object dependencies.

              For each global object, record the list of other global objects that are
              affected by it.

           2. Compute a list of global objects that need to have a bad time using the
              current global object dependency graph.

           3. For each global object in the list of affected global objects, fire their
              HaveABadTime watchpoint and convert all their array structures to the
              SlowPut alternatives.

           4. Re-run ObjectsWithBrokenIndexingFinder to find all objects that are affected
              by any of the globals in the list from (2).

        2. Enhance Structure::mayInterceptIndexedAccesses() to also return true if the
           structure's global object is having a bad time.

        Note: there are 3 scenarios that we need to consider:

            let g1 = global1
            let g2 = global2
            let o1 = an object in g1
            let o2 = an object in g2

            Scenario 1: o2 is a prototype, and
                        g1 has a bad time after o1 is inserted into the o2's prototype chain.

            Scenario 2: o2 is a prototype, and
                        o1 is inserted into the o2's prototype chain after g1 has a bad time.

            Scenario 3: o2 is NOT a prototype, and
                        o1 is inserted into the o2's prototype chain after g1 has a bad time.

            For scenario 1, when g1 has a bad time, we need to also make sure g2 has
            a bad time.  This is handled by enhancement 1 above.

            For scenario 2, when o1 is inserted into o2's prototype chain, we need to check
            if o1's global object has a bad time.  If so, then we need to make sure o2's
            global also has a bad time (because o2 is a prototype) and convert o2's
            storage type to SlowPut.  This is handled by enhancement 2 above in conjunction
            with JSObject::setPrototypeDirect().

            For scenario 3, when o1 is inserted into o2's prototype chain, we need to check
            if o1's global object has a bad time.  If so, then we only need to convert o2's
            storage type to SlowPut (because o2 is NOT a prototype).  This is handled by
            enhancement 2 above.

        3. Also add $vm.isHavingABadTime(), $vm.createGlobalObject() to enable us to
           write some tests for this issue.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::fireWatchpointAndMakeAllArrayStructuresSlowPut):
        (JSC::JSGlobalObject::haveABadTime):
        * runtime/JSGlobalObject.h:
        * runtime/JSObject.h:
        (JSC::JSObject::mayInterceptIndexedAccesses): Deleted.
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::mayInterceptIndexedAccesses):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::mayInterceptIndexedAccesses const):
        * tools/JSDollarVM.cpp:
        (JSC::functionHaveABadTime):
        (JSC::functionIsHavingABadTime):
        (JSC::functionCreateGlobalObject):
        (JSC::JSDollarVM::finishCreation):

2018-10-26  Keith Miller  <keith_miller@apple.com>

        JSC xcconfig should set DEFINES_MODULE
        https://bugs.webkit.org/show_bug.cgi?id=190952

        Reviewed by Mark Lam.

        This should mean that the JavaScriptCore.framework will have a module map.

        * Configurations/JavaScriptCore.xcconfig:

2018-10-25  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] havingABadTimeWatchpoint is not required in Array#indexOf optimization
        https://bugs.webkit.org/show_bug.cgi?id=190941

        Reviewed by Saam Barati.

        While "Rest" operation fast path requires havingABadTimeWatchpoint since it allocates
        JSArray, Array#{indexOf,lastIndexOf} do not require it when we use the fast path for them.
        This patch removes watching on havingABadTimeWatchpoint in Array#indexOf. The test causing
        "havingABadTime" is already included in our test suites (e.g. array-indexof-have-a-bad-time.js).

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::canDoFastIndexedAccess):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectInlines.h:
        (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
        (JSC::JSGlobalObject::isArrayPrototypeIndexedAccessFastAndNonObservable): Deleted.

2018-10-25  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, partial rolling in r237254
        https://bugs.webkit.org/show_bug.cgi?id=190340

        We do not use the added function right now to investigate what is the reason of the regression.
        If it causes the regression, it seems that Parser.cpp's inlining decision seems culprit.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseSingleFunction):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        (JSC::parse):
        (JSC::parseFunctionForFunctionConstructor):
        * parser/ParserModes.h:
        * parser/ParserTokens.h:
        (JSC::JSTextPosition::JSTextPosition):
        (JSC::JSTokenLocation::JSTokenLocation): Deleted.
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator== const):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/CodeCache.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/FunctionExecutable.h:

2018-10-25  Brent Fulgham  <bfulgham@apple.com>

        Unreviewed build fix for Visual Studio 2017

        * API/tests/testapi.c:
        (testMarkingConstraintsAndHeapFinalizers):
        (main):

2018-10-25  Devin Rousso  <drousso@apple.com>

        Web Inspector: display fullscreen enter/exit events in Timelines and Network node waterfalls
        https://bugs.webkit.org/show_bug.cgi?id=189874
        <rdar://problem/44700000>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:
        Allow `data` to be passed to the frontend with `didFireEvent`.

2018-10-25  Ross Kirsling  <ross.kirsling@sony.com>

        Cleanup: inline constexpr is redundant as constexpr implies inline
        https://bugs.webkit.org/show_bug.cgi?id=190819

        Reviewed by Mark Lam.

        * bytecode/ArrayProfile.h:
        (JSC::asArrayModes):
        * runtime/IndexingType.h:
        (JSC::isCopyOnWrite):
        * runtime/MathCommon.h:
        (JSC::maxSafeInteger):
        (JSC::minSafeInteger):
        * runtime/StackAlignment.h:
        (JSC::stackAlignmentBytes):
        (JSC::stackAlignmentRegisters):

2018-10-24  Megan Gardner  <megan_gardner@apple.com>

        Turn on Conic Gradients
        https://bugs.webkit.org/show_bug.cgi?id=190810

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

2018-10-24  Michael Saboff  <msaboff@apple.com>

        Increase executable memory pool from 64MB to 128MB for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=190453

        Unreviewed, rolling back in r237024.

        The original change did impact ARES-6 performance by 4-8%.  That will
        be investigated separately.

2018-10-22  Keith Rollin  <krollin@apple.com>

        Use Location = "Relative to Build Products" rather than "Relative to Group"
        https://bugs.webkit.org/show_bug.cgi?id=190781

        Reviewed by Alexey Proskuryakov.

        Almost all Derived Files are included in Xcode projects with the
        Location attribute set to "Relative to Group". While this currently
        works, the Derived Files can no longer be found when enabling XCBuild
        (which has stricter requirements). Fix this by setting the Location
        attribute to "Relative to Build Products".

        * JavaScriptCore.xcodeproj/project.pbxproj:

2018-10-22  Mark Lam  <mark.lam@apple.com>

        DFGAbstractValue::m_arrayModes expects IndexingMode values, not IndexingType.
        https://bugs.webkit.org/show_bug.cgi?id=190515
        <rdar://problem/45222379>

        Reviewed by Saam Barati.

        1. Fixes calls to asArrayModes() to take a structure's IndexingMode instead of
           IndexingType.

        2. DFG's compileNewArrayBuffer()'s HaveABadTime case was previously using the
           node's indexingType (instead of indexingMode) to choose the array structure
           to use for creating an array buffer with.  This turns out to not be an issue
           because when the VM is in having a bad time, all the
           arrayStructureForIndexingTypeDuringAllocation structure pointers will point to
           the SlowPutArrayStorage structure anyway.  However, to be strictly correct,
           we'll fix it to use the structure for the node's indexingMode.

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::mergeOSREntryValue):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::validate const):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::executeOSRExit):
        * dfg/DFGRegisteredStructureSet.cpp:
        (JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewArrayBuffer):

2018-10-19  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r237254.
        https://bugs.webkit.org/show_bug.cgi?id=190760

        "It regresses JetStream 2 by 5% on some iOS devices"
        (Requested by saamyjoon on #webkit).

        Reverted changeset:

        "[JSC] JSC should have "parseFunction" to optimize Function
        constructor"
        https://bugs.webkit.org/show_bug.cgi?id=190340
        https://trac.webkit.org/changeset/237254

2018-10-19  Saam Barati  <sbarati@apple.com>

        vmCall should check if we exit before emitting an OSR exit due to exceptions
        https://bugs.webkit.org/show_bug.cgi?id=190740
        <rdar://problem/45220139>

        Reviewed by Mark Lam.

        The bug we were seeing is the MovHint removal phase would
        eliminate a superfluous MovHint. This left a certain range
        of nodes in a state where they would not be able to reconstruct
        values for an OSR exit. This is OK, since this phase proved those
        nodes don't exit. However, some of these nodes may use the vmCall
        construct in FTLLower. vmCall used to unconditionally emit an
        exception check after each call. However, if such a call happens
        in the range of nodes where we can't exit, we would end up generating
        an invalid exit (and running with validateFTLOSRExitLiveness flag
        would find this issue).
        
        This patch makes vmCall check to see if the node can exit before
        emitting an exception check. A node not being able to exit implies
        that it can't exit for exceptions, therefore, by definition, it can't
        throw an exception.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::vmCall):

2018-10-19  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Implement support for "^"
        https://bugs.webkit.org/show_bug.cgi?id=186235

        Reviewed by Yusuke Suzuki.

        This patch is introducing support for BigInt into bitwise xor
        operation. We are including only support into LLInt and Baseline.

        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::bitwiseXor):
        (JSC::JSBigInt::absoluteXor):
        * runtime/JSBigInt.h:

2018-10-19  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Add ValueSub into DFG
        https://bugs.webkit.org/show_bug.cgi?id=186176

        Reviewed by Yusuke Suzuki.

        We are introducing in this patch a new node called ValueSub. This node
        is necessary due to introduction of BigInt, making subtraction
        operations result in non-Number values in some cases. In such case, ValueSub is
        responsible to handle Untyped and BigInt operations.
        In addition, we are also creating a speculative path when both
        operands are BigInt. According to a simple BigInt subtraction microbenchmark,
        this represents a speedup of ~1.2x faster.

        big-int-simple-sub    14.6427+-0.5652    ^    11.9559+-0.6485   ^   definitely 1.2247x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addSpeculationMode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueSub):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):

2018-10-18  Alexey Proskuryakov  <ap@apple.com>

        Switch from PLATFORM(IOS) to PLATFORM(IOS_FAMILY)
        https://bugs.webkit.org/show_bug.cgi?id=190729

        Reviewed by Tim Horton.

        * API/JSBase.cpp:
        * API/JSWrapperMap.mm:
        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::cacheFlush):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::cacheFlush):
        * assembler/AssemblerCommon.h:
        (JSC::isIOS):
        * heap/FullGCActivityCallback.cpp:
        (JSC::FullGCActivityCallback::doCollection):
        * heap/Heap.cpp:
        (JSC::Heap::overCriticalMemoryThreshold):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::collectIfNecessaryOrDefer):
        * heap/Heap.h:
        * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
        (Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget):
        * jit/ExecutableAllocator.cpp:
        (JSC::allowJIT):
        * jit/ExecutableAllocator.h:
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::reservedHardwareRegisters):
        (JSC::RegisterSet::calleeSaveRegisters):
        * jit/ThunkGenerators.cpp:
        * jsc.cpp:
        (main):
        * runtime/MathCommon.cpp:
        * runtime/Options.cpp:
        (JSC::overrideDefaults):
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2018-10-18  Ross Kirsling  <ross.kirsling@sony.com>

        delete expression should not throw without a reference
        https://bugs.webkit.org/show_bug.cgi?id=190637

        Reviewed by Yusuke Suzuki.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseUnaryExpression):
        Eliminate non-spec-compliant switch case.

2018-10-18  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] JSC should have "parseFunction" to optimize Function constructor
        https://bugs.webkit.org/show_bug.cgi?id=190340

        Reviewed by Mark Lam.

        The current Function constructor is suboptimal. We parse the piece of the same code three times to meet
        the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function.
        And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation
        is really costly and ideally we should meet the above requirement by the one time parsing.

        To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function
        takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser.
        For example, if we run the code,

            Function('/*', '*/){')

        According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter
        string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing
        that, in our implementation, we first create the entire string.

            function anonymous(/*) {
                */){
            }

        And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case,
        the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token
        offset of the parameters is the given end position. This check allows us to raise the error correctly to the
        above example while we parse the entire function only once. And we do not need to create two strings too.

        This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is
        significantly sped up (28.2%).

        Before:
            uglify-js:  2.94 runs/s
        After:
            uglify-js:  3.77 runs/s

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseSingleFunction):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        (JSC::parse):
        (JSC::parseFunctionForFunctionConstructor):
        * parser/ParserModes.h:
        * parser/ParserTokens.h:
        (JSC::JSTextPosition::JSTextPosition):
        (JSC::JSTokenLocation::JSTokenLocation): Deleted.
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator== const):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/CodeCache.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/FunctionExecutable.h:

2018-10-18  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r237242.
        https://bugs.webkit.org/show_bug.cgi?id=190701

        it breaks "stress/sampling-profiler-basic.js" (Requested by
        caiolima on #webkit).

        Reverted changeset:

        "[BigInt] Add ValueSub into DFG"
        https://bugs.webkit.org/show_bug.cgi?id=186176
        https://trac.webkit.org/changeset/237242

2018-10-18  Takafumi Kubota  <takafumi.kubota1012@sslab.ics.keio.ac.jp>

        Missing #pragma once in WasmOpcodeOrigin.h
        https://bugs.webkit.org/show_bug.cgi?id=190699

        Reviewed by Yusuke Suzuki.

        This patch add ''#pragma once'' into WasmOpcodeOrigin.h to avoid the
        multiple inclusion that can happen in the unified build
        configuration.

        * wasm/WasmOpcodeOrigin.h:

2018-10-17  Wenson Hsieh  <wenson_hsieh@apple.com>

        Enable the datalist element by default on iOS and macOS
        https://bugs.webkit.org/show_bug.cgi?id=190594
        <rdar://problem/45281159>

        Reviewed by Ryosuke Niwa and Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

2018-10-17  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] Add ValueSub into DFG
        https://bugs.webkit.org/show_bug.cgi?id=186176

        Reviewed by Yusuke Suzuki.

        We are introducing in this patch a new node called ValueSub. This node
        is necessary due to introduction of BigInt, making subtraction
        operations result in non-Number values in some cases. In such case, ValueSub is
        responsible to handle Untyped and BigInt operations.
        In addition, we are also creating a speculative path when both
        operands are BigInt. According to a simple BigInt subtraction microbenchmark,
        this represents a speedup of ~1.2x faster.

        big-int-simple-sub    14.6427+-0.5652    ^    11.9559+-0.6485   ^   definitely 1.2247x faster

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addSpeculationMode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueSub):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):

2018-10-17  Mark Lam  <mark.lam@apple.com>

        The parser should not emit a ApplyFunctionCallDotNode for Reflect.apply.
        https://bugs.webkit.org/show_bug.cgi?id=190671
        <rdar://problem/45201145>

        Reviewed by Saam Barati.

        The bytecode generator does not currently know how to inline Reflect.apply (see
        https://bugs.webkit.org/show_bug.cgi?id=190668).  Hence, it's a waste of time to
        emit the ApplyFunctionCallDotNode since the function check against Function.apply
        that it will generate will always fail.

        Also fixed CallVariant::dump() to be able to handle dumping a non-executable
        callee.  Reflect.apply used to trip this up.  Any object with an apply property
        invoked as a function could also trip this up.  This is now fixed.

        * bytecode/CallVariant.cpp:
        (JSC::CallVariant::dump const):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::makeFunctionCallNode):

2018-10-17  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r237024.
        https://bugs.webkit.org/show_bug.cgi?id=190673

        "It regressed ARES6 on iOS devices by 4-8%" (Requested by
        saamyjoon on #webkit).

        Reverted changeset:

        "Increase executable memory pool from 64MB to 128MB for ARM64"
        https://bugs.webkit.org/show_bug.cgi?id=190453
        https://trac.webkit.org/changeset/237024

2018-10-17  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Use WTF::Function instead of std::function
        https://bugs.webkit.org/show_bug.cgi?id=190665

        Reviewed by Keith Miller.

        We should use WTF::Function as much as possible. It allocates memory from bmalloc instead of standard malloc.

        * runtime/JSNativeStdFunction.h:

2018-10-17  Keith Miller  <keith_miller@apple.com>

        Remove debug logging from generate_offsets_extractor.rb
        https://bugs.webkit.org/show_bug.cgi?id=190667

        Reviewed by Mark Lam.

        * offlineasm/generate_offset_extractor.rb:

2018-10-17  Keith Miller  <keith_miller@apple.com>

        AI does not clear Phantom allocation nodes.
        https://bugs.webkit.org/show_bug.cgi?id=190694

        Reviewed by Saam Barati.

        Phantom nodes claim to have a result so they should make sure they clear
        their abstract values.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2018-10-17  Keith Miller  <keith_miller@apple.com>

        Unreviewed, fix windows build.

        * offlineasm/generate_offset_extractor.rb:

2018-10-17  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] More aggressively use `constexpr` in LowLevelInterpreter.asm for constant values
        https://bugs.webkit.org/show_bug.cgi?id=190659

        Reviewed by Keith Miller.

        Asking the actual constant value to the JSC binary is always the best way to get the correct value.
        The value is correctly updated once the original value is changed. We would like to encourage this
        approach more in LowLevelInterpreter.asm.

        This patch expands the coverage of this approach. We make ObservedType, ResultType, and ArithProfile
        constexpr-friendly to produce the magic value used in LowLevelInterpreter.asm at compiling time.
        This change allows us to easily extend ArithProfile in the future to adopt BigInt efficiently.

        We additionally use `constexpr` for several constant values in LowLevelInterpreter.asm.

        * assembler/MaxFrameExtentForSlowPathCall.h:
        Use this value in LowLevelInterpreter.asm directly. We also make them constexpr. And we add CPU(ARM64E).

        * bytecode/ArithProfile.h:
        (JSC::ObservedType::ObservedType):
        (JSC::ObservedType::sawInt32 const):
        (JSC::ObservedType::isOnlyInt32 const):
        (JSC::ObservedType::sawNumber const):
        (JSC::ObservedType::isOnlyNumber const):
        (JSC::ObservedType::sawNonNumber const):
        (JSC::ObservedType::isOnlyNonNumber const):
        (JSC::ObservedType::isEmpty const):
        (JSC::ObservedType::bits const):
        (JSC::ObservedType::withInt32 const):
        (JSC::ObservedType::withNumber const):
        (JSC::ObservedType::withNonNumber const):
        (JSC::ObservedType::withoutNonNumber const):
        (JSC::ObservedType::operator== const):
        (JSC::ArithProfile::ArithProfile):
        (JSC::ArithProfile::fromInt):
        (JSC::ArithProfile::observedUnaryInt):
        (JSC::ArithProfile::observedUnaryNumber):
        (JSC::ArithProfile::observedBinaryIntInt):
        (JSC::ArithProfile::observedBinaryNumberInt):
        (JSC::ArithProfile::observedBinaryIntNumber):
        (JSC::ArithProfile::observedBinaryNumberNumber):
        (JSC::ArithProfile::lhsObservedType const):
        (JSC::ArithProfile::rhsObservedType const):
        (JSC::ArithProfile::bits const):
        Make ObservedType and ArithProfile constexpr-friendly.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        Make several ASSERTs to STATIC_ASSERTs. Remove some unnecessary checks.
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LowLevelInterpreter.asm:
        Remove unused constant values. Use constexpr more and more aggressively.

        * parser/ResultType.h:
        (JSC::ResultType::ResultType):
        (JSC::ResultType::isInt32 const):
        (JSC::ResultType::definitelyIsNumber const):
        (JSC::ResultType::definitelyIsString const):
        (JSC::ResultType::definitelyIsBoolean const):
        (JSC::ResultType::definitelyIsBigInt const):
        (JSC::ResultType::mightBeNumber const):
        (JSC::ResultType::isNotNumber const):
        (JSC::ResultType::mightBeBigInt const):
        (JSC::ResultType::isNotBigInt const):
        (JSC::ResultType::nullType):
        (JSC::ResultType::booleanType):
        (JSC::ResultType::numberType):
        (JSC::ResultType::numberTypeIsInt32):
        (JSC::ResultType::stringOrNumberType):
        (JSC::ResultType::addResultType):
        (JSC::ResultType::stringType):
        (JSC::ResultType::bigIntType):
        (JSC::ResultType::unknownType):
        (JSC::ResultType::forAdd):
        (JSC::ResultType::forLogicalOp):
        (JSC::ResultType::forBitOp):
        (JSC::ResultType::bits const):
        Make ResultType constexpr-friendly.

        * runtime/JSCJSValue.h:
        Use offsetof instead of OBJECT_OFFSETOF. It is OK since EncodedValueDescriptor is POD.
        This change makes TagOffset and PayloadOffset macros constexpr-friendly while OBJECT_OFFSETOF
        cannot be used in constexpr since it uses reinterpret_cast.

2018-10-17  Keith Miller  <keith_miller@apple.com>

        Unreviewed revert Fujii's revert in r237214 with new WinCairo build fix.

2018-10-16  Mark Lam  <mark.lam@apple.com>

        GetIndexedPropertyStorage can GC.
        https://bugs.webkit.org/show_bug.cgi?id=190625
        <rdar://problem/45309366>

        Reviewed by Saam Barati.

        This is because if the ArrayMode type is String, the DFG and FTL will be emitting
        a call to operationResolveRope, and operationResolveRope can GC.  This patch
        updates doesGC() to reflect this.

        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2018-10-16  Fujii Hironori  <Hironori.Fujii@sony.com>

        Unreviewed, rolling out r237188, r237189, and r237197.

        It breaks WinCairo Debug builds and Release LayoutTests

        Reverted changesets:

        https://bugs.webkit.org/show_bug.cgi?id=189708
        https://trac.webkit.org/changeset/237188

        "Unreviewed, forgot to add untracked files."
        https://trac.webkit.org/changeset/237189

        "isASTErroneous in offlineasm should de-macroify before
        looking for Errors"
        https://bugs.webkit.org/show_bug.cgi?id=190634
        https://trac.webkit.org/changeset/237197

2018-10-16  Devin Rousso  <drousso@apple.com>

        Web Inspector: Canvas: capture previously saved states and add them to the recording payload
        https://bugs.webkit.org/show_bug.cgi?id=190473

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Recording.json:
        Add `states` key to `InitialState` object.

2018-10-16  Keith Miller  <keith_miller@apple.com>

        isASTErroneous in offlineasm should de-macroify before looking for Errors
        https://bugs.webkit.org/show_bug.cgi?id=190634

        Reviewed by Mark Lam.

        If a macro isn't usable in a configuration it might still cause us to
        think the ast is invalid. This change runs the de-macroifier before
        looking for errors.

        Also, it adds a missing include to Printer.h.

        * assembler/Printer.h:
        * offlineasm/settings.rb:

2018-10-16  Justin Michaud  <justin_michaud@apple.com>

        Implement feature flag and bindings for CSS Painting API
        https://bugs.webkit.org/show_bug.cgi?id=190237

        Reviewed by Ryosuke Niwa.

        * Configurations/FeatureDefines.xcconfig:

2018-10-16  Keith Miller  <keith_miller@apple.com>

        Unreviewed, forgot to add untracked files.

        * llint/LLIntSettingsExtractor.cpp: Added.
        (main):
        * offlineasm/generate_settings_extractor.rb: Added.

2018-10-16  Keith Miller  <keith_miller@apple.com>

        Unreviewed, reland https://bugs.webkit.org/show_bug.cgi?id=189708 with build fix.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * llint/LLIntOffsetsExtractor.cpp:
        (JSC::LLIntOffsetsExtractor::dummy):
        * offlineasm/generate_offset_extractor.rb:
        * offlineasm/offsets.rb:
        * offlineasm/settings.rb:

2018-10-16  Keith Miller  <keith_miller@apple.com>

        Unreviewed, add missing include.

        * runtime/BasicBlockLocation.h:

2018-10-15  Keith Miller  <keith_miller@apple.com>

        Support arm64 CPUs with a 32-bit address space
        https://bugs.webkit.org/show_bug.cgi?id=190273

        Reviewed by Michael Saboff.

        This patch adds support for arm64_32 in the LLInt. In order to
        make this work we needed to add a new type that reflects the size
        of a cpu register. This type is called CPURegister or UCPURegister
        for the unsigned version. Most places that used void* or intptr_t
        to refer to a register have been changed to use this new type.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARM64Assembler.h:
        (JSC::isInt):
        (JSC::is4ByteAligned):
        (JSC::PairPostIndex::PairPostIndex):
        (JSC::PairPreIndex::PairPreIndex):
        (JSC::ARM64Assembler::readPointer):
        (JSC::ARM64Assembler::readCallTarget):
        (JSC::ARM64Assembler::computeJumpType):
        (JSC::ARM64Assembler::linkCompareAndBranch):
        (JSC::ARM64Assembler::linkConditionalBranch):
        (JSC::ARM64Assembler::linkTestAndBranch):
        (JSC::ARM64Assembler::loadRegisterLiteral):
        (JSC::ARM64Assembler::loadStoreRegisterPairPostIndex):
        (JSC::ARM64Assembler::loadStoreRegisterPairPreIndex):
        (JSC::ARM64Assembler::loadStoreRegisterPairOffset):
        (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
        (JSC::isInt7): Deleted.
        (JSC::isInt11): Deleted.
        * assembler/CPU.h:
        (JSC::isAddress64Bit):
        (JSC::isAddress32Bit):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::shouldBlind):
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::MacroAssemblerARM64::collectCPUFeatures):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::load):
        (JSC::MacroAssemblerARM64::store):
        (JSC::MacroAssemblerARM64::isInIntRange): Deleted.
        * assembler/Printer.h:
        * assembler/ProbeContext.h:
        (JSC::Probe::CPUState::gpr):
        (JSC::Probe::CPUState::spr):
        (JSC::Probe::Context::gpr):
        (JSC::Probe::Context::spr):
        * b3/B3ConstPtrValue.h:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::stackSlot const):
        (JSC::B3::Air::Arg::special const):
        * b3/air/testair.cpp:
        * b3/testb3.cpp:
        (JSC::B3::testStoreConstantPtr):
        (JSC::B3::testInterpreter):
        (JSC::B3::testAddShl32):
        (JSC::B3::testLoadBaseIndexShift32):
        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptCallArgumentHandler::appendArgument):
        * bindings/ScriptFunctionCall.h:
        * bytecode/CodeBlock.cpp:
        (JSC::roundCalleeSaveSpaceAsVirtualRegisters):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::restoreCalleeSavesFor):
        (JSC::DFG::saveCalleeSavesFor):
        (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
        (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * disassembler/UDis86Disassembler.cpp:
        (JSC::tryToDisassembleWithUDis86):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet):
        * heap/MachineStackMarker.cpp:
        (JSC::copyMemory):
        * interpreter/CallFrame.h:
        (JSC::ExecState::returnPC const):
        (JSC::ExecState::hasReturnPC const):
        (JSC::ExecState::clearReturnPC):
        (JSC::ExecState::returnPCOffset):
        (JSC::ExecState::isGlobalExec const):
        (JSC::ExecState::setReturnPC):
        * interpreter/CalleeBits.h:
        (JSC::CalleeBits::boxWasm):
        (JSC::CalleeBits::isWasm const):
        (JSC::CalleeBits::asWasmCallee const):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
        * interpreter/VMEntryRecord.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::clearStackFrame):
        * jit/RegisterAtOffset.h:
        (JSC::RegisterAtOffset::offsetAsIndex const):
        * jit/RegisterAtOffsetList.cpp:
        (JSC::RegisterAtOffsetList::RegisterAtOffsetList):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/arm64.rb:
        * offlineasm/asm.rb:
        * offlineasm/ast.rb:
        * offlineasm/backends.rb:
        * offlineasm/parser.rb:
        * offlineasm/x86.rb:
        * runtime/BasicBlockLocation.cpp:
        (JSC::BasicBlockLocation::dumpData const):
        (JSC::BasicBlockLocation::emitExecuteCode const):
        * runtime/BasicBlockLocation.h:
        * runtime/HasOwnPropertyCache.h:
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::inplaceMultiplyAdd):
        (JSC::JSBigInt::digitDiv):
        * runtime/JSBigInt.h:
        * runtime/JSObject.h:
        * runtime/Options.cpp:
        (JSC::jitEnabledByDefault):
        * runtime/Options.h:
        * runtime/RegExp.cpp:
        (JSC::RegExp::printTraceData):
        * runtime/SamplingProfiler.cpp:
        (JSC::CFrameWalker::walk):
        * runtime/SlowPathReturnType.h:
        (JSC::encodeResult):
        (JSC::decodeResult):
        * tools/SigillCrashAnalyzer.cpp:
        (JSC::SigillCrashAnalyzer::dumpCodeBlock):

2018-10-15  Justin Fan  <justin_fan@apple.com>

        Add WebGPU 2018 feature flag and experimental feature flag
        https://bugs.webkit.org/show_bug.cgi?id=190509

        Reviewed by Dean Jackson.

        Re-add ENABLE_WEBGPU, an experimental feature flag, and a RuntimeEnabledFeature
        for the 2018 WebGPU prototype.

        * Configurations/FeatureDefines.xcconfig:

2018-10-15  Timothy Hatcher  <timothy@apple.com>

        Add support for prefers-color-scheme media query
        https://bugs.webkit.org/show_bug.cgi?id=190499
        rdar://problem/45212025

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig: Added ENABLE_DARK_MODE_CSS.

2018-10-15  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r237084, r237088, r237098, and
        r237114.
        https://bugs.webkit.org/show_bug.cgi?id=190602

        Breaks internal builds. (Requested by ryanhaddad on #webkit).

        Reverted changesets:

        "Separate configuration extraction from offset extraction"
        https://bugs.webkit.org/show_bug.cgi?id=189708
        https://trac.webkit.org/changeset/237084

        "Gardening: Build fix after r237084."
        https://bugs.webkit.org/show_bug.cgi?id=189708
        https://trac.webkit.org/changeset/237088

        "Gardening: Build fix after r237084."
        https://bugs.webkit.org/show_bug.cgi?id=189708
        https://trac.webkit.org/changeset/237098

        "REGRESSION (r237084): JavaScriptCore fails to build on Linux"
        https://trac.webkit.org/changeset/237114

2018-10-15  Keith Miller  <keith_miller@apple.com>

        BytecodeDumper should print all switch labels
        https://bugs.webkit.org/show_bug.cgi?id=190596

        Reviewed by Saam Barati.

        Right now the bytecode dumper only prints the default target not any of the
        non-default targets.

        * bytecode/BytecodeDumper.cpp:
        (JSC::BytecodeDumper<Block>::dumpBytecode):

2018-10-15  Saam barati  <sbarati@apple.com>

        Emit fjcvtzs on ARM64E on Darwin
        https://bugs.webkit.org/show_bug.cgi?id=184023

        Reviewed by Yusuke Suzuki and Filip Pizlo.

        ARMv8.3 introduced the fjcvtzs instruction which does double->int32
        conversion using the semantics defined by JavaScript:
        http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801g/hko1477562192868.html
        This patch teaches JSC to use that instruction when possible.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::fjcvtzs):
        (JSC::ARM64Assembler::fjcvtzsInsn):
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::MacroAssemblerARM64::collectCPUFeatures):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::supportsDoubleToInt32ConversionUsingJavaScriptSemantics):
        (JSC::MacroAssemblerARM64::convertDoubleToInt32UsingJavaScriptSemantics):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        * disassembler/ARM64/A64DOpcode.cpp:
        * disassembler/ARM64/A64DOpcode.h:
        (JSC::ARM64Disassembler::A64DOpcode::appendInstructionName):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
        * jit/JITRightShiftGenerator.cpp:
        (JSC::JITRightShiftGenerator::generateFastPath):
        * runtime/MathCommon.h:
        (JSC::toInt32):

2018-10-15  Saam Barati  <sbarati@apple.com>

        JSArray::shiftCountWithArrayStorage is wrong when an array has holes
        https://bugs.webkit.org/show_bug.cgi?id=190262
        <rdar://problem/44986241>

        Reviewed by Mark Lam.

        We would take the fast path for shiftCountWithArrayStorage when the array
        hasHoles(). However, the code for this was wrong. It'd incorrectly update
        ArrayStorage::m_numValuesInVector. Since the hasHoles() for ArrayStorage
        path is never taken in JetStream 2, this patch just removes that from
        the fast path. Instead, we just fallback to the slow path when hasHoles().
        If we find evidence that this matters for real use cases, we can
        figure out a way to make the fast path work.

        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCountWithArrayStorage):

2018-10-15  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r237054.
        https://bugs.webkit.org/show_bug.cgi?id=190593

        "this regressed JetStream 2 by 6% on iOS" (Requested by
        saamyjoon on #webkit).

        Reverted changeset:

        "[JSC] JSC should have "parseFunction" to optimize Function
        constructor"
        https://bugs.webkit.org/show_bug.cgi?id=190340
        https://trac.webkit.org/changeset/237054

2018-10-14  David Kilzer  <ddkilzer@apple.com>

        REGRESSION (r237084): JavaScriptCore fails to build on Linux
        <https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10949>

        * llint/LLIntSettingsExtractor.cpp: Attempt to fix build by
        including <stdio.h>.

2018-10-15  Alex Christensen  <achristensen@webkit.org>

        Shrink more enum classes
        https://bugs.webkit.org/show_bug.cgi?id=190540

        Reviewed by Chris Dumez.

        * runtime/ConsoleTypes.h:

2018-10-15  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Disable DOMJIT on 32bit architecture
        https://bugs.webkit.org/show_bug.cgi?id=190387

        Reviewed by Mark Lam.

        We disable DOMJIT on 32bit architecture due to exhaustion of registers.

        * runtime/Options.h:

2018-10-15  Alex Christensen  <achristensen@webkit.org>

        Include EnumTraits.h less
        https://bugs.webkit.org/show_bug.cgi?id=190535

        Reviewed by Chris Dumez.

        * runtime/ConsoleTypes.h:

2018-10-14  Mark Lam  <mark.lam@apple.com>

        Gardening: Build fix after r237084.
        https://bugs.webkit.org/show_bug.cgi?id=189708

        Unreviewd.

        * llint/LLIntOffsetsExtractor.cpp:

2018-10-14  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Remove Option::useAsyncIterator
        https://bugs.webkit.org/show_bug.cgi?id=190567

        Reviewed by Saam Barati.

        Async iterator is enabled by default at 2017-08-09. It is already shipped in several releases,
        and we can think that it is already mature. Let's drop the option `Option::useAsyncIterator`.

        * Configurations/FeatureDefines.xcconfig:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewFunction):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionMetadata):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseForStatement):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseAsyncFunctionExpression):
        * runtime/Options.h:

2018-10-14  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Remove Options::useObjectRestSpread
        https://bugs.webkit.org/show_bug.cgi?id=190568

        Reviewed by Saam Barati.

        Options::useObjectRestSpread is enabled by default at 2017-06-27. It is already shipped in several releases,
        and we can think that it is mature. Let's drop Options::useObjectRestSpread() flag.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseProperty):
        * parser/Parser.h:
        * runtime/Options.h:

2018-10-13  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] JSON.stringify can accept call-with-no-arguments
        https://bugs.webkit.org/show_bug.cgi?id=190343

        Reviewed by Mark Lam.

        JSON.stringify can accept `JSON.stringify()` call (call-with-no-arguments) according to the spec[1].
        Instead of throwing an error, we should take the first argument as `undefined` if it is not given.

        [1]: https://tc39.github.io/ecma262/#sec-json.stringify

        * runtime/JSONObject.cpp:
        (JSC::JSONProtoFuncStringify):

2018-10-12  Tadeu Zagallo  <tzagallo@apple.com>

        Gardening: Build fix after r237084.
        https://bugs.webkit.org/show_bug.cgi?id=189708

        Unreviewd.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2018-10-12  Tadeu Zagallo  <tzagallo@apple.com>

        Separate configuration extraction from offset extraction
        https://bugs.webkit.org/show_bug.cgi?id=189708

        Reviewed by Keith Miller.

        Instead of generating a file with all offsets for every combination of
        configurations, we first generate a file with only the configuration
        indices and pass that to the offset extractor. The offset extractor then
        only generates the offsets for valid configurations

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * llint/LLIntOffsetsExtractor.cpp:
        (JSC::LLIntOffsetsExtractor::dummy):
        * llint/LLIntSettingsExtractor.cpp: Added.
        (main):
        * offlineasm/generate_offset_extractor.rb:
        * offlineasm/generate_settings_extractor.rb: Added.
        * offlineasm/offsets.rb:
        * offlineasm/settings.rb:

2018-10-12  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r237063.

        Caused layout test fast/dom/Window/window-postmessage-clone-
        deep-array.html to fail on macOS and iOS Debug bots.

        Reverted changeset:

        "[JSC] Remove gcc warnings on mips and armv7"
        https://bugs.webkit.org/show_bug.cgi?id=188598
        https://trac.webkit.org/changeset/237063

2018-10-11  Guillaume Emont  <guijemont@igalia.com>

        [JSC] Remove gcc warnings on mips and armv7
        https://bugs.webkit.org/show_bug.cgi?id=188598

        Reviewed by Mark Lam.

        Fix many gcc/clang warnings that are false positives, mostly alignment
        issues.

        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printMemory):
        Use bitwise_cast instead of reinterpret_cast.
        * assembler/testmasm.cpp:
        (JSC::floatOperands):
        marked as potentially unused as it is not used on all platforms.
        (JSC::testProbeModifiesStackValues):
        modifiedFlags is not used on mips, so don't declare it.
        * bytecode/CodeBlock.h:
        Make ScriptExecutable::prepareForExecution() return an
        std::optional<Exception*> instead of a JSObject*.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeProgram):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeModuleProgram):
        Update calling code for the prototype change of
        ScriptExecutable::prepareForExecution().
        * jit/JITOperations.cpp: Same as for Interpreter.cpp.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall): Same as for Interpreter.cpp.
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::dataStorage):
        Use bitwise_cast instead of reinterpret_cast.
        * runtime/ScriptExecutable.cpp:
        * runtime/ScriptExecutable.h:
        Make ScriptExecutable::prepareForExecution() return an
        std::optional<Exception*> instead of a JSObject*.
        * tools/JSDollarVM.cpp:
        (JSC::codeBlockFromArg): Use bitwise_cast instead of reinterpret_cast.

2018-10-11  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Use currentStackPointer more
        https://bugs.webkit.org/show_bug.cgi?id=190503

        Reviewed by Saam Barati.

        * runtime/VM.cpp:
        (JSC::VM::committedStackByteCount):

2018-10-08  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] JSC should have "parseFunction" to optimize Function constructor
        https://bugs.webkit.org/show_bug.cgi?id=190340

        Reviewed by Mark Lam.

        The current Function constructor is suboptimal. We parse the piece of the same code three times to meet
        the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function.
        And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation
        is really costly and ideally we should meet the above requirement by the one time parsing.

        To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function
        takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser.
        For example, if we run the code,

            Function('/*', '*/){')

        According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter
        string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing
        that, in our implementation, we first create the entire string.

            function anonymous(/*) {
                */){
            }

        And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case,
        the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token
        offset of the parameters is the given end position. This check allows us to raise the error correctly to the
        above example while we parse the entire function only once. And we do not need to create two strings too.

        This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is
        significantly sped up (28.2%).

        Before:
            uglify-js:  2.94 runs/s
        After:
            uglify-js:  3.77 runs/s

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedFunctionExecutable.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseSingleFunction):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parseFunctionExpression):
        (JSC::Parser<LexerType>::parseAsyncFunctionExpression):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        (JSC::parse):
        (JSC::parseFunctionForFunctionConstructor):
        * parser/ParserModes.h:
        * parser/ParserTokens.h:
        (JSC::JSTextPosition::JSTextPosition):
        (JSC::JSTokenLocation::JSTokenLocation): Deleted.
        * parser/SourceCodeKey.h:
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::operator== const):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
        (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
        * runtime/CodeCache.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionExecutable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/FunctionExecutable.h:

2018-10-11  Ross Kirsling  <ross.kirsling@sony.com>

        Fix non-existent define `CPU(JSVALUE64)`
        https://bugs.webkit.org/show_bug.cgi?id=190479

        Reviewed by Yusuke Suzuki.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsImpl):
        Correct CPU(JSVALUE64) to USE(JSVALUE64).

2018-10-11  Keith Rollin  <krollin@apple.com>

        CURRENT_ARCH should not be used in Run Script phase.
        https://bugs.webkit.org/show_bug.cgi?id=190407
        <rdar://problem/45133556>

        Reviewed by Alexey Proskuryakov.

        CURRENT_ARCH is used in a number of Xcode Run Script phases. However,
        CURRENT_ARCH is not well-defined during this phase (and may even have
        the value "undefined") since this phase is run just once per build
        rather than once per supported architecture. Migrate away from
        CURRENT_ARCH in favor of ARCHS, either by iterating over ARCHS and
        performing an operation for each value, or by picking the first entry
        in ARCHS and using that as a representative value.

        * JavaScriptCore.xcodeproj/project.pbxproj: Store
        LLIntDesiredOffsets.h into a directory with a name based on ARCHS
        rather than CURRENT_ARCH.

2018-10-10  Mark Lam  <mark.lam@apple.com>

        Changes towards allowing use of the ASAN detect_stack_use_after_return option.
        https://bugs.webkit.org/show_bug.cgi?id=190405
        <rdar://problem/45131464>

        Reviewed by Michael Saboff.

        The ASAN detect_stack_use_after_return option checks for use of stack variables
        after they have been freed.  It does this by allocating relevant stack variables
        in heap memory (instead of on the stack) if the code ever takes the address of
        those stack variables.  Unfortunately, this is a common idiom that we use to
        compute the approximate stack pointer value.  As a result, on such ASAN runs, the
        computed approximate stack pointer value will point into the heap instead of the
        stack.  This breaks the VM's expectations and wreaks havoc.

        To fix this, we use the newly introduced WTF::currentStackPointer() instead of
        taking the address of stack variables.

        We also need to enhance ExceptionScopes to be able to work with ASAN
        detect_stack_use_after_return which will allocated the scope in the heap.  We
        work around this by passing the current stack pointer of the instantiating calling
        frame into the scope constructor, and using that for the position check in
        ~ThrowScope() instead.

        The above is only a start towards enabling ASAN detect_stack_use_after_return on
        the VM.  There are still other issues to be resolved before we can run with this
        ASAN option.

        * runtime/CatchScope.h:
        * runtime/ExceptionEventLocation.h:
        (JSC::ExceptionEventLocation::ExceptionEventLocation):
        * runtime/ExceptionScope.h:
        (JSC::ExceptionScope::stackPosition const):
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):
        * runtime/ThrowScope.cpp:
        (JSC::ThrowScope::~ThrowScope):
        * runtime/ThrowScope.h:
        * runtime/VM.h:
        (JSC::VM::needExceptionCheck const):
        (JSC::VM::isSafeToRecurse const):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const):

2018-10-10  Devin Rousso  <drousso@apple.com>

        Web Inspector: create special Network waterfall for media events
        https://bugs.webkit.org/show_bug.cgi?id=189773
        <rdar://problem/44626605>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/DOM.json:
        Add `didFireEvent` event that is fired when specific event listeners added by
        `InspectorInstrumentation::addEventListenersToNode` are fired.

2018-10-10  Michael Saboff  <msaboff@apple.com>

        Increase executable memory pool from 64MB to 128MB for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=190453

        Reviewed by Saam Barati.

        * jit/ExecutableAllocator.cpp:

2018-10-10  Devin Rousso  <drousso@apple.com>

        Web Inspector: notify the frontend when a canvas has started recording via console.record
        https://bugs.webkit.org/show_bug.cgi?id=190306

        Reviewed by Brian Burg.

        * inspector/protocol/Canvas.json:
        Add `recordingStarted` event.

        * inspector/protocol/Recording.json:
        Add `Initiator` enum for determining who started the recording.

2018-10-10  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Rename createXXX to tryCreateXXX if it can return RefPtr
        https://bugs.webkit.org/show_bug.cgi?id=190429

        Reviewed by Saam Barati.

        Some createXXX functions can fail. But sometimes the caller does not perform error checking.
        To make it explicit that these functions can fail, we rename these functions from createXXX
        to tryCreateXXX. In this patch, we focus on non-JS-managed factory functions. If the factory
        function does not fail, it should return Ref<>. Otherwise, it should be named as tryCreateXXX
        and it should return RefPtr<>.

        This patch mainly focuses on TypedArray factory functions. Previously, these functions are
        `RefPtr<XXXArray> create(...)`. This patch changes them to `RefPtr<XXXArray> tryCreate(...)`.
        And we also introduce `Ref<XXXArray> create(...)` function which internally performs
        RELEASE_ASSERT on the result of `tryCreate(...)`.

        And we also convert OpaqueJSString::create to OpaqueJSString::tryCreate since it can fail.

        This change actually finds one place which does not perform any null checkings while it uses
        `RefPtr<> create(...)` function.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
        (JSC::JSCallbackObject<Parent>::put):
        (JSC::JSCallbackObject<Parent>::putByIndex):
        (JSC::JSCallbackObject<Parent>::deleteProperty):
        (JSC::JSCallbackObject<Parent>::callbackGetter):
        * API/JSClassRef.h:
        (StaticValueEntry::StaticValueEntry):
        * API/JSContext.mm:
        (-[JSContext evaluateScript:withSourceURL:]):
        (-[JSContext setName:]):
        * API/JSContextRef.cpp:
        (JSGlobalContextCopyName):
        (JSContextCreateBacktrace):
        * API/JSObjectRef.cpp:
        (JSObjectCopyPropertyNames):
        * API/JSScriptRef.cpp:
        * API/JSStringRef.cpp:
        (JSStringCreateWithCharactersNoCopy):
        * API/JSValue.mm:
        (+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]):
        (+[JSValue valueWithNewErrorFromMessage:inContext:]):
        (+[JSValue valueWithNewSymbolFromDescription:inContext:]):
        (performPropertyOperation):
        (-[JSValue invokeMethod:withArguments:]):
        (containerValueToObject):
        (objectToValueWithoutCopy):
        (objectToValue):
        * API/JSValueRef.cpp:
        (JSValueCreateJSONString):
        (JSValueToStringCopy):
        * API/OpaqueJSString.cpp:
        (OpaqueJSString::tryCreate):
        (OpaqueJSString::create): Deleted.
        * API/OpaqueJSString.h:
        * API/glib/JSCContext.cpp:
        (evaluateScriptInContext):
        * API/glib/JSCValue.cpp:
        (jsc_value_new_string_from_bytes):
        * ftl/FTLLazySlowPath.h:
        (JSC::FTL::LazySlowPath::createGenerator):
        * ftl/FTLLazySlowPathCall.h:
        (JSC::FTL::createLazyCallGenerator):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::emitOSRExit):
        (JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        * ftl/FTLOSRExit.h:
        * ftl/FTLPatchpointExceptionHandle.cpp:
        (JSC::FTL::PatchpointExceptionHandle::create):
        (JSC::FTL::PatchpointExceptionHandle::createHandle):
        * ftl/FTLPatchpointExceptionHandle.h:
        * heap/EdenGCActivityCallback.h:
        (JSC::GCActivityCallback::tryCreateEdenTimer):
        (JSC::GCActivityCallback::createEdenTimer): Deleted.
        * heap/FullGCActivityCallback.h:
        (JSC::GCActivityCallback::tryCreateFullTimer):
        (JSC::GCActivityCallback::createFullTimer): Deleted.
        * heap/GCActivityCallback.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        * inspector/AsyncStackTrace.cpp:
        (Inspector::AsyncStackTrace::create):
        * inspector/AsyncStackTrace.h:
        * jsc.cpp:
        (fillBufferWithContentsOfFile):
        * runtime/ArrayBuffer.h:
        * runtime/GenericTypedArrayView.h:
        * runtime/GenericTypedArrayViewInlines.h:
        (JSC::GenericTypedArrayView<Adaptor>::create):
        (JSC::GenericTypedArrayView<Adaptor>::tryCreate):
        (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
        (JSC::GenericTypedArrayView<Adaptor>::tryCreateUninitialized):
        (JSC::GenericTypedArrayView<Adaptor>::subarray const):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::possiblySharedImpl):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::possiblySharedTypedImpl):
        (JSC::JSGenericTypedArrayView<Adaptor>::unsharedTypedImpl):
        * wasm/WasmMemory.cpp:
        (JSC::Wasm::Memory::create):
        (JSC::Wasm::Memory::tryCreate):
        * wasm/WasmMemory.h:
        * wasm/WasmTable.cpp:
        (JSC::Wasm::Table::tryCreate):
        (JSC::Wasm::Table::create): Deleted.
        * wasm/WasmTable.h:
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::create):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
        * wasm/js/WebAssemblyMemoryConstructor.cpp:
        (JSC::constructJSWebAssemblyMemory):
        * wasm/js/WebAssemblyModuleRecord.cpp:
        (JSC::WebAssemblyModuleRecord::link):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):

2018-10-09  Devin Rousso  <drousso@apple.com>

        Web Inspector: show redirect requests in Network and Timelines tabs
        https://bugs.webkit.org/show_bug.cgi?id=150005
        <rdar://problem/5378164>

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Network.json:
        Add missing fields to `ResourceTiming`.

2018-10-09  Claudio Saavedra  <csaavedra@igalia.com>

        [WPE] Explicitly link against gmodule where used
        https://bugs.webkit.org/show_bug.cgi?id=190398

        Reviewed by Michael Catanzaro.

        * PlatformWPE.cmake:

2018-10-08  Justin Fan  <justin_fan@apple.com>

        WebGPU: Rename old WebGPU prototype to WebMetal
        https://bugs.webkit.org/show_bug.cgi?id=190325
        <rdar://problem/44990443>

        Reviewed by Dean Jackson.

        Rename WebGPU prototype files to WebMetal in preparation for implementing the new (Oct 2018) WebGPU interface.

        * Configurations/FeatureDefines.xcconfig:
        * inspector/protocol/Canvas.json:
        * inspector/scripts/codegen/generator.py:

2018-10-08  Aditya Keerthi  <akeerthi@apple.com>

        Make <input type=color> a runtime enabled (on-by-default) feature
        https://bugs.webkit.org/show_bug.cgi?id=189162

        Reviewed by Wenson Hsieh and Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

2018-10-08  Devin Rousso  <drousso@apple.com>

        Web Inspector: group media network entries by the node that triggered the request
        https://bugs.webkit.org/show_bug.cgi?id=189606
        <rdar://problem/44438527>

        Reviewed by Brian Burg.

        * inspector/protocol/Network.json:
        Add an optional `nodeId` field to the `Initiator` object that is set it is possible to
        determine which ancestor node triggered the load. It may not correspond directly to the node
        with the href/src, as that url may only be used by an ancestor for loading.

2018-10-07  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC][Linux] Use non-truncated name for JIT workers in Linux
        https://bugs.webkit.org/show_bug.cgi?id=190339

        Reviewed by Mark Lam.

        The current thread names are meaningless in Linux environment. We do not want to
        have truncated name in Linux: we want to have clear name in Linux. Instead, we
        should have the name for Linux separately from the name used in the non-Linux
        environments. This patch adds FTLWorker, DFGWorker, and JITWorker names for
        Linux environment.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::createWorklistName):
        (JSC::DFG::Worklist::Worklist):
        (JSC::DFG::Worklist::create):
        (JSC::DFG::ensureGlobalDFGWorklist):
        (JSC::DFG::ensureGlobalFTLWorklist):
        * dfg/DFGWorklist.h:
        * jit/JITWorklist.cpp:

2018-10-07  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Name Heap threads
        https://bugs.webkit.org/show_bug.cgi?id=190337

        Reviewed by Mark Lam.

        Name heap threads as "Heap Helper Thread". In Linux, we name it "HeapHelper" since
        Linux does not accept the name longer than 15. We do not want to use the short name
        for non-Linux environment. And we want to have clear name in Linux: truncated name
        is not good. So, having the two names is the only way.

        * heap/HeapHelperPool.cpp:
        (JSC::heapHelperPool):

2018-10-07  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Avoid creating ProgramExecutable in checkSyntax
        https://bugs.webkit.org/show_bug.cgi?id=190332

        Reviewed by Mark Lam.

        uglify-js in web-tooling-benchmark executes massive number of Function constructor calls.
        In Function constructor code, we perform checkSyntax for body and parameters. So fast checkSyntax
        is important when the performance of Function constructor matters. Current checkSyntax code
        unnecessarily allocates ProgramExecutable. This patch removes this allocation and improves
        the benchmark score slightly.

        Before:
            uglify-js:  2.87 runs/s
        After:
            uglify-js:  2.94 runs/s

        * runtime/Completion.cpp:
        (JSC::checkSyntaxInternal):
        (JSC::checkSyntax):
        * runtime/ProgramExecutable.cpp:
        (JSC::ProgramExecutable::checkSyntax): Deleted.
        * runtime/ProgramExecutable.h:

2018-10-06  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Implement support for "|"
        https://bugs.webkit.org/show_bug.cgi?id=186229

        Reviewed by Yusuke Suzuki.

        This patch is introducing support for BigInt into bitwise "or" operator.
        In addition, we are also introducing 2 new DFG nodes, named "ArithBitOr" and
        "ValueBitOr", to replace "BitOr" node. The idea is to follow the
        difference that we make on Arith<op> and Value<op>, where ArithBitOr
        handles cases when the operands are Int32 and ValueBitOr handles
        the remaining cases.

        We are also changing op_bitor to use ValueProfile. We are using
        ValueProfile during DFG generation to emit "ArithBitOr" when
        outcome prediction is Int32.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::arithProfileForPC):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitBinaryOp):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::bitwiseOp):
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
        (JSC::DFG::SpeculativeJIT::compileBitwiseOp):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::bitOp):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueBitOr):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithBitOr):
        (JSC::FTL::DFG::LowerDFGToB3::compileBitOr): Deleted.
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_bitor):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::bitwiseAnd):
        (JSC::JSBigInt::bitwiseOr):
        (JSC::JSBigInt::absoluteBitwiseOp):
        (JSC::JSBigInt::absoluteAddOne):
        * runtime/JSBigInt.h:

2018-10-05  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Use new extra memory reporting in SparseArrayMap
        https://bugs.webkit.org/show_bug.cgi?id=190278

        Reviewed by Keith Miller.

        This patch switches the extra memory reporting mechanism from deprecatedReportExtraMemory
        to reportExtraMemoryAllocated & reportExtraMemoryVisited in SparseArrayMap.

        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::add):
        (JSC::SparseArrayValueMap::visitChildren):

2018-10-05  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC][Linux] Support Perf JITDump logging
        https://bugs.webkit.org/show_bug.cgi?id=189893

        Reviewed by Mark Lam.

        This patch adds Linux `perf` command's JIT Dump support. It allows JSC to tell perf about JIT code information.
        We add a command line option, `--logJITCodeForPerf`, which dumps `jit-%pid.dump` in the current directory.
        By using this dump and perf.data output, we can annotate JIT code with profiling information.

            $ echo "(function f() { var s = 0; for (var i = 0; i < 1000000000; i++) { s += i; } return s; })();" > test.js
            $ perf record -k mono ../../WebKitBuild/perf/Release/bin/jsc test.js --logJITCodeForPerf=true
            [ perf record: Woken up 1 times to write data ]
            [ perf record: Captured and wrote 0.182 MB perf.data (4346 samples) ]
            $ perf inject --jit -i perf.data -o perf.jit.data
            $ perf report -i perf.jit.data

        * Sources.txt:
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * assembler/PerfLog.cpp: Added.
        (JSC::PerfLog::singleton):
        (JSC::generateTimestamp):
        (JSC::getCurrentThreadID):
        (JSC::PerfLog::PerfLog):
        (JSC::PerfLog::write):
        (JSC::PerfLog::flush):
        (JSC::PerfLog::log):
        * assembler/PerfLog.h: Added.
        * jit/ExecutableAllocator.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        * runtime/Options.cpp:
        (JSC::Options::isAvailable):
        * runtime/Options.h:

2018-10-05  Mark Lam  <mark.lam@apple.com>

        Gardening: Build fix after r236880.
        https://bugs.webkit.org/show_bug.cgi?id=190317

        Unreviewed.

        * jit/ExecutableAllocator.h:

2018-10-05  Mark Lam  <mark.lam@apple.com>

        performJITMemcpy() should handle the case when the executable allocator is not initialized yet.
        https://bugs.webkit.org/show_bug.cgi?id=190317
        <rdar://problem/45039398>

        Reviewed by Saam Barati.

        When SeparatedWXHeaps is in use, jitWriteThunkGenerator() will call performJITMemcpy()
        to copy memory before the JIT fixed memory pool is initialize.  Before r236864,
        performJITMemcpy() would just do a memcpy in that case.  We need to restore the
        equivalent behavior.

        * jit/ExecutableAllocator.cpp:
        (JSC::isJITPC):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):

2018-10-05  Carlos Eduardo Ramalho  <cadubentzen@gmail.com>

        [WPE][JSC] Use Unified Sources for Platform-specific sources
        https://bugs.webkit.org/show_bug.cgi?id=190300

        Reviewed by Yusuke Suzuki.

        Currently the GTK port already used Unified Sources with the same source files.
        As WPE has conditional code using gmodule, we need to add GLIB_GMODULE_LIBRARIES
        to the list of libraries to link with.

        * PlatformWPE.cmake:
        * SourcesWPE.txt: Added.
        * shell/PlatformWPE.cmake:

2018-10-05  Mike Gorse  <mgorse@alum.wpi.edu>

        [GTK] build fails with python 3 if LANG and LC_TYPE are unset
        https://bugs.webkit.org/show_bug.cgi?id=190258

        Reviewed by Konstantin Tokarev.

        * Scripts/cssmin.py: Set stdout to UTF-8 on python 3.
        * Scripts/generateIntlCanonicalizeLanguage.py: Open files with
          encoding=UTF-8 on Python 3.
        * yarr/generateYarrCanonicalizeUnicode: Ditto.
        * yarr/generateYarrUnicodePropertyTables.py: Ditto.

2018-10-04  Mark Lam  <mark.lam@apple.com>

        Move start/EndOfFixedExecutableMemoryPool pointers into the FixedVMPoolExecutableAllocator object.
        https://bugs.webkit.org/show_bug.cgi?id=190295
        <rdar://problem/19197193>

        Reviewed by Saam Barati.

        This allows us to use the tagging logic already baked into MacroAssemblerCodePtr
        instead of needing to use our own custom version here.

        * jit/ExecutableAllocator.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::memoryStart):
        (JSC::FixedVMPoolExecutableAllocator::memoryEnd):
        (JSC::FixedVMPoolExecutableAllocator::isJITPC):
        (JSC::ExecutableAllocator::allocate):
        (JSC::startOfFixedExecutableMemoryPoolImpl):
        (JSC::endOfFixedExecutableMemoryPoolImpl):
        (JSC::isJITPC):
        * jit/ExecutableAllocator.h:

2018-10-04  Mark Lam  <mark.lam@apple.com>

        Disable Options::useWebAssemblyFastMemory() on linux if ASAN signal handling is not disabled.
        https://bugs.webkit.org/show_bug.cgi?id=190283
        <rdar://problem/45015752>

        Reviewed by Keith Miller.

        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * wasm/WasmFaultSignalHandler.cpp:
        (JSC::Wasm::enableFastMemory):

2018-10-03  Ross Kirsling  <ross.kirsling@sony.com>

        [JSC] print() changes CRLF to CRCRLF on Windows
        https://bugs.webkit.org/show_bug.cgi?id=190228

        Reviewed by Mark Lam.

        * jsc.cpp:
        (main):
        Ultimately, this is just the normal behavior of printf in text mode on Windows.
        Since we're reading in files as binary, we need to be printing out as binary too
        (just as we do in DumpRenderTree and ImageDiff.)

2018-10-03  Saam barati  <sbarati@apple.com>

        lowXYZ in FTLLower should always filter the type of the incoming edge
        https://bugs.webkit.org/show_bug.cgi?id=189939
        <rdar://problem/44407030>

        Reviewed by Michael Saboff.

        For example, the FTL may know more about data flow than AI in certain programs,
        and it needs to inform AI of these data flow properties to appease the assertion
        we have in AI that a node must perform type checks on its child nodes.
        
        For example, consider this program:
        
        ```
        bb#1
        a: Phi // Let's say it has an Int32 result, so it goes into the int32 hash table in FTLLower
        Branch(...,  #2, #3)
        
        bb#2
        ArrayifyToStructure(Cell:@a) // This modifies @a to have the its previous type union the type of some structure set.
        Jump(#3)
        
        bb#3
        c: Add(Int32:@something, Int32:@a)
        ```
        
        When the Add node does lowInt32() for @a, FTL lower used to just grab it
        from the int32 hash table without filtering the AbstractValue. However,
        the parent node is asking for a type check to happen, so we must inform
        AI of this "type check" if we want to appease the assertion that all nodes
        perform type checks for their edges that semantically perform type checks.
        This patch makes it so we filter the AbstractValue in the lowXYZ even
        if FTLLower proved the value must be XYZ.

        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compilePhi):
        (JSC::FTL::DFG::LowerDFGToB3::simulatedTypeCheck):
        (JSC::FTL::DFG::LowerDFGToB3::lowInt32):
        (JSC::FTL::DFG::LowerDFGToB3::lowCell):
        (JSC::FTL::DFG::LowerDFGToB3::lowBoolean):

2018-10-03  Michael Saboff  <msaboff@apple.com>

        Command line jsc should report memory footprint in bytes
        https://bugs.webkit.org/show_bug.cgi?id=190267

        Reviewed by Mark Lam.

        Change to leave the footprint values from the system unmodified.

        * jsc.cpp:
        (JSCMemoryFootprint::finishCreation):

2018-10-03  Mark Lam  <mark.lam@apple.com>

        Suppress unreachable code warning for LLIntAssembly.h code.
        https://bugs.webkit.org/show_bug.cgi?id=190263
        <rdar://problem/44986532>

        Reviewed by Saam Barati.

        This is needed because LLIntAssembly.h is template generated from LowLevelInterpreter
        asm files, and may contain dead code which are harmless, but will trip up the warning.
        We should suppress the warning so that it doesn't break builds.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):

2018-10-03  Dan Bernstein  <mitz@apple.com>

        JavaScriptCore part of [Xcode] Update some build settings as recommended by Xcode 10
        https://bugs.webkit.org/show_bug.cgi?id=190250

        Reviewed by Alex Christensen.

        * API/tests/Regress141275.mm:
        (-[JSTEvaluator _sourcePerform]): Addressed newly-enabled CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF
          by making the self-retaining explicit.

        * API/tests/testapi.cpp:
        (testCAPIViaCpp): Addressed newly-enabled CLANG_WARN_UNREACHABLE_CODE by breaking out of the
          loop instead of returning from the lambda.

        * Configurations/Base.xcconfig: Enabled CLANG_WARN_COMMA, CLANG_WARN_UNREACHABLE_CODE,
          CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS, CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF, and
          CLANG_ANALYZER_LOCALIZABILITY_NONLOCALIZED.

        * JavaScriptCore.xcodeproj/project.pbxproj: Removed a duplicate reference to
          UnlinkedFunctionExecutable.h, and let Xcode update the project file.

        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::Printer::printAllRegisters): Addressed newly-enabled CLANG_WARN_COMMA by replacing
          some commas with semicolons.

2018-10-03  Mark Lam  <mark.lam@apple.com>

        Make string MaxLength for all WTF and JS strings consistently equal to INT_MAX.
        https://bugs.webkit.org/show_bug.cgi?id=190187
        <rdar://problem/42512909>

        Reviewed by Michael Saboff.

        Allowing different max string lengths at each level opens up opportunities for
        bugs to creep in.  With 2 different max length values, it is more difficult to
        keep the story straight on how we do overflow / bounds checks at each place in
        the code.  It's also difficult to tell if a seemingly valid check at the WTF level
        will have bad ramifications at the JSC level.  Also, it's also not meaningful to
        support a max length > INT_MAX.  To eliminate this class of bugs, we'll
        standardize on a MaxLength of INT_MAX at all levels.

        We'll also standardize the way we do length overflow checks on using
        CheckedArithmetic, and add some asserts to document the assumptions of the code.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        - Fix OOM error handling which crashed a test after the new MaxLength was applied.
        * runtime/JSString.h:
        (JSC::JSString::finishCreation):
        (JSC::JSString::createHasOtherOwner):
        (JSC::JSString::setLength):
        * runtime/JSStringInlines.h:
        (JSC::jsMakeNontrivialString):
        * runtime/Operations.h:
        (JSC::jsString):

2018-10-03  Koby Boyango  <koby.b@mce-sys.com>

        [JSC] Add a C++ callable overload of objectConstructorSeal
        https://bugs.webkit.org/show_bug.cgi?id=190137

        Reviewed by Yusuke Suzuki.

        * runtime/ObjectConstructor.cpp:
        * runtime/ObjectConstructor.h:

2018-10-02  Dominik Infuehr  <dinfuehr@igalia.com>

        Fix Disassembler-output on ARM Thumb2
        https://bugs.webkit.org/show_bug.cgi?id=190203

        On ARMv7 with Thumb2 addresses have bit 0 set to 1 to force
        execution in thumb mode for jumps and calls. The actual machine
        instructions are still aligned to 2-bytes though. Use dataLocation() as
        start address for disassembling since it unsets the thumb bit.
        Until now the disassembler would start at the wrong address (off by 1),
        resulting in the wrong disassembled machine instructions.

        Reviewed by Mark Lam.

        * disassembler/CapstoneDisassembler.cpp:
        (JSC::tryToDisassemble):

2018-10-02  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Add stub of ExecutableAllocator used when JIT is disabled
        https://bugs.webkit.org/show_bug.cgi?id=190215

        Reviewed by Mark Lam.

        When ENABLE(JIT) is disabled, we do not use JIT. But we ExecutableAllocator is still available since
        it is guarded by ENABLE(ASSEMBLER). ENABLE(ASSEMBLER) is necessary for LLInt ASM interpreter since
        our MacroAssembler tells machine architecture information. Eventually, we would like to decouple
        this machine architecture information from MacroAssembler. But for now, we use ENABLE(ASSEMBLER)
        for LLInt ASM interpreter even if JIT is disabled by ENABLE(JIT).

        To ensure any executable memory allocation is not done, we add a stub of ExecutableAllocator for
        non-JIT configurations. This does not have any functionality allocating executable memory, thus
        any accidental operation cannot attempt to allocate executable memory if ENABLE(JIT) = OFF.

        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::initializeAllocator):
        (JSC::ExecutableAllocator::singleton):
        * jit/ExecutableAllocator.h:
        (JSC::ExecutableAllocator::isValid const):
        (JSC::ExecutableAllocator::underMemoryPressure):
        (JSC::ExecutableAllocator::memoryPressureMultiplier):
        (JSC::ExecutableAllocator::dumpProfile):
        (JSC::ExecutableAllocator::allocate):
        (JSC::ExecutableAllocator::isValidExecutableMemory):
        (JSC::ExecutableAllocator::committedByteCount):
        (JSC::ExecutableAllocator::getLock const):
        (JSC::performJITMemcpy):

2018-10-01  Dean Jackson  <dino@apple.com>

        Remove CSS Animation Triggers
        https://bugs.webkit.org/show_bug.cgi?id=190175
        <rdar://problem/44925626>

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2018-10-02  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] BigInt.proptotype.toString is broken when radix is power of 2
        https://bugs.webkit.org/show_bug.cgi?id=190033

        Reviewed by Yusuke Suzuki.

        The implementation of JSBigInt::toStringToGeneric doesn't handle power
        of 2 radix when JSBigInt length is >= 2. To handle such cases, we
        implemented JSBigInt::toStringBasePowerOfTwo that follows the
        algorithm that groups bits using mask of (2 ^ n) - 1 to extract every
        digit.

        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::toString):
        (JSC::JSBigInt::toStringBasePowerOfTwo):
        * runtime/JSBigInt.h:

2018-10-01  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Add branchIfNaN and branchIfNotNaN
        https://bugs.webkit.org/show_bug.cgi?id=190122

        Reviewed by Mark Lam.

        Add AssemblyHelpers::{branchIfNaN, branchIfNotNaN} to make code more readable.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
        (JSC::DFG::SpeculativeJIT::compileDoubleRep):
        (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
        (JSC::DFG::SpeculativeJIT::compileSpread):
        (JSC::DFG::SpeculativeJIT::compileNewArray):
        (JSC::DFG::SpeculativeJIT::speculateRealNumber):
        (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
        (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
        (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::purifyNaN):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfNaN):
        (JSC::AssemblyHelpers::branchIfNotNaN):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGenericContiguousPutByVal):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):

2018-10-01  Mark Lam  <mark.lam@apple.com>

        Function.toString() should also copy the source code Functions that are class definitions.
        https://bugs.webkit.org/show_bug.cgi?id=190186
        <rdar://problem/44733360>

        Reviewed by Saam Barati.

        Previously, if the Function is a class definition, functionProtoFuncToString()
        would create a String using StringView::toStringWithoutCopying(), and use that
        String to make a JSString.  This is not a problem if the underlying SourceProvider
        (that backs the characters in that StringView) is immortal.  However, this is
        not always the case in practice.

        This patch fixes this issue by changing functionProtoFuncToString() to create the
        String using StringView::toString() instead, which makes a copy of the underlying
        characters buffer.  This detaches the resultant JSString from the SourceProvider
        characters buffer that it was created from, and ensure that the underlying
        characters buffer of the string will be alive for the entire lifetime of the
        JSString.

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):

2018-10-01  Keith Miller  <keith_miller@apple.com>

        Create a RELEASE_AND_RETURN macro for ExceptionScopes
        https://bugs.webkit.org/show_bug.cgi?id=190163

        Reviewed by Mark Lam.

        The new RELEASE_AND_RETURN does all the work for cases
        where you want to return the result of some expression
        without explicitly checking for an exception. This is
        much like the existing RETURN_IF_EXCEPTION macro.

        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithSize):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * jsc.cpp:
        (functionDollarAgentReceiveBroadcast):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::varargsSetup):
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::toJSON const):
        * runtime/AbstractModuleRecord.cpp:
        (JSC::AbstractModuleRecord::hostResolveImportedModule):
        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        * runtime/ArrayPrototype.cpp:
        (JSC::getProperty):
        (JSC::fastJoin):
        (JSC::arrayProtoFuncToString):
        (JSC::arrayProtoFuncToLocaleString):
        (JSC::arrayProtoFuncJoin):
        (JSC::arrayProtoFuncPop):
        (JSC::arrayProtoPrivateFuncConcatMemcpy):
        * runtime/BigIntConstructor.cpp:
        (JSC::toBigInt):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opInByVal):
        * runtime/ConstructData.cpp:
        (JSC::construct):
        * runtime/DateConstructor.cpp:
        (JSC::dateParse):
        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncToPrimitiveSymbol):
        * runtime/DirectArguments.h:
        * runtime/ErrorConstructor.cpp:
        (JSC::Interpreter::constructWithErrorConstructor):
        * runtime/ErrorPrototype.cpp:
        (JSC::errorProtoFuncToString):
        * runtime/ExceptionScope.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        * runtime/GenericArgumentsInlines.h:
        (JSC::GenericArguments<Type>::defineOwnProperty):
        * runtime/GetterSetter.cpp:
        (JSC::callGetter):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorFuncCompare):
        (JSC::IntlCollatorPrototypeFuncResolvedOptions):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatFuncFormatDateTime):
        (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatFuncFormatNumber):
        (JSC::IntlNumberFormatPrototypeFuncFormatToParts):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::intlNumberOption):
        * runtime/IntlObjectInlines.h:
        (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
        * runtime/IntlPluralRules.cpp:
        (JSC::IntlPluralRules::resolvedOptions):
        * runtime/IntlPluralRulesConstructor.cpp:
        (JSC::IntlPluralRulesConstructorFuncSupportedLocalesOf):
        * runtime/IntlPluralRulesPrototype.cpp:
        (JSC::IntlPluralRulesPrototypeFuncSelect):
        (JSC::IntlPluralRulesPrototypeFuncResolvedOptions):
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        (JSC::JSArray::put):
        (JSC::JSArray::setLength):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoGetterFuncByteLength):
        (JSC::sharedArrayBufferProtoGetterFuncByteLength):
        * runtime/JSArrayInlines.h:
        (JSC::toLength):
        * runtime/JSBoundFunction.cpp:
        (JSC::boundFunctionCall):
        (JSC::boundFunctionConstruct):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::toIndex const):
        (JSC::JSValue::toPropertyKey const):
        (JSC::JSValue::get const):
        (JSC::JSValue::getPropertySlot const):
        (JSC::JSValue::getOwnPropertySlot const):
        (JSC::JSValue::equalSlowCaseInline):
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::put):
        (JSC::JSDataView::defineOwnProperty):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::put):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::set):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::speciesConstruct):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::put):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::decode):
        (JSC::globalFuncEval):
        (JSC::globalFuncProtoGetter):
        * runtime/JSInternalPromise.cpp:
        (JSC::JSInternalPromise::then):
        * runtime/JSModuleEnvironment.cpp:
        (JSC::JSModuleEnvironment::put):
        * runtime/JSModuleLoader.cpp:
        (JSC::JSModuleLoader::provideFetch):
        (JSC::JSModuleLoader::loadAndEvaluateModule):
        (JSC::JSModuleLoader::loadModule):
        (JSC::JSModuleLoader::linkAndEvaluateModule):
        (JSC::JSModuleLoader::requestImportModule):
        (JSC::JSModuleLoader::getModuleNamespaceObject):
        (JSC::moduleLoaderRequestedModules):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::stringify):
        (JSC::Stringifier::toJSON):
        (JSC::Walker::walk):
        (JSC::JSONProtoFuncStringify):
        * runtime/JSObject.cpp:
        (JSC::ordinarySetSlow):
        (JSC::JSObject::putInlineSlow):
        (JSC::JSObject::toPrimitive const):
        (JSC::JSObject::hasInstance):
        (JSC::JSObject::toNumber const):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::defineOwnNonIndexProperty):
        * runtime/JSObject.h:
        (JSC::JSObject::get const):
        * runtime/JSObjectInlines.h:
        (JSC::JSObject::getPropertySlot const):
        (JSC::JSObject::putInlineForJSObject):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor):
        * runtime/ObjectConstructor.cpp:
        (JSC::constructObject):
        (JSC::objectConstructorGetPrototypeOf):
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorGetOwnPropertyDescriptors):
        (JSC::objectConstructorGetOwnPropertyNames):
        (JSC::objectConstructorGetOwnPropertySymbols):
        (JSC::objectConstructorKeys):
        (JSC::objectConstructorDefineProperty):
        (JSC::objectConstructorDefineProperties):
        (JSC::objectConstructorCreate):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToLocaleString):
        (JSC::objectProtoFuncToString):
        * runtime/Operations.cpp:
        (JSC::jsAddSlowCase):
        * runtime/Operations.h:
        (JSC::jsString):
        (JSC::jsLess):
        (JSC::jsLessEq):
        * runtime/ParseInt.h:
        (JSC::toStringView):
        * runtime/ProxyConstructor.cpp:
        (JSC::constructProxyObject):
        * runtime/ProxyObject.cpp:
        (JSC::ProxyObject::toStringName):
        (JSC::performProxyGet):
        (JSC::ProxyObject::performInternalMethodGetOwnProperty):
        (JSC::ProxyObject::performHasProperty):
        (JSC::ProxyObject::getOwnPropertySlotCommon):
        (JSC::ProxyObject::performPut):
        (JSC::ProxyObject::putByIndexCommon):
        (JSC::performProxyCall):
        (JSC::performProxyConstruct):
        (JSC::ProxyObject::performDelete):
        (JSC::ProxyObject::performPreventExtensions):
        (JSC::ProxyObject::performIsExtensible):
        (JSC::ProxyObject::performDefineOwnProperty):
        (JSC::ProxyObject::performSetPrototype):
        (JSC::ProxyObject::performGetPrototype):
        * runtime/ReflectObject.cpp:
        (JSC::reflectObjectConstruct):
        (JSC::reflectObjectDefineProperty):
        (JSC::reflectObjectGet):
        (JSC::reflectObjectGetOwnPropertyDescriptor):
        (JSC::reflectObjectGetPrototypeOf):
        (JSC::reflectObjectOwnKeys):
        (JSC::reflectObjectSet):
        * runtime/RegExpConstructor.cpp:
        (JSC::constructRegExp):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::defineOwnProperty):
        (JSC::RegExpObject::matchGlobal):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncTestFast):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncToString):
        * runtime/ScriptExecutable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/SetConstructor.cpp:
        (JSC::constructSet):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayEntry::put):
        * runtime/StringConstructor.cpp:
        (JSC::stringFromCharCode):
        (JSC::stringFromCodePoint):
        * runtime/StringObject.cpp:
        (JSC::StringObject::put):
        (JSC::StringObject::putByIndex):
        (JSC::StringObject::defineOwnProperty):
        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::removeUsingRegExpSearch):
        (JSC::replaceUsingRegExpSearch):
        (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
        (JSC::replaceUsingStringSearch):
        (JSC::repeatCharacter):
        (JSC::replace):
        (JSC::stringProtoFuncReplaceUsingRegExp):
        (JSC::stringProtoFuncReplaceUsingStringSearch):
        (JSC::stringProtoFuncSplitFast):
        (JSC::stringProtoFuncToLowerCase):
        (JSC::stringProtoFuncToUpperCase):
        (JSC::toLocaleCase):
        (JSC::trimString):
        (JSC::stringProtoFuncIncludes):
        (JSC::builtinStringIncludesInternal):
        (JSC::normalize):
        (JSC::stringProtoFuncNormalize):
        * runtime/SymbolPrototype.cpp:
        (JSC::symbolProtoFuncToString):
        (JSC::symbolProtoFuncValueOf):
        * tools/JSDollarVM.cpp:
        (WTF::functionWasmStreamingParserAddBytes):
        (JSC::functionGetPrivateProperty):
        * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
        (JSC::constructJSWebAssemblyCompileError):
        * wasm/js/WebAssemblyModuleConstructor.cpp:
        (JSC::constructJSWebAssemblyModule):
        (JSC::WebAssemblyModuleConstructor::createModule):
        * wasm/js/WebAssemblyTableConstructor.cpp:
        (JSC::constructJSWebAssemblyTable):
        * wasm/js/WebAssemblyWrapperFunction.cpp:
        (JSC::callWebAssemblyWrapperFunction):

2018-10-01  Koby Boyango  <koby.b@mce-sys.com>

        [JSC] Add a JSONStringify overload that receives a JSValue space
        https://bugs.webkit.org/show_bug.cgi?id=190131

        Reviewed by Yusuke Suzuki.

        * runtime/JSONObject.cpp:
        * runtime/JSONObject.h:

2018-10-01  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r236647.
        https://bugs.webkit.org/show_bug.cgi?id=190124

        Breaking test stress/big-int-to-string.js (Requested by
        caiolima_ on #webkit).

        Reverted changeset:

        "[BigInt] BigInt.proptotype.toString is broken when radix is
        power of 2"
        https://bugs.webkit.org/show_bug.cgi?id=190033
        https://trac.webkit.org/changeset/236647

2018-10-01  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [WebAssembly] Move type conversion code of JSToWasm return type to JS wasm wrapper
        https://bugs.webkit.org/show_bug.cgi?id=189498

        Reviewed by Saam Barati.

        To call JS-to-Wasm code we need to convert the result value from wasm function to
        the JS type. Previously this is done by callWebAssemblyFunction by using swtich
        over signature.returnType(). But since we know the value of `signature.returnType()`
        at compiling phase, we can emit a small conversion code directly to JSToWasm glue
        and remove this switch from callWebAssemblyFunction.

        In JSToWasm glue code, we do not have tag registers. So we use DoNotHaveTagRegisters
        in boxInt32 and boxDouble. Since boxDouble does not have DoNotHaveTagRegisters version,
        we add an implementation for that.

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::boxDouble):
        * wasm/js/JSToWasm.cpp:
        (JSC::Wasm::createJSToWasmWrapper):
        * wasm/js/WebAssemblyFunction.cpp:
        (JSC::callWebAssemblyFunction):

2018-09-30  Caio Lima  <ticaiolima@gmail.com>

        [BigInt] BigInt.proptotype.toString is broken when radix is power of 2
        https://bugs.webkit.org/show_bug.cgi?id=190033

        Reviewed by Yusuke Suzuki.

        The implementation of JSBigInt::toStringToGeneric doesn't handle power
        of 2 radix when JSBigInt length is >= 2. To handle such cases, we
        implemented JSBigInt::toStringBasePowerOfTwo that follows the
        algorithm that groups bits using mask of (2 ^ n) - 1 to extract every
        digit.

        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::toString):
        (JSC::JSBigInt::toStringBasePowerOfTwo):
        * runtime/JSBigInt.h:

2018-09-28  Caio Lima  <ticaiolima@gmail.com>

        [ESNext][BigInt] Implement support for "&"
        https://bugs.webkit.org/show_bug.cgi?id=186228

        Reviewed by Yusuke Suzuki.

        This patch introduces support of BigInt into bitwise "&" operation.
        We are also introducing the ValueBitAnd DFG node, that is responsible
        to take care of JIT for non-Int32 operands. With the introduction of this
        new node, we renamed the BitAnd node to ArithBitAnd. The ArithBitAnd
        follows the behavior of ArithAdd and other arithmetic nodes, where
        the Arith<op> version always results in Number (in the case of
        ArithBitAnd, its is always an Int32).

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitBinaryOp):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
        (JSC::DFG::SpeculativeJIT::compileBitwiseOp):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::bitOp):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToB3.cpp:
        (JSC::FTL::DFG::LowerDFGToB3::compileNode):
        (JSC::FTL::DFG::LowerDFGToB3::compileValueBitAnd):
        (JSC::FTL::DFG::LowerDFGToB3::compileArithBitAnd):
        (JSC::FTL::DFG::LowerDFGToB3::compileBitAnd): Deleted.
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitBitBinaryOpFastPath):
        (JSC::JIT::emit_op_bitand):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::JSBigInt):
        (JSC::JSBigInt::initialize):
        (JSC::JSBigInt::createZero):
        (JSC::JSBigInt::createFrom):
        (JSC::JSBigInt::bitwiseAnd):
        (JSC::JSBigInt::absoluteBitwiseOp):
        (JSC::JSBigInt::absoluteAnd):
        (JSC::JSBigInt::absoluteOr):
        (JSC::JSBigInt::absoluteAndNot):
        (JSC::JSBigInt::absoluteAddOne):
        (JSC::JSBigInt::absoluteSubOne):
        * runtime/JSBigInt.h:
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::toBigIntOrInt32 const):

2018-09-28  Mark Lam  <mark.lam@apple.com>

        Gardening: speculative build fix.
        <rdar://problem/44869924>

        Not reviewed.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):

2018-09-28  Guillaume Emont  <guijemont@igalia.com>

        [JSC] [Armv7] Add a copy function argument to MacroAssemblerARMv7::link() and pass it down to the assembler's linking functions.
        https://bugs.webkit.org/show_bug.cgi?id=190080

        Reviewed by Mark Lam.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::link):
        (JSC::ARMv7Assembler::linkJumpT1):
        (JSC::ARMv7Assembler::linkJumpT2):
        (JSC::ARMv7Assembler::linkJumpT3):
        (JSC::ARMv7Assembler::linkJumpT4):
        (JSC::ARMv7Assembler::linkConditionalJumpT4):
        (JSC::ARMv7Assembler::linkBX):
        (JSC::ARMv7Assembler::linkConditionalBX):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::link):

2018-09-27  Saam barati  <sbarati@apple.com>

        Verify the contents of AssemblerBuffer on arm64e
        https://bugs.webkit.org/show_bug.cgi?id=190057
        <rdar://problem/38916630>

        Reviewed by Mark Lam.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::ARM64Assembler):
        (JSC::ARM64Assembler::fillNops):
        (JSC::ARM64Assembler::link):
        (JSC::ARM64Assembler::linkJumpOrCall):
        (JSC::ARM64Assembler::linkCompareAndBranch):
        (JSC::ARM64Assembler::linkConditionalBranch):
        (JSC::ARM64Assembler::linkTestAndBranch):
        (JSC::ARM64Assembler::unlinkedCode): Deleted.
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::fillNops):
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::unlinkedCode): Deleted.
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::emitNops):
        (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
        * assembler/AssemblerBuffer.h:
        (JSC::ARM64EHash::ARM64EHash):
        (JSC::ARM64EHash::update):
        (JSC::ARM64EHash::hash const):
        (JSC::ARM64EHash::randomSeed const):
        (JSC::AssemblerBuffer::AssemblerBuffer):
        (JSC::AssemblerBuffer::putShort):
        (JSC::AssemblerBuffer::putIntUnchecked):
        (JSC::AssemblerBuffer::putInt):
        (JSC::AssemblerBuffer::hash const):
        (JSC::AssemblerBuffer::data const):
        (JSC::AssemblerBuffer::putIntegralUnchecked):
        (JSC::AssemblerBuffer::append): Deleted.
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::fillNops):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::jumpsToLink):
        (JSC::MacroAssemblerARM64::link):
        (JSC::MacroAssemblerARM64::unlinkedCode): Deleted.
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::jumpsToLink):
        (JSC::MacroAssemblerARMv7::unlinkedCode): Deleted.
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::fillNops):

2018-09-27  Mark Lam  <mark.lam@apple.com>

        ByValInfo should not use integer offsets.
        https://bugs.webkit.org/show_bug.cgi?id=190070
        <rdar://problem/44803430>

        Reviewed by Saam Barati.

        Also moved some fields around to allow the ByValInfo struct to be more densely packed.

        * bytecode/ByValInfo.h:
        (JSC::ByValInfo::ByValInfo):
        * jit/JIT.cpp:
        (JSC::JIT::link):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileHasIndexedProperty):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileHasIndexedProperty):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompileGetByValWithCachedId):
        (JSC::JIT::privateCompilePutByVal):
        (JSC::JIT::privateCompilePutByValWithCachedId):

2018-09-27  Saam barati  <sbarati@apple.com>

        DFG::OSRExit::m_patchableCodeOffset should not be an int
        https://bugs.webkit.org/show_bug.cgi?id=190066
        <rdar://problem/39498244>

        Reviewed by Mark Lam.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::codeLocationForRepatch const):
        (JSC::DFG::OSRExit::compileOSRExit):
        (JSC::DFG::OSRExit::setPatchableCodeOffset): Deleted.
        (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): Deleted.
        (JSC::DFG::OSRExit::correctJump): Deleted.
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompilationInfo.h:

2018-09-27  Saam barati  <sbarati@apple.com>

        Don't use int offsets in StructureStubInfo
        https://bugs.webkit.org/show_bug.cgi?id=190064
        <rdar://problem/44784719>

        Reviewed by Mark Lam.

        * bytecode/InlineAccess.cpp:
        (JSC::linkCodeInline):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::slowPathCallLocation):
        (JSC::StructureStubInfo::doneLocation):
        (JSC::StructureStubInfo::slowPathStartLocation):
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITInlineCacheGenerator::finalize):

2018-09-27  Mark Lam  <mark.lam@apple.com>

        DFG::OSREntry::m_machineCodeOffset should be a CodeLocation.
        https://bugs.webkit.org/show_bug.cgi?id=190054
        <rdar://problem/44803543>

        Reviewed by Saam Barati.

        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::appendOSREntryData):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::noticeOSREntry):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::OSREntryData::dumpInContext const):
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSREntry.h:
        * runtime/JSCPtrTag.h:

2018-09-27  Mark Lam  <mark.lam@apple.com>

        JITMathIC should not use integer offsets into machine code.
        https://bugs.webkit.org/show_bug.cgi?id=190030
        <rdar://problem/44803307>

        Reviewed by Saam Barati.

        We'll replace them with CodeLocation smart pointers instead.

        * jit/JITMathIC.h:
        (JSC::isProfileEmpty):

2018-09-26  Mark Lam  <mark.lam@apple.com>

        Options::useSeparatedWXHeap() should always be false when ENABLE(FAST_JIT_PERMISSIONS) && CPU(ARM64E).
        https://bugs.webkit.org/show_bug.cgi?id=190022
        <rdar://problem/44800928>

        Reviewed by Saam Barati.

        * jit/ExecutableAllocator.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2018-09-26  Mark Lam  <mark.lam@apple.com>

        Assert that performJITMemcpy() is always called with instruction size aligned addresses on ARM64.
        https://bugs.webkit.org/show_bug.cgi?id=190016
        <rdar://problem/44802875>

        Reviewed by Saam Barati.

        Also assert in performJITMemcpy() that the entire buffer to be copied will fit in
        JIT memory.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::fillNops):
        (JSC::ARM64Assembler::replaceWithVMHalt):
        (JSC::ARM64Assembler::replaceWithJump):
        (JSC::ARM64Assembler::replaceWithLoad):
        (JSC::ARM64Assembler::replaceWithAddressComputation):
        (JSC::ARM64Assembler::setPointer):
        (JSC::ARM64Assembler::repatchInt32):
        (JSC::ARM64Assembler::repatchCompact):
        (JSC::ARM64Assembler::linkJumpOrCall):
        (JSC::ARM64Assembler::linkCompareAndBranch):
        (JSC::ARM64Assembler::linkConditionalBranch):
        (JSC::ARM64Assembler::linkTestAndBranch):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::copyCompactAndLinkCode):
        (JSC::LinkBuffer::linkCode):
        * jit/ExecutableAllocator.h:
        (JSC::performJITMemcpy):

2018-09-25  Keith Miller  <keith_miller@apple.com>

        Move Symbol API to SPI
        https://bugs.webkit.org/show_bug.cgi?id=189946

        Reviewed by Michael Saboff.

        Some of the property access methods on JSValue needed to be moved
        to a category so that SPI overloads don't result in a compiler
        error for internal users.

        Additionally, this patch does not move the new enum entry for
        Symbols in the JSType enumeration.

        * API/JSObjectRef.h:
        * API/JSObjectRefPrivate.h:
        * API/JSValue.h:
        * API/JSValuePrivate.h:
        * API/JSValueRef.h:

2018-09-26  Keith Miller  <keith_miller@apple.com>

        We should zero unused property storage when rebalancing array storage.
        https://bugs.webkit.org/show_bug.cgi?id=188151

        Reviewed by Michael Saboff.

        In unshiftCountSlowCase we sometimes will move property storage to the right even when net adding elements.
        This can happen because we "balance" the pre/post-capacity in that code so we need to zero the unused
        property storage.

        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):

2018-09-26  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        Unreviewed, add scope verification handling
        https://bugs.webkit.org/show_bug.cgi?id=189780

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncIndexOf):
        (JSC::arrayProtoFuncLastIndexOf):

2018-09-26  Koby Boyango  <koby.b@mce.systems>

        [JSC] offlineasm parser should handle CRLF in asm files
        https://bugs.webkit.org/show_bug.cgi?id=189949

        Reviewed by Mark Lam.

        * offlineasm/parser.rb:

2018-09-20  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Optimize Array#lastIndexOf
        https://bugs.webkit.org/show_bug.cgi?id=189780

        Reviewed by Saam Barati.

        Optimize Array#lastIndexOf as the same to Array#indexOf. We add a fast path
        for JSArray with contiguous storage.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncLastIndexOf):

2018-09-25  Saam Barati  <sbarati@apple.com>

        Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObjectInOSR should actually pass in the baseline CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=189940
        <rdar://problem/43640987>

        Reviewed by Mark Lam.

        We were calling baselineCodeBlockForOriginAndBaselineCodeBlock with the FTL
        CodeBlock. There is nothing semantically wrong with doing that (except for
        poor naming), however, the poor naming here led us to make a real semantic
        mistake. We wanted the baseline CodeBlock's constant pool, but we were
        accessing the FTL CodeBlock's constant pool accidentally. We need to
        access the baseline CodeBlock's constant pool when we update the NewArrayBuffer
        constant value.

        * bytecode/InlineCallFrame.h:
        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):

2018-09-25  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Stricter block syntax in generated ObjC protocol interfaces
        https://bugs.webkit.org/show_bug.cgi?id=189962
        <rdar://problem/44648287>

        Reviewed by Brian Burg.

        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator._callback_block_for_command):
        If there are no return parameters include "void" in the block signature.

        * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
        * inspector/scripts/tests/generic/expected/domain-availability.json-result:
        * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
        * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
        Rebaseline test results.

2018-09-24  Joseph Pecoraro  <pecoraro@apple.com>

        Remove AUTHORS and THANKS files which are stale
        https://bugs.webkit.org/show_bug.cgi?id=189941

        Reviewed by Darin Adler.

        Included mentions below so their names are still in ChangeLogs.

        * AUTHORS: Removed.
        Harri Porten (porten@kde.org) and Peter Kelly (pmk@post.com).
        These authors remain mentioned in copyrights in source files.

        * THANKS: Removed.
        Richard Moore <rich@kde.org> - for filling the Math object with some life
        Daegeun Lee <realking@mizi.com> - for pointing out some bugs and providing much code for the String and Date object.
        Marco Pinelli <pinmc@libero.it> - for his patches
        Christian Kirsch <ck@held.mind.de> - for his contribution to the Date object
        
2018-09-24  Fujii Hironori  <Hironori.Fujii@sony.com>

        Rename WTF_COMPILER_GCC_OR_CLANG to WTF_COMPILER_GCC_COMPATIBLE
        https://bugs.webkit.org/show_bug.cgi?id=189733

        Reviewed by Michael Catanzaro.

        * assembler/ARM64Assembler.h:
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::cacheFlush):
        * assembler/MacroAssemblerARM.cpp:
        (JSC::isVFPPresent):
        * assembler/MacroAssemblerARM64.cpp:
        * assembler/MacroAssemblerARMv7.cpp:
        * assembler/MacroAssemblerMIPS.cpp:
        * assembler/MacroAssemblerX86Common.cpp:
        * heap/HeapCell.cpp:
        * heap/HeapCell.h:
        * jit/HostCallReturnValue.h:
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        * jit/ThunkGenerators.cpp:
        * runtime/ArrayConventions.cpp:
        (JSC::clearArrayMemset):
        * runtime/JSBigInt.cpp:
        (JSC::JSBigInt::digitDiv):

2018-09-24  Saam Barati  <sbarati@apple.com>

        Array.prototype.indexOf fast path needs to ensure the length is still valid after performing effects
        https://bugs.webkit.org/show_bug.cgi?id=189922
        <rdar://problem/44651275>

        Reviewed by Mark Lam.

        The implementation was first getting the length to iterate up to,
        then getting the starting index. However, getting the starting
        index may perform effects. e.g, it could change the length of the
        array. This changes it so we verify the length is still valid.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncIndexOf):

2018-09-24  Tadeu Zagallo  <tzagallo@apple.com>

        offlineasm: fix macro scoping
        https://bugs.webkit.org/show_bug.cgi?id=189902

        Reviewed by Mark Lam.

        In the code below, the reference to `f` in `g`, which should refer to
        the outer macro definition will instead refer to the f argument of the
        anonymous macro passed to `g`. That leads to this code failing to
        compile (f expected 0 args but got 1).
        
        ```
        macro f(x)
            move x, t0
        end
        
        macro g(fn)
            fn(macro () f(42) end)
        end
        
        g(macro(f) f() end)
        ```

        * offlineasm/ast.rb:
        * offlineasm/transform.rb:

2018-09-24  Tadeu Zagallo  <tzagallo@apple.com>

        Add forEach method for iterating CodeBlock's ValueProfiles
        https://bugs.webkit.org/show_bug.cgi?id=189897

        Reviewed by Mark Lam.

        Add method to abstract how we find ValueProfiles in a CodeBlock in
        preparation for https://bugs.webkit.org/show_bug.cgi?id=189785, when
        ValueProfiles will be stored in the MetadataTable.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::updateAllValueProfilePredictions):
        (JSC::CodeBlock::shouldOptimizeNow):
        (JSC::CodeBlock::dumpValueProfiles):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::forEachValueProfile):
        (JSC::CodeBlock::numberOfArgumentValueProfiles):
        (JSC::CodeBlock::valueProfileForArgument):
        (JSC::CodeBlock::numberOfValueProfiles):
        (JSC::CodeBlock::valueProfile):
        (JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
        (JSC::CodeBlock::getFromAllValueProfiles): Deleted.
        * tools/HeapVerifier.cpp:
        (JSC::HeapVerifier::validateJSCell):

2018-09-24  Saam barati  <sbarati@apple.com>

        ArgumentsEliminationPhase should snip basic blocks after proven OSR exits
        https://bugs.webkit.org/show_bug.cgi?id=189682
        <rdar://problem/43557315>

        Reviewed by Mark Lam.

        Otherwise, if we have code like this:
        ```
        a: Arguments
        b: GetButterfly(@a)
        c: ForceExit
        d: GetArrayLength(@a, @b)
        ```
        it will get transformed into this invalid DFG IR:
        ```
        a: PhantomArguments
        b: Check(@a)
        c: ForceExit
        d: GetArrayLength(@a, @b)
        ```
        
        And we will fail DFG validation since @b does not have a result.
        
        The fix is to just remove all nodes after the ForceExit and plant an
        Unreachable after it. So the above code program will now turn into this:
        ```
        a: PhantomArguments
        b: Check(@a)
        c: ForceExit
        e: Unreachable
        ```

        * dfg/DFGArgumentsEliminationPhase.cpp:

2018-09-22  Saam barati  <sbarati@apple.com>

        The sampling should not use Strong<CodeBlock> in its machineLocation field
        https://bugs.webkit.org/show_bug.cgi?id=189319

        Reviewed by Filip Pizlo.

        The sampling profiler has a CLI mode where we gather information about inline
        call frames. That data structure was using a Strong<CodeBlock>. We were
        constructing this Strong<CodeBlock> during GC concurrently to processing all
        the Strong handles. This is a bug since we end up corrupting that data
        structure. This patch fixes this by just making this data structure use the
        sampling profiler's mechanism for holding onto and properly visiting heap pointers.

        * inspector/agents/InspectorScriptProfilerAgent.cpp:
        (Inspector::InspectorScriptProfilerAgent::trackingComplete):
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces):

        (JSC::SamplingProfiler::reportTopFunctions):
        (JSC::SamplingProfiler::reportTopBytecodes):
        These CLI helpers needed a DeferGC otherwise we may end up deadlocking when we
        cause a GC to happen while already holding the sampling profiler's
        lock.

2018-09-21  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Enable LLInt ASM interpreter on X64 and ARM64 in non JIT configuration
        https://bugs.webkit.org/show_bug.cgi?id=189778

        Reviewed by Keith Miller.

        LLInt ASM interpreter is 2x and 15% faster than CLoop interpreter on
        Linux and macOS respectively. We would like to enable it for non JIT
        configurations in X86_64 and ARM64.

        This patch enables LLInt for non JIT builds in X86_64 and ARM64 architectures.
        Previously, we switch LLInt ASM interpreter and CLoop by using ENABLE(JIT)
        configuration. But it is wrong in the new scenario since we have a build
        configuration that uses LLInt ASM interpreter and JIT is disabled. We introduce
        ENABLE(C_LOOP) option, which represents that we use CLoop. And we replace
        ENABLE(JIT) with ENABLE(C_LOOP) if the previous ENABLE(JIT) is essentially just
        related to LLInt ASM interpreter and not related to JIT.

        We also replace some ENABLE(JIT) configurations with ENABLE(ASSEMBLER).
        ENABLE(ASSEMBLER) is now enabled even if we disable JIT since MacroAssembler
        has machine register information that is used in LLInt ASM interpreter.

        * API/tests/PingPongStackOverflowTest.cpp:
        (testPingPongStackOverflow):
        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MaxFrameExtentForSlowPathCall.h:
        * bytecode/CallReturnOffsetToBytecodeOffset.h: Removed. It is no longer used.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::calleeSaveRegisters const):
        (JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters):
        (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * heap/Heap.cpp:
        (JSC::Heap::gatherJSStackRoots):
        (JSC::Heap::stopThePeriphery):
        * interpreter/CLoopStack.cpp:
        * interpreter/CLoopStack.h:
        * interpreter/CLoopStackInlines.h:
        * interpreter/EntryFrame.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::Interpreter):
        (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::calleeSaveRegisters):
        * interpreter/VMEntryRecord.h:
        * jit/ExecutableAllocator.h:
        * jit/FPRInfo.h:
        (WTF::printInternal):
        * jit/GPRInfo.cpp:
        * jit/GPRInfo.h:
        (WTF::printInternal):
        * jit/HostCallReturnValue.cpp:
        (JSC::getHostCallReturnValueWithExecState): Moved. They are used in LLInt ASM interpreter too.
        * jit/HostCallReturnValue.h:
        * jit/JITOperations.cpp:
        (JSC::getHostCallReturnValueWithExecState): Deleted.
        * jit/JITOperationsMSVC64.cpp:
        * jit/Reg.cpp:
        * jit/Reg.h:
        * jit/RegisterAtOffset.cpp:
        * jit/RegisterAtOffset.h:
        * jit/RegisterAtOffsetList.cpp:
        * jit/RegisterAtOffsetList.h:
        * jit/RegisterMap.h:
        * jit/RegisterSet.cpp:
        * jit/RegisterSet.h:
        * jit/TempRegisterSet.cpp:
        * jit/TempRegisterSet.h:
        * llint/LLIntCLoop.cpp:
        * llint/LLIntCLoop.h:
        * llint/LLIntData.cpp:
        (JSC::LLInt::initialize):
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntData.h:
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LLIntOpcode.h:
        * llint/LLIntPCRanges.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LLIntThunks.cpp:
        * llint/LowLevelInterpreter.cpp:
        * llint/LowLevelInterpreter.h:
        * runtime/JSCJSValue.h:
        * runtime/MachineContext.h:
        * runtime/SamplingProfiler.cpp:
        (JSC::SamplingProfiler::processUnverifiedStackTraces): Enable SamplingProfiler
        for LLInt ASM interpreter with non JIT configuration.
        * runtime/TestRunnerUtils.cpp:
        (JSC::optimizeNextInvocation):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::getHostFunction):
        (JSC::VM::updateSoftReservedZoneSize):
        (JSC::sanitizeStackForVM):
        (JSC::VM::committedStackByteCount):
        * runtime/VM.h:
        * runtime/VMInlines.h:
        (JSC::VM::ensureStackCapacityFor):
        (JSC::VM::isSafeToRecurseSoft const):

2018-09-21  Keith Miller  <keith_miller@apple.com>

        Add Promise SPI
        https://bugs.webkit.org/show_bug.cgi?id=189809

        Reviewed by Saam Barati.

        The Patch adds new SPI to create promises. It's mostly SPI because
        I want to see how internal users react to it before we make it
        public.

        This patch adds a couple of new Obj-C SPI methods. The first
        creates a new promise using the same API that JS does where the
        user provides an executor callback. If an exception is raised
        in/to that callback the promise is automagically rejected. The
        other methods create a pre-resolved or rejected promise as this
        appears to be a common way to initialize a promise.

        I was also considering adding a second version of executor API
        where it would catch specific Obj-C exceptions. This would work by
        taking a Class paramter and checking isKindOfClass: on the
        exception. I decided against this as nothing else in our API
        handles Obj-C exceptions. I'm pretty sure the VM will end up in a
        corrupt state if an Obj-C exception unwinds through JS frames.

        This patch adds a new C function that will create a "deferred"
        promise. A deferred promise is a style of creating promise/futures
        where the resolve and reject functions are passed as outputs of a
        function. I went with this style for the C SPI because we don't have
        any concept of forwarding exceptions in the C API.

        In order to make the C API work I refactored a bit of the promise code
        so that we can call a static method on JSDeferredPromise and just get
        the components without allocating an extra cell wrapper.

        * API/JSContext.mm:
        (+[JSContext currentCallee]):
        * API/JSObjectRef.cpp:
        (JSObjectMakeDeferredPromise):
        * API/JSObjectRefPrivate.h:
        * API/JSValue.mm:
        (+[JSValue valueWithNewPromiseInContext:fromExecutor:]):
        (+[JSValue valueWithNewPromiseResolvedWithResult:inContext:]):
        (+[JSValue valueWithNewPromiseRejectedWithReason:inContext:]):
        * API/JSValuePrivate.h: Added.
        * API/JSVirtualMachine.mm:
        * API/JSVirtualMachinePrivate.h:
        * API/tests/testapi.c:
        (main):
        * API/tests/testapi.cpp:
        (APIContext::operator JSC::ExecState*):
        (TestAPI::failed const):
        (TestAPI::check):
        (TestAPI::basicSymbol):
        (TestAPI::symbolsTypeof):
        (TestAPI::symbolsGetPropertyForKey):
        (TestAPI::symbolsSetPropertyForKey):
        (TestAPI::symbolsHasPropertyForKey):
        (TestAPI::symbolsDeletePropertyForKey):
        (TestAPI::promiseResolveTrue):
        (TestAPI::promiseRejectTrue):
        (testCAPIViaCpp):
        (TestAPI::run): Deleted.
        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):
        (promiseWithExecutor):
        (promiseRejectOnJSException):
        (promiseCreateResolved):
        (promiseCreateRejected):
        (parallelPromiseResolveTest):
        (testObjectiveCAPI):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSPromise.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::createDeferredData):
        (JSC::JSPromiseDeferred::create):
        (JSC::JSPromiseDeferred::finishCreation):
        (JSC::newPromiseCapability): Deleted.
        * runtime/JSPromiseDeferred.h:
        (JSC::JSPromiseDeferred::promise const):
        (JSC::JSPromiseDeferred::resolve const):
        (JSC::JSPromiseDeferred::reject const):

2018-09-21  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r236359.

        Broke the Windows build.

        Reverted changeset:

        "Add Promise SPI"
        https://bugs.webkit.org/show_bug.cgi?id=189809
        https://trac.webkit.org/changeset/236359

2018-09-21  Mark Lam  <mark.lam@apple.com>

        JSRopeString::resolveRope() wrongly assumes that tryGetValue() passes it a valid ExecState.
        https://bugs.webkit.org/show_bug.cgi?id=189855
        <rdar://problem/44680181>

        Reviewed by Filip Pizlo.

        tryGetValue() always passes a nullptr to JSRopeString::resolveRope() for the
        ExecState* argument.  This is intentional so that resolveRope() does not throw
        in the event of an OutOfMemory error.  Hence, JSRopeString::resolveRope() should
        get the VM from the cell instead of via the ExecState.

        Also removed an obsolete and unused field in JSString.

        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRope const):
        (JSC::JSRopeString::outOfMemory const):
        * runtime/JSString.h:
        (JSC::JSString::tryGetValue const):

2018-09-21  Michael Saboff  <msaboff@apple.com>

        Add functions to measure memory footprint to JSC
        https://bugs.webkit.org/show_bug.cgi?id=189768

        Reviewed by Saam Barati.

        Rolling this back in again.

        Provide system memory metrics for the current process to aid in memory reduction measurement and
        tuning using native JS tests.

        * jsc.cpp:
        (MemoryFootprint::now):
        (MemoryFootprint::resetPeak):
        (GlobalObject::finishCreation):
        (JSCMemoryFootprint::JSCMemoryFootprint):
        (JSCMemoryFootprint::createStructure):
        (JSCMemoryFootprint::create):
        (JSCMemoryFootprint::finishCreation):
        (JSCMemoryFootprint::addProperty):
        (functionResetMemoryPeak):

2018-09-21  Keith Miller  <keith_miller@apple.com>

        Add Promise SPI
        https://bugs.webkit.org/show_bug.cgi?id=189809

        Reviewed by Saam Barati.

        The Patch adds new SPI to create promises. It's mostly SPI because
        I want to see how internal users react to it before we make it
        public.

        This patch adds a couple of new Obj-C SPI methods. The first
        creates a new promise using the same API that JS does where the
        user provides an executor callback. If an exception is raised
        in/to that callback the promise is automagically rejected. The
        other methods create a pre-resolved or rejected promise as this
        appears to be a common way to initialize a promise.

        I was also considering adding a second version of executor API
        where it would catch specific Obj-C exceptions. This would work by
        taking a Class paramter and checking isKindOfClass: on the
        exception. I decided against this as nothing else in our API
        handles Obj-C exceptions. I'm pretty sure the VM will end up in a
        corrupt state if an Obj-C exception unwinds through JS frames.

        This patch adds a new C function that will create a "deferred"
        promise. A deferred promise is a style of creating promise/futures
        where the resolve and reject functions are passed as outputs of a
        function. I went with this style for the C SPI because we don't have
        any concept of forwarding exceptions in the C API.

        In order to make the C API work I refactored a bit of the promise code
        so that we can call a static method on JSDeferredPromise and just get
        the components without allocating an extra cell wrapper.

        * API/JSContext.mm:
        (+[JSContext currentCallee]):
        * API/JSObjectRef.cpp:
        (JSObjectMakeDeferredPromise):
        * API/JSObjectRefPrivate.h:
        * API/JSValue.mm:
        (+[JSValue valueWithNewPromiseInContext:fromExecutor:]):
        (+[JSValue valueWithNewPromiseResolvedWithResult:inContext:]):
        (+[JSValue valueWithNewPromiseRejectedWithReason:inContext:]):
        * API/JSValuePrivate.h: Added.
        * API/JSVirtualMachine.mm:
        * API/JSVirtualMachinePrivate.h:
        * API/tests/testapi.c:
        (main):
        * API/tests/testapi.cpp:
        (APIContext::operator JSC::ExecState*):
        (TestAPI::failed const):
        (TestAPI::check):
        (TestAPI::basicSymbol):
        (TestAPI::symbolsTypeof):
        (TestAPI::symbolsGetPropertyForKey):
        (TestAPI::symbolsSetPropertyForKey):
        (TestAPI::symbolsHasPropertyForKey):
        (TestAPI::symbolsDeletePropertyForKey):
        (TestAPI::promiseResolveTrue):
        (TestAPI::promiseRejectTrue):
        (testCAPIViaCpp):
        (TestAPI::run): Deleted.
        * API/tests/testapi.mm:
        (testObjectiveCAPIMain):
        (promiseWithExecutor):
        (promiseRejectOnJSException):
        (promiseCreateResolved):
        (promiseCreateRejected):
        (parallelPromiseResolveTest):
        (testObjectiveCAPI):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSInternalPromiseDeferred.cpp:
        (JSC::JSInternalPromiseDeferred::create):
        * runtime/JSPromise.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        * runtime/JSPromiseDeferred.cpp:
        (JSC::JSPromiseDeferred::createDeferredData):
        (JSC::JSPromiseDeferred::create):
        (JSC::JSPromiseDeferred::finishCreation):
        (JSC::newPromiseCapability): Deleted.
        * runtime/JSPromiseDeferred.h:
        (JSC::JSPromiseDeferred::promise const):
        (JSC::JSPromiseDeferred::resolve const):
        (JSC::JSPromiseDeferred::reject const):

2018-09-21  Truitt Savell  <tsavell@apple.com>

        Rebaseline tests after changes in https://trac.webkit.org/changeset/236321/webkit
        https://bugs.webkit.org/show_bug.cgi?id=156674

        Unreviewed Test Gardening

        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:

2018-09-21  Mike Gorse  <mgorse@suse.com>

        Build tools should work when the /usr/bin/python is python3
        https://bugs.webkit.org/show_bug.cgi?id=156674

        Reviewed by Michael Catanzaro.

        * Scripts/cssmin.py:
        * Scripts/generate-js-builtins.py:
        (do_open):
        (generate_bindings_for_builtins_files):
        * Scripts/generateIntlCanonicalizeLanguage.py:
        * Scripts/jsmin.py:
        (JavascriptMinify.minify.write):
        (JavascriptMinify):
        (JavascriptMinify.minify):
        * Scripts/make-js-file-arrays.py:
        (chunk):
        (main):
        * Scripts/wkbuiltins/__init__.py:
        * Scripts/wkbuiltins/builtins_generate_combined_header.py:
        (generate_section_for_global_private_code_name_macro):
        * Scripts/wkbuiltins/builtins_generate_internals_wrapper_header.py:
        (BuiltinsInternalsWrapperHeaderGenerator.__init__):
        * Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py:
        (BuiltinsInternalsWrapperImplementationGenerator.__init__):
        * Scripts/wkbuiltins/builtins_model.py:
        (BuiltinFunction.__lt__):
        (BuiltinsCollection.copyrights):
        (BuiltinsCollection._parse_functions):
        * disassembler/udis86/ud_opcode.py:
        (UdOpcodeTables.pprint.printWalk):
        * generate-bytecode-files:
        * inspector/scripts/codegen/__init__.py:
        * inspector/scripts/codegen/cpp_generator.py:
        * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
        (CppAlternateBackendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator.domains_to_generate):
        (CppBackendDispatcherHeaderGenerator.generate_output):
        (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator.domains_to_generate):
        (CppBackendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.domains_to_generate):
        (CppFrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator.domains_to_generate):
        (CppFrontendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator.generate_output):
        (CppProtocolTypesHeaderGenerator._generate_forward_declarations):
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
        (CppProtocolTypesImplementationGenerator.generate_output):
        (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
        (CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods):
        (CppProtocolTypesImplementationGenerator._generate_open_field_names):
        (CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
        (CppProtocolTypesImplementationGenerator._generate_assertion_for_object_declaration):
        * inspector/scripts/codegen/generate_js_backend_commands.py:
        (JSBackendCommandsGenerator.should_generate_domain):
        (JSBackendCommandsGenerator.domains_to_generate):
        (JSBackendCommandsGenerator.generate_output):
        (JSBackendCommandsGenerator.generate_domain):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
        (ObjCBackendDispatcherHeaderGenerator.domains_to_generate):
        (ObjCBackendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator.domains_to_generate):
        (ObjCBackendDispatcherImplementationGenerator.generate_output):
        (ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command):
        * inspector/scripts/codegen/generate_objc_configuration_header.py:
        * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.domains_to_generate):
        (ObjCFrontendDispatcherImplementationGenerator.generate_output):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event):
        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator.generate_output):
        (ObjCHeaderGenerator._generate_type_interface):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
        (ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate):
        (ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
        (ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.domains_to_generate):
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        (ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
        * inspector/scripts/codegen/generator.py:
        (Generator.non_supplemental_domains):
        (Generator.open_fields):
        (Generator.calculate_types_requiring_shape_assertions):
        (Generator._traverse_and_assign_enum_values):
        (Generator.stylized_name_for_enum_value):
        * inspector/scripts/codegen/models.py:
        (find_duplicates):
        * inspector/scripts/codegen/objc_generator.py:
        * wasm/generateWasm.py:
        (opcodeIterator):
        * yarr/generateYarrCanonicalizeUnicode:
        * yarr/generateYarrUnicodePropertyTables.py:
        * yarr/hasher.py:
        (stringHash):

2018-09-21  Tomas Popela  <tpopela@redhat.com>

        [ARM] Build broken on armv7hl after r235517
        https://bugs.webkit.org/show_bug.cgi?id=189831

        Reviewed by Yusuke Suzuki.

        Add missing implementation of patchebleBranch8() for traditional ARM.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::patchableBranch8):

2018-09-20  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r236293.

        Internal build still broken.

        Reverted changeset:

        "Add functions to measure memory footprint to JSC"
        https://bugs.webkit.org/show_bug.cgi?id=189768
        https://trac.webkit.org/changeset/236293

2018-09-20  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Heap::reportExtraMemoryVisited shows contention if we have many JSString
        https://bugs.webkit.org/show_bug.cgi?id=189558

        Reviewed by Mark Lam.

        When running web-tooling-benchmark postcss test on Linux JSCOnly port, we get the following result in `perf report`.

            10.95%  AutomaticThread  libJavaScriptCore.so.1.0.0  [.] JSC::Heap::reportExtraMemoryVisited

        This is because postcss produces bunch of JSString, which require reportExtraMemoryVisited calls in JSString::visitChildren.
        And since reportExtraMemoryVisited attempts to update atomic counter, if we have bunch of marking threads, it becomes super contended.

        This patch reduces the frequency of updating the atomic counter. Each SlotVisitor has per-SlotVisitor m_extraMemorySize counter.
        And we propagate this value to the global atomic counter when rebalance happens.

        We also reduce HeapCell::heap() access by using `vm.heap`.

        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::propagateExternalMemoryVisitedIfNecessary):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::performIncrementOfDraining):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        * runtime/JSString.cpp:
        (JSC::JSRopeString::resolveRopeToAtomicString const):
        (JSC::JSRopeString::resolveRope const):
        * runtime/JSString.h:
        (JSC::JSString::finishCreation):
        * wasm/js/JSWebAssemblyInstance.cpp:
        (JSC::JSWebAssemblyInstance::finishCreation):
        * wasm/js/JSWebAssemblyMemory.cpp:
        (JSC::JSWebAssemblyMemory::finishCreation):

2018-09-20  Michael Saboff  <msaboff@apple.com>

        Add functions to measure memory footprint to JSC
        https://bugs.webkit.org/show_bug.cgi?id=189768

        Reviewed by Saam Barati.

        Rolling this back in.

        Provide system memory metrics for the current process to aid in memory reduction measurement and
        tuning using native JS tests.

        * jsc.cpp:
        (MemoryFootprint::now):
        (MemoryFootprint::resetPeak):
        (GlobalObject::finishCreation):
        (JSCMemoryFootprint::JSCMemoryFootprint):
        (JSCMemoryFootprint::createStructure):
        (JSCMemoryFootprint::create):
        (JSCMemoryFootprint::finishCreation):
        (JSCMemoryFootprint::addProperty):
        (functionResetMemoryPeak):

2018-09-20  Ryan Haddad  <ryanhaddad@apple.com>

        Unreviewed, rolling out r236235.

        Breaks internal builds.

        Reverted changeset:

        "Add functions to measure memory footprint to JSC"
        https://bugs.webkit.org/show_bug.cgi?id=189768
        https://trac.webkit.org/changeset/236235

2018-09-20  Fujii Hironori  <Hironori.Fujii@sony.com>

        [Win][Clang] JITMathIC.h: error: missing 'template' keyword prior to dependent template name 'retagged'
        https://bugs.webkit.org/show_bug.cgi?id=189730

        Reviewed by Saam Barati.

        Clang for Windows can't compile the workaround for MSVC quirk in generateOutOfLine.

        * jit/JITMathIC.h:
        (generateOutOfLine): Append "&& !COMPILER(CLANG)" to "#if COMPILER(MSVC)".

2018-09-19  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [JSC] Optimize Array#indexOf in C++ runtime
        https://bugs.webkit.org/show_bug.cgi?id=189507

        Reviewed by Saam Barati.

        C++ Array#indexOf runtime function takes so much time in babylon benchmark in
        web-tooling-benchmark. While our DFG and FTL has Array#indexOf optimization
        and actually it is working well, C++ Array#indexOf is called significant amount
        of time before tiering up, and it takes 6.74% of jsc main thread samples according
        to perf command in Linux. This is because C++ Array#indexOf is too generic and
        misses the chance to optimize JSArray cases.

        This patch adds JSArray fast path for Array#indexOf. If we know that indexed
        access to the given JSArray is non-observable and indexing type is good for the fast
        path, we go to the fast path. This makes sampling of Array#indexOf 3.83% in
        babylon web-tooling-benchmark.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncIndexOf):
        * runtime/JSArray.h:
        * runtime/JSArrayInlines.h:
        (JSC::JSArray::canDoFastIndexedAccess):
        (JSC::toLength):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::JSValue):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectInlines.h:
        (JSC::JSGlobalObject::isArrayPrototypeIndexedAccessFastAndNonObservable):
        (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
        * runtime/MathCommon.h:
        (JSC::canBeStrictInt32):
        (JSC::canBeInt32):

2018-09-19  Michael Saboff  <msaboff@apple.com>

        Add functions to measure memory footprint to JSC
        https://bugs.webkit.org/show_bug.cgi?id=189768

        Reviewed by Saam Barati.

        Provide system memory metrics for the current process to aid in memory reduction measurement and
        tuning using native JS tests.

        * jsc.cpp:
        (MemoryFootprint::now):
        (MemoryFootprint::resetPeak):
        (GlobalObject::finishCreation):
        (JSCMemoryFootprint::JSCMemoryFootprint):
        (JSCMemoryFootprint::createStructure):
        (JSCMemoryFootprint::create):
        (JSCMemoryFootprint::finishCreation):
        (JSCMemoryFootprint::addProperty):
        (functionResetMemoryPeak):

2018-09-19  Saam barati  <sbarati@apple.com>

        CheckStructureOrEmpty should pass in a tempGPR to emitStructureCheck since it may jump over that code
        https://bugs.webkit.org/show_bug.cgi?id=189703

        Reviewed by Mark Lam.

        This fixes a crash that a TypeProfiler change revealed.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2018-09-19  Saam barati  <sbarati@apple.com>

        AI rule for MultiPutByOffset executes its effects in the wrong order
        https://bugs.webkit.org/show_bug.cgi?id=189757
        <rdar://problem/43535257>

        Reviewed by Michael Saboff.

        The AI rule for MultiPutByOffset was executing effects in the wrong order.
        It first executed the transition effects and the effects on the base, and
        then executed the filtering effects on the value being stored. However, you
        can end up with the wrong type when the base and the value being stored
        are the same. E.g, in a program like `o.f = o`. These effects need to happen
        in the opposite order, modeling what happens in the runtime executing of
        MultiPutByOffset.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

2018-09-18  Mark Lam  <mark.lam@apple.com>

        Ensure that ForInContexts are invalidated if their loop local is over-written.
        https://bugs.webkit.org/show_bug.cgi?id=189571
        <rdar://problem/44402277>

        Reviewed by Saam Barati.

        Instead of hunting down every place in the BytecodeGenerator that potentially
        needs to invalidate an enclosing ForInContext (if one exists), we simply iterate
        the bytecode range of the loop body when the ForInContext is popped, and
        invalidate the context if we ever find the loop temp variable over-written.

        This has 2 benefits:
        1. It ensures that every type of opcode that can write to the loop temp will be
           handled appropriately, not just the op_mov that we've hunted down.
        2. It avoids us having to check the BytecodeGenerator's m_forInContextStack
           every time we emit an op_mov (or other opcodes that can write to a local)
           even when we're not inside a for-in loop.

        JSC benchmarks show that that this change is performance neutral.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::pushIndexedForInScope):
        (JSC::BytecodeGenerator::popIndexedForInScope):
        (JSC::BytecodeGenerator::pushStructureForInScope):
        (JSC::BytecodeGenerator::popStructureForInScope):
        (JSC::ForInContext::finalize):
        (JSC::StructureForInContext::finalize):
        (JSC::IndexedForInContext::finalize):
        (JSC::BytecodeGenerator::invalidateForInContextForLocal): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::ForInContext::ForInContext):
        (JSC::ForInContext::bodyBytecodeStartOffset const):
        (JSC::StructureForInContext::StructureForInContext):
        (JSC::IndexedForInContext::IndexedForInContext):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::EmptyLetExpression::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::BindingNode::bindValue const):
        (JSC::AssignmentElementNode::bindValue const):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2018-09-17  Devin Rousso  <drousso@apple.com>

        Web Inspector: generate CSSKeywordCompletions from backend values
        https://bugs.webkit.org/show_bug.cgi?id=189041

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/CSS.json:
        Include an optional `aliases` array and `inherited` boolean for `CSSPropertyInfo`.

2018-09-17  Saam barati  <sbarati@apple.com>

        We must convert ProfileType to CheckStructureOrEmpty instead of CheckStructure
        https://bugs.webkit.org/show_bug.cgi?id=189676
        <rdar://problem/39682897>

        Reviewed by Michael Saboff.

        Because the incoming value may be TDZ, CheckStructure may end up crashing.
        Since the Type Profile does not currently record TDZ values in any of its
        data structures, this is not a semantic change in how it will show you data.
        It just fixes crashes when we emit a CheckStructure and the incoming value
        is TDZ.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToCheckStructureOrEmpty):

2018-09-17  Darin Adler  <darin@apple.com>

        Use OpaqueJSString rather than JSRetainPtr inside WebKit
        https://bugs.webkit.org/show_bug.cgi?id=189652

        Reviewed by Saam Barati.

        * API/JSCallbackObjectFunctions.h: Removed an uneeded include of
        JSStringRef.h.

        * API/JSContext.mm:
        (-[JSContext evaluateScript:withSourceURL:]): Use OpaqueJSString::create rather
        than JSStringCreateWithCFString, simplifying the code and also obviating the
        need for explicit JSStringRelease.
        (-[JSContext setName:]): Ditto.

        * API/JSStringRef.cpp:
        (JSStringIsEqualToUTF8CString): Use adoptRef rather than explicit JSStringRelease.
        It seems that additional optimization is possible, obviating the need to allocate
        an OpaqueJSString, but that's true almost everywhere else in this patch, too.

        * API/JSValue.mm:
        (+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]): Use
        OpaqueJSString::create and adoptRef as appropriate.
        (+[JSValue valueWithNewErrorFromMessage:inContext:]): Ditto.
        (+[JSValue valueWithNewSymbolFromDescription:inContext:]): Ditto.
        (performPropertyOperation): Ditto.
        (-[JSValue invokeMethod:withArguments:]): Ditto.
        (valueToObjectWithoutCopy): Ditto.
        (containerValueToObject): Ditto.
        (valueToString): Ditto.
        (objectToValueWithoutCopy): Ditto.
        (objectToValue): Ditto.

2018-09-08  Darin Adler  <darin@apple.com>

        Streamline JSRetainPtr, fix leaks of JSString and JSGlobalContext
        https://bugs.webkit.org/show_bug.cgi?id=189455

        Reviewed by Keith Miller.

        * API/JSObjectRef.cpp:
        (OpaqueJSPropertyNameArray): Use Ref<OpaqueJSString> instead of
        JSRetainPtr<JSStringRef>.
        (JSObjectCopyPropertyNames): Remove now-unneeded use of leakRef and
        adopt constructor.
        (JSPropertyNameArrayGetNameAtIndex): Use ptr() instead of get() since
        the array elements are now Ref.

        * API/JSRetainPtr.h: While JSRetainPtr is written as a template,
        it only works for two specific unrelated types, JSStringRef and
        JSGlobalContextRef. Simplified the default constructor using data
        member initialization. Prepared to make the adopt constructor private
        (got everything compiling that way, then made it public again so that
        Apple internal software will still build). Got rid of unneeded
        templated constructor and assignment operator, since it's not relevant
        since there is no inheritance between JSRetainPtr template types.
        Added WARN_UNUSED_RETURN to leakRef as in RefPtr and RetainPtr.
        Added move constructor and move assignment operator for slightly better
        performance. Simplified implementations of various member functions
        so they are more obviously correct, by using leakPtr in more of them
        and using std::exchange to make the flow of values more obvious.

        * API/JSValue.mm:
        (+[JSValue valueWithNewSymbolFromDescription:inContext:]): Added a
        missing JSStringRelease to fix a leak.

        * API/tests/CustomGlobalObjectClassTest.c:
        (customGlobalObjectClassTest): Added a JSGlobalContextRelease to fix a leak.
        (globalObjectSetPrototypeTest): Ditto.
        (globalObjectPrivatePropertyTest): Ditto.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testResetAfterTimeout): Added a call to JSStringRelease to fix a leak.
        (testExecutionTimeLimit): Ditto, lots more.

        * API/tests/FunctionOverridesTest.cpp:
        (testFunctionOverrides): Added a call to JSStringRelease to fix a leak.

        * API/tests/JSObjectGetProxyTargetTest.cpp:
        (testJSObjectGetProxyTarget): Added a call to JSGlobalContextRelease to fix
        a leak.

        * API/tests/PingPongStackOverflowTest.cpp:
        (testPingPongStackOverflow): Added calls to JSGlobalContextRelease and
        JSStringRelease to fix leaks.

        * API/tests/testapi.c:
        (throwException): Added. Helper function for repeated idiom where we want
        to throw an exception, but with additional JSStringRelease calls so we don't
        have to leak just to keep the code simpler to read.
        (MyObject_getProperty): Use throwException.
        (MyObject_setProperty): Ditto.
        (MyObject_deleteProperty): Ditto.
        (isValueEqualToString): Added. Helper function for an idiom where we check
        if something is a string and then if it's equal to a particular string
        constant, but a version that has an additional JSStringRelease call so we
        don't have to leak just to keep the code simpler to read.
        (MyObject_callAsFunction): Use isValueEqualToString and throwException.
        (MyObject_callAsConstructor): Ditto.
        (MyObject_hasInstance): Ditto.
        (globalContextNameTest): Added a JSGlobalContextRelease to fix a leak.
        (testMarkingConstraintsAndHeapFinalizers): Ditto.

2018-09-14  Saam barati  <sbarati@apple.com>

        Don't dump OSRAvailabilityData in Graph::dump because a stale Availability may point to a Node that is already freed
        https://bugs.webkit.org/show_bug.cgi?id=189628
        <rdar://problem/39481690>

        Reviewed by Mark Lam.

        An Availability may point to a Node. And that Node may be removed from
        the graph, e.g, it's freed and its memory is no longer owned by Graph.
        This patch makes it so we no longer dump this metadata by default. If
        this metadata is interesting to you, you'll need to go in and change
        Graph::dump to dump the needed metadata.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):

2018-09-14  Mark Lam  <mark.lam@apple.com>

        Refactor some ForInContext code for better encapsulation.
        https://bugs.webkit.org/show_bug.cgi?id=189626
        <rdar://problem/44466415>

        Reviewed by Keith Miller.

        1. Add a ForInContext::m_type field to store the context type.  This does not
           increase the class size, but eliminates the need for a virtual call to get the
           type.

           Note: we still need a virtual destructor because we'll be mingling
           IndexedForInContexts and StructureForInContexts in the BytecodeGenerator::m_forInContextStack.

        2. Add ForInContext::isIndexedForInContext() and ForInContext::isStructureForInContext()
           convenience methods.

        3. Add ForInContext::asIndexedForInContext() and ForInContext::asStructureForInContext()
           to do the casting to the subclass types.  This ensures that we'll properly
           assert that the casting is legal.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetByVal):
        (JSC::BytecodeGenerator::popIndexedForInScope):
        (JSC::BytecodeGenerator::popStructureForInScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::ForInContext::type const):
        (JSC::ForInContext::isIndexedForInContext const):
        (JSC::ForInContext::isStructureForInContext const):
        (JSC::ForInContext::asIndexedForInContext):
        (JSC::ForInContext::asStructureForInContext):
        (JSC::ForInContext::ForInContext):
        (JSC::StructureForInContext::StructureForInContext):
        (JSC::IndexedForInContext::IndexedForInContext):
        (JSC::ForInContext::~ForInContext): Deleted.

2018-09-14  Devin Rousso  <webkit@devinrousso.com>

        Web Inspector: Record actions performed on ImageBitmapRenderingContext
        https://bugs.webkit.org/show_bug.cgi?id=181341

        Reviewed by Joseph Pecoraro.

        * inspector/protocol/Recording.json:
        * inspector/scripts/codegen/generator.py:

2018-09-14  Mike Gorse  <mgorse@suse.com>

        builtins directory causes name conflict on Python 3
        https://bugs.webkit.org/show_bug.cgi?id=189552

        Reviewed by Michael Catanzaro.

        * CMakeLists.txt: builtins -> wkbuiltins.
        * DerivedSources.make: builtins -> wkbuiltins.
        * Scripts/generate-js-builtins.py: import wkbuiltins, rather than
          builtins.
        * Scripts/wkbuiltins/__init__.py: Renamed from Source/JavaScriptCore/Scripts/builtins/__init__.py.
        * Scripts/wkbuiltins/builtins_generate_combined_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_combined_header.py.
        * Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_internals_wrapper_implementation.py.
        * Scripts/wkbuiltins/builtins_generate_separate_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_separate_header.py.
        * Scripts/wkbuiltins/builtins_generate_separate_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_separate_implementation.py.
        * Scripts/wkbuiltins/builtins_generate_wrapper_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_wrapper_header.py.
        * Scripts/wkbuiltins/builtins_generate_wrapper_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_wrapper_implementation.py.
        * Scripts/wkbuiltins/builtins_generator.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generator.py.
        * Scripts/wkbuiltins/builtins_model.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_model.py.
        * Scripts/wkbuiltins/builtins_templates.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_templates.py.
        * Scripts/wkbuiltins/wkbuiltins.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins.py.
        * JavaScriptCore.xcodeproj/project.pbxproj: Update for the renaming.

2018-09-13  Yusuke Suzuki  <yusukesuzuki@slowstart.org>

        [WebAssembly] Inline WasmContext accessor functions
        https://bugs.webkit.org/show_bug.cgi?id=189416

        Reviewed by Saam Barati.

        WasmContext accessor functions are very small while it resides in the critical path of
        JS to Wasm function call. This patch makes them inline to improve performance.
        This change improves a small benchmark (calling JS to Wasm function 1e7 times) from 320ms to 270ms.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Sources.txt:
        * interpreter/CallFrame.cpp:
        * jit/AssemblyHelpers.cpp:
        * wasm/WasmB3IRGenerator.cpp:
        * wasm/WasmContextInlines.h: Renamed from Source/JavaScriptCore/wasm/WasmContext.cpp.
        (JSC::Wasm::Context::useFastTLS):
        (JSC::Wasm::Context::load const):
        (JSC::Wasm::Context::store):
        * wasm/WasmMemoryInformation.cpp:
        * wasm/WasmModuleParser.cpp: Include <wtf/SHA1.h> due to changes of unified source combinations.
        * wasm/js/JSToWasm.cpp:
        * wasm/js/WebAssemblyFunction.cpp:

2018-09-12  David Kilzer  <ddkilzer@apple.com>

        Move JavaScriptCore files to match Xcode project hierarchy
        <https://webkit.org/b/189574>

        Reviewed by Filip Pizlo.

        * API/JSAPIValueWrapper.cpp: Rename from Source/JavaScriptCore/runtime/JSAPIValueWrapper.cpp.
        * API/JSAPIValueWrapper.h: Rename from Source/JavaScriptCore/runtime/JSAPIValueWrapper.h.
        * CMakeLists.txt: Update for new path to
        generateYarrUnicodePropertyTables.py, hasher.py and
        JSAPIValueWrapper.h.
        * DerivedSources.make: Ditto. Add missing dependency on
        hasher.py captured by CMakeLists.txt.
        * JavaScriptCore.xcodeproj/project.pbxproj: Update for new file
        reference paths. Add hasher.py library to project.
        * Sources.txt: Update for new path to
        JSAPIValueWrapper.cpp.
        * runtime/JSImmutableButterfly.h: Add missing includes
        after changes to Sources.txt and regenerating unified
        sources.
        * runtime/RuntimeType.h: Ditto.
        * yarr/generateYarrUnicodePropertyTables.py: Rename from Source/JavaScriptCore/Scripts/generateYarrUnicodePropertyTables.py.
        * yarr/hasher.py: Rename from Source/JavaScriptCore/Scripts/hasher.py.

2018-09-12  David Kilzer  <ddkilzer@apple.com>

        Let Xcode have its way with the JavaScriptCore project

        * JavaScriptCore.xcodeproj/project.pbxproj:

2018-09-12  Guillaume Emont  <guijemont@igalia.com>

        Add IGNORE_WARNING_.* macros
        https://bugs.webkit.org/show_bug.cgi?id=188996

        Reviewed by Michael Catanzaro.

        * API/JSCallbackObject.h:
        * API/tests/testapi.c:
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * b3/B3LowerToAir.cpp:
        * b3/B3Opcode.cpp:
        * b3/B3Type.h:
        * b3/B3TypeMap.h:
        * b3/B3Width.h:
        * b3/air/AirArg.cpp:
        * b3/air/AirArg.h:
        * b3/air/AirCode.h:
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateNumber):
        (JSC::DFG::SpeculativeJIT::speculateMisc):
        * dfg/DFGSpeculativeJIT64.cpp:
        * ftl/FTLOutput.h:
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::calculatePokeOffset):
        * llint/LLIntData.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::slowPathLogF):
        * runtime/ConfigFile.cpp:
        (JSC::ConfigFile::canonicalizePaths):
        * runtime/JSDataViewPrototype.cpp:
        * runtime/JSGenericTypedArrayViewConstructor.h:
        * runtime/JSGenericTypedArrayViewPrototype.h:
        * runtime/Options.cpp:
        (JSC::Options::setAliasedOption):
        * tools/CodeProfiling.cpp:
        * wasm/WasmSections.h:
        * wasm/generateWasmValidateInlinesHeader.py:

== Rolled over to ChangeLog-2018-09-11 ==