Source/JavaScriptCore/ChangeLog

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Heap variables shouldn't end up in the stack frame
        https://bugs.webkit.org/show_bug.cgi?id=141174

        Reviewed by Geoffrey Garen.
        
        This is a major change to how JavaScriptCore handles declared variables (i.e. "var"). It removes
        any ambiguity about whether a variable should be in the heap or on the stack. A variable will no
        longer move between heap and stack during its lifetime. This enables a bunch of optimizations and
        simplifications:
        
        - Accesses to variables no longer need checks or indirections to determine where the variable is
          at that moment in time. For example, loading a closure variable now takes just one load instead
          of two. Loading an argument by index now takes a bounds check and a load in the fastest case
          (when no arguments object allocation is required) while previously that same operation required
          a "did I allocate arguments yet" check, a bounds check, and then the load.
        
        - Reasoning about the allocation of an activation or arguments object now follows the same simple
          logic as the allocation of any other kind of object. Previously, those objects were lazily
          allocated - so an allocation instruction wasn't the actual allocation site, since it might not
          allocate anything at all. This made the implementation of traditional escape analyses really
          awkward, and ultimately it meant that we missed important cases. Now, we can reason about the
          arguments object using the usual SSA tricks which allows for more comprehensive removal.
        
        - The allocations of arguments objects, functions, and activations are now much faster. While
          this patch generally expands our ability to eliminate arguments object allocations, an earlier
          version of the patch - which lacked that functionality - was a progression on some arguments-
          and closure-happy benchmarks because although no allocations were eliminated, all allocations
          were faster.
        
        - There is no tear-off. The runtime no loner needs to know about where on the stack a frame keeps
          its arguments objects or activations. The runtime doesn't have to do things to the arguments
          objects and activations that a frame allocated, when the frame is unwound. We always had horrid
          bugs in that code, so it's good to see it go. This removes *a ton* of machinery from the DFG,
          FTL, CodeBlock, and other places. All of the things having to do with "captured variables" is
          now gone. This also enables implementing block-scoping. Without this change, block-scope
          support would require telling CodeBlock and all of the rest of the runtime about all of the
          variables that store currently-live scopes. That would have been so disastrously hard that it
          might as well be impossible. With this change, it's fair game for the bytecode generator to
          simply allocate whatever activations it wants, wherever it wants, and to keep them live for
          however long it wants. This all works, because after bytecode generation, an activation is just
          an object and variables that refer to it are just normal variables.
        
        - SymbolTable can now tell you explicitly where a variable lives. The answer is in the form of a
          VarOffset object, which has methods like isStack(), isScope(), etc. VirtualRegister is never
          used for offsets of non-stack variables anymore. We now have shiny new objects for other kinds
          of offsets - ScopeOffset for offsets into scopes, and DirectArgumentsOffset for offsets into
          an arguments object.
        
        - Functions that create activations can now tier-up into the FTL. Previously they couldn't. Also,
          using activations used to prevent inlining; now functions that use activations can be inlined
          just fine.
        
        This is a >1% speed-up on Octane. This is a >2% speed-up on CompressionBench. This is a tiny
        speed-up on AsmBench (~0.4% or something). This looks like it might be a speed-up on SunSpider.
        It's only a slow-down on very short-running microbenchmarks we had previously written for our old
        style of tear-off-based arguments optimization. Those benchmarks are not part of any major suite.
        
        The easiest way of understanding this change is to start by looking at the changes in runtime/,
        and then the changes in bytecompiler/, and then sort of work your way up the compiler tiers.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbortReason.h:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::BaseIndex::withOffset):
        * bytecode/ByValInfo.h:
        (JSC::hasOptimizableIndexingForJSType):
        (JSC::hasOptimizableIndexing):
        (JSC::jitArrayModeForJSType):
        (JSC::jitArrayModePermitsPut):
        (JSC::jitArrayModeForStructure):
        * bytecode/BytecodeKills.h: Added.
        (JSC::BytecodeKills::BytecodeKills):
        (JSC::BytecodeKills::operandIsKilled):
        (JSC::BytecodeKills::forEachOperandKilledAt):
        (JSC::BytecodeKills::KillSet::KillSet):
        (JSC::BytecodeKills::KillSet::add):
        (JSC::BytecodeKills::KillSet::forEachLocal):
        (JSC::BytecodeKills::KillSet::contains):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::isValidRegisterForLiveness):
        (JSC::stepOverInstruction):
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
        (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::BytecodeLivenessAnalysis::computeKills):
        (JSC::indexForOperand): Deleted.
        (JSC::BytecodeLivenessAnalysis::getLivenessInfoForNonCapturedVarsAtBytecodeOffset): Deleted.
        (JSC::getLivenessInfo): Deleted.
        * bytecode/BytecodeLivenessAnalysis.h:
        * bytecode/BytecodeLivenessAnalysisInlines.h:
        (JSC::operandIsAlwaysLive):
        (JSC::operandThatIsNotAlwaysLiveIsLive):
        (JSC::operandIsLive):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::nameForRegister):
        (JSC::CodeBlock::validate):
        (JSC::CodeBlock::isCaptured): Deleted.
        (JSC::CodeBlock::framePointerOffsetToGetActivationRegisters): Deleted.
        (JSC::CodeBlock::machineSlowArguments): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::unmodifiedArgumentsRegister): Deleted.
        (JSC::CodeBlock::setArgumentsRegister): Deleted.
        (JSC::CodeBlock::argumentsRegister): Deleted.
        (JSC::CodeBlock::uncheckedArgumentsRegister): Deleted.
        (JSC::CodeBlock::usesArguments): Deleted.
        (JSC::CodeBlock::captureCount): Deleted.
        (JSC::CodeBlock::captureStart): Deleted.
        (JSC::CodeBlock::captureEnd): Deleted.
        (JSC::CodeBlock::argumentIndexAfterCapture): Deleted.
        (JSC::CodeBlock::hasSlowArguments): Deleted.
        (JSC::ExecState::argumentAfterCapture): Deleted.
        * bytecode/CodeOrigin.h:
        * bytecode/DataFormat.h:
        (JSC::dataFormatToString):
        * bytecode/FullBytecodeLiveness.h:
        (JSC::FullBytecodeLiveness::getLiveness):
        (JSC::FullBytecodeLiveness::operandIsLive):
        (JSC::FullBytecodeLiveness::FullBytecodeLiveness): Deleted.
        (JSC::FullBytecodeLiveness::getOut): Deleted.
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        * bytecode/Operands.h:
        (JSC::Operands::virtualRegisterForIndex):
        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromClassInfo):
        * bytecode/SpeculatedType.h:
        (JSC::isDirectArgumentsSpeculation):
        (JSC::isScopedArgumentsSpeculation):
        (JSC::isActionableMutableArraySpeculation):
        (JSC::isActionableArraySpeculation):
        (JSC::isArgumentsSpeculation): Deleted.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::setArgumentsRegister): Deleted.
        (JSC::UnlinkedCodeBlock::usesArguments): Deleted.
        (JSC::UnlinkedCodeBlock::argumentsRegister): Deleted.
        * bytecode/ValueRecovery.cpp:
        (JSC::ValueRecovery::dumpInContext):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::directArgumentsThatWereNotCreated):
        (JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated):
        (JSC::ValueRecovery::nodeID):
        (JSC::ValueRecovery::argumentsThatWereNotCreated): Deleted.
        * bytecode/VirtualRegister.h:
        (JSC::VirtualRegister::operator==):
        (JSC::VirtualRegister::operator!=):
        (JSC::VirtualRegister::operator<):
        (JSC::VirtualRegister::operator>):
        (JSC::VirtualRegister::operator<=):
        (JSC::VirtualRegister::operator>=):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeNextParameter):
        (JSC::BytecodeGenerator::visibleNameForParameter):
        (JSC::BytecodeGenerator::emitMove):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitGetFromScope):
        (JSC::BytecodeGenerator::emitPutToScope):
        (JSC::BytecodeGenerator::initializeVariable):
        (JSC::BytecodeGenerator::emitInstanceOf):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitNewFunctionInternal):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::isArgumentNumber):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::addVar): Deleted.
        (JSC::BytecodeGenerator::emitInitLazyRegister): Deleted.
        (JSC::BytecodeGenerator::initializeCapturedVariable): Deleted.
        (JSC::BytecodeGenerator::resolveCallee): Deleted.
        (JSC::BytecodeGenerator::addCallee): Deleted.
        (JSC::BytecodeGenerator::addParameter): Deleted.
        (JSC::BytecodeGenerator::willResolveToArgumentsRegister): Deleted.
        (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister): Deleted.
        (JSC::BytecodeGenerator::createLazyRegisterIfNecessary): Deleted.
        (JSC::BytecodeGenerator::isCaptured): Deleted.
        (JSC::BytecodeGenerator::local): Deleted.
        (JSC::BytecodeGenerator::constLocal): Deleted.
        (JSC::BytecodeGenerator::emitResolveConstantLocal): Deleted.
        (JSC::BytecodeGenerator::emitGetArgumentsLength): Deleted.
        (JSC::BytecodeGenerator::emitGetArgumentByVal): Deleted.
        (JSC::BytecodeGenerator::emitLazyNewFunction): Deleted.
        (JSC::BytecodeGenerator::createArgumentsIfNecessary): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::Variable::Variable):
        (JSC::Variable::isResolved):
        (JSC::Variable::ident):
        (JSC::Variable::offset):
        (JSC::Variable::isLocal):
        (JSC::Variable::local):
        (JSC::Variable::isSpecial):
        (JSC::BytecodeGenerator::argumentsRegister):
        (JSC::BytecodeGenerator::emitNode):
        (JSC::BytecodeGenerator::registerFor):
        (JSC::Local::Local): Deleted.
        (JSC::Local::operator bool): Deleted.
        (JSC::Local::get): Deleted.
        (JSC::Local::isSpecial): Deleted.
        (JSC::ResolveScopeInfo::ResolveScopeInfo): Deleted.
        (JSC::ResolveScopeInfo::isLocal): Deleted.
        (JSC::ResolveScopeInfo::localIndex): Deleted.
        (JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister): Deleted.
        (JSC::BytecodeGenerator::captureMode): Deleted.
        (JSC::BytecodeGenerator::shouldTearOffArgumentsEagerly): Deleted.
        (JSC::BytecodeGenerator::shouldCreateArgumentsEagerly): Deleted.
        (JSC::BytecodeGenerator::hasWatchableVariable): Deleted.
        (JSC::BytecodeGenerator::watchableVariableIdentifier): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::isPure):
        (JSC::ResolveNode::emitBytecode):
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::DeleteResolveNode::emitBytecode):
        (JSC::TypeOfResolveNode::emitBytecode):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::EmptyVarExpression::emitBytecode):
        (JSC::ForInNode::tryGetBoundLocal):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::ArrayPatternNode::emitDirectBinding):
        (JSC::BindingNode::bindValue):
        (JSC::getArgumentByVal): Deleted.
        * dfg/DFGAbstractHeap.h:
        * dfg/DFGAbstractInterpreter.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberWorld):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberCapturedVars): Deleted.
        * dfg/DFGAbstractValue.h:
        * dfg/DFGArgumentPosition.h:
        (JSC::DFG::ArgumentPosition::addVariable):
        * dfg/DFGArgumentsEliminationPhase.cpp: Added.
        (JSC::DFG::performArgumentsElimination):
        * dfg/DFGArgumentsEliminationPhase.h: Added.
        * dfg/DFGArgumentsSimplificationPhase.cpp: Removed.
        * dfg/DFGArgumentsSimplificationPhase.h: Removed.
        * dfg/DFGArgumentsUtilities.cpp: Added.
        (JSC::DFG::argumentsInvolveStackSlot):
        (JSC::DFG::emitCodeToGetArgumentsArrayLength):
        * dfg/DFGArgumentsUtilities.h: Added.
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        (JSC::DFG::ArrayMode::alreadyChecked):
        (JSC::DFG::arrayTypeToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::canCSEStorage):
        (JSC::DFG::ArrayMode::modeForPut):
        * dfg/DFGAvailabilityMap.cpp:
        (JSC::DFG::AvailabilityMap::prune):
        * dfg/DFGAvailabilityMap.h:
        (JSC::DFG::AvailabilityMap::closeOverNodes):
        (JSC::DFG::AvailabilityMap::closeStartingWithLocal):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::newVariableAccessData):
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::getArgument):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::flushDirect):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::noticeArgumentsUse):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: Added.
        (JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::isSupportedForInlining):
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCommon.h:
        * dfg/DFGCommonData.h:
        (JSC::DFG::CommonData::CommonData):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::cleanVariables):
        * dfg/DFGDisassembler.h:
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGFlushFormat.cpp:
        (WTF::printInternal):
        * dfg/DFGFlushFormat.h:
        (JSC::DFG::resultFor):
        (JSC::DFG::useKindFor):
        (JSC::DFG::dataFormatFor):
        * dfg/DFGForAllKills.h: Added.
        (JSC::DFG::forAllLiveNodesAtTail):
        (JSC::DFG::forAllDirectlyKilledOperands):
        (JSC::DFG::forAllKilledOperands):
        (JSC::DFG::forAllKilledNodesAtNodeIndex):
        (JSC::DFG::forAllKillsInBlock):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::substituteGetLocal):
        (JSC::DFG::Graph::livenessFor):
        (JSC::DFG::Graph::killsFor):
        (JSC::DFG::Graph::tryGetConstantClosureVar):
        (JSC::DFG::Graph::tryGetRegisters): Deleted.
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::symbolTableFor):
        (JSC::DFG::Graph::uses):
        (JSC::DFG::Graph::bytecodeRegisterForArgument): Deleted.
        (JSC::DFG::Graph::capturedVarsFor): Deleted.
        (JSC::DFG::Graph::usesArguments): Deleted.
        (JSC::DFG::Graph::argumentsRegisterFor): Deleted.
        (JSC::DFG::Graph::machineArgumentsRegisterFor): Deleted.
        (JSC::DFG::Graph::uncheckedArgumentsRegisterFor): Deleted.
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGMinifiedID.h:
        * dfg/DFGMinifiedNode.cpp:
        (JSC::DFG::MinifiedNode::fromNode):
        * dfg/DFGMinifiedNode.h:
        (JSC::DFG::belongsInMinifiedGraph):
        (JSC::DFG::MinifiedNode::hasInlineCallFrame):
        (JSC::DFG::MinifiedNode::inlineCallFrame):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToIdentityOn):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasConstant):
        (JSC::DFG::Node::constant):
        (JSC::DFG::Node::hasScopeOffset):
        (JSC::DFG::Node::scopeOffset):
        (JSC::DFG::Node::hasDirectArgumentsOffset):
        (JSC::DFG::Node::capturedArgumentsOffset):
        (JSC::DFG::Node::variablePointer):
        (JSC::DFG::Node::hasCallVarargsData):
        (JSC::DFG::Node::hasLoadVarargsData):
        (JSC::DFG::Node::hasHeapPrediction):
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::objectMaterializationData):
        (JSC::DFG::Node::isPhantomAllocation):
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        (JSC::DFG::Node::shouldSpeculateDirectArguments):
        (JSC::DFG::Node::shouldSpeculateScopedArguments):
        (JSC::DFG::Node::isPhantomArguments): Deleted.
        (JSC::DFG::Node::hasVarNumber): Deleted.
        (JSC::DFG::Node::varNumber): Deleted.
        (JSC::DFG::Node::registerPointer): Deleted.
        (JSC::DFG::Node::shouldSpeculateArguments): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::OSRExitCompiler::emitRestoreArguments):
        * dfg/DFGOSRExitCompiler.h:
        (JSC::DFG::OSRExitCompiler::badIndex): Deleted.
        (JSC::DFG::OSRExitCompiler::initializePoisoned): Deleted.
        (JSC::DFG::OSRExitCompiler::poisonIndex): Deleted.
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::ArgumentsRecoveryGenerator::ArgumentsRecoveryGenerator): Deleted.
        (JSC::DFG::ArgumentsRecoveryGenerator::~ArgumentsRecoveryGenerator): Deleted.
        (JSC::DFG::ArgumentsRecoveryGenerator::generateFor): Deleted.
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::read):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::write):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::def):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        (JSC::DFG::preciseLocalClobberize):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::writeTop): Deleted.
        (JSC::DFG::forEachLocalReadByUnwind): Deleted.
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::run):
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        (JSC::DFG::PredictionPropagationPhase::propagateThroughArgumentPositions):
        * dfg/DFGPromoteHeapAccess.h:
        (JSC::DFG::promoteHeapAccess):
        * dfg/DFGPromotedHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
        (JSC::DFG::SpeculativeJIT::emitGetLength):
        (JSC::DFG::SpeculativeJIT::emitGetCallee):
        (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
        (JSC::DFG::SpeculativeJIT::compileCreateActivation):
        (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
        (JSC::DFG::SpeculativeJIT::compileGetFromArguments):
        (JSC::DFG::SpeculativeJIT::compilePutToArguments):
        (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
        (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
        (JSC::DFG::SpeculativeJIT::emitAllocateArguments): Deleted.
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): Deleted.
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): Deleted.
        (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck): Deleted.
        (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        (JSC::DFG::SpeculativeJIT::framePointerOffsetToGetActivationRegisters): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):
        * dfg/DFGUnificationPhase.cpp:
        (JSC::DFG::UnificationPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * dfg/DFGValueSource.cpp:
        (JSC::DFG::ValueSource::dump):
        * dfg/DFGValueSource.h:
        (JSC::DFG::dataFormatToValueSourceKind):
        (JSC::DFG::valueSourceKindToDataFormat):
        (JSC::DFG::ValueSource::ValueSource):
        (JSC::DFG::ValueSource::forFlushFormat):
        (JSC::DFG::ValueSource::valueRecovery):
        * dfg/DFGVarargsForwardingPhase.cpp: Added.
        (JSC::DFG::performVarargsForwarding):
        * dfg/DFGVarargsForwardingPhase.h: Added.
        * dfg/DFGVariableAccessData.cpp:
        (JSC::DFG::VariableAccessData::VariableAccessData):
        (JSC::DFG::VariableAccessData::flushFormat):
        (JSC::DFG::VariableAccessData::mergeIsCaptured): Deleted.
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::shouldNeverUnbox):
        (JSC::DFG::VariableAccessData::shouldUseDoubleFormat):
        (JSC::DFG::VariableAccessData::isCaptured): Deleted.
        (JSC::DFG::VariableAccessData::mergeIsArgumentsAlias): Deleted.
        (JSC::DFG::VariableAccessData::isArgumentsAlias): Deleted.
        * dfg/DFGVariableAccessDataDump.cpp:
        (JSC::DFG::VariableAccessDataDump::dump):
        * dfg/DFGVariableAccessDataDump.h:
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
        * dfg/DFGVariableEventStream.h:
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::AbstractHeap::dump):
        (JSC::FTL::AbstractField::dump):
        (JSC::FTL::IndexedAbstractHeap::dump):
        (JSC::FTL::NumberedAbstractHeap::dump):
        (JSC::FTL::AbsoluteAbstractHeap::dump):
        * ftl/FTLAbstractHeap.h:
        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExitArgument.cpp:
        (JSC::FTL::ExitArgument::dump):
        * ftl/FTLExitPropertyValue.cpp:
        (JSC::FTL::ExitPropertyValue::withLocalsOffset):
        * ftl/FTLExitPropertyValue.h:
        * ftl/FTLExitTimeObjectMaterialization.cpp:
        (JSC::FTL::ExitTimeObjectMaterialization::ExitTimeObjectMaterialization):
        (JSC::FTL::ExitTimeObjectMaterialization::accountForLocalsOffset):
        * ftl/FTLExitTimeObjectMaterialization.h:
        (JSC::FTL::ExitTimeObjectMaterialization::origin):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::withLocalsOffset):
        (JSC::FTL::ExitValue::valueFormat):
        (JSC::FTL::ExitValue::dumpInContext):
        * ftl/FTLExitValue.h:
        (JSC::FTL::ExitValue::isArgument):
        (JSC::FTL::ExitValue::argumentsObjectThatWasNotCreated): Deleted.
        (JSC::FTL::ExitValue::isArgumentsObjectThatWasNotCreated): Deleted.
        (JSC::FTL::ExitValue::valueFormat): Deleted.
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfCallForwardVarargs):
        (JSC::FTL::sizeOfConstructForwardVarargs):
        (JSC::FTL::sizeOfICFor):
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLJSCallVarargs.cpp:
        (JSC::FTL::JSCallVarargs::JSCallVarargs):
        (JSC::FTL::JSCallVarargs::emit):
        * ftl/FTLJSCallVarargs.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compilePutStack):
        (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
        (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
        (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
        (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
        (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
        (JSC::FTL::LowerDFGToLLVM::compileCreateScopedArguments):
        (JSC::FTL::LowerDFGToLLVM::compileCreateClonedArguments):
        (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
        (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
        (JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
        (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
        (JSC::FTL::LowerDFGToLLVM::compileGetArgumentCount):
        (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
        (JSC::FTL::LowerDFGToLLVM::compilePutClosureVar):
        (JSC::FTL::LowerDFGToLLVM::compileGetFromArguments):
        (JSC::FTL::LowerDFGToLLVM::compilePutToArguments):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::LowerDFGToLLVM::compileForwardVarargs):
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorPname):
        (JSC::FTL::LowerDFGToLLVM::ArgumentsLength::ArgumentsLength):
        (JSC::FTL::LowerDFGToLLVM::getArgumentsLength):
        (JSC::FTL::LowerDFGToLLVM::getCurrentCallee):
        (JSC::FTL::LowerDFGToLLVM::getArgumentsStart):
        (JSC::FTL::LowerDFGToLLVM::baseIndex):
        (JSC::FTL::LowerDFGToLLVM::allocateObject):
        (JSC::FTL::LowerDFGToLLVM::allocateVariableSizedObject):
        (JSC::FTL::LowerDFGToLLVM::isArrayType):
        (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
        (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
        (JSC::FTL::LowerDFGToLLVM::loadStructure):
        (JSC::FTL::LowerDFGToLLVM::compilePhantomArguments): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentsLength): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileCheckArgumentsNotCreated): Deleted.
        (JSC::FTL::LowerDFGToLLVM::checkArgumentsNotCreated): Deleted.
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileRecovery):
        (JSC::FTL::compileStub):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::zeroExtPtr):
        * heap/CopyToken.h:
        * interpreter/CallFrame.h:
        (JSC::ExecState::getArgumentUnsafe):
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        (JSC::sizeFrameForVarargs):
        (JSC::loadVarargs):
        (JSC::unwindCallFrame):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::createArguments):
        (JSC::StackVisitor::Frame::existingArguments): Deleted.
        * interpreter/StackVisitor.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::storeValue):
        (JSC::AssemblyHelpers::loadValue):
        (JSC::AssemblyHelpers::storeTrustedValue):
        (JSC::AssemblyHelpers::branchIfNotCell):
        (JSC::AssemblyHelpers::branchIsEmpty):
        (JSC::AssemblyHelpers::argumentsStart):
        (JSC::AssemblyHelpers::baselineArgumentsRegisterFor): Deleted.
        (JSC::AssemblyHelpers::offsetOfLocals): Deleted.
        (JSC::AssemblyHelpers::offsetOfArguments): Deleted.
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgument):
        * jit/GPRInfo.h:
        (JSC::JSValueRegs::withTwoAvailableRegs):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_lexical_environment):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_create_direct_arguments):
        (JSC::JIT::emit_op_create_scoped_arguments):
        (JSC::JIT::emit_op_create_out_of_band_arguments):
        (JSC::JIT::emit_op_tear_off_arguments): Deleted.
        (JSC::JIT::emit_op_create_arguments): Deleted.
        (JSC::JIT::emit_op_init_lazy_reg): Deleted.
        (JSC::JIT::emit_op_get_arguments_length): Deleted.
        (JSC::JIT::emitSlow_op_get_arguments_length): Deleted.
        (JSC::JIT::emit_op_get_argument_by_val): Deleted.
        (JSC::JIT::emitSlow_op_get_argument_by_val): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_lexical_environment):
        (JSC::JIT::emit_op_tear_off_arguments): Deleted.
        (JSC::JIT::emit_op_create_arguments): Deleted.
        (JSC::JIT::emit_op_init_lazy_reg): Deleted.
        (JSC::JIT::emit_op_get_arguments_length): Deleted.
        (JSC::JIT::emitSlow_op_get_arguments_length): Deleted.
        (JSC::JIT::emit_op_get_argument_by_val): Deleted.
        (JSC::JIT::emitSlow_op_get_argument_by_val): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetClosureVar):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::emitDirectArgumentsGetByVal):
        (JSC::JIT::emitScopedArgumentsGetByVal):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetClosureVar):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emit_op_get_from_arguments):
        (JSC::JIT::emit_op_put_to_arguments):
        (JSC::JIT::emit_op_init_global_const):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/Nodes.h:
        (JSC::ScopeNode::captures):
        * runtime/Arguments.cpp: Removed.
        * runtime/Arguments.h: Removed.
        * runtime/ArgumentsMode.h: Added.
        * runtime/DirectArgumentsOffset.cpp: Added.
        (JSC::DirectArgumentsOffset::dump):
        * runtime/DirectArgumentsOffset.h: Added.
        (JSC::DirectArgumentsOffset::DirectArgumentsOffset):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/ConstantMode.cpp: Added.
        (WTF::printInternal):
        * runtime/ConstantMode.h:
        (JSC::modeForIsConstant):
        * runtime/DirectArguments.cpp: Added.
        (JSC::DirectArguments::DirectArguments):
        (JSC::DirectArguments::createUninitialized):
        (JSC::DirectArguments::create):
        (JSC::DirectArguments::createByCopying):
        (JSC::DirectArguments::visitChildren):
        (JSC::DirectArguments::copyBackingStore):
        (JSC::DirectArguments::createStructure):
        (JSC::DirectArguments::overrideThings):
        (JSC::DirectArguments::overrideThingsIfNecessary):
        (JSC::DirectArguments::overrideArgument):
        (JSC::DirectArguments::copyToArguments):
        (JSC::DirectArguments::overridesSize):
        * runtime/DirectArguments.h: Added.
        (JSC::DirectArguments::internalLength):
        (JSC::DirectArguments::length):
        (JSC::DirectArguments::canAccessIndexQuickly):
        (JSC::DirectArguments::getIndexQuickly):
        (JSC::DirectArguments::setIndexQuickly):
        (JSC::DirectArguments::callee):
        (JSC::DirectArguments::argument):
        (JSC::DirectArguments::overrodeThings):
        (JSC::DirectArguments::offsetOfCallee):
        (JSC::DirectArguments::offsetOfLength):
        (JSC::DirectArguments::offsetOfMinCapacity):
        (JSC::DirectArguments::offsetOfOverrides):
        (JSC::DirectArguments::storageOffset):
        (JSC::DirectArguments::offsetOfSlot):
        (JSC::DirectArguments::allocationSize):
        (JSC::DirectArguments::storage):
        * runtime/FunctionPrototype.cpp:
        * runtime/GenericArguments.h: Added.
        (JSC::GenericArguments::GenericArguments):
        * runtime/GenericArgumentsInlines.h: Added.
        (JSC::GenericArguments<Type>::getOwnPropertySlot):
        (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
        (JSC::GenericArguments<Type>::getOwnPropertyNames):
        (JSC::GenericArguments<Type>::put):
        (JSC::GenericArguments<Type>::putByIndex):
        (JSC::GenericArguments<Type>::deleteProperty):
        (JSC::GenericArguments<Type>::deletePropertyByIndex):
        (JSC::GenericArguments<Type>::defineOwnProperty):
        (JSC::GenericArguments<Type>::copyToArguments):
        * runtime/GenericOffset.h: Added.
        (JSC::GenericOffset::GenericOffset):
        (JSC::GenericOffset::operator!):
        (JSC::GenericOffset::offsetUnchecked):
        (JSC::GenericOffset::offset):
        (JSC::GenericOffset::operator==):
        (JSC::GenericOffset::operator!=):
        (JSC::GenericOffset::operator<):
        (JSC::GenericOffset::operator>):
        (JSC::GenericOffset::operator<=):
        (JSC::GenericOffset::operator>=):
        (JSC::GenericOffset::operator+):
        (JSC::GenericOffset::operator-):
        (JSC::GenericOffset::operator+=):
        (JSC::GenericOffset::operator-=):
        * runtime/JSArgumentsIterator.cpp:
        (JSC::JSArgumentsIterator::finishCreation):
        (JSC::argumentsFuncIterator):
        * runtime/JSArgumentsIterator.h:
        (JSC::JSArgumentsIterator::create):
        (JSC::JSArgumentsIterator::next):
        * runtime/JSEnvironmentRecord.cpp:
        (JSC::JSEnvironmentRecord::visitChildren):
        * runtime/JSEnvironmentRecord.h:
        (JSC::JSEnvironmentRecord::variables):
        (JSC::JSEnvironmentRecord::isValid):
        (JSC::JSEnvironmentRecord::variableAt):
        (JSC::JSEnvironmentRecord::offsetOfVariables):
        (JSC::JSEnvironmentRecord::offsetOfVariable):
        (JSC::JSEnvironmentRecord::allocationSizeForScopeSize):
        (JSC::JSEnvironmentRecord::allocationSize):
        (JSC::JSEnvironmentRecord::JSEnvironmentRecord):
        (JSC::JSEnvironmentRecord::finishCreationUninitialized):
        (JSC::JSEnvironmentRecord::finishCreation):
        (JSC::JSEnvironmentRecord::registers): Deleted.
        (JSC::JSEnvironmentRecord::registerAt): Deleted.
        (JSC::JSEnvironmentRecord::addressOfRegisters): Deleted.
        (JSC::JSEnvironmentRecord::offsetOfRegisters): Deleted.
        * runtime/JSFunction.cpp:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::addGlobalVar):
        (JSC::JSGlobalObject::addFunction):
        (JSC::JSGlobalObject::visitChildren):
        (JSC::JSGlobalObject::addStaticGlobals):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::directArgumentsStructure):
        (JSC::JSGlobalObject::scopedArgumentsStructure):
        (JSC::JSGlobalObject::outOfBandArgumentsStructure):
        (JSC::JSGlobalObject::argumentsStructure): Deleted.
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::symbolTableGet):
        (JSC::JSLexicalEnvironment::symbolTablePut):
        (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
        (JSC::JSLexicalEnvironment::symbolTablePutWithAttributes):
        (JSC::JSLexicalEnvironment::visitChildren): Deleted.
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::create):
        (JSC::JSLexicalEnvironment::JSLexicalEnvironment):
        (JSC::JSLexicalEnvironment::registersOffset): Deleted.
        (JSC::JSLexicalEnvironment::storageOffset): Deleted.
        (JSC::JSLexicalEnvironment::storage): Deleted.
        (JSC::JSLexicalEnvironment::allocationSize): Deleted.
        (JSC::JSLexicalEnvironment::isValidIndex): Deleted.
        (JSC::JSLexicalEnvironment::isValid): Deleted.
        (JSC::JSLexicalEnvironment::registerAt): Deleted.
        * runtime/JSNameScope.cpp:
        (JSC::JSNameScope::visitChildren): Deleted.
        * runtime/JSNameScope.h:
        (JSC::JSNameScope::create):
        (JSC::JSNameScope::value):
        (JSC::JSNameScope::finishCreation):
        (JSC::JSNameScope::JSNameScope):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::findVariableIndex):
        (JSC::JSSegmentedVariableObject::addVariables):
        (JSC::JSSegmentedVariableObject::visitChildren):
        (JSC::JSSegmentedVariableObject::findRegisterIndex): Deleted.
        (JSC::JSSegmentedVariableObject::addRegisters): Deleted.
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::variableAt):
        (JSC::JSSegmentedVariableObject::assertVariableIsInThisObject):
        (JSC::JSSegmentedVariableObject::registerAt): Deleted.
        (JSC::JSSegmentedVariableObject::assertRegisterIsInThisObject): Deleted.
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::offsetOfSymbolTable):
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/JSType.h:
        * runtime/Options.h:
        * runtime/ClonedArguments.cpp: Added.
        (JSC::ClonedArguments::ClonedArguments):
        (JSC::ClonedArguments::createEmpty):
        (JSC::ClonedArguments::createWithInlineFrame):
        (JSC::ClonedArguments::createWithMachineFrame):
        (JSC::ClonedArguments::createByCopyingFrom):
        (JSC::ClonedArguments::createStructure):
        (JSC::ClonedArguments::getOwnPropertySlot):
        (JSC::ClonedArguments::getOwnPropertyNames):
        (JSC::ClonedArguments::put):
        (JSC::ClonedArguments::deleteProperty):
        (JSC::ClonedArguments::defineOwnProperty):
        (JSC::ClonedArguments::materializeSpecials):
        (JSC::ClonedArguments::materializeSpecialsIfNecessary):
        * runtime/ClonedArguments.h: Added.
        (JSC::ClonedArguments::specialsMaterialized):
        * runtime/ScopeOffset.cpp: Added.
        (JSC::ScopeOffset::dump):
        * runtime/ScopeOffset.h: Added.
        (JSC::ScopeOffset::ScopeOffset):
        * runtime/ScopedArguments.cpp: Added.
        (JSC::ScopedArguments::ScopedArguments):
        (JSC::ScopedArguments::finishCreation):
        (JSC::ScopedArguments::createUninitialized):
        (JSC::ScopedArguments::create):
        (JSC::ScopedArguments::createByCopying):
        (JSC::ScopedArguments::createByCopyingFrom):
        (JSC::ScopedArguments::visitChildren):
        (JSC::ScopedArguments::createStructure):
        (JSC::ScopedArguments::overrideThings):
        (JSC::ScopedArguments::overrideThingsIfNecessary):
        (JSC::ScopedArguments::overrideArgument):
        (JSC::ScopedArguments::copyToArguments):
        * runtime/ScopedArguments.h: Added.
        (JSC::ScopedArguments::internalLength):
        (JSC::ScopedArguments::length):
        (JSC::ScopedArguments::canAccessIndexQuickly):
        (JSC::ScopedArguments::getIndexQuickly):
        (JSC::ScopedArguments::setIndexQuickly):
        (JSC::ScopedArguments::callee):
        (JSC::ScopedArguments::overrodeThings):
        (JSC::ScopedArguments::offsetOfOverrodeThings):
        (JSC::ScopedArguments::offsetOfTotalLength):
        (JSC::ScopedArguments::offsetOfTable):
        (JSC::ScopedArguments::offsetOfScope):
        (JSC::ScopedArguments::overflowStorageOffset):
        (JSC::ScopedArguments::allocationSize):
        (JSC::ScopedArguments::overflowStorage):
        * runtime/ScopedArgumentsTable.cpp: Added.
        (JSC::ScopedArgumentsTable::ScopedArgumentsTable):
        (JSC::ScopedArgumentsTable::~ScopedArgumentsTable):
        (JSC::ScopedArgumentsTable::destroy):
        (JSC::ScopedArgumentsTable::create):
        (JSC::ScopedArgumentsTable::clone):
        (JSC::ScopedArgumentsTable::setLength):
        (JSC::ScopedArgumentsTable::set):
        (JSC::ScopedArgumentsTable::createStructure):
        * runtime/ScopedArgumentsTable.h: Added.
        (JSC::ScopedArgumentsTable::length):
        (JSC::ScopedArgumentsTable::get):
        (JSC::ScopedArgumentsTable::lock):
        (JSC::ScopedArgumentsTable::offsetOfLength):
        (JSC::ScopedArgumentsTable::offsetOfArguments):
        (JSC::ScopedArgumentsTable::at):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTableEntry::prepareToWatch):
        (JSC::SymbolTable::SymbolTable):
        (JSC::SymbolTable::visitChildren):
        (JSC::SymbolTable::localToEntry):
        (JSC::SymbolTable::entryFor):
        (JSC::SymbolTable::cloneScopePart):
        (JSC::SymbolTable::prepareForTypeProfiling):
        (JSC::SymbolTable::uniqueIDForOffset):
        (JSC::SymbolTable::globalTypeSetForOffset):
        (JSC::SymbolTable::cloneCapturedNames): Deleted.
        (JSC::SymbolTable::uniqueIDForRegister): Deleted.
        (JSC::SymbolTable::globalTypeSetForRegister): Deleted.
        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::varOffsetFromBits):
        (JSC::SymbolTableEntry::scopeOffsetFromBits):
        (JSC::SymbolTableEntry::Fast::varOffset):
        (JSC::SymbolTableEntry::Fast::scopeOffset):
        (JSC::SymbolTableEntry::Fast::isDontEnum):
        (JSC::SymbolTableEntry::Fast::getAttributes):
        (JSC::SymbolTableEntry::SymbolTableEntry):
        (JSC::SymbolTableEntry::varOffset):
        (JSC::SymbolTableEntry::isWatchable):
        (JSC::SymbolTableEntry::scopeOffset):
        (JSC::SymbolTableEntry::setAttributes):
        (JSC::SymbolTableEntry::constantMode):
        (JSC::SymbolTableEntry::isDontEnum):
        (JSC::SymbolTableEntry::disableWatching):
        (JSC::SymbolTableEntry::pack):
        (JSC::SymbolTableEntry::isValidVarOffset):
        (JSC::SymbolTable::createNameScopeTable):
        (JSC::SymbolTable::maxScopeOffset):
        (JSC::SymbolTable::didUseScopeOffset):
        (JSC::SymbolTable::didUseVarOffset):
        (JSC::SymbolTable::scopeSize):
        (JSC::SymbolTable::nextScopeOffset):
        (JSC::SymbolTable::takeNextScopeOffset):
        (JSC::SymbolTable::add):
        (JSC::SymbolTable::set):
        (JSC::SymbolTable::argumentsLength):
        (JSC::SymbolTable::setArgumentsLength):
        (JSC::SymbolTable::argumentOffset):
        (JSC::SymbolTable::setArgumentOffset):
        (JSC::SymbolTable::arguments):
        (JSC::SlowArgument::SlowArgument): Deleted.
        (JSC::SymbolTableEntry::Fast::getIndex): Deleted.
        (JSC::SymbolTableEntry::getIndex): Deleted.
        (JSC::SymbolTableEntry::isValidIndex): Deleted.
        (JSC::SymbolTable::captureStart): Deleted.
        (JSC::SymbolTable::setCaptureStart): Deleted.
        (JSC::SymbolTable::captureEnd): Deleted.
        (JSC::SymbolTable::setCaptureEnd): Deleted.
        (JSC::SymbolTable::captureCount): Deleted.
        (JSC::SymbolTable::isCaptured): Deleted.
        (JSC::SymbolTable::parameterCount): Deleted.
        (JSC::SymbolTable::parameterCountIncludingThis): Deleted.
        (JSC::SymbolTable::setParameterCountIncludingThis): Deleted.
        (JSC::SymbolTable::slowArguments): Deleted.
        (JSC::SymbolTable::setSlowArguments): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * runtime/VarOffset.cpp: Added.
        (JSC::VarOffset::dump):
        (WTF::printInternal):
        * runtime/VarOffset.h: Added.
        (JSC::VarOffset::VarOffset):
        (JSC::VarOffset::assemble):
        (JSC::VarOffset::isValid):
        (JSC::VarOffset::operator!):
        (JSC::VarOffset::kind):
        (JSC::VarOffset::isStack):
        (JSC::VarOffset::isScope):
        (JSC::VarOffset::isDirectArgument):
        (JSC::VarOffset::stackOffsetUnchecked):
        (JSC::VarOffset::scopeOffsetUnchecked):
        (JSC::VarOffset::capturedArgumentsOffsetUnchecked):
        (JSC::VarOffset::stackOffset):
        (JSC::VarOffset::scopeOffset):
        (JSC::VarOffset::capturedArgumentsOffset):
        (JSC::VarOffset::rawOffset):
        (JSC::VarOffset::checkSanity):
        (JSC::VarOffset::operator==):
        (JSC::VarOffset::operator!=):
        (JSC::VarOffset::hash):
        (JSC::VarOffset::isHashTableDeletedValue):
        (JSC::VarOffsetHash::hash):
        (JSC::VarOffsetHash::equal):
        * tests/stress/arguments-exit-strict-mode.js: Added.
        * tests/stress/arguments-exit.js: Added.
        * tests/stress/arguments-inlined-exit-strict-mode-fixed.js: Added.
        * tests/stress/arguments-inlined-exit-strict-mode.js: Added.
        * tests/stress/arguments-inlined-exit.js: Added.
        * tests/stress/arguments-interference.js: Added.
        * tests/stress/arguments-interference-cfg.js: Added.
        * tests/stress/dead-get-closure-var.js: Added.
        * tests/stress/get-declared-unpassed-argument-in-direct-arguments.js: Added.
        * tests/stress/get-declared-unpassed-argument-in-scoped-arguments.js: Added.
        * tests/stress/varargs-closure-inlined-exit-strict-mode.js: Added.
        * tests/stress/varargs-closure-inlined-exit.js: Added.
        * tests/stress/varargs-exit.js: Added.
        * tests/stress/varargs-inlined-exit.js: Added.
        * tests/stress/varargs-inlined-simple-exit-aliasing-weird-reversed-args.js: Added.
        * tests/stress/varargs-inlined-simple-exit-aliasing-weird.js: Added.
        * tests/stress/varargs-inlined-simple-exit-aliasing.js: Added.
        * tests/stress/varargs-inlined-simple-exit.js: Added.
        * tests/stress/varargs-too-few-arguments.js: Added.
        * tests/stress/varargs-varargs-closure-inlined-exit.js: Added.
        * tests/stress/varargs-varargs-inlined-exit-strict-mode.js: Added.
        * tests/stress/varargs-varargs-inlined-exit.js: Added.

2015-03-25  Andy Estes  <aestes@apple.com>

        [Cocoa] RemoteInspectorXPCConnection::deserializeMessage() leaks a NSDictionary under Objective-C GC
        https://bugs.webkit.org/show_bug.cgi?id=143068

        Reviewed by Dan Bernstein.

        * inspector/remote/RemoteInspectorXPCConnection.mm:
        (Inspector::RemoteInspectorXPCConnection::deserializeMessage): Used RetainPtr::autorelease(), which does the right thing under GC.

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Use JITCompilationCanFail in more places, and make the fail path of JITCompilationMustSucceed a crash instead of attempting GC
        https://bugs.webkit.org/show_bug.cgi?id=142993

        Reviewed by Geoffrey Garen and Mark Lam.
        
        This changes the most commonly invoked paths that relied on JITCompilationMustSucceed
        into using JITCompilationCanFail and having a legit fallback path. This mostly involves
        having the FTL JIT do the same trick as the DFG JIT in case of any memory allocation
        failure, but also involves adding the same kind of thing to the stub generators in
        Repatch.
        
        Because of that change, there are relatively few uses of JITCompilationMustSucceed. Most
        of those uses cannot handle a GC, and so cannot do releaseExecutableMemory(). Only a few,
        like host call stub generation, could handle a GC, but those get invoked very rarely. So,
        this patch changes the releaseExecutableMemory() call into a crash with some diagnostic
        printout.
        
        Also add a way of inducing executable allocation failure, so that we can test this.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::link): Deleted.
        (JSC::DFG::JITCompiler::linkFunction): Deleted.
        * dfg/DFGJITCompiler.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateCodeSection):
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLState.h:
        * jit/ArityCheckFailReturnThunks.cpp:
        (JSC::ArityCheckFailReturnThunks::returnPCsFor):
        * jit/ExecutableAllocationFuzz.cpp: Added.
        (JSC::numberOfExecutableAllocationFuzzChecks):
        (JSC::doExecutableAllocationFuzzing):
        * jit/ExecutableAllocationFuzz.h: Added.
        (JSC::doExecutableAllocationFuzzingIfEnabled):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::ExecutableAllocator::allocate):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITCompilationEffort.h:
        * jit/Repatch.cpp:
        (JSC::generateByIdStub):
        (JSC::tryCacheGetByID):
        (JSC::tryBuildGetByIDList):
        (JSC::emitPutReplaceStub):
        (JSC::emitPutTransitionStubAndGetOldStructure):
        (JSC::tryCachePutByID):
        (JSC::tryBuildPutByIdList):
        (JSC::tryRepatchIn):
        (JSC::linkPolymorphicCall):
        * jsc.cpp:
        (jscmain):
        * runtime/Options.h:
        * runtime/TestRunnerUtils.h:
        * runtime/VM.cpp:
        * tests/executableAllocationFuzz: Added.
        * tests/executableAllocationFuzz.yaml: Added.
        * tests/executableAllocationFuzz/v8-raytrace.js: Added.

2015-03-25  Mark Lam  <mark.lam@apple.com>

        REGRESSION(169139): LLINT intermittently fails JSC testapi tests.
        <https://webkit.org/b/135719>

        Reviewed by Geoffrey Garen.

        This is a regression introduced in http://trac.webkit.org/changeset/169139 which
        changed VM::watchdog from an embedded field into a std::unique_ptr, but did not
        update the LLINT to access it as such.

        The issue has only manifested so far on the CLoop tests because those are LLINT
        only.  In the non-CLoop cases, the JIT kicks in and does the right thing, thereby
        hiding the bug in the LLINT.

        * API/JSContextRef.cpp:
        (createWatchdogIfNeeded):
        (JSContextGroupSetExecutionTimeLimit):
        (JSContextGroupClearExecutionTimeLimit):
        * llint/LowLevelInterpreter.asm:

2015-03-25  Filip Pizlo  <fpizlo@apple.com>

        Change Atomic methods from using the_wrong_naming_conventions to using theRightNamingConventions. Also make seq_cst the default.

        Rubber stamped by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitAggregate):

2015-03-25  Joseph Pecoraro  <pecoraro@apple.com>

        Fix formatting in BuiltinExecutables
        https://bugs.webkit.org/show_bug.cgi?id=143061

        Reviewed by Ryosuke Niwa.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createExecutableInternal):

2015-03-25  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Classes: Program level class statement throws exception in strict mode
        https://bugs.webkit.org/show_bug.cgi?id=143038

        Reviewed by Ryosuke Niwa.

        Classes expose a name to the current lexical environment. This treats
        "class X {}" like "var X = class X {}". Ideally it would be "let X = class X {}".
        Also, improve error messages for class statements where the class is missing a name.

        * parser/Parser.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        Fill name in info parameter if needed. Better error message if name is needed and missing.

        (JSC::Parser<LexerType>::parseClassDeclaration):
        Pass info parameter to get name, and expose the name as a variable name.

        (JSC::Parser<LexerType>::parsePrimaryExpression):
        Pass info parameter that is ignored.

        * parser/ParserFunctionInfo.h:
        Add a parser info for class, to extract the name.

2015-03-25  Yusuke Suzuki  <utatane.tea@gmail.com>

        New map and set modification tests in r181922 fails
        https://bugs.webkit.org/show_bug.cgi?id=143031

        Reviewed and tweaked by Geoffrey Garen.

        When packing Map/Set backing store, we need to decrement Map/Set iterator's m_index
        to adjust for the packed backing store.

        Consider the following map data.

        x: deleted, o: exists
        0 1 2 3 4
        x x x x o

        And iterator with m_index 3.

        When packing the map data, map data will become,

        0
        o

        At that time, we perfom didRemoveEntry 4 times on iterators.
        times => m_index/index/result
        1 => 3/0/dec
        2 => 2/1/dec
        3 => 1/2/nothing
        4 => 1/3/nothing

        After iteration, iterator's m_index becomes 1. But we expected that becomes 0.
        This is because if we use decremented m_index for comparison,
        while provided deletedIndex is the index in old storage, m_index is the index in partially packed storage.

        In this patch, we compare against the packed index instead.
        times => m_index/packedIndex/result
        1 => 3/0/dec
        2 => 2/0/dec
        3 => 1/0/dec
        4 => 0/0/nothing

        So m_index becomes 0 as expected.

        And according to the spec, once the iterator is closed (becomes done: true),
        its internal [[Map]]/[[Set]] is set to undefined.
        So after the iterator is finished, we don't revive the iterator (e.g. by clearing m_index = 0).

        In this patch, we change 2 things.
        1.
        Compare an iterator's index against the packed index when removing an entry.

        2.
        If the iterator is closed (isFinished()), we don't apply adjustment to the iterator.

        * runtime/MapData.h:
        (JSC::MapDataImpl::IteratorData::finish):
        (JSC::MapDataImpl::IteratorData::isFinished):
        (JSC::MapDataImpl::IteratorData::didRemoveEntry):
        (JSC::MapDataImpl::IteratorData::didRemoveAllEntries):
        (JSC::MapDataImpl::IteratorData::startPackBackingStore):
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::replaceAndPackBackingStore):
        * tests/stress/modify-map-during-iteration.js:
        * tests/stress/modify-set-during-iteration.js:

2015-03-24  Joseph Pecoraro  <pecoraro@apple.com>

        Setter should have a single formal parameter, Getter no parameters
        https://bugs.webkit.org/show_bug.cgi?id=142903

        Reviewed by Geoffrey Garen.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        Enforce no parameters for getters and a single parameter
        for setters, with informational error messages.

2015-03-24  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Classes: Early return in sub-class constructor results in returning undefined instead of instance
        https://bugs.webkit.org/show_bug.cgi?id=143012

        Reviewed by Ryosuke Niwa.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitReturn):
        Fix handling of "undefined" when returned from a Derived class. It was
        returning "undefined" when it should have returned "this".

2015-03-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r181458): Heap use-after-free in JSSetIterator destructor
        https://bugs.webkit.org/show_bug.cgi?id=142696

        Reviewed and tweaked by Geoffrey Garen.

        Before r142556, JSSetIterator::destroy was not defined.
        So accidentally MapData::const_iterator in JSSet was never destroyed.
        But it had non trivial destructor, decrementing MapData->m_iteratorCount.

        After r142556, JSSetIterator::destroy works.
        It correctly destruct MapData::const_iterator and m_iteratorCount partially works.
        But JSSetIterator::~JSSetIterator requires owned JSSet since it mutates MapData->m_iteratorCount.

        It is guaranteed that JSSet is live since JSSetIterator has a reference to JSSet
        and marks it in visitChildren (WriteBarrier<Unknown>).
        However, the order of destructions is not guaranteed in GC-ed system.

        Consider the following case,
        allocate JSSet and subsequently allocate JSSetIterator.
        And they resides in the separated MarkedBlock, <1> and <2>.

        JSSet<1> <- JSSetIterator<2>

        And after that, when performing GC, Marker decides that the above 2 objects are not marked.
        And Marker also decides MarkedBlocks <1> and <2> can be sweeped.

        First Sweeper sweep <1>, destruct JSSet<1> and free MarkedBlock<1>.
        Second Sweeper sweep <2>, attempt to destruct JSSetIterator<2>.
        However, JSSetIterator<2>'s destructor,
        JSSetIterator::~JSSetIterator requires live JSSet<1>, it causes use-after-free.

        In this patch, we introduce WeakGCMap into JSMap/JSSet to track live iterators.
        When packing the removed elements in JSSet/JSMap, we apply the change to all live
        iterators tracked by WeakGCMap.

        WeakGCMap can only track JSCell since they are managed by GC.
        So we drop JSSet/JSMap C++ style iterators. Instead of C++ style iterator, this patch
        introduces JS style iterator signatures into C++ class IteratorData.
        If we need to iterate over JSMap/JSSet, use JSSetIterator/JSMapIterator instead of using
        IteratorData directly.

        * runtime/JSMap.cpp:
        (JSC::JSMap::destroy):
        * runtime/JSMap.h:
        (JSC::JSMap::JSMap):
        (JSC::JSMap::begin): Deleted.
        (JSC::JSMap::end): Deleted.
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::destroy):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::next):
        (JSC::JSMapIterator::nextKeyValue):
        (JSC::JSMapIterator::iteratorData):
        (JSC::JSMapIterator::JSMapIterator):
        * runtime/JSSet.cpp:
        (JSC::JSSet::destroy):
        * runtime/JSSet.h:
        (JSC::JSSet::JSSet):
        (JSC::JSSet::begin): Deleted.
        (JSC::JSSet::end): Deleted.
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::destroy):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::next):
        (JSC::JSSetIterator::iteratorData):
        (JSC::JSSetIterator::JSSetIterator):
        * runtime/MapData.h:
        (JSC::MapDataImpl::IteratorData::finish):
        (JSC::MapDataImpl::IteratorData::isFinished):
        (JSC::MapDataImpl::shouldPack):
        (JSC::JSIterator>::MapDataImpl):
        (JSC::JSIterator>::KeyType::KeyType):
        (JSC::JSIterator>::IteratorData::IteratorData):
        (JSC::JSIterator>::IteratorData::next):
        (JSC::JSIterator>::IteratorData::ensureSlot):
        (JSC::JSIterator>::IteratorData::applyMapDataPatch):
        (JSC::JSIterator>::IteratorData::refreshCursor):
        (JSC::MapDataImpl::const_iterator::key): Deleted.
        (JSC::MapDataImpl::const_iterator::value): Deleted.
        (JSC::MapDataImpl::const_iterator::operator++): Deleted.
        (JSC::MapDataImpl::const_iterator::finish): Deleted.
        (JSC::MapDataImpl::const_iterator::atEnd): Deleted.
        (JSC::MapDataImpl::begin): Deleted.
        (JSC::MapDataImpl::end): Deleted.
        (JSC::MapDataImpl<Entry>::MapDataImpl): Deleted.
        (JSC::MapDataImpl<Entry>::clear): Deleted.
        (JSC::MapDataImpl<Entry>::KeyType::KeyType): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::internalIncrement): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::ensureSlot): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::const_iterator): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::~const_iterator): Deleted.
        (JSC::MapDataImpl<Entry>::const_iterator::operator): Deleted.
        (JSC::=): Deleted.
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::clear):
        (JSC::JSIterator>::find):
        (JSC::JSIterator>::contains):
        (JSC::JSIterator>::add):
        (JSC::JSIterator>::set):
        (JSC::JSIterator>::get):
        (JSC::JSIterator>::remove):
        (JSC::JSIterator>::replaceAndPackBackingStore):
        (JSC::JSIterator>::replaceBackingStore):
        (JSC::JSIterator>::ensureSpaceForAppend):
        (JSC::JSIterator>::visitChildren):
        (JSC::JSIterator>::copyBackingStore):
        (JSC::JSIterator>::applyMapDataPatch):
        (JSC::MapDataImpl<Entry>::find): Deleted.
        (JSC::MapDataImpl<Entry>::contains): Deleted.
        (JSC::MapDataImpl<Entry>::add): Deleted.
        (JSC::MapDataImpl<Entry>::set): Deleted.
        (JSC::MapDataImpl<Entry>::get): Deleted.
        (JSC::MapDataImpl<Entry>::remove): Deleted.
        (JSC::MapDataImpl<Entry>::replaceAndPackBackingStore): Deleted.
        (JSC::MapDataImpl<Entry>::replaceBackingStore): Deleted.
        (JSC::MapDataImpl<Entry>::ensureSpaceForAppend): Deleted.
        (JSC::MapDataImpl<Entry>::visitChildren): Deleted.
        (JSC::MapDataImpl<Entry>::copyBackingStore): Deleted.
        * runtime/MapPrototype.cpp:
        (JSC::mapProtoFuncForEach):
        * runtime/SetPrototype.cpp:
        (JSC::setProtoFuncForEach):
        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::forEach):
        * tests/stress/modify-map-during-iteration.js: Added.
        (testValue):
        (identityPairs):
        (.set if):
        (var):
        (set map):
        * tests/stress/modify-set-during-iteration.js: Added.
        (testValue):
        (set forEach):
        (set delete):

2015-03-24  Mark Lam  <mark.lam@apple.com>

        The ExecutionTimeLimit test should use its own JSGlobalContextRef.
        <https://webkit.org/b/143024>

        Reviewed by Geoffrey Garen.

        Currently, the ExecutionTimeLimit test is using a JSGlobalContextRef
        passed in from testapi.c.  It should create its own for better
        encapsulation of the test.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (currentCPUTimeAsJSFunctionCallback):
        (testExecutionTimeLimit):
        * API/tests/ExecutionTimeLimitTest.h:
        * API/tests/testapi.c:
        (main):

2015-03-24  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Object Literal Methods toString is missing method name
        https://bugs.webkit.org/show_bug.cgi?id=142992

        Reviewed by Geoffrey Garen.

        Always stringify functions in the pattern:

          "function " + <function name> + <text from opening parenthesis to closing brace>.

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        Update the path that was not stringifying in this pattern.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::parametersStartOffset):
        * parser/Nodes.h:
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::parametersStartOffset):
        Pass the already known function parameter opening parenthesis
        start offset through to the FunctionExecutable. 

        * tests/mozilla/js1_5/Scope/regress-185485.js:
        (with.g):
        Add back original space in this test that was removed by r181810
        now that we have the space again in stringification.

2015-03-24  Michael Saboff  <msaboff@apple.com>

        REGRESSION (172175-172177): Change in for...in processing causes properties added in loop to be enumerated
        https://bugs.webkit.org/show_bug.cgi?id=142856

        Reviewed by Filip Pizlo.

        Refactored the way the for .. in enumeration over objects is done.  We used to make three C++ calls to
        get info for three loops to iterate over indexed properties, structure properties and other properties,
        respectively.  We still have the three loops, but now we make one C++ call to get all the info needed
        for all loops before we exectue any enumeration.

        The JSPropertyEnumerator has a count of the indexed properties and a list of named properties.
        The named properties are one list, with structured properties in the range [0,m_endStructurePropertyIndex)
        and the generic properties in the range [m_endStructurePropertyIndex, m_endGenericPropertyIndex);

        Eliminated the bytecodes op_get_structure_property_enumerator, op_get_generic_property_enumerator and
        op_next_enumerator_pname.
        Added the bytecodes op_get_property_enumerator, op_enumerator_structure_pname and op_enumerator_generic_pname.
        The bytecodes op_enumerator_structure_pname and op_enumerator_generic_pname are similar except for what
        end value we stop iterating on.

        Made corresponding node changes to the DFG and FTL for the bytecode changes.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetPropertyEnumerator):
        (JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
        (JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
        (JSC::BytecodeGenerator::emitGetStructurePropertyEnumerator): Deleted.
        (JSC::BytecodeGenerator::emitGetGenericPropertyEnumerator): Deleted.
        (JSC::BytecodeGenerator::emitNextEnumeratorPropertyName): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitMultiLoopBytecode):
        * 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:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * 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/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumerableLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetPropertyEnumerator):
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorStructurePname):
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorGenericPname):
        (JSC::FTL::LowerDFGToLLVM::compileGetStructurePropertyEnumerator): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileGetGenericPropertyEnumerator): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorPname): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_get_property_enumerator):
        (JSC::JIT::emit_op_next_enumerator_pname): Deleted.
        (JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
        (JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_enumerator_structure_pname):
        (JSC::JIT::emit_op_enumerator_generic_pname):
        (JSC::JIT::emit_op_next_enumerator_pname): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::create):
        (JSC::JSPropertyNameEnumerator::finishCreation):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::JSPropertyNameEnumerator::indexedLength):
        (JSC::JSPropertyNameEnumerator::endStructurePropertyIndex):
        (JSC::JSPropertyNameEnumerator::endGenericPropertyIndex):
        (JSC::JSPropertyNameEnumerator::indexedLengthOffset):
        (JSC::JSPropertyNameEnumerator::endStructurePropertyIndexOffset):
        (JSC::JSPropertyNameEnumerator::endGenericPropertyIndexOffset):
        (JSC::JSPropertyNameEnumerator::cachedInlineCapacityOffset):
        (JSC::propertyNameEnumerator):
        (JSC::JSPropertyNameEnumerator::cachedPropertyNamesLengthOffset): Deleted.
        (JSC::structurePropertyNameEnumerator): Deleted.
        (JSC::genericPropertyNameEnumerator): Deleted.
        * runtime/Structure.cpp:
        (JSC::Structure::setCachedPropertyNameEnumerator):
        (JSC::Structure::cachedPropertyNameEnumerator):
        (JSC::Structure::canCachePropertyNameEnumerator):
        (JSC::Structure::setCachedStructurePropertyNameEnumerator): Deleted.
        (JSC::Structure::cachedStructurePropertyNameEnumerator): Deleted.
        (JSC::Structure::setCachedGenericPropertyNameEnumerator): Deleted.
        (JSC::Structure::cachedGenericPropertyNameEnumerator): Deleted.
        (JSC::Structure::canCacheStructurePropertyNameEnumerator): Deleted.
        (JSC::Structure::canCacheGenericPropertyNameEnumerator): Deleted.
        * runtime/Structure.h:
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::visitChildren):
        (JSC::StructureRareData::cachedPropertyNameEnumerator):
        (JSC::StructureRareData::setCachedPropertyNameEnumerator):
        (JSC::StructureRareData::cachedStructurePropertyNameEnumerator): Deleted.
        (JSC::StructureRareData::setCachedStructurePropertyNameEnumerator): Deleted.
        (JSC::StructureRareData::cachedGenericPropertyNameEnumerator): Deleted.
        (JSC::StructureRareData::setCachedGenericPropertyNameEnumerator): Deleted.
        * runtime/StructureRareData.h:
        * tests/stress/for-in-delete-during-iteration.js:

2015-03-24  Michael Saboff  <msaboff@apple.com>

        Unreviewed build fix for debug builds.

        * runtime/ExceptionHelpers.cpp:
        (JSC::invalidParameterInSourceAppender):

2015-03-24  Saam Barati  <saambarati1@gmail.com>

        Improve error messages in JSC
        https://bugs.webkit.org/show_bug.cgi?id=141869

        Reviewed by Geoffrey Garen.

        JavaScriptCore has some unintuitive error messages associated
        with certain common errors. This patch changes some specific
        error messages to be more understandable and also creates a
        mechanism that will allow for easy modification of error messages
        in the future. The specific errors we change are not a function
        errors and invalid parameter errors.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        * jit/JITOperations.cpp:
        op_throw_static_error always has a JSString as its argument.
        There is no need to dance around this, and we should assert
        that this always holds. This JSString represents the error 
        message we want to display to the user, so there is no need
        to pass it into errorDescriptionForValue which will now place
        quotes around the string.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::ErrorInstance):
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::hasSourceAppender):
        (JSC::ErrorInstance::sourceAppender):
        (JSC::ErrorInstance::setSourceAppender):
        (JSC::ErrorInstance::clearSourceAppender):
        (JSC::ErrorInstance::setRuntimeTypeForCause):
        (JSC::ErrorInstance::runtimeTypeForCause):
        (JSC::ErrorInstance::clearRuntimeTypeForCause):
        (JSC::ErrorInstance::appendSourceToMessage): Deleted.
        (JSC::ErrorInstance::setAppendSourceToMessage): Deleted.
        (JSC::ErrorInstance::clearAppendSourceToMessage): Deleted.
        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue):
        (JSC::defaultApproximateSourceError):
        (JSC::defaultSourceAppender):
        (JSC::functionCallBase):
        (JSC::notAFunctionSourceAppender):
        (JSC::invalidParameterInSourceAppender):
        (JSC::invalidParameterInstanceofSourceAppender):
        (JSC::createError):
        (JSC::createInvalidFunctionApplyParameterError):
        (JSC::createInvalidInParameterError):
        (JSC::createInvalidInstanceofParameterError):
        (JSC::createNotAConstructorError):
        (JSC::createNotAFunctionError):
        (JSC::createNotAnObjectError):
        (JSC::createInvalidParameterError): Deleted.
        * runtime/ExceptionHelpers.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):
        * runtime/RuntimeType.cpp: Added.
        (JSC::runtimeTypeForValue):
        (JSC::runtimeTypeAsString):
        * runtime/RuntimeType.h: Added.
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::getRuntimeTypeForValue): Deleted.
        * runtime/TypeSet.h:
        * runtime/VM.cpp:
        (JSC::appendSourceToError):
        (JSC::VM::throwException):

2015-03-23  Filip Pizlo  <fpizlo@apple.com>

        JSC should have a low-cost asynchronous disassembler
        https://bugs.webkit.org/show_bug.cgi?id=142997

        Reviewed by Mark Lam.
        
        This adds a JSC_asyncDisassembly option that disassembles on a thread. Disassembly
        doesn't block execution. Some code will live a little longer because of this, since the
        work tasks hold a ref to the code, but other than that there is basically no overhead.
        
        At present, this isn't really a replacement for JSC_showDisassembly, since it doesn't
        provide contextual IR information for Baseline and DFG disassemblies, and it doesn't do
        the separate IR dumps for FTL. Using JSC_showDisassembly and friends along with
        JSC_asyncDisassembly has bizarre behavior - so just choose one.
        
        A simple way of understanding how great this is, is to run a small benchmark like
        V8Spider/earley-boyer.
        
        Performance without any disassembly flags: 60ms
        Performance with JSC_showDisassembly=true: 477ms
        Performance with JSC_asyncDisassembly=true: 65ms
        
        So, the overhead of disassembly goes from 8x to 8%.
        
        Note that JSC_asyncDisassembly=true does make it incorrect to run "time" as a way of
        measuring benchmark performance. This is because at VM exit, we wait for all async
        disassembly requests to finish. For example, for earley-boyer, we spend an extra ~130ms
        after the benchmark completely finishes to finish the disassemblies. This small weirdness
        should be OK for the intended use-cases, since all you have to do to get around it is to
        measure the execution time of the benchmark payload rather than the end-to-end time of
        launching the VM.

        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::finalizeCodeWithDisassembly):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::wasAlreadyDisassembled):
        (JSC::LinkBuffer::didAlreadyDisassemble):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::disassemble):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        * disassembler/Disassembler.cpp:
        (JSC::disassembleAsynchronously):
        (JSC::waitForAsynchronousDisassembly):
        * disassembler/Disassembler.h:
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jsc.cpp:
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2015-03-23  Dean Jackson  <dino@apple.com>

        ES7: Implement Array.prototype.includes
        https://bugs.webkit.org/show_bug.cgi?id=142707

        Reviewed by Geoffrey Garen.

        Add support for the ES7 includes method on Arrays.
        https://github.com/tc39/Array.prototype.includes

        * builtins/Array.prototype.js:
        (includes): Implementation in JS.
        * runtime/ArrayPrototype.cpp: Add 'includes' to the lookup table.

2015-03-23  Joseph Pecoraro  <pecoraro@apple.com>

        __defineGetter__/__defineSetter__ should throw exceptions
        https://bugs.webkit.org/show_bug.cgi?id=142934

        Reviewed by Geoffrey Garen.

        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        Throw exceptions when these functions are used directly.

2015-03-23  Joseph Pecoraro  <pecoraro@apple.com>

        Fix DO_PROPERTYMAP_CONSTENCY_CHECK enabled build
        https://bugs.webkit.org/show_bug.cgi?id=142952

        Reviewed by Geoffrey Garen.

        * runtime/Structure.cpp:
        (JSC::PropertyTable::checkConsistency):
        The check offset method doesn't exist in PropertyTable, it exists in Structure.

        (JSC::Structure::checkConsistency):
        So move it here, and always put it at the start to match normal behavior.

2015-03-22  Filip Pizlo  <fpizlo@apple.com>

        Remove DFG::ValueRecoveryOverride; it's been dead since we removed forward speculations
        https://bugs.webkit.org/show_bug.cgi?id=142956

        Rubber stamped by Gyuyoung Kim.
        
        Just removing dead code.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGValueRecoveryOverride.h: Removed.

2015-03-22  Filip Pizlo  <fpizlo@apple.com>

        DFG OSR exit shouldn't assume that the frame count for exit is greater than the frame count in DFG
        https://bugs.webkit.org/show_bug.cgi?id=142948

        Reviewed by Sam Weinig.
        
        It's necessary to ensure that the stack pointer accounts for the extent of our stack usage
        since a signal may clobber the area below the stack pointer. When the DFG is executing,
        the stack pointer accounts for the DFG's worst-case stack usage. When we OSR exit back to
        baseline, we will use a different amount of stack. This is because baseline is a different
        compiler. It will make different decisions. So it will use a different amount of stack.
        
        This gets tricky when we are in the process of doing an OSR exit, because we are sort of
        incrementally transforming the stack from how it looked in the DFG to how it will look in
        baseline. The most conservative approach would be to set the stack pointer to the max of
        DFG and baseline.
        
        When this code was written, a reckless assumption was made: that the stack usage in
        baseline is always at least as large as the stack usage in DFG. Based on this incorrect
        assumption, the code first adjusts the stack pointer to account for the baseline stack
        usage. This sort of usually works, because usually baseline does happen to use more stack.
        But that's not an invariant. Nobody guarantees this. We will never make any changes that
        would make this be guaranteed, because that would be antithetical to how optimizing
        compilers work. The DFG should be allowed to use however much stack it decides that it
        should use in order to get good performance, and it shouldn't try to guarantee that it
        always uses less stack than baseline.
        
        As such, we must always assume that the frame size for DFG execution (i.e.
        frameRegisterCount) and the frame size in baseline once we exit (i.e.
        requiredRegisterCountForExit) are two independent quantities and they have no
        relationship.
        
        Fortunately, though, this code can be made correct by just moving the stack adjustment to
        just before we do conversions. This is because we have since changed the OSR exit
        algorithm to first lift up all state from the DFG state into a scratch buffer, and then to
        drop it out of the scratch buffer and into the stack according to the baseline layout. The
        point just before conversions is the point where we have finished reading the DFG frame
        and will not read it anymore, and we haven't started writing the baseline frame. So, at
        this point it is safe to set the stack pointer to account for the frame size at exit.
        
        This is benign because baseline happens to create larger frames than DFG.

        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::adjustAndJumpToTarget):

2015-03-22  Filip Pizlo  <fpizlo@apple.com>

        Shorten the number of iterations to 10,000 since that's enough to test all tiers.

        Rubber stamped by Sam Weinig.

        * tests/stress/equals-masquerader.js:

2015-03-22  Filip Pizlo  <fpizlo@apple.com>

        tests/stress/*tdz* tests do 10x more iterations than necessary
        https://bugs.webkit.org/show_bug.cgi?id=142946

        Reviewed by Ryosuke Niwa.
        
        The stress test harness runs all of these tests in various configurations. This includes
        no-cjit, which has tier-up heuristics locked in such a way that 10,000 iterations is
        enough to get to the highest tier. The only exceptions are very large functions or
        functions that have some reoptimizations. That happens rarely, and when it does happen,
        usually 20,000 iterations is enough.
        
        Therefore, these tests use 10x too many iterations. This is bad, since these tests
        allocate on each iteration, and so they run very slowly in debug mode.

        * tests/stress/class-syntax-no-loop-tdz.js:
        * tests/stress/class-syntax-no-tdz-in-catch.js:
        * tests/stress/class-syntax-no-tdz-in-conditional.js:
        * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js:
        * tests/stress/class-syntax-no-tdz-in-loop.js:
        * tests/stress/class-syntax-no-tdz.js:
        * tests/stress/class-syntax-tdz-in-catch.js:
        * tests/stress/class-syntax-tdz-in-conditional.js:
        * tests/stress/class-syntax-tdz-in-loop.js:
        * tests/stress/class-syntax-tdz.js:

2015-03-21  Joseph Pecoraro  <pecoraro@apple.com>

        Fix a typo in Parser error message
        https://bugs.webkit.org/show_bug.cgi?id=142942

        Reviewed by Alexey Proskuryakov.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_resolve_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitSlow_op_resolve_scope):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        Fix a common identifier typo.

2015-03-21  Joseph Pecoraro  <pecoraro@apple.com>

        Computed Property names should allow only AssignmentExpressions not any Expression
        https://bugs.webkit.org/show_bug.cgi?id=142902

        Reviewed by Ryosuke Niwa.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        Limit computed expressions to just assignment expressions instead of
        any expression (which allowed comma expressions).

2015-03-21  Andreas Kling  <akling@apple.com>

        Make UnlinkedFunctionExecutable fit in a 128-byte cell.
        <https://webkit.org/b/142939>

        Reviewed by Mark Hahnenberg.

        Re-arrange the members of UnlinkedFunctionExecutable so it can fit inside
        a 128-byte heap cell instead of requiring a 256-byte one.

        Threw in a static_assert to catch anyone pushing it over the limit again.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::functionMode):

2015-03-20  Mark Hahnenberg  <mhahnenb@gmail.com>

        GCTimer should know keep track of nested GC phases
        https://bugs.webkit.org/show_bug.cgi?id=142675

        Reviewed by Darin Adler.

        This improves the GC phase timing output in Heap.cpp by linking
        phases nested inside other phases together, allowing tools
        to compute how much time we're spending in various nested phases.

        * heap/Heap.cpp:

2015-03-20  Geoffrey Garen  <ggaren@apple.com>

        FunctionBodyNode should known where its parameters started
        https://bugs.webkit.org/show_bug.cgi?id=142926

        Reviewed by Ryosuke Niwa.

        This will allow us to re-parse parameters instead of keeping the
        parameters piece of the AST around forever.

        I also took the opportunity to initialize most FunctionBodyNode data
        members at construction time, to help clarify that they are set right.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr): No need to pass
        functionKeywordStart here; we now provide it at FunctionBodyNode
        creation time.

        (JSC::ASTBuilder::createFunctionBody): Require everything we need at
        construction time, including the start of our parameters.

        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createFuncDeclStatement):  No need to pass
        functionKeywordStart here; we now provide it at FunctionBodyNode
        creation time.

        (JSC::ASTBuilder::setFunctionNameStart): Deleted.

        * parser/Nodes.cpp:
        (JSC::FunctionBodyNode::FunctionBodyNode): Initialize everything at
        construction time.

        * parser/Nodes.h: Added a field for the location of our parameters.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h: Refactored to match above interface changes.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionBody):
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createGetterOrSetterProperty): Refactored to match
        above interface changes.

        (JSC::SyntaxChecker::setFunctionNameStart): Deleted.

2015-03-20  Filip Pizlo  <fpizlo@apple.com>

        Observably effectful nodes in DFG IR should come last in their bytecode instruction (i.e. forExit section), except for Hint nodes
        https://bugs.webkit.org/show_bug.cgi?id=142920

        Reviewed by Oliver Hunt, Geoffrey Garen, and Mark Lam.
        
        Observably effectful, n.: If we reexecute the bytecode instruction after this node has
        executed, then something other than the bytecode instruction's specified outcome will
        happen.

        We almost never had observably effectful nodes except at the end of the bytecode
        instruction.  The exception is a lowered transitioning PutById:

        PutStructure(@o, S1 -> S2)
        PutByOffset(@o, @o, @v)

        The PutStructure is observably effectful: if you try to reexecute the bytecode after
        doing the PutStructure, then we'll most likely crash.  The generic PutById handling means
        first checking what the old structure of the object is; but if we reexecute, the old
        structure will seem to be the new structure.  But the property ensured by the new
        structure hasn't been stored yet, so any attempt to load it or scan it will crash.

        Intriguingly, however, none of the other operations involved in the PutById are
        observably effectful.  Consider this example:

        PutByOffset(@o, @o, @v)
        PutStructure(@o, S1 -> S2)

        Note that the PutStructure node doesn't reallocate property storage; see further below
        for an example that does that. Because no property storage is happening, we know that we
        already had room for the new property.  This means that the PutByOffset is no observable
        until the PutStructure executes and "reveals" the property.  Hence, PutByOffset is not
        observably effectful.

        Now consider this:

        b: AllocatePropertyStorage(@o)
        PutByOffset(@b, @o, @v)
        PutStructure(@o, S1 -> S2)

        Surprisingly, this is also safe, because the AllocatePropertyStorage is not observably
        effectful. It *does* reallocate the property storage and the new property storage pointer
        is stored into the object. But until the PutStructure occurs, the world will just think
        that the reallocation didn't happen, in the sense that we'll think that the property
        storage is using less memory than what we just allocated. That's harmless.

        The AllocatePropertyStorage is safe in other ways, too. Even if we GC'd after the
        AllocatePropertyStorage but before the PutByOffset (or before the PutStructure),
        everything could be expected to be fine, so long as all of @o, @v and @b are on the
        stack. If they are all on the stack, then the GC will leave the property storage alone
        (so the extra memory we just allocated would be safe). The GC will not scan the part of
        the property storage that contains @v, but that's fine, so long as @v is on the stack.
        
        The better long-term solution is probably bug 142921.
        
        But for now, this:
        
        - Fixes an object materialization bug, exemplified by the two tests, that previously
          crashed 100% of the time with FTL enabled and concurrent JIT disabled.
        
        - Allows us to remove the workaround introduced in r174856.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::insertCheck):
        (JSC::DFG::FixupPhase::indexOfNode): Deleted.
        (JSC::DFG::FixupPhase::indexOfFirstNodeOfExitOrigin): Deleted.
        * dfg/DFGInsertionSet.h:
        (JSC::DFG::InsertionSet::insertOutOfOrder): Deleted.
        (JSC::DFG::InsertionSet::insertOutOfOrderNode): Deleted.
        * tests/stress/materialize-past-butterfly-allocation.js: Added.
        (bar):
        (foo0):
        (foo1):
        (foo2):
        (foo3):
        (foo4):
        * tests/stress/materialize-past-put-structure.js: Added.
        (foo):

2015-03-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION (r179429): Potential Use after free in JavaScriptCore`WTF::StringImpl::ref + 83
        https://bugs.webkit.org/show_bug.cgi?id=142410

        Reviewed by Geoffrey Garen.

        Before this patch, added function JSValue::toPropertyKey returns PropertyName.
        Since PropertyName doesn't have AtomicStringImpl ownership,
        if Identifier is implicitly converted to PropertyName and Identifier is destructed,
        PropertyName may refer freed AtomicStringImpl*.

        This patch changes the result type of JSValue::toPropertyName from PropertyName to Identifier,
        to keep AtomicStringImpl* ownership after the toPropertyName call is done.
        And receive the result value as Identifier type to keep ownership in the caller side.

        To catch the result of toPropertyKey as is, we catch the result of toPropertyName as auto.

        However, now we don't need to have both Identifier and PropertyName.
        So we'll merge PropertyName to Identifier in the subsequent patch.

        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getByVal):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::toPropertyKey):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncPropertyIsEnumerable):

2015-03-18  Geoffrey Garen  <ggaren@apple.com>

        Function.prototype.toString should not decompile the AST
        https://bugs.webkit.org/show_bug.cgi?id=142853

        Reviewed by Sam Weinig.

        To recover the function parameter string, Function.prototype.toString
        decompiles the function parameters from the AST. This is bad for a few
        reasons:

        (1) It requires us to keep pieces of the AST live forever. This is an
        awkward design and a waste of memory.

        (2) It doesn't match Firefox or Chrome (because it changes whitespace
        and ES6 destructuring expressions).

        (3) It doesn't scale to ES6 default argument parameters, which require
        arbitrarily complex decompilation.

        (4) It can counterfeit all the line numbers in a function (because
        whitespace can include newlines).

        (5) It's expensive, and we've seen cases where websites invoke
        Function.prototype.toString a lot by accident.

        The fix is to do what we do for the rest of the function: Just quote the
        original source text.

        Since this change inevitably changes some function stringification, I
        took the opportunity to make our stringification match Firefox's and
        Chrome's.

        * API/tests/testapi.c:
        (assertEqualsAsUTF8String): Be more informative when this fails.

        (main): Updated to match new stringification rules.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::paramString): Deleted. Yay!
        * bytecode/UnlinkedCodeBlock.h:

        * parser/Nodes.h:
        (JSC::StatementNode::isFuncDeclNode): New helper for constructing
        anonymous functions.

        * parser/SourceCode.h:
        (JSC::SourceCode::SourceCode): Allow zero because WebCore wants it.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Updated for use
        of function declaration over function expression.

        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::paramString): Deleted. Yay!
        * runtime/Executable.h:
        (JSC::FunctionExecutable::parameterCount):

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck): Added a newline after
        the opening brace to match Firefox and Chrome, and a space after the comma
        to match Firefox and WebKit coding style. Added the function name to
        the text of the function so it would look right when stringify-ing. Switched
        from parentheses to braces to produce a function declaration instead of
        a function expression because we are required to exclude the function's
        name from its scope, and that's what a function declaration does.

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString): Removed an old workaround because the
        library it worked around doesn't really exist anymore, and the behavior
        doesn't match Firefox or Chrome. Use type profiling offsets instead of
        function body offsets because we want to include the function name and
        the parameter string, rather than stitching them in manually by
        decompiling the AST.

        (JSC::insertSemicolonIfNeeded): Deleted.

        * tests/mozilla/js1_2/function/tostring-1.js:
        * tests/mozilla/js1_5/Scope/regress-185485.js:
        (with.g): Updated these test results for formatting changes.

2015-03-20  Joseph Pecoraro  <pecoraro@apple.com>

        SyntaxChecker assertion is trapped with computed property name and getter
        https://bugs.webkit.org/show_bug.cgi?id=142863

        Reviewed by Ryosuke Niwa.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::getName):
        Remove invalid assert. Computed properties will not have a name
        and the calling code is checking for null expecting it. The
        AST path (non-CheckingPath) already does this without the assert
        so it is well tested.

2015-03-19  Mark Lam  <mark.lam@apple.com>

        JSCallbackObject<JSGlobalObject> should not destroy its JSCallbackObjectData before all its finalizers have been called.
        <https://webkit.org/b/142846>

        Reviewed by Geoffrey Garen.

        Currently, JSCallbackObject<JSGlobalObject> registers weak finalizers via 2 mechanisms:
        1. JSCallbackObject<Parent>::init() registers a weak finalizer for all JSClassRef
           that a JSCallbackObject references.
        2. JSCallbackObject<JSGlobalObject>::create() registers a finalizer via
           vm.heap.addFinalizer() which destroys the JSCallbackObject.

        The first finalizer is implemented as a virtual function of a JSCallbackObjectData
        instance that will be destructed if the 2nd finalizer is called.  Hence, if the
        2nd finalizer if called first, the later invocation of the 1st finalizer will
        result in a crash.

        This patch fixes the issue by eliminating the finalizer registration in init().
        Instead, we'll have the JSCallbackObject destructor call all the JSClassRef finalizers
        if needed.  This ensures that these finalizers are called before the JSCallbackObject
        is destructor.

        Also added assertions to a few Heap functions because JSCell::classInfo() expects
        all objects that are allocated from MarkedBlock::Normal blocks to be derived from
        JSDestructibleObject.  These assertions will help us catch violations of this
        expectation earlier.

        * API/JSCallbackObject.cpp:
        (JSC::JSCallbackObjectData::finalize): Deleted.
        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::~JSCallbackObjectData):
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
        (JSC::JSCallbackObject<Parent>::init):
        * API/tests/GlobalContextWithFinalizerTest.cpp: Added.
        (finalize):
        (testGlobalContextWithFinalizer):
        * API/tests/GlobalContextWithFinalizerTest.h: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/HeapInlines.h:
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):

2015-03-19  Andreas Kling  <akling@apple.com>

        JSCallee unnecessarily overrides a bunch of things in the method table.
        <https://webkit.org/b/142855>

        Reviewed by Geoffrey Garen.

        Remove JSCallee method table overrides that simply call to base class.
        This makes JSFunction property slot lookups slightly more efficient since
        they can take the fast path when passing over JSCallee in the base class chain.

        * runtime/JSCallee.cpp:
        (JSC::JSCallee::getOwnPropertySlot): Deleted.
        (JSC::JSCallee::getOwnNonIndexPropertyNames): Deleted.
        (JSC::JSCallee::put): Deleted.
        (JSC::JSCallee::deleteProperty): Deleted.
        (JSC::JSCallee::defineOwnProperty): Deleted.
        * runtime/JSCallee.h:

2015-03-19  Andreas Kling  <akling@apple.com>

        DFGAllocator should use bmalloc's aligned allocator.
        <https://webkit.org/b/142871>

        Reviewed by Geoffrey Garen.

        Switch DFGAllocator to using bmalloc through fastAlignedMalloc().

        * dfg/DFGAllocator.h:
        (JSC::DFG::Allocator<T>::allocateSlow):
        (JSC::DFG::Allocator<T>::freeRegionsStartingAt):
        * heap/CopiedSpace.h:
        * heap/MarkedBlock.h:
        * heap/MarkedSpace.h:

2015-03-18  Joseph Pecoraro  <pecoraro@apple.com>

        ES6 Classes: Extends should accept an expression without parenthesis
        https://bugs.webkit.org/show_bug.cgi?id=142840

        Reviewed by Ryosuke Niwa.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        "extends" allows a LeftHandExpression (new expression / call expression,
        which includes a member expression), not a primary expression. Our
        parseMemberExpression does all of these.

2015-03-18  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Debugger Popovers and Probes should use FormattedValue/ObjectTreeView instead of Custom/ObjectPropertiesSection
        https://bugs.webkit.org/show_bug.cgi?id=142830

        Reviewed by Timothy Hatcher.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        Give Probe Samples object previews.

2015-03-17  Ryuan Choi  <ryuan.choi@navercorp.com>

        [EFL] Expose JavaScript binding interface through ewk_extension
        https://bugs.webkit.org/show_bug.cgi?id=142033

        Reviewed by Gyuyoung Kim.

        * PlatformEfl.cmake: Install Javascript APIs.

2015-03-17  Geoffrey Garen  <ggaren@apple.com>

        Function bodies should always include braces
        https://bugs.webkit.org/show_bug.cgi?id=142795

        Reviewed by Michael Saboff.

        Having a mode for excluding the opening and closing braces from a function
        body was unnecessary and confusing.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock): Adopt the new one true linking function.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::link):
        (JSC::UnlinkedFunctionExecutable::codeBlockFor): No need to pass through
        a boolean: there is only one kind of function now.

        (JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Deleted.
        (JSC::UnlinkedFunctionExecutable::linkGlobalCode): Deleted. Let's only
        have one way to do things. This removes the old mode that would pretend
        that a function always started at column 1. That pretense was not true:
        an attribute event listener does not necessarily start at column 1.

        * bytecode/UnlinkedCodeBlock.h:
        * generate-js-builtins: Adopt the new one true linking function.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        (JSC::parse): needsReparsingAdjustment is always true now, so I removed it.

        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::ProgramExecutable::initializeGlobalProperties):
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::create):
        (JSC::FunctionExecutable::bodyIncludesBraces): Deleted. Removed unused stuff.

        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck): Always provide a
        leading space because that's what this function's comment says is required
        for web compatibility. We used to fake this up after the fact when
        stringifying, based on the bodyIncludesBraces flag, but that flag is gone now.

        * runtime/FunctionPrototype.cpp:
        (JSC::insertSemicolonIfNeeded):
        (JSC::functionProtoFuncToString): No need to add braces and/or a space
        after the fact -- we always have them now.

2015-03-17  Mark Lam  <mark.lam@apple.com>

        Refactor execution time limit tests out of testapi.c.
        <https://webkit.org/b/142798>

        Rubber stamped by Michael Saboff.

        These tests were sometimes failing to time out on C loop builds.  Let's
        refactor them out of the big monolith that is testapi.c so that we can
        reason more easily about them and make adjustments if needed.

        * API/tests/ExecutionTimeLimitTest.cpp: Added.
        (currentCPUTime):
        (currentCPUTimeAsJSFunctionCallback):
        (shouldTerminateCallback):
        (cancelTerminateCallback):
        (extendTerminateCallback):
        (testExecutionTimeLimit):
        * API/tests/ExecutionTimeLimitTest.h: Added.
        * API/tests/testapi.c:
        (main):
        (currentCPUTime): Deleted.
        (currentCPUTime_callAsFunction): Deleted.
        (shouldTerminateCallback): Deleted.
        (cancelTerminateCallback): Deleted.
        (extendTerminateCallback): Deleted.
        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-03-17  Geoffrey Garen  <ggaren@apple.com>

        Built-in functions should know that they use strict mode
        https://bugs.webkit.org/show_bug.cgi?id=142788

        Reviewed by Mark Lam.

        Even though all of our builtin functions use strict mode, the parser
        thinks that they don't. This is because Executable::toStrictness treats
        builtin-ness and strict-ness as mutually exclusive.

        The fix is to disambiguate builtin-ness from strict-ness.

        This bug is currently unobservable because of some other parser bugs. But
        it causes lots of test failures once those other bugs are fixed.

        * API/JSScriptRef.cpp:
        (parseScript):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createBuiltinExecutable): Adopt the new API
        for a separate value to indicate builtin-ness vs strict-ness.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::codeBlockFor): Ditto.

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::toStrictness): Deleted. This function
        was misleading since it pretended that no builtin function was ever
        strict, which is the opposite of true.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer):
        * parser/Lexer.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        * parser/Parser.h:
        (JSC::parse): Adopt the new API.

        * parser/ParserModes.h: Added JSParserBuiltinMode, and tried to give
        existing modes clearer names.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Adopt the new API.

        * runtime/CodeCache.h:
        (JSC::SourceCodeKey::SourceCodeKey): Be sure to treat strict-ness and
        bulitin-ness as separate pieces of the code cache key. We would not want
        a user function to match a built-in function in the cache, even if they
        agreed about strictness, since builtin functions have different lexing
        rules.

        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::create):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock): Adopt the new API.

2015-03-16  Filip Pizlo  <fpizlo@apple.com>

        DFG IR shouldn't have a separate node for every kind of put hint that could be described using PromotedLocationDescriptor
        https://bugs.webkit.org/show_bug.cgi?id=142769

        Reviewed by Michael Saboff.
        
        When we sink an object allocation, we need to have some way of tracking what stores would
        have happened had the allocation not been sunk, so that we know how to rematerialize the
        object on OSR exit. Prior to this change, trunk had two ways of describing such a "put
        hint":
        
        - The PutStrutureHint and PutByOffsetHint node types.
        - The PromotedLocationDescriptor class, which has an enum with cases StructurePLoc and
          NamedPropertyPLoc.
        
        We also had ways of converting from a Node with those two node types to a
        PromotedLocationDescriptor, and we had a way of converting a PromotedLocationDescriptor to
        a Node.
        
        This change removes the redundancy. We now have just one node type that corresponds to a
        put hint, and it's called PutHint. It has a PromotedLocationDescriptor as metadata.
        Converting between a PutHint node and a PromotedLocationDescriptor and vice-versa is now
        trivial.
        
        This means that if we add new kinds of sunken objects, we'll have less pro-forma to write
        for the put hints to those objects. This is mainly to simplify the implementation of
        arguments elimination in bug 141174.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::mergeRelevantToOSR):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::convertToPutHint):
        (JSC::DFG::Node::convertToPutStructureHint):
        (JSC::DFG::Node::convertToPutByOffsetHint):
        (JSC::DFG::Node::promotedLocationDescriptor):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::hasPromotedLocationDescriptor):
        (JSC::DFG::Node::convertToPutByOffsetHint): Deleted.
        (JSC::DFG::Node::convertToPutStructureHint): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::run):
        (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
        (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPromoteHeapAccess.h:
        (JSC::DFG::promoteHeapAccess):
        * dfg/DFGPromotedHeapLocation.cpp:
        (JSC::DFG::PromotedHeapLocation::createHint):
        * dfg/DFGPromotedHeapLocation.h:
        (JSC::DFG::PromotedLocationDescriptor::imm1):
        (JSC::DFG::PromotedLocationDescriptor::imm2):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):

2015-03-17  Michael Saboff  <msaboff@apple.com>

        Windows X86-64 should use the fixed executable allocator
        https://bugs.webkit.org/show_bug.cgi?id=142749

        Reviewed by Filip Pizlo.

        Added jit/ExecutableAllocatorFixedVMPool.cpp to Windows build.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * jit/ExecutableAllocatorFixedVMPool.cpp: Don't include unistd.h on Windows.

2015-03-17  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Show rendering frames (and FPS) in Layout and Rendering timeline
        https://bugs.webkit.org/show_bug.cgi?id=142029

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:
        Added new event type for runloop timeline records.

2015-03-16  Ryosuke Niwa  <rniwa@webkit.org>

        Enable ES6 classes by default
        https://bugs.webkit.org/show_bug.cgi?id=142774

        Reviewed by Gavin Barraclough.

        Enabled the feature and unskipped tests.

        * Configurations/FeatureDefines.xcconfig:
        * tests/stress/class-syntax-no-loop-tdz.js:
        * tests/stress/class-syntax-no-tdz-in-catch.js:
        * tests/stress/class-syntax-no-tdz-in-conditional.js:
        * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js:
        * tests/stress/class-syntax-no-tdz-in-loop.js:
        * tests/stress/class-syntax-no-tdz.js:
        * tests/stress/class-syntax-tdz-in-catch.js:
        * tests/stress/class-syntax-tdz-in-conditional.js:
        * tests/stress/class-syntax-tdz-in-loop.js:
        * tests/stress/class-syntax-tdz.js:

2015-03-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Better Console Previews for Arrays / Small Objects
        https://bugs.webkit.org/show_bug.cgi?id=142322

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        Create deep valuePreviews for simple previewable objects,
        such as arrays with 5 values, or basic objects with
        3 properties.

2015-03-16  Ryosuke Niwa  <rniwa@webkit.org>

        Add support for default constructor
        https://bugs.webkit.org/show_bug.cgi?id=142388

        Reviewed by Filip Pizlo.

        Added the support for default constructors. They're generated by ClassExprNode::emitBytecode
        via BuiltinExecutables::createDefaultConstructor.

        UnlinkedFunctionExecutable now has the ability to override SourceCode provided by the owner
        executable. We can't make store SourceCode in UnlinkedFunctionExecutable since CodeCache can use
        the same UnlinkedFunctionExecutable to generate code blocks for multiple functions.

        Parser now has the ability to treat any function expression as a constructor of the kind specified
        by m_defaultConstructorKind member variable.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor): Added.
        (JSC::BuiltinExecutables::createExecutableInternal): Generalized from createBuiltinExecutable.
        Parse default constructors as normal non-builtin functions. Override SourceCode in the unlinked
        function executable since the Miranda function's code is definitely not in the owner executable's
        source code. That's the whole point.
        * builtins/BuiltinExecutables.h:
        (UnlinkedFunctionExecutable::createBuiltinExecutable): Added. Wraps createExecutableInternal.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::linkInsideExecutable):
        (JSC::UnlinkedFunctionExecutable::linkGlobalCode):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::create):
        (JSC::UnlinkedFunctionExecutable::symbolTable): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewDefaultConstructor): Added.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode): Generate the default constructor if needed.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseFunctionInfo): Override ownerClassKind and assume the function as
        a constructor if we're parsing a default constructor.
        (JSC::Parser<LexerType>::parseClass): Allow omission of the class constructor.
        * parser/Parser.h:
        (JSC::parse):

2015-03-16  Alex Christensen  <achristensen@webkit.org>

        Progress towards CMake on Mac
        https://bugs.webkit.org/show_bug.cgi?id=142747

        Reviewed by Chris Dumez.

        * CMakeLists.txt:
        Include AugmentableInspectorController.h in CMake build.

2015-03-16  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Enable generating idiv instructions if it is supported
        https://bugs.webkit.org/show_bug.cgi?id=142725

        Reviewed by Michael Saboff.

        * assembler/ARMAssembler.h: Added sdiv and udiv implementation for ARM Traditional instruction set.
        (JSC::ARMAssembler::sdiv):
        (JSC::ARMAssembler::udiv):
        * assembler/ARMv7Assembler.h: Use HAVE(ARM_IDIV_INSTRUCTIONS) instead of CPU(APPLE_ARMV7S).
        * assembler/AbstractMacroAssembler.h:
        (JSC::isARMv7IDIVSupported):
        (JSC::optimizeForARMv7IDIVSupported):
        (JSC::isARMv7s): Renamed to isARMv7IDIVSupported().
        (JSC::optimizeForARMv7s): Renamed to optimizeForARMv7IDIVSupported().
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArithMod):

2015-03-15  Filip Pizlo  <fpizlo@apple.com>

        DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source, and emit GetStacks when the stack's value is needed and none is deferred
        https://bugs.webkit.org/show_bug.cgi?id=141624

        Reviewed by Geoffrey Garen.

        Not eliminating GetStacks was an obvious omission from the original PutStackSinkingPhase.
        Previously, we would treat GetStacks conservatively and assume that the stack slot
        escaped. That's pretty dumb, since a GetStack is a local load of the stack. This change
        makes GetStack a no-op from the standpoint of this phase's deferral analysis. At the end
        we either keep the GetStack (if there was no concrete deferral) or we replace it with an
        identity over the value that would have been stored by the deferred PutStack. Note that
        this might be a Phi that the phase creates, so this is strictly stronger than what GCSE
        could do.
        
        But this change revealed the fact that this phase never correctly handled side effects in
        case that we had done a GetStack, then a side-effect, and then found ourselves wanting the
        value on the stack due to (for example) a Phi on a deferred PutStack and that GetStack.
        Basically, it's only correct to use the SSA converter's incoming value mapping if we have
        a concrete deferral - since anything but a concrete deferral may imply that the value has
        been clobbered.
        
        This has no performance change. I believe that the bug was previously benign because we
        have so few operations that clobber the stack anymore, and most of those get used in a
        very idiomatic way. The GetStack elimination will be very useful for the varargs
        simplification that is part of bug 141174.
        
        This includes a test for the case that Speedometer hit, plus tests for the other cases I
        thought of once I realized the deeper issue.

        * dfg/DFGPutStackSinkingPhase.cpp:
        * tests/stress/get-stack-identity-due-to-sinking.js: Added.
        (foo):
        (bar):
        * tests/stress/get-stack-mapping-with-dead-get-stack.js: Added.
        (bar):
        (foo):
        * tests/stress/get-stack-mapping.js: Added.
        (bar):
        (foo):
        * tests/stress/weird-put-stack-varargs.js: Added.
        (baz):
        (foo):
        (fuzz):
        (bar):

2015-03-16  Joseph Pecoraro  <pecoraro@apple.com>

        Update Map/Set to treat -0 and 0 as the same value
        https://bugs.webkit.org/show_bug.cgi?id=142709

        Reviewed by Csaba Osztrogonác.

        * runtime/MapData.h:
        (JSC::MapDataImpl<Entry>::KeyType::KeyType):
        No longer special case -0. It will be treated as the same as 0.

2015-03-15  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Better handle displaying -0
        https://bugs.webkit.org/show_bug.cgi?id=142708

        Reviewed by Timothy Hatcher.

        Modeled after a blink change:

        Patch by <aandrey@chromium.org>
        DevTools: DevTools: Show -0 for negative zero in console
        https://src.chromium.org/viewvc/blink?revision=162605&view=revision

        * inspector/InjectedScriptSource.js:
        When creating a description string, or preview value string
        for -0, be sure the string is "-0" and not "0".

2015-03-14  Ryosuke Niwa  <rniwa@webkit.org>

        parseClass should popScope after pushScope
        https://bugs.webkit.org/show_bug.cgi?id=142689

        Reviewed by Benjamin Poulain.

        Pop the parser scope as needed.

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

2015-03-14  Dean Jackson  <dino@apple.com>

        Feature flag for Animations Level 2
        https://bugs.webkit.org/show_bug.cgi?id=142699
        <rdar://problem/20165097>

        Reviewed by Brent Fulgham.

        Add ENABLE_CSS_ANIMATIONS_LEVEL_2 and a runtime flag animationTriggersEnabled.

        * Configurations/FeatureDefines.xcconfig:

2015-03-14  Commit Queue  <commit-queue@webkit.org>

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

        Caused Speedometer/Full.html to fail (Requested by smfr on
        #webkit).

        Reverted changeset:

        "DFG::PutStackSinkingPhase should eliminate GetStacks that
        have an obviously known source"
        https://bugs.webkit.org/show_bug.cgi?id=141624
        http://trac.webkit.org/changeset/181487

2015-03-14  Michael Saboff  <msaboff@apple.com>

        ES6: Add binary and octal literal support
        https://bugs.webkit.org/show_bug.cgi?id=142681

        Reviewed by Ryosuke Niwa.

        Added a binary literal parser function, parseBinary(), to Lexer patterned after the octal parser.
        Refactored the parseBinary, parseOctal and parseDecimal to use a constant size for the number of
        characters to try and handle directly. Factored out the shifting past any prefix to be handled by
        the caller. Added binary and octal parsing to toDouble() via helper functions.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::parseHex):
        (JSC::Lexer<T>::parseBinary):
        (JSC::Lexer<T>::parseOctal):
        (JSC::Lexer<T>::parseDecimal):
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        * parser/ParserTokens.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::jsBinaryIntegerLiteral):
        (JSC::jsOctalIntegerLiteral):
        (JSC::toDouble):

2015-03-13  Alex Christensen  <achristensen@webkit.org>

        Progress towards CMake on Mac.
        https://bugs.webkit.org/show_bug.cgi?id=142680

        Reviewed by Gyuyoung Kim.

        * PlatformMac.cmake:
        Generate TracingDtrace.h based on project.pbxproj.

2015-03-13  Filip Pizlo  <fpizlo@apple.com>

        Object allocation sinking phase shouldn't re-decorate previously sunken allocations on each fixpoint operation
        https://bugs.webkit.org/show_bug.cgi?id=142686

        Reviewed by Oliver Hunt.
        
        Just because promoteHeapAccess() notifies us of an effect to a heap location in a node doesn't
        mean that we should handle it as if it was for one of our sinking candidates. Instead we should
        prune based on m_sinkCandidates.
        
        This fixes a benign bug where we would generate a lot of repeated IR for some pathological
        tests.

        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):

2015-03-13  Eric Carlson  <eric.carlson@apple.com>

        [Mac] Enable WIRELESS_PLAYBACK_TARGET
        https://bugs.webkit.org/show_bug.cgi?id=142635

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:

2015-03-13  Ryosuke Niwa  <rniwa@webkit.org>

        Class constructor should throw TypeError when "called"
        https://bugs.webkit.org/show_bug.cgi?id=142566

        Reviewed by Michael Saboff.

        Added ConstructorKind::None to denote code that doesn't belong to an ES6 class.
        This allows BytecodeGenerator to emit code to throw TypeError when generating code block
        to call ES6 class constructors.

        Most of changes are about increasing the number of bits to store ConstructorKind from one
        bit to two bits.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::needsActivation):
        (JSC::ExecutableInfo::usesEval):
        (JSC::ExecutableInfo::isStrictMode):
        (JSC::ExecutableInfo::isConstructor):
        (JSC::ExecutableInfo::isBuiltinFunction):
        (JSC::ExecutableInfo::constructorKind):
        (JSC::UnlinkedFunctionExecutable::constructorKind):
        (JSC::UnlinkedCodeBlock::constructorKind):
        (JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Deleted.
        (JSC::UnlinkedCodeBlock::constructorKindIsDerived): Deleted.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate): Don't emit bytecode when we had already emitted code
        to throw TypeError.
        (JSC::BytecodeGenerator::BytecodeGenerator): Emit code to throw TypeError when generating
        code to call.
        (JSC::BytecodeGenerator::emitReturn):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::constructorKind):
        (JSC::BytecodeGenerator::constructorKindIsDerived): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        * parser/Nodes.cpp:
        (JSC::FunctionBodyNode::FunctionBodyNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo): Renamed the incoming function argument to
        ownerClassKind. Set constructorKind to Base or Derived only if we're parsing a constructor.
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass): Don't parse static methods using MethodMode since that
        would result in BytecodeGenerator erroneously treating static method named "constructor" as
        a class constructor.
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        * parser/Parser.h:
        * parser/ParserModes.h:
        * runtime/Executable.h:
        (JSC::EvalExecutable::executableInfo):
        (JSC::ProgramExecutable::executableInfo):

2015-03-13  Filip Pizlo  <fpizlo@apple.com>

        DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source
        https://bugs.webkit.org/show_bug.cgi?id=141624

        Reviewed by Oliver Hunt.
        
        This was an obvious omission from the original PutStackSinkingPhase. Previously, we would treat
        GetStacks conservatively and assume that the stack slot escaped. That's pretty dumb, since a
        GetStack is a local load of the stack. This change makes GetStack a no-op from the standpoint of
        this phase's deferral analysis. At the end we either keep the GetStack (if there was no concrete
        deferral) or we replace it with an identity over the value that would have been stored by the
        deferred PutStack. Note that this might be a Phi that the phase creates, so this is strictly
        stronger than what GCSE could do.
        
        This is probably not a speed-up now, but it will be very useful for the varargs simplification
        done in bug 141174.

        * dfg/DFGPutStackSinkingPhase.cpp:

2015-03-12  Geoffrey Garen  <ggaren@apple.com>

        Prohibit GC while sweeping
        https://bugs.webkit.org/show_bug.cgi?id=142638

        Reviewed by Andreas Kling.

        I noticed in https://bugs.webkit.org/show_bug.cgi?id=142636 that a GC
        could trigger a sweep which could trigger another GC. Yo Dawg.

        I tried to figure out whether this could cause problems or not and it
        made me cross-eyed.

        (Some clients like to report extra memory cost during deallocation as a
        way to indicate that the GC now owns something exclusively. It's
        arguably a bug to communicate with the GC in this way, but we shouldn't
        do crazy when this happens.)

        This patch makes explicit the fact that we don't allow GC while sweeping.

        Usually, sweeping implicitly defers GC by virtue of happening during
        allocation. But not always.

        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage): Defer GC while sweeping due to an
        explicit GC request.

        (JSC::Heap::didFinishCollection): Make sure that zombifying sweep
        defers GC by not returning to the non-GC state until we're all done.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::sweepNextBlock): Defer GC while sweeping due
        to a timer.

2015-03-13  Mark Lam  <mark.lam@apple.com>

        Replace TCSpinLock with a new WTF::SpinLock based on WTF::Atomic.
        <https://webkit.org/b/142674>

        Reviewed by Filip Pizlo.

        * API/JSValue.mm:
        (handerForStructTag):
        * API/JSWrapperMap.mm:
        * dfg/DFGCommon.cpp:
        (JSC::DFG::startCrashing):
        (JSC::DFG::isCrashing):
        - Changed to use a StaticSpinLock since that's what this code was trying to do
          anyway.
        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::CopiedBlock):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::CopiedSpace):
        * heap/CopiedSpace.h:
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData):
        * heap/GCThreadSharedData.h:
        * heap/ListableHandler.h:
        (JSC::ListableHandler::List::List):
        * parser/SourceProvider.cpp:
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::addDatabaseToAtExit):
        (JSC::Profiler::Database::removeDatabaseFromAtExit):
        (JSC::Profiler::Database::removeFirstAtExitDatabase):

2015-03-13  Ryosuke Niwa  <rniwa@webkit.org>

        BytecodeGenerator needs to be re-entrant to support miranda functions
        https://bugs.webkit.org/show_bug.cgi?id=142627

        Reviewed by Filip Pizlo.

        Made CodeCache::getGlobalCodeBlock and CodeCache::getFunctionExecutableFromGlobalCode re-entrant
        by not keeping AddResult while invoking BytecodeGenerator::generate.

        This is needed to support Miranda functions since they need to be lazily initialized.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::findCacheAndUpdateAge): Extracted from add.
        (JSC::CodeCacheMap::addCache): Extracted from add.
        (JSC::CodeCacheMap::add): Deleted.

2015-03-13  Mark Lam  <mark.lam@apple.com>

        Introduce WTF::Atomic to wrap std::atomic for a friendlier CAS.
        <https://webkit.org/b/142661>

        Reviewed by Filip Pizlo.

        Changed CodeBlock, and the DFG's crashLock to use WTF::Atomic instead of
        std::atomic.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitAggregate):
        * bytecode/CodeBlock.h:
        * dfg/DFGCommon.cpp:
        (JSC::DFG::startCrashing):

2015-03-12  Mark Lam  <mark.lam@apple.com>

        Change the DFG crashLock to use std::atomic.
        <https://webkit.org/b/142649>

        Reviewed by Filip Pizlo.

        * dfg/DFGCommon.cpp:
        (JSC::DFG::startCrashing):
        (JSC::DFG::isCrashing):

2015-03-12  Filip Pizlo  <fpizlo@apple.com>

        Bytecode liveness analysis should have more lambdas and fewer sets
        https://bugs.webkit.org/show_bug.cgi?id=142647

        Reviewed by Mark Lam.
        
        In bug 141174 I'll need to identify all of the bytecode kill sites. This requires hooking into
        the bytecode analysis' stepOverFunction method, except in such a way that we observe uses that
        are not in outs. This refactors stepOverFunction so that you can pass it use/def functors that
        can either be used to propagate outs (as we do right now) or to additionally detect kills or
        whatever else.
        
        In order to achieve this, the liveness analysis was moved off of maintaining uses/defs
        bitvectors. This wasn't helping the abstraction and was probably inefficient. The new code
        should be a bit faster since we don't have to clear uses/defs bitvectors on each instruction. On
        the other hand, being able to intercept each use means that our code for exception handlers is
        no longer a bitwise-merge; it requires finding set bits. Fortunately, this code only kicks in
        for instructions inside a try, and its performance is O(live at catch), so that's probably not
        bad.

        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::indexForOperand):
        (JSC::stepOverInstruction):
        (JSC::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::setForOperand): Deleted.
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:

2015-03-12  Ryosuke Niwa  <rniwa@webkit.org>

        "this" should be in TDZ until super is called in the constructor of a derived class
        https://bugs.webkit.org/show_bug.cgi?id=142527

        Reviewed by Mark Hahnenberg.

        DFG and FTL implementations co-authored by Filip Pizlo.

        In ES6 class syntax, "this" register must be in the "temporal dead zone" (TDZ) and throw ReferenceError until
        super() is called inside the constructor of a derived class.

        Added op_check_tdz, a new OP code, which throws a reference error when the first operand is an empty value
        to all tiers of JIT and LLint. The op code throws in the slow path on the basis that a TDZ error should be
        a programming error and not a part of the programs' normal control flow. In DFG, this op code is represented
        by a no-op must-generate node CheckNotEmpty modeled after CheckCell.

        Also made the constructor of a derived class assign the empty value to "this" register rather than undefined
        so that ThisNode can emit the op_check_tdz to check the initialized-ness of "this" in such a constructor.

        * bytecode/BytecodeList.json: Added op_check_tdz.
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset): Ditto.
        (JSC::computeDefsForBytecodeOffset): Ditto.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Ditto.
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString): Added TDZFailure.
        * bytecode/ExitKind.h: Ditto.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Assign the empty value to "this" register to indicate it's in TDZ.
        (JSC::BytecodeGenerator::emitTDZCheck): Added.
        (JSC::BytecodeGenerator::emitReturn): Emit the TDZ check since "this" can still be in TDZ if super() was never
        called. e.g. class B extends A { constructor() { } }
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode): Always emit the TDZ check if we're inside the constructor of a derived class.
        We can't omit this check even if the result was ignored per spec.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Previously, empty value could never appear
        in a local variable. This is no longer true so generalize this code. Also added the support for CheckNotEmpty.
        Like CheckCell, we phantomize this DFG node in the constant folding phase if the type of the operand is already
        found to be not empty. Otherwise filter out SpecEmpty.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Added op_check_tdz.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel): op_check_tdz can be compiled and inlined.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize): CheckNotEmpty doesn't read or write values.
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants): Convert CheckNotEmpty to a phantom if non-emptiness had already
        been proven for the operand prior to this node.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC): CheckNotEmpty does not trigger GC.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): CheckNotEmpty is a no-op in the fixup phase.
        * dfg/DFGNodeType.h: CheckNotEmpty cannot be removed even if the result was ignored. See ThisNode::emitBytecode.
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate): CheckNotEmpty doesn't return any value.
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute): CheckNotEmpty doesn't load from heap so it's safe.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Speculative the operand to be not empty. OSR exit if the speculation fails.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Ditto.
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile): CheckNotEmpty can be compiled in FTL.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode): Calls compileCheckNotEmpty for CheckNotEmpty.
        (JSC::FTL::LowerDFGToLLVM::compileCheckNotEmpty): OSR exit with "TDZFailure" if the operand is not empty.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass): Added op_check_tdz.
        (JSC::JIT::privateCompileSlowCases): Ditto.
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_check_tdz): Implements op_check_tdz in Baseline JIT.
        (JSC::JIT::emitSlow_op_check_tdz): Ditto.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_check_tdz): Ditto.
        (JSC::JIT::emitSlow_op_check_tdz): Ditto.
        * llint/LowLevelInterpreter32_64.asm: Implements op_check_tdz in LLint.
        * llint/LowLevelInterpreter64.asm: Ditto.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): Throws a reference error for op_check_tdz. Shared by LLint and Baseline JIT.
        * runtime/CommonSlowPaths.h:
        * tests/stress/class-syntax-no-loop-tdz.js: Added.
        * tests/stress/class-syntax-no-tdz-in-catch.js: Added.
        * tests/stress/class-syntax-no-tdz-in-conditional.js: Added.
        * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js: Added.
        * tests/stress/class-syntax-no-tdz-in-loop.js: Added.
        * tests/stress/class-syntax-no-tdz.js: Added.
        * tests/stress/class-syntax-tdz-in-catch.js: Added.
        * tests/stress/class-syntax-tdz-in-conditional.js: Added.
        * tests/stress/class-syntax-tdz-in-loop.js: Added.
        * tests/stress/class-syntax-tdz.js: Added.

2015-03-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        Integrate MapData into JSMap and JSSet
        https://bugs.webkit.org/show_bug.cgi?id=142556

        Reviewed by Filip Pizlo.

        This patch integrates MapData into JSMap and JSSet.
        This removes 2 object allocation per one JSMap / JSSet.

        MapDataImpl is specialized into MapData and SetData.
        In the case of SetData, it does not have the dummy values
        previously stored in the MapDataImpl. So the storage size of SetData
        becomes the half of the previous implementation.

        And now MapData and SetData are completely integrated into JSMap and JSSet,
        these structures are not exposed to the other code even in WebCore world.

        And at the same time, this patch fixes missing destroy functions
        in JSMapIterator and JSSetIterator.
        They are needed because MapData::const_iterator is a non-trivial destructor.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSMap.cpp:
        (JSC::JSMap::destroy):
        (JSC::JSMap::visitChildren):
        (JSC::JSMap::copyBackingStore):
        (JSC::JSMap::has):
        (JSC::JSMap::size):
        (JSC::JSMap::get):
        (JSC::JSMap::set):
        (JSC::JSMap::clear):
        (JSC::JSMap::remove):
        (JSC::JSMap::finishCreation): Deleted.
        * runtime/JSMap.h:
        (JSC::JSMap::Entry::key):
        (JSC::JSMap::Entry::value):
        (JSC::JSMap::Entry::visitChildren):
        (JSC::JSMap::Entry::setKey):
        (JSC::JSMap::Entry::setKeyWithoutWriteBarrier):
        (JSC::JSMap::Entry::setValue):
        (JSC::JSMap::Entry::clear):
        (JSC::JSMap::begin):
        (JSC::JSMap::end):
        (JSC::JSMap::JSMap):
        (JSC::JSMap::mapData): Deleted.
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::finishCreation):
        (JSC::JSMapIterator::destroy):
        (JSC::JSMapIterator::visitChildren):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::JSMapIterator):
        * runtime/JSSet.cpp:
        (JSC::JSSet::destroy):
        (JSC::JSSet::visitChildren):
        (JSC::JSSet::copyBackingStore):
        (JSC::JSSet::has):
        (JSC::JSSet::size):
        (JSC::JSSet::add):
        (JSC::JSSet::clear):
        (JSC::JSSet::remove):
        (JSC::JSSet::finishCreation): Deleted.
        * runtime/JSSet.h:
        (JSC::JSSet::Entry::key):
        (JSC::JSSet::Entry::value):
        (JSC::JSSet::Entry::visitChildren):
        (JSC::JSSet::Entry::setKey):
        (JSC::JSSet::Entry::setKeyWithoutWriteBarrier):
        (JSC::JSSet::Entry::setValue):
        (JSC::JSSet::Entry::clear):
        (JSC::JSSet::begin):
        (JSC::JSSet::end):
        (JSC::JSSet::JSSet):
        (JSC::JSSet::mapData): Deleted.
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::finishCreation):
        (JSC::JSSetIterator::visitChildren):
        (JSC::JSSetIterator::destroy):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::JSSetIterator):
        * runtime/MapConstructor.cpp:
        (JSC::constructMap):
        * runtime/MapData.h:
        (JSC::MapDataImpl::const_iterator::key):
        (JSC::MapDataImpl::const_iterator::value):
        (JSC::MapDataImpl::size):
        (JSC::MapDataImpl<Entry>::MapDataImpl):
        (JSC::MapDataImpl<Entry>::clear):
        (JSC::MapDataImpl<Entry>::KeyType::KeyType):
        (JSC::MapDataImpl<Entry>::const_iterator::internalIncrement):
        (JSC::MapDataImpl<Entry>::const_iterator::ensureSlot):
        (JSC::MapDataImpl<Entry>::const_iterator::const_iterator):
        (JSC::MapDataImpl<Entry>::const_iterator::~const_iterator):
        (JSC::MapDataImpl<Entry>::const_iterator::operator):
        (JSC::=):
        (JSC::MapData::const_iterator::key): Deleted.
        (JSC::MapData::const_iterator::value): Deleted.
        (JSC::MapData::create): Deleted.
        (JSC::MapData::createStructure): Deleted.
        (JSC::MapData::size): Deleted.
        (JSC::MapData::clear): Deleted.
        (JSC::MapData::KeyType::KeyType): Deleted.
        (JSC::MapData::const_iterator::internalIncrement): Deleted.
        (JSC::MapData::const_iterator::ensureSlot): Deleted.
        (JSC::MapData::const_iterator::const_iterator): Deleted.
        (JSC::MapData::const_iterator::~const_iterator): Deleted.
        (JSC::MapData::const_iterator::operator*): Deleted.
        (JSC::MapData::const_iterator::end): Deleted.
        (JSC::MapData::const_iterator::operator!=): Deleted.
        (JSC::MapData::const_iterator::operator==): Deleted.
        * runtime/MapDataInlines.h: Renamed from Source/JavaScriptCore/runtime/MapData.cpp.
        (JSC::MapDataImpl<Entry>::find):
        (JSC::MapDataImpl<Entry>::contains):
        (JSC::MapDataImpl<Entry>::add):
        (JSC::MapDataImpl<Entry>::set):
        (JSC::MapDataImpl<Entry>::get):
        (JSC::MapDataImpl<Entry>::remove):
        (JSC::MapDataImpl<Entry>::replaceAndPackBackingStore):
        (JSC::MapDataImpl<Entry>::replaceBackingStore):
        (JSC::MapDataImpl<Entry>::ensureSpaceForAppend):
        (JSC::MapDataImpl<Entry>::visitChildren):
        (JSC::MapDataImpl<Entry>::copyBackingStore):
        * runtime/MapPrototype.cpp:
        (JSC::getMap):
        (JSC::mapProtoFuncClear):
        (JSC::mapProtoFuncDelete):
        (JSC::mapProtoFuncForEach):
        (JSC::mapProtoFuncGet):
        (JSC::mapProtoFuncHas):
        (JSC::mapProtoFuncSet):
        (JSC::mapProtoFuncSize):
        (JSC::getMapData): Deleted.
        * runtime/SetPrototype.cpp:
        (JSC::getSet):
        (JSC::setProtoFuncAdd):
        (JSC::setProtoFuncClear):
        (JSC::setProtoFuncDelete):
        (JSC::setProtoFuncForEach):
        (JSC::setProtoFuncHas):
        (JSC::setProtoFuncSize):
        (JSC::getMapData): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2015-03-12  Mark Lam  <mark.lam@apple.com>

        Use std::atomic for CodeBlock::m_visitAggregateHasBeenCalled.
        <https://webkit.org/b/142640>

        Reviewed by Mark Hahnenberg.

        We used to spin our own compare and swap on a uint8_t.  Now that we can
        use C++11, let's use std::atomic instead.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitAggregate):
        - The CAS here needs std::memory_order_acquire ordering because it
          requires lock acquisition semantics to visit the CodeBlock.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlockSet::mark):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::clearMarksForFullCollection):
        (JSC::CodeBlockSet::clearMarksForEdenCollection):
        - These can go with relaxed ordering because they are all done before
          the GC starts parallel marking.

2015-03-12  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Fix the incremental build issue revealed by r181419
        https://bugs.webkit.org/show_bug.cgi?id=142613

        Reviewed by Carlos Garcia Campos.

        * CMakeLists.txt:

2015-03-11  Ryosuke Niwa  <rniwa@webkit.org>

        "static" should not be a reserved keyword in non-strict mode even when ES6 class is enabled
        https://bugs.webkit.org/show_bug.cgi?id=142600

        Reviewed by Mark Lam.

        Make "static" RESERVED_IF_STRICT and manually detect it in parseClass.

        No new tests. This is already checked by js/reserved-words.html and js/keywords-and-reserved_words.html

        * parser/Keywords.table:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        * parser/ParserTokens.h:

2015-03-11  Geoffrey Garen  <ggaren@apple.com>

        Many users of Heap::reportExtraMemory* are wrong, causing lots of memory growth
        https://bugs.webkit.org/show_bug.cgi?id=142593

        Reviewed by Andreas Kling.

        Adopt deprecatedReportExtraMemory as a short-term fix for runaway
        memory growth in these cases where we have not adopted
        reportExtraMemoryVisited.

        Long-term, we should use reportExtraMemoryAllocated+reportExtraMemoryVisited.
        That's tracked by https://bugs.webkit.org/show_bug.cgi?id=142595.

        * API/JSBase.cpp:
        (JSReportExtraMemoryCost):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::add):

2015-03-11  Geoffrey Garen  <ggaren@apple.com>

        Refactored the JSC::Heap extra cost API for clarity and to make some known bugs more obvious
        https://bugs.webkit.org/show_bug.cgi?id=142589

        Reviewed by Andreas Kling.

        * API/JSBase.cpp:
        (JSReportExtraMemoryCost): Added a FIXME to annotate a known bug.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitAggregate):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode): Updated for rename.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::reportExtraMemoryAllocatedSlowCase):
        (JSC::Heap::deprecatedReportExtraMemorySlowCase): Renamed our reporting
        APIs to clarify their relationship to each other: One must report extra
        memory at the time of allocation, and at the time the GC visits it.

        (JSC::Heap::extraMemorySize):
        (JSC::Heap::size):
        (JSC::Heap::capacity):
        (JSC::Heap::sizeAfterCollect):
        (JSC::Heap::willStartCollection): Updated for renames. Added explicit
        API for deprecated users who can't use our best API.
 
        (JSC::Heap::reportExtraMemoryCostSlowCase): Deleted.
        (JSC::Heap::extraSize): Deleted.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::reportExtraMemoryAllocated):
        (JSC::Heap::reportExtraMemoryVisited):
        (JSC::Heap::deprecatedReportExtraMemory):
        (JSC::Heap::reportExtraMemoryCost): Deleted. Ditto.

        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        (JSC::SlotVisitor::reportExtraMemoryUsage): Deleted. Moved this
        functionality into the Heap since it's pretty detailed in its access
        to the heap.

        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Updated for
        renames.

        * runtime/JSString.cpp:
        (JSC::JSString::visitChildren):
        (JSC::JSRopeString::resolveRopeToAtomicString):
        (JSC::JSRopeString::resolveRope):
        * runtime/JSString.h:
        (JSC::JSString::finishCreation): Updated for renames.

        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::add): Added FIXME.

        * runtime/WeakMapData.cpp:
        (JSC::WeakMapData::visitChildren): Updated for rename.

2015-03-11  Ryosuke Niwa  <rniwa@webkit.org>

        Calling super() in a base class results in a crash
        https://bugs.webkit.org/show_bug.cgi?id=142563

        Reviewed by Filip Pizlo.

        The bug was caused by BytecodeGenerator trying to generate "super" expression inside the constructor of a base class.
        Disallow that by keeping track of whether "super" has been used in the current scope or not (needsSuperBinding flag)
        and then throwing a syntax error in parseFunctionInfo if it was used and the current scope wasn't the constructor of
        a derived class.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo): Don't allow super() or super.foo outside the constructor of a derived class.
        (JSC::Parser<LexerType>::parseClass): Pass in the constructor kind to parseGetterSetter.
        (JSC::Parser<LexerType>::parseGetterSetter): Ditto to parseFunctionInfo.
        (JSC::Parser<LexerType>::parseMemberExpression): Set needsSuperBinding flag true on the containing scope.
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::needsSuperBinding): Added.
        (JSC::Scope::setNeedsSuperBinding): Added.

2015-03-10  Darin Adler  <darin@apple.com>

        Some event handler fixes
        https://bugs.webkit.org/show_bug.cgi?id=142474

        Reviewed by Anders Carlsson.

        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript): Call clearException.
        I spotted the fact it was missing by auditing all the calls to JSC::call.

2015-03-10  Matthew Mirman  <mmirman@apple.com>

        Functions should have initialization precedence over arguments. 
        https://bugs.webkit.org/show_bug.cgi?id=142550
        rdar://problem/19702564

        Reviewed by Geoffrey Garen.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeCapturedVariable):
        * tests/stress/initialize_functions_after_arguments.js: Added.

2015-03-10  Andreas Kling  <akling@apple.com>

        Eden collections should trigger sweep of MarkedBlocks containing new objects.
        <https://webkit.org/b/142538>

        Reviewed by Geoffrey Garen.

        Take a snapshot of all MarkedBlocks with new objects as part of Eden collections,
        and append that to the IncrementalSweeper's working set.

        This ensures that we run destructors for objects that were discovered to be garbage during
        Eden collections, instead of delaying their teardown until the next full collection,
        or the next allocation cycle for their block.

        * heap/Heap.cpp:
        (JSC::Heap::snapshotMarkedSpace): For Eden collections, snapshot the list of MarkedBlocks
        that contain new objects, since those are the only ones we're interested in.
        Also use Vector::resizeToFit() to allocate the snapshot for full collections, since we know
        the final size we need up front.

        (JSC::Heap::notifyIncrementalSweeper): For Eden collections, tell the IncrementalSweeper
        to add the block snapshot (taken earlier) to its existing set of blocks instead of replacing
        it entirely. This allows Eden collections and incremental sweeping to occur interleaved with
        each other without missing destruction opportunities.

        * heap/IncrementalSweeper.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doSweep):
        (JSC::IncrementalSweeper::sweepNextBlock): Change the way we iterate over the sweeper's
        work list: instead of keeping an index for the next block, just pop from the end of the list.
        This allows us to add new blocks and deduplicate the list without disturbing iteration.

        (JSC::IncrementalSweeper::startSweeping): Make this take a Vector<MarkedBlock>&& so we can
        pass ownership of this Vector efficiently from Heap to IncrementalSweeper.

        (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Added. This is used by Eden
        collections to add a set of MarkedBlocks with new objects to the sweeper's existing
        working set and kick the timer.

        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::blocksWithNewObjects): Expose the list of MarkedBlocks with new objects.

2015-03-10  Alex Christensen  <achristensen@webkit.org>

        Use unsigned for HashSet size.
        https://bugs.webkit.org/show_bug.cgi?id=142518

        Reviewed by Benjamin Poulain.

        * dfg/DFGAvailabilityMap.cpp:
        (JSC::DFG::AvailabilityMap::prune):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * heap/MarkedBlockSet.h:
        (JSC::MarkedBlockSet::remove):
        * runtime/WeakMapData.h:

2015-03-10  Mark Lam  <mark.lam@apple.com>

        Use std::numeric_limits<unsigned>::max() instead of (unsigned)-1.
        <https://webkit.org/b/142539>

        Reviewed by Benjamin Poulain.

        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JITInlines.h:
        (JSC::JIT::emitNakedCall):
        (JSC::JIT::addSlowCase):
        (JSC::JIT::addJump):
        (JSC::JIT::emitJumpSlowToHot):
        (JSC::JIT::emitGetVirtualRegister):
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::call):
        * yarr/Yarr.h:

2015-03-10  Mark Lam  <mark.lam@apple.com>

        [Win] JSC Build Warnings Need to be Resolved.
        <https://webkit.org/b/142366>

        Reviewed by Brent Fulgham.

        Applied some benign changes to make the MSVC compiler happy.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillJSValue):
        * runtime/BasicBlockLocation.cpp:
        (JSC::BasicBlockLocation::getExecutedRanges):
        * runtime/ControlFlowProfiler.cpp:
        (JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):

2015-03-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        Upgrade Map, Set and WeakMap constructor interface
        https://bugs.webkit.org/show_bug.cgi?id=142348

        Reviewed by Filip Pizlo.

        In the latest ES6 spec, Map and Set constructors take initialization data sets
        as iterable value. And iterate it and add the values into the constructed one.

        This is breaking change because the old constructor interface is
        already shipped in Safari 8.

        * runtime/MapConstructor.cpp:
        (JSC::callMap):
        (JSC::constructMap):
        (JSC::MapConstructor::getCallData):
        * runtime/SetConstructor.cpp:
        (JSC::callSet):
        (JSC::constructSet):
        * runtime/WeakMapConstructor.cpp:
        (JSC::callWeakMap):
        (JSC::constructWeakMap):
        (JSC::WeakMapConstructor::getCallData):
        * tests/stress/map-constructor-adder.js: Added.
        * tests/stress/map-constructor.js: Added.
        (testCallTypeError):
        (testTypeError):
        (for):
        * tests/stress/set-constructor-adder.js: Added.
        (Set.prototype.add):
        * tests/stress/set-constructor.js: Added.
        (for):
        * tests/stress/weak-map-constructor-adder.js: Added.
        * tests/stress/weak-map-constructor.js: Added.
        (testCallTypeError):
        (testTypeError):
        (for):

2015-03-10  Michael Catanzaro  <mcatanzaro@igalia.com>

        GCC: CRASH() should be annotated with NORETURN
        https://bugs.webkit.org/show_bug.cgi?id=142524

        Reviewed by Anders Carlsson.

        Don't return from a NORETURN function. This used to avoid a warning from GCC, but now it
        causes one.

        * jsc.cpp:

2015-03-10  Mark Lam  <mark.lam@apple.com>

        Gardening: fix bleeding debug test bots.
        https://webkit.org/b/142513>

        Not reviewed.

        The test needs to initialize WTF threading explicitly before using it.

        * API/tests/CompareAndSwapTest.cpp:
        (testCompareAndSwap):

2015-03-10  Alex Christensen  <achristensen@webkit.org>

        [WinCairo] Unreviewed build fix.

        * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:
        Added directory containing config.h, like r181304.

2015-03-09  Mark Lam  <mark.lam@apple.com>

        Yet another build fix for Windows.
        https://webkit.org/b/142513>

        Reviewed by Alex Christensen.

        Looks like MSVC requires the function be explicitly declared in a header file
        in order for it to be linkable from another file in the same project.  This is
        strange, but it seems to make MSVC happy.

        Also fixed a typo in testapi.vcxproj.filters.

        * API/tests/CompareAndSwapTest.cpp:
        * API/tests/CompareAndSwapTest.h: Added.
        * API/tests/testapi.c:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-03-09  Chris Dumez  <cdumez@apple.com>

        [iOS] Sweep all collected objects on critical memory pressure
        https://bugs.webkit.org/show_bug.cgi?id=142457
        <rdar://problem/20044440>

        Reviewed by Geoffrey Garen.

        All fullSweep() API to IncrementalSweeper so that we can call it in the
        memory pressure handler.

        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::fullSweep):
        * heap/IncrementalSweeper.h:
        (JSC::IncrementalSweeper::hasWork):

2015-03-09  Mark Lam  <mark.lam@apple.com>

        Another build fix for Windows.
        https://webkit.org/b/142513>

        Not reviewed.

        * API/tests/CompareAndSwapTest.cpp:
        - Added JS_EXPORT_PRIVATE attribute.

2015-03-09  Mark Lam  <mark.lam@apple.com>

        Build fix for Windows after r181305.
        https://webkit.org/b/142513>

        Reviewed by Alex Christensen.

        Windows doesn't like pthreads anymore.  Changed test to use WTF threading.

        * API/tests/CompareAndSwapTest.cpp:
        (setBitThreadFunc):
        (testCompareAndSwap):

2015-03-09  Mark Lam  <mark.lam@apple.com>

        8-bit version of weakCompareAndSwap() can cause an infinite loop.
        https://webkit.org/b/142513>

        Reviewed by Filip Pizlo.

        Added a test that exercises the 8-bit CAS from multiple threads.  The threads
        will contend to set bits in a large array of bytes using the CAS function.

        * API/tests/CompareAndSwapTest.cpp: Added.
        (Bitmap::Bitmap):
        (Bitmap::numBits):
        (Bitmap::clearAll):
        (Bitmap::concurrentTestAndSet):
        (setBitThreadFunc):
        (testCompareAndSwap):
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-03-09  Brent Fulgham  <bfulgham@apple.com>

        [Win] testapi project is unable to find the 'config.h' file.

        Rubberstamped by Mark Lam.

        * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Add JavaScriptCore source directory
        to the include path.

2015-03-09  Andreas Kling  <akling@apple.com>

        Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
        <https://webkit.org/b/142115>
        <rdar://problem/19992268>

        Reviewed by Geoffrey Garen.

        Prune stale entries from WeakGCMaps as part of every full garbage collection.
        This frees up tons of previously-stuck WeakBlocks that were only sitting around
        with finalized handles waiting to die.

        Note that WeakGCMaps register/unregister themselves with the GC heap in their
        ctor/dtor, so creating one now requires passing the VM.

        Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
        to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
        It seems somewhat excessive to do this on every Eden collection, so it's only
        doing work in full collections for now.

        Because the GC may now mutate WeakGCMap below object allocation, I've made it
        so that the classic HashMap::add() optimization can't be used with WeakGCMap.
        This caused intermittent test failures when originally landed due to having
        an invalid iterator on the stack after add() inserted a new entry and we
        proceeded to allocate the new object, triggering GC.

        * API/JSWeakObjectMapRefInternal.h:
        (OpaqueJSWeakObjectMap::create):
        (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * API/JSWrapperMap.mm:
        (-[JSWrapperMap initWithContext:]):
        (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.

        * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
        it project-private so WebCore clients can access it.

        * heap/Heap.cpp:
        (JSC::Heap::collect):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
        stale entries from WeakGCMaps. This is only executed during full collections.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::registerWeakGCMap):
        (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
        themselves with the Heap and provide a pruning callback.

        * runtime/PrototypeMap.h:
        (JSC::PrototypeMap::PrototypeMap):
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.

        * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"

        * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.

        * runtime/JSString.cpp:
        (JSC::jsStringWithCacheSlowCase):
        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::addPrototype):
        (JSC::PrototypeMap::emptyObjectStructureForPrototype): Remove HashMap add()
        optimization since it's not safe in the GC-managed WeakGCMap world.

        * runtime/VM.cpp:
        (JSC::VM::VM): Pass VM to WeakGCMap constructor.

        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::set):
        (JSC::WeakGCMap::add):
        (JSC::WeakGCMap::WeakGCMap): Deleted.
        (JSC::WeakGCMap::gcMap): Deleted.
        (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
        * runtime/WeakGCMapInlines.h: Added.
        (JSC::WeakGCMap::WeakGCMap):
        (JSC::WeakGCMap::~WeakGCMap):
        (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
        to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
        prunes WeakGCMap at certain growth milestones and instead rely on the GC
        callback for housekeeping.

2015-03-09  Ryosuke Niwa  <rniwa@webkit.org>

        Support extends and super keywords
        https://bugs.webkit.org/show_bug.cgi?id=142200

        Reviewed by Filip Pizlo.

        Added the support for ES6 class syntax inheritance.

        Added ConstructorKind as well as boolean flags indicating the constructor kind to
        various classes in UnlinkedCodeBlock as well as AST nodes.

        Each method stores the associated class as its homeObjectPrivateName. This value is used to
        make super calls.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Added.
        (JSC::UnlinkedCodeBlock::constructorKindIsDerived): Added.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Don't emit op_create_this in a derived class
        as the object is allocated by the highest base class's constructor. Also set "this" to null
        and store the original value in m_newTargetRegister. "this" is supposed to be in TDZ but
        that will be implemented in a separate patch.
        (JSC::BytecodeGenerator::emitReturn): Allow "undefined" to be returned from a derived class.
        In a derived class's constructor, not returning "undefined" or an object results in a type
        error instead of "this" being returned.
        (JSC::BytecodeGenerator::emitThrowTypeError): Added.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::constructorKindIsDerived): Added.
        (JSC::BytecodeGenerator::newTarget): Added.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::SuperNode::emitBytecode): Added. Emits the code to obtain the callee's parent class.
        (JSC::emitSuperBaseForCallee): Added. Emits the code to obtain the parent class's prototype.
        (JSC::emitPutHomeObject): Added.
        (JSC::PropertyListNode::emitBytecode): Stores the home object when adding methods.
        (JSC::PropertyListNode::emitPutConstantProperty): Ditto.
        (JSC::BracketAccessorNode::emitBytecode): Added the support for super['foo'].
        (JSC::DotAccessorNode::emitBytecode): Added the support for super.foo.
        (JSC::FunctionCallValueNode::emitBytecode): Added the support for super().
        (JSC::FunctionCallBracketNode::emitBytecode): Added the support for super['foo']().
        (JSC::FunctionCallDotNode::emitBytecode): Added the support for super.foo().
        (JSC::DeleteBracketNode::emitBytecode): Forbid "delete super.foo".
        (JSC::DeleteDotNode::emitBytecode): Forbid "delete super['foo']".
        (JSC::ClassExprNode::emitBytecode): Added the support for "classHeritage". This is the main
        logic for inheritance. When a class B inherits from a class A, set B.__proto__ to A and set
        B.prototype.__proto__ to A.prototype. Throw exceptions when either A or A.__proto__ is not
        an object.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::superExpr): Added.

        * parser/NodeConstructors.h:
        (JSC::SuperNode::SuperNode): Added.

        * parser/Nodes.cpp:
        (JSC::FunctionBodyNode::FunctionBodyNode):

        * parser/Nodes.h:
        (JSC::ExpressionNode::isSuperNode):
        (JSC::PropertyNode::type):
        (JSC::PropertyNode::needsSuperBinding):

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::Parser<LexerType>::parseFunctionInfo): Throw a parser error if super() is used outside
        of class constructors.
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass): ConstructorKind is "derived" if and only if the parent
        class is specified in the declaration / expression.
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseMemberExpression): Added the support for "super()", "super.foo",
        and "super['foo']". Throw a semantic error if "super" appears by itself.

        * parser/Parser.h:
        (JSC::Scope::Scope): Added m_hasDirectSuper. This variable keeps track of the use of "super()"
        so that parseFunctionInfo can spit an error if it's used outside of class constructors.
        (JSC::Scope::hasDirectSuper): Added.
        (JSC::Scope::setHasDirectSuper): Added.

        * parser/ParserModes.h:
        (JSC::ConstructorKind): Added.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::superExpr): Added.

        * runtime/CommonIdentifiers.h: Added homeObjectPrivateName.

        * runtime/Executable.h:
        (JSC::EvalExecutable::executableInfo): 
        (JSC::ProgramExecutable::executableInfo):

2015-03-08  Andreas Kling  <akling@apple.com>

        JITThunks keeps finalized Weaks around, pinning WeakBlocks.
        <https://webkit.org/b/142454>

        Reviewed by Darin Adler.

        Make JITThunks a WeakHandleOwner so it can keep its host function map free of stale entries.
        This fixes an issue I was seeing where a bunch of WeakBlocks stuck around with nothing but
        finalized Weak<NativeExecutable> entries.

        * jit/JITThunks.h:
        * jit/JITThunks.cpp:
        (JSC::JITThunks::finalize): Make JITThunks inherit from WeakHandleOwner so it can receive
        a callback when the NativeExecutables get garbage collected.

        (JSC::JITThunks::hostFunctionStub): Pass 'this' as the handle owner when creating Weaks.

2015-03-08  Andreas Kling  <akling@apple.com>

        BuiltinExecutables keeps finalized Weaks around, pinning WeakBlocks.
        <https://webkit.org/b/142460>

        Reviewed by Geoffrey Garen.

        Make BuiltinExecutables a WeakHandleOwner so it can clear out its respective Weak members
        if and when their pointees get garbage collected.

        This fixes an issue I've seen locally where a WeakBlock is pinned down by a single one of
        these Weak<BuiltinExecutables>.

        * builtins/BuiltinExecutables.h: Make BuiltinExecutables inherit from WeakHandleOwner.

        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::finalize): Clear out the relevant member pointer when it's been
        garbage collected. We use the WeakImpl's "context" field to pass the address of the member.

2015-03-07  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the removal of BlockAllocator, which is now unused.

        * API/JSBase.cpp:
        * CMakeLists.txt:
        * JavaScriptCore.order:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/BlockAllocator.cpp: Removed.
        * heap/BlockAllocator.h: Removed.
        * heap/GCThreadSharedData.h:
        * heap/HandleBlockInlines.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::blockAllocator): Deleted.
        * heap/HeapTimer.cpp:
        * heap/MarkedBlock.h:
        * heap/MarkedSpace.h:
        * heap/Region.h: Removed.
        * heap/SuperRegion.cpp: Removed.
        * heap/SuperRegion.h: Removed.

2015-03-07  Commit Queue  <commit-queue@webkit.org>

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

        Broke media/video-src-invalid-poster.html (Requested by kling
        on #webkit).

        Reverted changeset:

        "Stale entries in WeakGCMaps are keeping tons of WeakBlocks
        alive unnecessarily."
        https://bugs.webkit.org/show_bug.cgi?id=142115
        http://trac.webkit.org/changeset/181010

2015-03-07  Ryosuke Niwa  <rniwa@webkit.org>

        The code to link FunctionExecutable is duplicated everywhere
        https://bugs.webkit.org/show_bug.cgi?id=142436

        Reviewed by Darin Adler.

        Reduced code duplication by factoring out linkInsideExecutable and linkGlobalCode.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock): Calls linkInsideExecutable.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Renamed from link. Now takes care of startOffset.
        This change was needed to use this function in CodeBlock::CodeBlock. Also, this function no longer takes
        lineOffset since this information is already stored in the source code.
        (JSC::UnlinkedFunctionExecutable::linkGlobalCode): Extracted from FunctionExecutable::fromGlobalCode.

        * bytecode/UnlinkedCodeBlock.h:

        * generate-js-builtins: Calls linkGlobalCode.

        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties): Calls linkGlobalCode.
        (JSC::FunctionExecutable::fromGlobalCode): Calls linkGlobalCode.

2015-03-06  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the MarkedBlock piece of this patch.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::capacity):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::freeBlock):

2015-03-07  Ryosuke Niwa  <rniwa@webkit.org>

        fromGlobalCode has an unused Debugger* argument
        https://bugs.webkit.org/show_bug.cgi?id=142430

        Reviewed by Darin Adler.

        Removed the debugger argument from UnlinkedFunctionExecutable::fromGlobalCode and
        FunctionExecutable::fromGlobalCode since it's not used in either function.

        Also use reference in other arguments.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        * bytecode/UnlinkedCodeBlock.h:
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::fromGlobalCode):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunctionSkippingEvalEnabledCheck):

2015-03-06  Brent Fulgham  <bfulgham@apple.com>

        [Win] Turn off a warning on Windows.

        Reduce build logging noise on Windows.

        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:

2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ES6: Improved Support for Iterator Objects
        https://bugs.webkit.org/show_bug.cgi?id=142420

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Runtime.json:
        Add new object subtype "iterator" for built-in iterator objects.

        * inspector/InjectedScriptSource.js:
        Return iterator values as Entry objects.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        Identify "iterator" typed objects.

        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Provide internal properties for the different Iterator objects.

        (Inspector::JSInjectedScriptHost::iteratorEntries):
        Fetch the next few iterator entries of a built-in iterator object.

        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
        Call through to JSInjectedScriptHost.

        * runtime/JSArgumentsIterator.cpp:
        (JSC::JSArgumentsIterator::clone):
        * runtime/JSArgumentsIterator.h:
        (JSC::JSArgumentsIterator::iteratedValue):
        * runtime/JSArrayIterator.cpp:
        (JSC::JSArrayIterator::kind):
        (JSC::JSArrayIterator::iteratedValue):
        (JSC::JSArrayIterator::clone):
        * runtime/JSArrayIterator.h:
        * runtime/JSMapIterator.cpp:
        (JSC::JSMapIterator::finishCreation):
        (JSC::JSMapIterator::clone):
        * runtime/JSMapIterator.h:
        (JSC::JSMapIterator::kind):
        (JSC::JSMapIterator::iteratedValue):
        * runtime/JSSetIterator.cpp:
        (JSC::JSSetIterator::finishCreation):
        (JSC::JSSetIterator::clone):
        * runtime/JSSetIterator.h:
        (JSC::JSSetIterator::kind):
        (JSC::JSSetIterator::iteratedValue):
        * runtime/JSStringIterator.cpp:
        (JSC::JSStringIterator::iteratedValue):
        (JSC::JSStringIterator::clone):
        * runtime/JSStringIterator.h:
        Add accessors for internal properties and provide a way to clone the
        iterator so we can be at the same index and peek at the next few
        objects without modifying the original iterator object.

2015-03-06  Ryosuke Niwa  <rniwa@webkit.org>

        REGRESSION(r180595): construct varargs fails in FTL
        https://bugs.webkit.org/show_bug.cgi?id=142030

        Reviewed by Michael Saboff.

        Increase sizeOfCallVarargs as done for sizeOfConstructVarargs in r180651.

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfCallVarargs):

2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Adopt Object Literal Shorthand Property Construction Syntax
        https://bugs.webkit.org/show_bug.cgi?id=142374

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:

2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Object Literal Extensions - Methods
        https://bugs.webkit.org/show_bug.cgi?id=142390

        Reviewed by Geoffrey Garen.

        Support method syntax in object literals.

        * parser/Parser.h:
        * parser/Parser.cpp:
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseProperty):
        Methods are allowed for identifier, string, and numeric names,
        and computed property names.

        (JSC::Parser<LexerType>::parsePropertyMethod):
        Helper for parsing a property method.

2015-03-05  Joseph Pecoraro  <pecoraro@apple.com>

        __proto__ shorthand property should not modify prototype in Object Literal construction
        https://bugs.webkit.org/show_bug.cgi?id=142382

        Reviewed by Geoffrey Garen.

        When parsing shorthand property syntax we know we will do a
        put direct, even if the property name is __proto__. Pass that
        information through to bytecode generation.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDirectPutById):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitPutConstantProperty):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createProperty):
        * parser/NodeConstructors.h:
        (JSC::PropertyNode::PropertyNode):
        * parser/Nodes.h:
        (JSC::PropertyNode::putType):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseProperty):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createProperty):

2015-03-06  Geoffrey Garen  <ggaren@apple.com>

        Fix crashes seen on the the 32-bit buildbots after my last patch.

        Unreviewed.

        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::payload):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::tryAllocateOversize): Round up to the right alignment,
        since the size of the CopiedBlock class is not guaranteed to be the
        right alignment, and is in fact the wrong alignment on 32-bit.

2015-03-05  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the CopiedBlock piece of this patch.

        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::createNoZeroFill):
        (JSC::CopiedBlock::destroy):
        (JSC::CopiedBlock::create):
        (JSC::CopiedBlock::CopiedBlock):
        (JSC::CopiedBlock::isOversize):
        (JSC::CopiedBlock::payloadEnd):
        (JSC::CopiedBlock::capacity):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::~CopiedSpace):
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocateOversize):
        * heap/CopiedSpaceInlines.h:
        (JSC::CopiedSpace::recycleEvacuatedBlock):
        (JSC::CopiedSpace::recycleBorrowedBlock):
        (JSC::CopiedSpace::allocateBlockForCopyingPhase):
        (JSC::CopiedSpace::allocateBlock):
        (JSC::CopiedSpace::startedCopying):
        * heap/CopyWorkList.h:

2015-03-06  Myles C. Maxfield  <mmaxfield@apple.com>

        [iOS] SVG fonts are garbled
        https://bugs.webkit.org/show_bug.cgi?id=142377

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2015-03-05  Joseph Pecoraro  <pecoraro@apple.com>

        ES6: Object Literal Extensions - Shorthand Properties (Identifiers)
        https://bugs.webkit.org/show_bug.cgi?id=142353

        Reviewed by Geoffrey Garen.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseProperty):
        Parsing an identifier property followed by a comma or end brace treat
        as a shorthand property and create a property that has the same
        property name as the identifier name and value of a variable with that
        identifier. Otherwise, fall through to getter/setter parsing.

2015-03-05  Brent Fulgham  <bfulgham@apple.com>

        [Win] Unreviewed gardening.

        Confirmed with JSC that warning 4611 (interaction between '_setjmp' and C++ object
        destruction is non-portable) should be ignored in the JavaScriptCore project.

        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Silence warning 4611.

2015-03-05  Chris Dumez  <cdumez@apple.com>

        Regression(r173761): ASSERTION FAILED: !is8Bit() in StringImpl::characters16()
        https://bugs.webkit.org/show_bug.cgi?id=142350

        Reviewed by Michael Saboff and Benjamin Poulain.

        Call WTFString::hasInfixStartingAt() / hasInfixEndingAt() now that these
        methods have been renamed for clarity.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):

2015-03-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        Implement ES6 StringIterator
        https://bugs.webkit.org/show_bug.cgi?id=142080

        Reviewed by Filip Pizlo.

        This patch introduces ES6 String Iterator.
        It enumerates code points instead of elements in String.
        So surrogate pairs should be handled correctly.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/StringIterator.prototype.js: Added.
        (next):
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSStringIterator.cpp: Added.
        (JSC::JSStringIterator::finishCreation):
        * runtime/JSStringIterator.h: Added.
        (JSC::JSStringIterator::createStructure):
        (JSC::JSStringIterator::create):
        (JSC::JSStringIterator::JSStringIterator):
        * runtime/StringIteratorConstructor.cpp: Added.
        (JSC::StringIteratorConstructor::finishCreation):
        * runtime/StringIteratorConstructor.h: Added.
        (JSC::StringIteratorConstructor::create):
        (JSC::StringIteratorConstructor::createStructure):
        (JSC::StringIteratorConstructor::StringIteratorConstructor):
        * runtime/StringIteratorPrototype.cpp: Added.
        (JSC::StringIteratorPrototype::finishCreation):
        (JSC::StringIteratorPrototype::getOwnPropertySlot):
        (JSC::stringIteratorPrototypeIterator):
        * runtime/StringIteratorPrototype.h: Added.
        (JSC::StringIteratorPrototype::create):
        (JSC::StringIteratorPrototype::createStructure):
        (JSC::StringIteratorPrototype::StringIteratorPrototype):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncIterator):
        * tests/stress/string-iterators.js: Added.
        (testSurrogatePair):
        (increment):
        (for):

2015-03-05  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Fix the FTL build on Aarch64 Linux after r177421
        https://bugs.webkit.org/show_bug.cgi?id=142040

        Reviewed by Mark Lam.

        * llvm/library/LLVMExports.cpp:
        (initializeAndGetJSCLLVMAPI):

2015-03-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        Upgrade ES6 Iterator interfaces
        https://bugs.webkit.org/show_bug.cgi?id=141351

        Reviewed by Filip Pizlo.

        This patch upgrades the exising ES6 iterator to align the latest spec.
        In the latest spec,
        1. `Iterator.next` returns object that implements IteratorResult interface { value: value, done, boolean }.
        2. `Iterator.return` is introduced. When the iteration is terminated by the abrupt completion,
        it is called to close iterator state.
        3. Iterator.next of Array is moved from an iterator object to `%ArrayIteratorPrototype%`.

        To upgrade it, we changes the bytecode that represents for-of loops.
        And to embody the efficient iteration with an iterator object,
        we implemented %ArrayIteratorPrototype%.next in JavaScript and
        it is located in builtins/ArrayIterator.prototype.js.
        Implementing it in JavaScript encourages inlining and
        utilizes escape analysis for an iterator result object in DFG JIT.
        And we dropped the intrinsic version of %ArrayIteratorPrototype%.next.

        And we introduced IteratorOperations that is defined in the spec.
        It aligns the iteration in the runtime to the latest spec.
        Currently, Promise.all and Promise.race uses an iterable object.
        However, Promise.all and Promise.race implementation is also based on the old spec.
        Subsequent patches will upgrade it.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayIterator.prototype.js: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.h.
        (next):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitThrowTypeError):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::emitIsObject):
        (JSC::BytecodeGenerator::emitIsUndefined):
        * bytecompiler/BytecodeGenerator.h:
        * jit/ThunkGenerators.cpp:
        (JSC::arrayIteratorNextThunkGenerator): Deleted.
        (JSC::arrayIteratorNextKeyThunkGenerator): Deleted.
        (JSC::arrayIteratorNextValueThunkGenerator): Deleted.
        * jit/ThunkGenerators.h:
        * runtime/ArgumentsIteratorPrototype.cpp:
        (JSC::ArgumentsIteratorPrototype::finishCreation):
        (JSC::argumentsIteratorPrototypeFuncNext):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::ArrayIteratorPrototype::getOwnPropertySlot):
        (JSC::arrayIteratorProtoFuncIterator):
        (JSC::arrayIteratorPrototypeIterate): Deleted.
        * runtime/ArrayIteratorPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/Intrinsic.h:
        * runtime/IteratorOperations.cpp: Added.
        (JSC::iteratorNext):
        (JSC::iteratorValue):
        (JSC::iteratorComplete):
        (JSC::iteratorStep):
        (JSC::iteratorClose):
        (JSC::createIterResultObject):
        * runtime/IteratorOperations.h: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.cpp.
        * runtime/JSArrayIterator.cpp:
        (JSC::JSArrayIterator::finishCreation):
        (JSC::JSArrayIterator::visitChildren): Deleted.
        (JSC::createIteratorResult): Deleted.
        (JSC::arrayIteratorNext): Deleted.
        (JSC::arrayIteratorNextKey): Deleted.
        (JSC::arrayIteratorNextValue): Deleted.
        (JSC::arrayIteratorNextGeneric): Deleted.
        * runtime/JSArrayIterator.h:
        (JSC::JSArrayIterator::JSArrayIterator):
        (JSC::JSArrayIterator::iterationKind): Deleted.
        (JSC::JSArrayIterator::iteratedObject): Deleted.
        (JSC::JSArrayIterator::nextIndex): Deleted.
        (JSC::JSArrayIterator::setNextIndex): Deleted.
        (JSC::JSArrayIterator::finish): Deleted.
        (JSC::JSArrayIterator::offsetOfIterationKind): Deleted.
        (JSC::JSArrayIterator::offsetOfIteratedObject): Deleted.
        (JSC::JSArrayIterator::offsetOfNextIndex): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSPromiseConstructor.cpp:
        (JSC::performPromiseRaceLoop):
        (JSC::JSPromiseConstructorFuncRace):
        (JSC::performPromiseAll):
        (JSC::JSPromiseConstructorFuncAll):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):
        * tests/stress/array-iterators-next-with-call.js: Added.
        (increment):
        (for):
        * tests/stress/array-iterators-next.js: Added.

        Revive the older Array iterator tests that manually call 'next' method.

        * tests/stress/custom-iterators.js: Added.
        (iter.next):
        (iter.Symbol.iterator):
        (iter.return):
        (iter.get next):
        (iter.get return):
        (iteratorInterfaceErrorTest.iter.next):
        (iteratorInterfaceErrorTest.iter.Symbol.iterator):
        (iteratorInterfaceErrorTest.iter.return):
        (iteratorInterfaceErrorTest):
        (iteratorInterfaceErrorTestReturn.iter.next):
        (iteratorInterfaceErrorTestReturn.iter.Symbol.iterator):
        (iteratorInterfaceErrorTestReturn.iter.return):
        (iteratorInterfaceErrorTestReturn):
        (iteratorInterfaceBreakTestReturn.iter.next):
        (iteratorInterfaceBreakTestReturn.iter.Symbol.iterator):
        (iteratorInterfaceBreakTestReturn.iter.return):
        (iteratorInterfaceBreakTestReturn):

        This tests the behavior of custom iterators.
        'next' and 'return' of iterator work with for-of.

        * tests/stress/iterators-shape.js: Added.
        (iteratorShape):
        (sameNextMethods):
        (set var):

        This tests the shape of iterators; iterators of Array have 'next' method in %ArrayIteratorPrototype%.

        * tests/stress/map-iterators-next.js: Added.
        (set var):
        (.get if):
        (otherKey):
        * tests/stress/set-iterators-next.js: Added.
        (otherKey):

2015-03-04  Yusuke Suzuki  <utatane.tea@gmail.com>

        Hide Promise with runtime flags under Cocoa JSContext API
        https://bugs.webkit.org/show_bug.cgi?id=141965

        Reviewed by Filip Pizlo.

        Since there's no run loop in JavaScriptCore APIs, Promises don't work currently.
        So until they work, we hide Promise from a global object.
        Introduce new JSC runtime flag, PromiseDisabled. When `isPromiseDisabled` is true,
        Promise constructor is not attached to JSGlobalObject.

        To make 0 as default runtime flags, we choose PromiseDisabled flag
        instead of PromiseEnabled flag. So by default, Promise is enabled.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject<Parent>::JSCallbackObject):
        * API/JSContextRef.cpp:
        (javaScriptRuntimeFlags):
        (JSGlobalContextCreateInGroup):
        * API/tests/testapi.c:
        (main):
        * API/tests/testapi.mm:
        (testObjectiveCAPI):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::create):
        * runtime/RuntimeFlags.h:
        (JSC::RuntimeFlags::createAllEnabled):

2015-03-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Array/Collection Sizes should be visible and distinct
        https://bugs.webkit.org/show_bug.cgi?id=142254

        Reviewed by Timothy Hatcher.

        * runtime/WeakMapData.h:
        (JSC::WeakMapData::size):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::weakMapSize):
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
        Add a way to get a WeakMap's size.

        * inspector/protocol/Runtime.json:
        Include size in RemoteObject and ObjectPreview.

        * inspector/InjectedScriptSource.js:
        Set the size of RemoteObjects and previews if they
        are array/collection types.

2015-03-04  Andreas Kling  <akling@apple.com>

        GC should compute stack bounds and dump registers at the earliest opportunity.
        <https://webkit.org/b/142310>
        <rdar://problem/20045624>

        Reviewed by Geoffrey Garen.

        Make Heap::collect() a wrapper function around a collectImpl() where the work is actually done.
        The wrapper function that grabs a snapshot of the current stack boundaries and register values
        on entry, and sanitizes the stack on exit.

        This is a speculative fix for what appears to be overly conservative behavior in the garbage
        collector following r178364 which caused a measurable regression in memory usage on Membuster.
        The theory being that we were putting pointers to dead things on the stack before scanning it,
        and by doing that ended up marking things that we'd otherwise discover to be garbage.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::collect):
        (JSC::Heap::collectImpl):
        * heap/Heap.h:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::gatherFromCurrentThread):
        (JSC::MachineThreads::gatherConservativeRoots):
        * heap/MachineStackMarker.h:

2015-03-04  Debarshi Ray  <debarshir@gnome.org>

        Silence GCC's -Wstrict-prototypes
        https://bugs.webkit.org/show_bug.cgi?id=142278

        Reviewed by Alexey Proskuryakov.

        * API/JSContextRef.h:

2015-03-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add a node for Math.log()
        https://bugs.webkit.org/show_bug.cgi?id=142126

        Reviewed by Geoffrey Garen.

        This patch adds the DFG node ArithLog for LogIntrinsic.

        Having a direct call to log has very little value by itself, the implementation
        in DFG and FTL is a simple function call.

        What is useful in ArithLog is that we know the operation is pure.
        This allow us to hoist it out of loops when the argument is independent
        is an invariant of the loop.

        Perf wise, this patch gives:
        -Kraken's imaging-darkroom: definitely 1.2372x faster.
        -AsmBench's Towers.c: definitely 1.0261x faster.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * 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:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithLog):
        * 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/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithLog):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doubleLog):
        * tests/stress/math-log-basics.js: Added.
        * tests/stress/math-log-with-constants.js: Added.

2015-03-04  Filip Pizlo  <fpizlo@apple.com>

        Only Heap should be in charge of deciding how to select a subspace for a type
        https://bugs.webkit.org/show_bug.cgi?id=142304

        Reviewed by Mark Lam.
        
        This slightly reduces the code duplication for selecting subspace based on type, and what
        duplication is left is at least localized in HeapInlines.h. The immediate effect is that
        the DFG and FTL don't have to duplicate this pattern.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::allocateObject):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::allocateObjectOfType):
        (JSC::Heap::subspaceForObjectOfType):
        (JSC::Heap::allocatorForObjectOfType):
        * runtime/JSCellInlines.h:
        (JSC::allocateCell):

2015-03-04  Andreas Kling  <akling@apple.com>

        Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
        <https://webkit.org/b/142115>
        <rdar://problem/19992268>

        Reviewed by Geoffrey Garen.

        Prune stale entries from WeakGCMaps as part of every full garbage collection.
        This frees up tons of previously-stuck WeakBlocks that were only sitting around
        with finalized handles waiting to die.

        Note that WeakGCMaps register/unregister themselves with the GC heap in their
        ctor/dtor, so creating one now requires passing the VM.

        Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
        to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
        It seems somewhat excessive to do this on every Eden collection, so it's only
        doing work in full collections for now.

        * API/JSWeakObjectMapRefInternal.h:
        (OpaqueJSWeakObjectMap::create):
        (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * API/JSWrapperMap.mm:
        (-[JSWrapperMap initWithContext:]):
        (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.

        * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
        it project-private so WebCore clients can access it.

        * heap/Heap.cpp:
        (JSC::Heap::collect):
        (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
        stale entries from WeakGCMaps. This is only executed during full collections.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::registerWeakGCMap):
        (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
        themselves with the Heap and provide a pruning callback.

        * runtime/PrototypeMap.h:
        (JSC::PrototypeMap::PrototypeMap):
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.

        * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"

        * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.

        * runtime/VM.cpp:
        (JSC::VM::VM): Pass VM to WeakGCMap constructor.

        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::set):
        (JSC::WeakGCMap::add):
        (JSC::WeakGCMap::WeakGCMap): Deleted.
        (JSC::WeakGCMap::gcMap): Deleted.
        (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
        * runtime/WeakGCMapInlines.h: Added.
        (JSC::WeakGCMap::WeakGCMap):
        (JSC::WeakGCMap::~WeakGCMap):
        (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
        to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
        prunes WeakGCMap at certain growth milestones and instead rely on the GC
        callback for housekeeping.

2015-03-03  Filip Pizlo  <fpizlo@apple.com>

        DFG IR should refer to FunctionExecutables directly and not via the CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=142229

        Reviewed by Mark Lam and Benjamin Poulain.
        
        Anytime a DFG IR node refers to something in CodeBlock, it has three effects:

        - Cumbersome API for accessing the thing that the node refers to.
        
        - Not obvious how to create a new such node after bytecode parsing, especially if the
          thing it refers to isn't already in the CodeBlock. We have done this in the past, but
          it usually involves subtle changes to CodeBlock.
        
        - Not obvious how to inline code that ends up using such nodes. Again, when we have done
          this, it involved subtle changes to CodeBlock.
        
        Prior to this change, the NewFunction* node types used an index into tables in CodeBlock.
        For this reason, those operations were not inlineable. But the functin tables in CodeBlock
        just point to FunctionExecutables, which are cells; this means that we can just abstract
        these operands in DFG IR as cellOperands. cellOperands use DFG::FrozenValue, which means
        that GC registration happens automagically. Even better, our dumping for cellOperand
        already did FunctionExecutable dumping - so that functionality gets to be deduplicated.
        
        Because this change increases the number of users of cellOperand, it also adds some
        convenience methods for using it. For example, whereas before you'd say things like:
        
            jsCast<Foo*>(node->cellOperand()->value())
        
        you can now just say:
        
            node->castOperand<Foo*>()
        
        This change also changes existing cellOperand users to use the new conveniance API when
        applicable.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettisonFunctionDeclsAndExprs):
        * bytecode/CodeBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGFrozenValue.h:
        (JSC::DFG::FrozenValue::cell):
        (JSC::DFG::FrozenValue::dynamicCast):
        (JSC::DFG::FrozenValue::cast):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::registerFrozenValues):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCellOperand):
        (JSC::DFG::Node::castOperand):
        (JSC::DFG::Node::hasFunctionDeclIndex): Deleted.
        (JSC::DFG::Node::functionDeclIndex): Deleted.
        (JSC::DFG::Node::hasFunctionExprIndex): Deleted.
        (JSC::DFG::Node::functionExprIndex): Deleted.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
        (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCheckCell):
        (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):

2015-03-03  Michael Saboff  <msaboff@apple.com>

        DelayedReleaseScope drops locks during GC which can cause a thread switch and code reentry
        https://bugs.webkit.org/show_bug.cgi?id=141275

        Reviewed by Geoffrey Garen.

        The original issue is that the CodeCache uses an unsafe method to add new UnlinkedCodeBlocks.
        It basically adds a null UnlinkedCodeBlock if there isn't a cached entry and then later
        updates the null entry to the result of the compilation.  If during that compilation and
        related processing we need to garbage collect, the DelayedReleaseScope would drop locks
        possibly allowing another thread to try to get the same source out of the CodeCache.
        This second thread would find the null entry and crash.  The fix is to move the processing of
        DelayedReleaseScope to when we drop locks and not drop locks during GC.  That was done in
        the original patch with the new function releaseDelayedReleasedObjects().

        Updated releaseDelayedReleasedObjects() so that objects are released with all locks
        dropped.  Now its processing follows these steps
            Increment recursion counter and do recursion check and exit if recursing
            While there are objects to release
                ASSERT that lock is held by current thread
                Take all items from delayed release Vector and put into temporary Vector
                Release API lock
                Release and clear items from temporary vector
                Reaquire API lock
        This meets the requirement that we release while the API lock is released and it is
        safer processing of the delayed release Vector.

        Added new regression test to testapi.

        Also added comment describing how recursion into releaseDelayedReleasedObjects() is
        prevented.

        * API/tests/Regress141275.h: Added.
        * API/tests/Regress141275.mm: Added.
        (+[JSTEvaluatorTask evaluatorTaskWithEvaluateBlock:completionHandler:]):
        (-[JSTEvaluator init]):
        (-[JSTEvaluator initWithScript:]):
        (-[JSTEvaluator _accessPendingTasksWithBlock:]):
        (-[JSTEvaluator insertSignPostWithCompletion:]):
        (-[JSTEvaluator evaluateScript:completion:]):
        (-[JSTEvaluator evaluateBlock:completion:]):
        (-[JSTEvaluator waitForTasksDoneAndReportResults]):
        (__JSTRunLoopSourceScheduleCallBack):
        (__JSTRunLoopSourcePerformCallBack):
        (__JSTRunLoopSourceCancelCallBack):
        (-[JSTEvaluator _jsThreadMain]):
        (-[JSTEvaluator _sourceScheduledOnRunLoop:]):
        (-[JSTEvaluator _setupEvaluatorThreadContextIfNeeded]):
        (-[JSTEvaluator _callCompletionHandler:ifNeededWithError:]):
        (-[JSTEvaluator _sourcePerform]):
        (-[JSTEvaluator _sourceCanceledOnRunLoop:]):
        (runRegress141275):
        * API/tests/testapi.mm:
        (testObjectiveCAPI):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::releaseDelayedReleasedObjects):
        * runtime/JSLock.cpp:
        (JSC::JSLock::unlock):

2015-03-03  Filip Pizlo  <fpizlo@apple.com>

        DFG should constant fold GetScope, and accesses to the scope register in the ByteCodeParser should not pretend that it's a constant as that breaks OSR exit liveness tracking
        https://bugs.webkit.org/show_bug.cgi?id=106202

        Rubber stamped by Benjamin Poulain.
        
        This fixes a bug discovered by working on https://bugs.webkit.org/show_bug.cgi?id=142229,
        which was in turn discovered by working on https://bugs.webkit.org/show_bug.cgi?id=141174.
        Our way of dealing with scopes known to be constant is very sketchy, and only really works
        when a function is inlined. When it is, we pretend that every load of the scopeRegister sees
        a constant. But this breaks the DFG's tracking of the liveness of the scopeRegister. The way
        this worked made us miss oppportunities for optimizing based on a constant scope, and it also
        meant that in some cases - particularly like when we inline code that uses NewFuction and
        friends, as I do in bug 142229 - it makes OSR exit think that the scope is dead even though
        it's most definitely alive and it's a constant.
        
        The problem here is that we were doing too many optimizations in the ByteCodeParser, and not
        later. Later optimization phases know how to preserve OSR exit liveness. They're actually
        really good at it. Also, later phases know how to infer that any variable is a constant no
        matter how that constant arose - rather than the inlining-specific thing in ByteCodeParser.
        
        This changes the ByteCodeParser to largely avoid doing constant folding on the scope, except
        making the GetScope operation itself a constant. This is a compilation-time hack for small
        functions, and it doesn't break the loads of local variables - so OSR exit liveness still
        sees that the scopeRegister is in use. This then adds a vastly more powerful GetScope and
        GetClosureVar constant folder in the AbstractInterpreter. This handles most general cases
        including those that arise in complex control flow. This will catch cases where the scope
        is constant for any number of reasons. Basically anytime that the callee is inferred constant
        this will give us a constant scope. Also, we still have the parse-time constant folding of
        ResolveScope based on the reentry watchpoint, which luckily did the right thing with respect
        to OSR exit liveness (it splats a Phantom on its inputs, and it produces a constant result
        which is then set() normally).
        
        This appears to be a broad speed-up, albeit a small one. But mainly it unblocks bug 142229,
        which then should unblock bug 141174.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::tryGetConstantClosureVar):
        (JSC::DFG::Graph::tryGetRegisters):
        (JSC::DFG::Graph::tryGetActivation): Deleted.
        * dfg/DFGGraph.h:
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasVariableWatchpointSet):
        (JSC::DFG::Node::hasSymbolTable): Deleted.
        (JSC::DFG::Node::symbolTable): Deleted.
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::visitChildren):
        (JSC::SymbolTable::localToEntry):
        (JSC::SymbolTable::entryFor):
        * runtime/SymbolTable.h:
        (JSC::SymbolTable::add):
        (JSC::SymbolTable::set):
        * tests/stress/function-expression-exit.js: Added.
        * tests/stress/function-reentry-infer-on-self.js: Added.
        (thingy):
        * tests/stress/goofy-function-reentry-incorrect-inference.js: Added.

2015-03-03  Anders Carlsson  <andersca@apple.com>

        Remove unused compression code
        https://bugs.webkit.org/show_bug.cgi?id=142237

        Reviewed by Geoffrey Garen.

        * bytecode/UnlinkedCodeBlock.h:

2015-03-03  Filip Pizlo  <fpizlo@apple.com>

        JIT debugging features that selectively disable the JITs for code blocks need to stay out of the way of the critical path of JIT management
        https://bugs.webkit.org/show_bug.cgi?id=142234

        Reviewed by Mark Lam and Benjamin Poulain.
        
        Long ago, we used to selectively disable compilation of CodeBlocks for debugging purposes by
        adding hacks to DFGDriver.cpp.  This was all well and good.  It used the existing
        CompilationFailed mode of the DFG driver to signal failure of CodeBlocks that we didn't want
        to compile.  That's great because CompilationFailed is a well-supported return value on the
        critical path, usually used for when we run out of JIT memory.

        Later, this was moved into DFGCapabilities. This was basically incorrect. It introduced a bug
        where disabling compiling of a CodeBlock meant that we stopped inlining it as well.  So if
        you had a compiler bug that arose if foo was inlined into bar, and you bisected down to bar,
        then foo would no longer get inlined and you wouldn't see the bug.  That's busted.

        So then we changed the code in DFGCapabilities to mark bar as CanCompile and foo as
        CanInline. Now, foo wouldn't get compiled alone but it would get inlined.

        But then we removed CanCompile because that capability mode only existed for the purpose of
        our old varargs hacks.  After that removal, "CanInline" became CannotCompile.  This means
        that if you bisect down on bar in the "foo inlined into bar" case, you'll crash in the DFG
        because the baseline JIT wouldn't have known to insert profiling on foo.

        We could fix this by bringing back CanInline.

        But this is all a pile of nonsense.  The debug support to selectively disable compilation of
        some CodeBlocks shouldn't cross-cut our entire engine and should most certainly never involve
        adding new capability modes.  This support is a hack at best and is for use by JSC hackers
        only.  It should be as unintrusive as possible.

        So, as in the ancient times, the only proper place to put this hack is in DFGDriver.cpp, and
        return CompilationFailed.  This is correct not just because it takes capability modes out of
        the picture (and obviates the need to introduce new ones), but also because it means that
        disabling compilation doesn't change the profiling mode of other CodeBlocks in the Baseline
        JIT.  Capability mode influences profiling mode which in turn influences code generation in
        the Baseline JIT, sometimes in very significant ways - like, we sometimes do additional
        double-to-int conversions in Baseline if we know that we might tier-up into the DFG, since
        this buys us more precise profiling.
        
        This change reduces the intrusiveness of debugging hacks by making them use the very simple
        CompilationFailed mechanism rather than trying to influence capability modes. Capability
        modes have very subtle effects on the whole engine, while CompilationFailed just makes the
        engine pretend like the DFG compilation will happen at timelike infinity. That makes these
        hacks much more likely to continue working as we make other changes to the system.
        
        This brings back the ability to bisect down onto a function bar when bar inlines foo. Prior
        to this change, we would crash in that case.

        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::isSupported):
        (JSC::DFG::mightCompileEval):
        (JSC::DFG::mightCompileProgram):
        (JSC::DFG::mightCompileFunctionForCall):
        (JSC::DFG::mightCompileFunctionForConstruct):
        * dfg/DFGCapabilities.h:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):

2015-03-03  peavo@outlook.com  <peavo@outlook.com>

        [Win64] JSC compile error.
        https://bugs.webkit.org/show_bug.cgi?id=142216

        Reviewed by Mark Lam.

        There is missing a version of setupArgumentsWithExecState when NUMBER_OF_ARGUMENT_REGISTERS == 4.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        DFG compile time measurements should really report milliseconds
        https://bugs.webkit.org/show_bug.cgi?id=142209

        Reviewed by Benjamin Poulain.
        
        Fix this to record milliseconds instead of seconds.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        Remove op_get_callee, it's unused
        https://bugs.webkit.org/show_bug.cgi?id=142206

        Reviewed by Andreas Kling.
        
        It's a bit of a shame that we stopped using this opcode since it gives us same-callee
        profiling. But, if we were to add this functionality back in, we would almost certainly do
        it by adding a JSFunction allocation watchpoint on FunctionExecutable.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::finalizeUnconditionally):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_callee): Deleted.
        (JSC::JIT::emitSlow_op_get_callee): Deleted.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_callee): Deleted.
        (JSC::JIT::emitSlow_op_get_callee): Deleted.
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): Deleted.

2015-03-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Context Menu to Log a Particular Object
        https://bugs.webkit.org/show_bug.cgi?id=142198

        Reviewed by Timothy Hatcher.

        Add a protocol method to assign a $n index to a value. For an object
        use the injected script context for that object. For a value, use
        the execution context to know where to save the value.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::saveResult):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptSource.js:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::saveResult):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Debugger.json:
        * inspector/protocol/Runtime.json:

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        SpeculativeJIT::emitAllocateArguments() should be a bit faster, and shouldn't do destructor initialization
        https://bugs.webkit.org/show_bug.cgi?id=142197

        Reviewed by Geoffrey Garen.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateArguments): Use shift instead of mul, since mul doesn't automatically strength-reduce to shift. Also pass the structure as a TrustedImmPtr.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject): Rationalize this a bit. The other emitAllocate... methods take a templated structure so that it can be either a TrustedImmPtr or a register. Also don't do destructor initialization, since its one client doesn't need it, and it's actually probably wrong.

2015-03-02  Mark Lam  <mark.lam@apple.com>

        Exception stack unwinding in JSC hangs while the Timeline Profiler is enabled.
        <https://webkit.org/b/142191>

        Reviewed by Geoffrey Garen.

        Imagine a scenario where the Inspector is paused / suspended at a breakpoint or
        while the user is stepping through JS code. The user then tries to evaluate an
        expression in the console, and that evaluation results in an exception being
        thrown. Currently, if the Timeline Profiler is enabled while this exception is
        being thrown, the WebProcess will hang while trying to handle that exception.

        The issue is that the Timeline Profiler's ProfileGenerator::didExecute() will
        return early and decline to process ProfileNodes if the Inspector is paused.
        This is proper because it does not want to count work done for injected scripts
        (e.g. from the console) towards the timeline profile of the webpage being run.
        However, this is in conflict with ProfileGenerator::exceptionUnwind()'s
        expectation that didExecute() will process ProfileNodes in order to do the stack
        unwinding for the exception handling. As a result,
        ProfileGenerator::exceptionUnwind() hangs.

        ProfileGenerator::exceptionUnwind() is in error. While the Inspector is paused,
        there will not be any ProfileNodes that it needs to "unwind". Hence, the fix is
        simply to return early also in ProfileGenerator::exceptionUnwind() if the
        Inspector is paused.

        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::exceptionUnwind):

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        FTL should correctly document where it puts the argument count for inlined varargs frames
        https://bugs.webkit.org/show_bug.cgi?id=142187

        Reviewed by Geoffrey Garn.
        
        After LLVM tells us where the captured variables alloca landed in the frame, we need to
        tell all of our meta-data about it. We were forgetting to do so for the argument count
        register, which is used by inlined varargs calls.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * tests/stress/inline-varargs-get-arguments.js: Added.
        (foo):
        (bar):
        (baz):

2015-03-02  Filip Pizlo  <fpizlo@apple.com>

        Deduplicate slow path calling code in JITOpcodes.cpp/JITOpcodes32_64.cpp
        https://bugs.webkit.org/show_bug.cgi?id=142184

        Reviewed by Michael Saboff.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_enumerable_length):
        (JSC::JIT::emitSlow_op_has_structure_property):
        (JSC::JIT::emit_op_has_generic_property):
        (JSC::JIT::emit_op_get_structure_property_enumerator):
        (JSC::JIT::emit_op_get_generic_property_enumerator):
        (JSC::JIT::emit_op_to_index_string):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_enumerable_length): Deleted.
        (JSC::JIT::emitSlow_op_has_structure_property): Deleted.
        (JSC::JIT::emit_op_has_generic_property): Deleted.
        (JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
        (JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
        (JSC::JIT::emit_op_to_index_string): Deleted.
        (JSC::JIT::emit_op_profile_control_flow): Deleted.

2015-03-02  Antti Koivisto  <antti@apple.com>

        Add way to dump cache meta data to file
        https://bugs.webkit.org/show_bug.cgi?id=142183

        Reviewed by Andreas Kling.

        Export appendQuotedJSONStringToBuilder.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::toString):
        * runtime/JSONObject.cpp:
        (JSC::appendQuotedJSONStringToBuilder):
        (JSC::Stringifier::appendQuotedString):
        (JSC::escapeStringToBuilder): Deleted.
        * runtime/JSONObject.h:

2015-03-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Add Context Menus to Object Tree properties
        https://bugs.webkit.org/show_bug.cgi?id=142125

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::functionDetails):
        Update to include columnNumber.

2015-03-01  Filip Pizlo  <fpizlo@apple.com>

        BytecodeGenerator shouldn't emit op_resolve_scope as a roundabout way of returning the scopeRegister
        https://bugs.webkit.org/show_bug.cgi?id=142153

        Reviewed by Michael Saboff.
        
        We don't need a op_resolve_scope if we know that it will simply return the scope register.
        This changes the BytecodeGenerator to use the scope register directly in those cases where
        we know statically that we would just have returned that from op_resolve_scope.
        
        This doesn't appear to have a significant impact on performance.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitReturn):
        (JSC::BytecodeGenerator::emitGetOwnScope): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::DeleteResolveNode::emitBytecode):
        (JSC::TypeOfResolveNode::emitBytecode):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::EmptyVarExpression::emitBytecode):
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        (JSC::BindingNode::bindValue):

2015-02-27  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Use the way number constants are written to help type speculation
        https://bugs.webkit.org/show_bug.cgi?id=142072

        Reviewed by Filip Pizlo.

        This patch changes how we interpret numeric constant based on how they appear
        in the source.

        Constants that are integers but written with a decimal point now carry that information
        to the optimizating tiers. From there, we use that to be more aggressive about typing
        math operations toward double operations.

        For example, in:
            var a = x + 1.0;
            var b = y + 1;
        The Add for a would be biased toward doubles, the Add for b would speculate
        integer as usual.


        The gains are tiny but this is a prerequisite to make my next patch useful:
        -SunSpider's access-fannkuch: definitely 1.0661x faster
        -SunSpider's math-cordic: definitely 1.0266x slower
            overal: might be 1.0066x slower.
        -Kraken's imaging-darkroom: definitely 1.0333x faster.

        * parser/Lexer.cpp:
        (JSC::tokenTypeForIntegerLikeToken):
        (JSC::Lexer<T>::lex):
        The lexer now create two types of tokens for number: INTEGER and DOUBLE.
        Those token types only carry information about how the values were
        entered, an INTEGER does not have to be an integer, it is only written like one.
        Large integer still end up represented as double in memory.

        One trap I fell into was typing numbers like 12e3 as double. This kind of literal
        is frequently used in integer-typed code, while 12.e3 would appear in double-typed
        code.
        Because of that, the only signals for double are: decimal point, negative zero,
        and ridiculously large values.

        * parser/NodeConstructors.h:
        (JSC::DoubleNode::DoubleNode):
        (JSC::IntegerNode::IntegerNode):
        * parser/Nodes.h:
        (JSC::NumberNode::value):
        (JSC::NumberNode::setValue): Deleted.
        Number get specialized in two new kind of nodes in the AST: IntegerNode and DoubleNode.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::NumberNode::emitBytecode):

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createDoubleExpr):
        (JSC::ASTBuilder::createIntegerExpr):
        (JSC::ASTBuilder::createIntegerLikeNumber):
        (JSC::ASTBuilder::createDoubleLikeNumber):
        (JSC::ASTBuilder::createNumberFromBinaryOperation):
        (JSC::ASTBuilder::createNumberFromUnaryOperation):
        (JSC::ASTBuilder::makeNegateNode):
        (JSC::ASTBuilder::makeBitwiseNotNode):
        (JSC::ASTBuilder::makeMultNode):
        (JSC::ASTBuilder::makeDivNode):
        (JSC::ASTBuilder::makeModNode):
        (JSC::ASTBuilder::makeAddNode):
        (JSC::ASTBuilder::makeSubNode):
        (JSC::ASTBuilder::makeLeftShiftNode):
        (JSC::ASTBuilder::makeRightShiftNode):
        (JSC::ASTBuilder::makeURightShiftNode):
        (JSC::ASTBuilder::makeBitOrNode):
        (JSC::ASTBuilder::makeBitAndNode):
        (JSC::ASTBuilder::makeBitXOrNode):
        (JSC::ASTBuilder::createNumberExpr): Deleted.
        (JSC::ASTBuilder::createNumber): Deleted.
        The AST has some optimization to resolve constants before emitting bytecode.
        In the new code, the intger representation is kept if both operands where
        also represented as integers.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDeconstructionPattern):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        * parser/ParserTokens.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createDoubleExpr):
        (JSC::SyntaxChecker::createIntegerExpr):
        (JSC::SyntaxChecker::createNumberExpr): Deleted.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::registerName):
        (JSC::CodeBlock::constantName):
        Change constantName(r, getConstant(r)) -> constantName(r) to simplify
        the dump code.

        (JSC::CodeBlock::dumpBytecode):
        Dump thre soure representation information we have with each constant.

        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::constantName): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::constantsSourceCodeRepresentation):
        (JSC::CodeBlock::addConstant):
        (JSC::CodeBlock::addConstantLazily):
        (JSC::CodeBlock::constantSourceCodeRepresentation):
        (JSC::CodeBlock::setConstantRegisters):

        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addConstant):
        (JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation):
        (JSC::UnlinkedCodeBlock::shrinkToFit):

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addConstantValue):
        (JSC::BytecodeGenerator::emitLoad):
        * bytecompiler/BytecodeGenerator.h:
        We have to differentiate between constants that have the same values but are
        represented differently in the source. Values like 1.0 and 1 now end up
        as different constants.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::addConstantToGraph):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::registerFrozenValues):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addSpeculationMode):
        (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
        ArithAdd is very aggressive toward using Int52, which is quite useful
        in many benchmarks.

        Here we need to specialize to make sure we don't force our literals
        to Int52 if there were represented as double.

        There is one exception to that rule: when the other operand is guaranteed
        to come from a NodeResultInt32. This is because there is some weird code
        doing stuff like:
            var b = a|0;
            var c = b*2.0;

        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (JSC::DFG::Node::setOpAndDefaultFlags):
        (JSC::DFG::Node::sourceCodeRepresentation):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * runtime/JSCJSValue.h:
        (JSC::EncodedJSValueWithRepresentationHashTraits::emptyValue):
        (JSC::EncodedJSValueWithRepresentationHashTraits::constructDeletedValue):
        (JSC::EncodedJSValueWithRepresentationHashTraits::isDeletedValue):
        (JSC::EncodedJSValueWithRepresentationHash::hash):
        (JSC::EncodedJSValueWithRepresentationHash::equal):
        * tests/stress/arith-add-with-constants.js: Added.
        * tests/stress/arith-mul-with-constants.js: Added.

2015-02-26  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out r180723. It broke a bunch of tests.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::constLocal):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ConstDeclNode::emitCodeSingle):
        * tests/stress/const-arguments.js: Removed.

2015-02-26  Mark Lam  <mark.lam@apple.com>

        Assertion fix for r180711: The bool returning form of BytecodeGenerator::addVar() can be removed.
        <https://webkit.org/b/142064>

        Reviewed by Joseph Pecoraro.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):

2015-02-26  Mark Lam  <mark.lam@apple.com>

        MachineThreads::Thread clean up has a use after free race condition.
        <https://webkit.org/b/141990>

        Reviewed by Filip Pizlo.

        MachineThreads::Thread clean up relies on the clean up mechanism
        implemented in _pthread_tsd_cleanup_key(), which looks like this:

        void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
        {
            void (*destructor)(void *);
            if (_pthread_key_get_destructor(key, &destructor)) {
                void **ptr = &self->tsd[key];
                void *value = *ptr;

            // === Start of window for the bug to manifest =================

                // At this point, this thread has cached "destructor" and "value"
                // (which is a MachineThreads*).  If the VM gets destructed (along
                // with its MachineThreads registry) by another thread, then this
                // thread will have no way of knowing that the MachineThreads* is
                // now pointing to freed memory.  Calling the destructor below will
                // therefore result in a use after free scenario when it tries to
                // access the MachineThreads' data members.

                if (value) {
                    *ptr = NULL;
                    if (destructor) {

            // === End of window for the bug to manifest ==================

                        destructor(value);
                    }
                }
            }
        }

        The fix is to add each active MachineThreads to an ActiveMachineThreadsManager,
        and always check if the manager still contains that MachineThreads object
        before we call removeCurrentThread() on it.  When MachineThreads is destructed,
        it will remove itself from the manager.  The add, remove, and checking
        operations are all synchronized on the manager's lock, thereby ensuring that
        the MachineThreads object, if found in the manager, will remain alive for the
        duration of time we call removeCurrentThread() on it.

        There's also possible for the MachineThreads object to already be destructed
        and another one happened to have been instantiated at the same address.
        Hence, we should only remove the exiting thread if it is found in the
        MachineThreads object.

        There is no test for this issue because this bug requires a race condition
        between 2 threads where:
        1. Thread B, which had previously used the VM, exiting and
           getting to the bug window shown in _pthread_tsd_cleanup_key() above.
        2. Thread A destructing the VM (and its MachineThreads object)
           within that window of time before Thread B calls the destructor.

        It is not possible to get a reliable test case without invasively
        instrumenting _pthread_tsd_cleanup_key() or MachineThreads::removeCurrentThread()
        to significantly increase that window of opportunity.

        * heap/MachineStackMarker.cpp:
        (JSC::ActiveMachineThreadsManager::Locker::Locker):
        (JSC::ActiveMachineThreadsManager::add):
        (JSC::ActiveMachineThreadsManager::remove):
        (JSC::ActiveMachineThreadsManager::contains):
        (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
        (JSC::activeMachineThreadsManager):
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::removeThreadIfFound):
        (JSC::MachineThreads::removeCurrentThread): Deleted.
        * heap/MachineStackMarker.h:

2015-02-26  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Save Console Evaluations into Command Line variables $1-$99 ($n)
        https://bugs.webkit.org/show_bug.cgi?id=142061

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Debugger.json:
        * inspector/protocol/Runtime.json:
        Input flag "saveResult" on whether we should try to save a result.
        Output int "savedResultIndex" to tell the frontend the saved state.

        * inspector/InjectedScriptSource.js:
        Handle saving and clearing $1-$99 values.
        Include in BasicCommandLineAPI for JSContext inspection.

        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeEvalCall):
        * inspector/InjectedScriptBase.h:
        Allow an optional "savedResultIndex" out value on evals.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::evaluate):
        (Inspector::InjectedScript::evaluateOnCallFrame):
        * inspector/InjectedScript.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::evaluate):
        * inspector/agents/InspectorRuntimeAgent.h:
        Plumbing for new in and out parameters.

2015-02-26  Filip Pizlo  <fpizlo@apple.com>

        The bool returning form of BytecodeGenerator::addVar() can be removed
        https://bugs.webkit.org/show_bug.cgi?id=142064

        Reviewed by Mark Lam.
        
        It's easier to implement addVar() when you don't have to return whether it's a new
        variable or not.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::addVar): Deleted.

2015-02-26  Filip Pizlo  <fpizlo@apple.com>

        Various array access corner cases should take OSR exit feedback
        https://bugs.webkit.org/show_bug.cgi?id=142056

        Reviewed by Geoffrey Garen.
        
        Two major changes here:
        
        - Don't keep converting GetById into GetArrayLength if we exited due to any kind of array
          type check.
        
        - Use a generic form of GetByVal/PutByVal if we exited due to any kind of exotic checks,
          like the Arguments safety checks. We use the "ExoticObjectMode" for out-of-bounds on
          arguments for now, since it's a convenient way of forcing out-of-bounds to be handled by
          the Generic array mode.

        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        * tests/stress/array-length-array-storage-plain-object.js: Added.
        (foo):
        * tests/stress/array-length-plain-object.js: Added.
        (foo):

2015-02-25  Filip Pizlo  <fpizlo@apple.com>

        DFG SSA stack accesses shouldn't speak of VariableAccessDatas
        https://bugs.webkit.org/show_bug.cgi?id=142036

        Reviewed by Michael Saboff.
        
        VariableAccessData is a useful thing in LoadStore and ThreadedCPS, but it's purely harmful in
        SSA because you can't cook up new VariableAccessDatas. So, if you know that you want to load
        or store to the stack, and you know what format to use as well as the location, then prior to
        this patch you couldn't do it unless you found some existing VariableAccessData that matched
        your requirements. That can be a hard task.
        
        It's better if SSA doesn't speak of VariableAccessDatas but instead just has stack accesses
        that speak of the things that a stack access needs: local, machineLocal, and format. This
        patch changes the SSA way of accessing the stack to do just that.
        
        Also add more IR validation.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * 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/DFGFlushFormat.h:
        (JSC::DFG::isConcrete):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::hasVariableAccessData):
        * dfg/DFGNode.h:
        (JSC::DFG::StackAccessData::StackAccessData):
        (JSC::DFG::StackAccessData::flushedAt):
        (JSC::DFG::Node::convertToPutStack):
        (JSC::DFG::Node::convertToGetStack):
        (JSC::DFG::Node::hasUnlinkedLocal):
        (JSC::DFG::Node::hasStackAccessData):
        (JSC::DFG::Node::stackAccessData):
        (JSC::DFG::Node::willHaveCodeGenOrOSR):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPutLocalSinkingPhase.cpp: Removed.
        * dfg/DFGPutLocalSinkingPhase.h: Removed.
        * dfg/DFGPutStackSinkingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.cpp.
        (JSC::DFG::performPutStackSinking):
        (JSC::DFG::performPutLocalSinking): Deleted.
        * dfg/DFGPutStackSinkingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.h.
        * 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/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::validateCPS):
        (JSC::DFG::Validate::validateSSA):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetStack):
        (JSC::FTL::LowerDFGToLLVM::compilePutStack):
        (JSC::FTL::LowerDFGToLLVM::compileGetLocal): Deleted.
        (JSC::FTL::LowerDFGToLLVM::compilePutLocal): Deleted.
        * ftl/FTLOSRExit.h:
        * tests/stress/many-sunken-locals.js: Added. This failure mode was caught by some miscellaneous test, so I figured I should write an explicit test for it.
        (foo):
        (bar):
        (baz):
        (fuzz):
        (buzz):

2015-02-26  Mark Lam  <mark.lam@apple.com>

        Rolling out r180602, r180608, r180613, r180617, r180671.
        <https://webkit.org/b/141990>

        Not reviewed.

        The r180602 solution does result in more work for GC when worker
        threads are in use.  Filip is uncomfortable with that.
        The EFL and GTK ports also seem to be unhappy with this change.
        Rolling out while we investigate.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::gatherStackRoots):
        (JSC::Heap::machineThreads): Deleted.
        * heap/Heap.h:
        (JSC::Heap::machineThreads):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        * heap/MachineStackMarker.h:
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):

2015-02-26  Myles C. Maxfield  <mmaxfield@apple.com>

        [Mac] [iOS] Parsing support for -apple-trailing-word
        https://bugs.webkit.org/show_bug.cgi?id=141939

        Reviewed by Andreas Kling.

        * Configurations/FeatureDefines.xcconfig:

2015-02-26  Michael Saboff  <msaboff@apple.com>

        [Win] Debug-only JavaScriptCore failures
        https://bugs.webkit.org/show_bug.cgi?id=142045

        Rubber stamped by Filip Pizlo.

        Reduced loop count to a more reasonable value of 10,000.  This still gets us to tier up
        to the FTL, but doesn't take too long to run.

        * tests/stress/repeated-arity-check-fail.js:

2015-02-26  Brent Fulgham  <bfulgham@apple.com>

        [Win] Make build logs more legible by reducing noise
        https://bugs.webkit.org/show_bug.cgi?id=142034

        Reviewed by Alexey Proskuryakov.

        Modify batch files, makefiles, and DOS commands to remove
        uninteresting/unhelpful output.

        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
        * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd:
        * JavaScriptCore.vcxproj/copy-files.cmd:
        * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd:
        * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd:

2015-02-26  Csaba Osztrogonác  <ossy@webkit.org>

        Add calleeSaveRegisters() implementation for ARM Traditional
        https://bugs.webkit.org/show_bug.cgi?id=141903

        Reviewed by Darin Adler.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::calleeSaveRegisters):

2015-02-25  Michael Saboff  <msaboff@apple.com>

        Web Inspector: CRASH when debugger pauses inside a Promise handler
        https://bugs.webkit.org/show_bug.cgi?id=141396

        Reviewed by Mark Lam.

        For frames that don't have a scope, typically native frames, use the lexicalGlobalObject to
        create the DebuggerScope for that frame.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::scope):

2015-02-25  Filip Pizlo  <fpizlo@apple.com>

        DFG abstract heaps should respect the difference between heap and stack
        https://bugs.webkit.org/show_bug.cgi?id=142022

        Reviewed by Geoffrey Garen.
        
        We will soon (https://bugs.webkit.org/show_bug.cgi?id=141174) be in a world where a "world
        clobbering" operation cannot write to our stack, but may be able to read from it. This
        means that we need to change the DFG abstract heap hierarchy to have a notion of Heap that
        subsumes all that World previously subsumed, and a new notion of Stack that is a subtype
        of World and a sibling of Heap.

        So, henceforth "clobbering the world" means reading World and writing Heap.
        
        This makes a bunch of changes to make this work, including changing the implementation of
        disjointness in AbstractHeap to make it support a more general hierarchy. I was expecting
        a slow-down, but I measured the heck out of this and found no perf difference.

        * dfg/DFGAbstractHeap.cpp:
        (JSC::DFG::AbstractHeap::dump):
        * dfg/DFGAbstractHeap.h:
        (JSC::DFG::AbstractHeap::supertype):
        (JSC::DFG::AbstractHeap::isStrictSubtypeOf):
        (JSC::DFG::AbstractHeap::isSubtypeOf):
        (JSC::DFG::AbstractHeap::overlaps):
        (JSC::DFG::AbstractHeap::isDisjoint):
        * dfg/DFGClobberize.cpp:
        (JSC::DFG::clobbersHeap):
        (JSC::DFG::clobbersWorld): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

2015-02-25  Ryosuke Niwa  <rniwa@webkit.org>

        REGRESSION(r180595): construct varargs fails in FTL
        https://bugs.webkit.org/show_bug.cgi?id=142030

        Reviewed by Geoffrey Garen.

        The bug was caused by IC size being too small for construct_varargs even though we've added a new argument.
        Fixed the bug by increasing the IC size to match call_varargs.

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfConstructVarargs):

2015-02-25  Mark Lam  <mark.lam@apple.com>

        ASan does not like JSC::MachineThreads::tryCopyOtherThreadStack.
        <https://webkit.org/b/141672>

        Reviewed by Alexey Proskuryakov.

        ASan does not like the fact that we memcpy the stack for GC scans.  So,
        we're working around this by using our own memcpy (asanUnsafeMemcpy)
        implementation that we can tell ASan to ignore.

        * heap/MachineStackMarker.cpp:
        (JSC::asanUnsafeMemcpy):

2015-02-25  Benjamin Poulain  <bpoulain@apple.com>

        CodeBlock crashes when dumping op_push_name_scope
        https://bugs.webkit.org/show_bug.cgi?id=141953

        Reviewed by Filip Pizlo and Csaba Osztrogonác.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * tests/stress/op-push-name-scope-crashes-profiler.js: Added.

2015-02-25  Benjamin Poulain  <benjamin@webkit.org>

        Make ParserError immutable by design
        https://bugs.webkit.org/show_bug.cgi?id=141955

        Reviewed by Geoffrey Garen.

        This patch enforce that no field of ParserError can
        be modified after the constructor.

        * parser/ParserError.h:
        Move the attributes to pack the integer + 2 bytes together.
        This is irrelevant for memory impact, it is to remve a load-store
        when copying by value.

        Also move the attributes to be private.

        (JSC::ParserError::isValid):
        To client of the interface cared about the type of the error,
        the only information needed was: is there an error.

        (JSC::ParserError::ParserError):
        (JSC::ParserError::syntaxErrorType):
        (JSC::ParserError::token):
        (JSC::ParserError::message):
        (JSC::ParserError::line):
        (JSC::ParserError::toErrorObject):
        * API/JSScriptRef.cpp:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createBuiltinExecutable):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
        (JSC::UnlinkedFunctionExecutable::codeBlockFor):
        * bytecode/UnlinkedCodeBlock.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::parse):
        * jsc.cpp:
        (runInteractive):
        * parser/Parser.h:
        (JSC::parse):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/Completion.h:
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createProgramCodeBlock):
        (JSC::JSGlobalObject::createEvalCodeBlock):

2015-02-25  Filip Pizlo  <fpizlo@apple.com>

        Need to pass RTLD_DEEPBIND to dlopen() to ensure that our LLVMOverrides take effect on Linux
        https://bugs.webkit.org/show_bug.cgi?id=142006

        Reviewed by Csaba Osztrogonác.

        This fixes hard-to-reproduce concurrency-related crashes when running stress tests with FTL and
        concurrent JIT enabled.

        * llvm/InitializeLLVMPOSIX.cpp:
        (JSC::initializeLLVMPOSIX):

2015-02-24  Filip Pizlo  <fpizlo@apple.com>

        CMake build of libllvmForJSC.so should limit its export list like the Xcode build does
        https://bugs.webkit.org/show_bug.cgi?id=141989

        Reviewed by Gyuyoung Kim.

        * CMakeLists.txt:
        * llvm/library/libllvmForJSC.version: Added.

2015-02-24  Alexey Proskuryakov  <ap@apple.com>

        More iOS build fix after r180602.

        * heap/Heap.h: Export Heap::machineThreads().

2015-02-24  Brent Fulgham  <bfulgham@apple.com>

        Unreviewed build fix after r180602.

        * heap/MachineStackMarker.h: Add missing 'no return'
        declaration for Windows.

2015-02-24  Commit Queue  <commit-queue@webkit.org>

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

        Lots of new test failures (Requested by smfr on #webkit).

        Reverted changeset:

        "Parsing support for -webkit-trailing-word"
        https://bugs.webkit.org/show_bug.cgi?id=141939
        http://trac.webkit.org/changeset/180599

2015-02-24  Mark Lam  <mark.lam@apple.com>

        MachineThreads::Thread clean up has a use after free race condition.
        <https://webkit.org/b/141990>

        Reviewed by Michael Saboff.

        MachineThreads::Thread clean up relies on the clean up mechanism
        implemented in _pthread_tsd_cleanup_key(), which looks like this:

        void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
        {
            void (*destructor)(void *);
            if (_pthread_key_get_destructor(key, &destructor)) {
                void **ptr = &self->tsd[key];
                void *value = *ptr;

                // At this point, this thread has cached "destructor" and "value"
                // (which is a MachineThreads*).  If the VM gets destructed (along
                // with its MachineThreads registry) by another thread, then this
                // thread will have no way of knowing that the MachineThreads* is
                // now pointing to freed memory.  Calling the destructor below will
                // therefore result in a use after free scenario when it tries to
                // access the MachineThreads' data members.

                if (value) {
                    *ptr = NULL;
                    if (destructor) {
                        destructor(value);
                    }
                }
            }
        }

        The solution is simply to change MachineThreads from a per VM thread
        registry to a process global singleton thread registry i.e. the
        MachineThreads registry is now immortal and we cannot have a use after
        free scenario since we never free it.

        The cost of this change is that all VM instances will have to scan
        stacks of all threads ever touched by a VM, and not just those that
        touched a specific VM.  However, stacks tend to be shallow.  Hence,
        those additional scans will tend to be cheap.

        Secondly, it is not common for there to be multiple JSC VMs in use
        concurrently on multiple threads.  Hence, this cost should rarely
        manifest in real world applications.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::machineThreads):
        (JSC::Heap::gatherStackRoots):
        * heap/Heap.h:
        (JSC::Heap::machineThreads): Deleted.
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        * heap/MachineStackMarker.h:
        * runtime/JSLock.cpp:
        (JSC::JSLock::didAcquireLock):

2015-02-24  Myles C. Maxfield  <mmaxfield@apple.com>

        [Mac] [iOS] Parsing support for -apple-trailing-word
        https://bugs.webkit.org/show_bug.cgi?id=141939

        Reviewed by Andreas Kling.

        * Configurations/FeatureDefines.xcconfig:

2015-02-24  Ryosuke Niwa  <rniwa@webkit.org>

        Use "this" instead of "callee" to get the constructor
        https://bugs.webkit.org/show_bug.cgi?id=141019

        Reviewed by Filip Pizlo.

        This patch uses "this" register to pass the constructor (newTarget) to op_create_this from
        op_construct or op_construct_varargs. This will allow future patches that implement ES6 class
        to pass in the most derived class' constructor through "this" argument.

        BytecodeGenerator's emitConstruct and emitConstructVarargs now passes thisRegister like
        regular calls and emitCreateThis passes in this register to op_create_this as constructor.

        The rest of the code change removes the code for special casing "this" register not being used
        in call to construct.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::NewExprNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::reconstruct):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * ftl/FTLJSCallVarargs.cpp:
        (JSC::FTL::JSCallVarargs::emit):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeConstruct):
        * jit/JITOperations.cpp:

2015-02-24  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Make Getter/Setter RemoteObject property and ObjectPreview handling consistent
        https://bugs.webkit.org/show_bug.cgi?id=141587

        Reviewed by Timothy Hatcher.

        Convert getProperties(ownAndGetterProperties) to getDisplayableProperties().
        Mark PropertyDescriptors that are presumed to be native getters / bindings
        separately so that the frontend may display them differently.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getDisplayableProperties):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptSource.js:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getProperties):
        (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Runtime.json:

2015-02-24  Mark Lam  <mark.lam@apple.com>

        Rolling out r179753.  The fix was invalid.
        <https://webkit.org/b/141990>

        Not reviewed.

        * API/tests/testapi.mm:
        (threadMain):
        (useVMFromOtherThread): Deleted.
        (useVMFromOtherThreadAndOutliveVM): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::~Heap):
        (JSC::Heap::gatherStackRoots):
        * heap/Heap.h:
        (JSC::Heap::machineThreads):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::removeCurrentThread):
        * heap/MachineStackMarker.h:

2015-02-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        Constructor returning null should construct an object instead of null
        https://bugs.webkit.org/show_bug.cgi?id=141640

        Reviewed by Filip Pizlo.

        When constructor code doesn't return object, constructor should return `this` object instead.
        Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
        it allows `null` as an object.
        This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
        Instead, constructor uses simplified `is_object`.

        As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.

        1. LLInt and baseline JIT support `op_is_object` as a fast path.
        2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
        3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
        4. FTL lowers DFG's IsObject into LLVM IR.

        And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
        in LLInt, JIT, DFG and FTL.
        Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
        So in many places, when the cell is not object, we recognize it as a string, and vice versa.
        However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
        So this patch stop using !isString as isObject.
        To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
        we examine typeInfo in JSCell.

        * JavaScriptCore.order:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::emitReturn):
        * 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):

        IsObject operation only touches JSCell typeInfoType.
        And this value would be changed through structure transition.
        As a result, IsObject can report that it doesn't read any information.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

        Just like IsString, IsObject is also fixed up.

        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
        (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
        (JSC::DFG::SpeculativeJIT::speculateObject):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        (JSC::DFG::SpeculativeJIT::emitSwitchString):
        (JSC::DFG::SpeculativeJIT::branchIsObject):
        (JSC::DFG::SpeculativeJIT::branchNotObject):
        (JSC::DFG::SpeculativeJIT::branchIsString):
        (JSC::DFG::SpeculativeJIT::branchNotString):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileToString):
        (JSC::FTL::LowerDFGToLLVM::compileIsObject):
        (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
        (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
        (JSC::FTL::LowerDFGToLLVM::isObject):
        (JSC::FTL::LowerDFGToLLVM::isNotObject):
        (JSC::FTL::LowerDFGToLLVM::isNotString):
        (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::emitJumpIfCellObject):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::compileOpStrictEq):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/Operations.cpp:
        (JSC::jsIsObjectTypeOrNull):
        (JSC::jsIsObjectType): Deleted.
        * runtime/Operations.h:
        * tests/stress/constructor-with-return.js: Added.
        (Test):

        When constructor doesn't return an object, `this` should be returned instead.
        In this test, we check all primitives. And test object, array and wrappers.

        * tests/stress/dfg-to-primitive-pass-symbol.js: Added.
        (toPrimitiveTarget):
        (doToPrimitive):

        op_to_primitive operation passes Symbol in fast path.

2015-02-24  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r179429): Can't type comments in Facebook
        https://bugs.webkit.org/show_bug.cgi?id=141859

        Reviewed by Brent Fulgham.

        When window.Symbol is exposed to user-space pages,
        Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
        However, to work with Symbols completely, it also requires
        1) Object.getOwnPropertySymbols (for mixin including Symbols)
        2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
        Since they are not landed yet, comments in Facebook don't work.

        This patch introduces RuntimeFlags for JavaScriptCore.
        Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
        And drop JavaScriptExperimentsEnabled flag
        because it is no longer used and use case of this is duplicated to runtime flags.

        * JavaScriptCore.order:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (GlobalObject::javaScriptRuntimeFlags):
        (GlobalObject::javaScriptExperimentsEnabled): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::finishCreation):
        (JSC::JSGlobalObject::javaScriptRuntimeFlags):
        (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
        * runtime/RuntimeFlags.h: Added.
        (JSC::RuntimeFlags::RuntimeFlags):
        (JSC::RuntimeFlags::createAllEnabled):

2015-02-23  Filip Pizlo  <fpizlo@apple.com>

        Our bizarre behavior on Arguments::defineOwnProperty should be deliberate rather than a spaghetti incident
        https://bugs.webkit.org/show_bug.cgi?id=141951

        Reviewed by Benjamin Poulain.
        
        This patch has no behavioral change, but it simplifies a bunch of wrong code. The code is
        still wrong in exactly the same way, but at least it's obvious what's going on. The wrongness
        is covered by this bug: https://bugs.webkit.org/show_bug.cgi?id=141952.

        * runtime/Arguments.cpp:
        (JSC::Arguments::copyBackingStore): We should only see the arguments token; assert otherwise. This works because if the GC sees the butterfly token it calls the JSObject::copyBackingStore method directly.
        (JSC::Arguments::defineOwnProperty): Make our bizarre behavior deliberate rather than an accident of a decade of patches.
        * tests/stress/arguments-bizarre-behavior.js: Added.
        (foo):
        * tests/stress/arguments-bizarre-behaviour-disable-enumerability.js: Added. My choice of spellings of the word "behavio[u]r" is almost as consistent as our implementation of arguments.
        (foo):
        * tests/stress/arguments-custom-properties-gc.js: Added. I added this test because at first I was unsure if we GCd arguments correctly.
        (makeBaseArguments):
        (makeArray):
        (cons):

2015-02-23  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r180547 and r180550.
        https://bugs.webkit.org/show_bug.cgi?id=141957

        Broke 10 Windows tests. (Requested by bfulgham_ on #webkit).

        Reverted changesets:

        "REGRESSION(r179429): Can't type comments in Facebook"
        https://bugs.webkit.org/show_bug.cgi?id=141859
        http://trac.webkit.org/changeset/180547

        "Constructor returning null should construct an object instead
        of null"
        https://bugs.webkit.org/show_bug.cgi?id=141640
        http://trac.webkit.org/changeset/180550

2015-02-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        Constructor returning null should construct an object instead of null
        https://bugs.webkit.org/show_bug.cgi?id=141640

        Reviewed by Geoffrey Garen.

        When constructor code doesn't return object, constructor should return `this` object instead.
        Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
        it allows `null` as an object.
        This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
        Instead, constructor uses simplified `is_object`.

        As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.

        1. LLInt and baseline JIT support `op_is_object` as a fast path.
        2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
        3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
        4. FTL lowers DFG's IsObject into LLVM IR.

        And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
        in LLInt, JIT, DFG and FTL.
        Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
        So in many places, when the cell is not object, we recognize it as a string, and vice versa.
        However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
        So this patch stop using !isString as isObject.
        To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
        we examine typeInfo in JSCell.

        * JavaScriptCore.order:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitEqualityOp):
        (JSC::BytecodeGenerator::emitReturn):
        * 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):

        IsObject operation only touches JSCell typeInfoType.
        And this value would not be changed through structure transition.
        As a result, IsObject can report that it doesn't read any information.

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

        Just like IsString, IsObject is also fixed up.

        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
        (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
        (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
        (JSC::DFG::SpeculativeJIT::speculateObject):
        (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        (JSC::DFG::SpeculativeJIT::emitSwitchString):
        (JSC::DFG::SpeculativeJIT::branchIsObject):
        (JSC::DFG::SpeculativeJIT::branchNotObject):
        (JSC::DFG::SpeculativeJIT::branchIsString):
        (JSC::DFG::SpeculativeJIT::branchNotString):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileToString):
        (JSC::FTL::LowerDFGToLLVM::compileIsObject):
        (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
        (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
        (JSC::FTL::LowerDFGToLLVM::isObject):
        (JSC::FTL::LowerDFGToLLVM::isNotObject):
        (JSC::FTL::LowerDFGToLLVM::isNotString):
        (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::emitJumpIfCellObject):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_to_primitive):
        (JSC::JIT::compileOpStrictEq):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/Operations.cpp:
        (JSC::jsIsObjectTypeOrNull):
        (JSC::jsIsObjectType): Deleted.
        * runtime/Operations.h:

2015-02-23  Ryosuke Niwa  <rniwa@webkit.org>

        Disable font loading events until our implementation gets updated to match the latest spec
        https://bugs.webkit.org/show_bug.cgi?id=141938

        Reviewed by Andreas Kling.

        * Configurations/FeatureDefines.xcconfig:

2015-02-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION(r179429): Can't type comments in Facebook
        https://bugs.webkit.org/show_bug.cgi?id=141859

        Reviewed by Geoffrey Garen.

        When window.Symbol is exposed to user-space pages,
        Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
        However, to work with Symbols completely, it also requires
        1) Object.getOwnPropertySymbols (for mixin including Symbols)
        2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
        Since they are not landed yet, comments in Facebook don't work.

        This patch introduces RuntimeFlags for JavaScriptCore.
        Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
        And drop JavaScriptExperimentsEnabled flag
        because it is no longer used and use case of this is duplicated to runtime flags.

        * JavaScriptCore.order:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jsc.cpp:
        (GlobalObject::javaScriptRuntimeFlags):
        (GlobalObject::javaScriptExperimentsEnabled): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::finishCreation):
        (JSC::JSGlobalObject::javaScriptRuntimeFlags):
        (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
        * runtime/RuntimeFlags.h: Added.
        (JSC::RuntimeFlags::RuntimeFlags):
        (JSC::RuntimeFlags::createAllEnabled):

2015-02-23  Benjamin Poulain  <bpoulain@apple.com>

        Set the semantic origin of delayed SetLocal to the Bytecode that originated it
        https://bugs.webkit.org/show_bug.cgi?id=141727

        Reviewed by Filip Pizlo.

        Previously, delayed SetLocals would have the NodeOrigin of the next
        bytecode. This was because delayed SetLocal are...delayed... and
        currentCodeOrigin() is the one where the node is emitted.

        This made debugging a little awkward since the OSR exits on SetLocal
        were reported for the next bytecode. This patch changes the semantic
        origin to keep the original bytecode.

        From benchmarks, this looks like it could be a tiny bit faster
        but it likely just noise.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::setDirect):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::currentNodeOrigin):
        (JSC::DFG::ByteCodeParser::addToGraph):
        (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
        (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute):

2015-02-23  Benjamin Poulain  <bpoulain@apple.com>

        Remove DFGNode::predictHeap()
        https://bugs.webkit.org/show_bug.cgi?id=141864

        Reviewed by Geoffrey Garen.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::predictHeap): Deleted.
        Unused code.

2015-02-23  Filip Pizlo  <fpizlo@apple.com>

        Get rid of JSLexicalEnvironment::argumentsGetter
        https://bugs.webkit.org/show_bug.cgi?id=141930

        Reviewed by Mark Lam.
        
        This function is unused, and the way it's written is bizarre - it's a return statement that
        dominates a bunch of dead code.

        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::argumentsGetter): Deleted.
        * runtime/JSLexicalEnvironment.h:

2015-02-23  Filip Pizlo  <fpizlo@apple.com>

        Remove unused activationCount and allTheThingsCount variable declarations.

        Rubber stamped by Mark Lam and Michael Saboff.

        * runtime/JSLexicalEnvironment.h:

2015-02-23  Saam Barati  <saambarati1@gmail.com>

        Adjust the ranges of basic block statements in JSC's control flow profiler to be mutually exclusive
        https://bugs.webkit.org/show_bug.cgi?id=141095

        Reviewed by Mark Lam.

        Suppose the control flow of a program forms basic block A with successor block
        B. A's end offset will be the *same* as B's start offset in the current architecture 
        of the control flow profiler. This makes reasoning about the text offsets of
        the control flow profiler unsound. To make reasoning about offsets sound, all 
        basic block ranges should be mutually exclusive.  All calls to emitProfileControlFlow 
        now pass in the *start* of a basic block as the text offset argument. This simplifies 
        all calls to emitProfileControlFlow because the previous implementation had a
        lot of edge cases for getting the desired basic block text boundaries.

        This patch also ensures that the basic block boundary of a block statement 
        is the exactly the block's open and close brace offsets (inclusive). For example,
        in if/for/while statements. This also has the consequence that for statements 
        like "if (cond) foo();", the whitespace preceding "foo()" is not part of 
        the "foo()" basic block, but instead is part of the "if (cond) " basic block. 
        This is okay because these text offsets aren't meant to be human readable.
        Instead, they reflect the text offsets of JSC's AST nodes. The Web Inspector 
        is the only client of this API and user of these text offsets and it is 
        not negatively effected by this new behavior.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        When computing basic block boundaries in CodeBlock, we ensure that every
        block's end offset is one less than its successor's start offset to
        maintain that boundaries' ranges should be mutually exclusive.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        Because the control flow profiler needs to know which functions
        have executed, we can't lazily create functions. This was a bug 
        from before that was hidden because the Type Profiler was always 
        enabled when the control flow profiler was enabled when profiling 
        was turned on from the Web Inspector. But, JSC allows for Control 
        Flow profiling to be turned on without Type Profiling, so we need 
        to ensure the Control Flow profiler has all the data it needs.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ConditionalNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitMultiLoopBytecode):
        (JSC::ForOfNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        * jsc.cpp:
        (functionHasBasicBlockExecuted):
        We now assert that the substring argument is indeed a substring
        of the function argument's text because subtle bugs could be
        introduced otherwise.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::setStartOffset):
        * parser/Nodes.h:
        (JSC::Node::setStartOffset):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseBlockStatement):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseMemberExpression):
        For the various function call AST nodes, their m_position member 
        variable is now the start of the entire function call expression 
        and not at the start of the open paren of the arguments list.

        * runtime/BasicBlockLocation.cpp:
        (JSC::BasicBlockLocation::getExecutedRanges):
        * runtime/ControlFlowProfiler.cpp:
        (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
        Function ranges inserted as gaps should follow the same criteria
        that the bytecode generator uses to ensure that basic blocks
        start and end offsets are mutually exclusive.

        * tests/controlFlowProfiler/brace-location.js: Added.
        (foo):
        (bar):
        (baz):
        (testIf):
        (testForRegular):
        (testForIn):
        (testForOf):
        (testWhile):
        (testIfNoBraces):
        (testForRegularNoBraces):
        (testForInNoBraces):
        (testForOfNoBraces):
        (testWhileNoBraces):
        * tests/controlFlowProfiler/conditional-expression.js: Added.
        (foo):
        (bar):
        (baz):
        (testConditionalBasic):
        (testConditionalFunctionCall):
        * tests/controlFlowProfiler/driver/driver.js:
        (checkBasicBlock):

2015-02-23  Matthew Mirman  <mmirman@apple.com>

        r9 is volatile on ARMv7 for iOS 3 and up. 
        https://bugs.webkit.org/show_bug.cgi?id=141489
        rdar://problem/19432916

        Reviewed by Michael Saboff.

        * jit/RegisterSet.cpp: 
        (JSC::RegisterSet::calleeSaveRegisters): removed r9 from the list of ARMv7 callee save registers.
        * tests/stress/regress-141489.js: Added.
        (foo):

2015-02-23  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Add the necessary setupArgumentsWithExecState after bug141915
        https://bugs.webkit.org/show_bug.cgi?id=141921

        Reviewed by Michael Saboff.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2015-02-23  Filip Pizlo  <fpizlo@apple.com>

        Scopes should always be created with a previously-created symbol table rather than creating one on the fly
        https://bugs.webkit.org/show_bug.cgi?id=141915

        Reviewed by Mark Lam.
        
        The main effect of this change is that pushing name scopes no longer requires creating symbol
        tables on the fly.
        
        This also makes it so that JSEnvironmentRecords must always have an a priori symbol table.
        
        JSSegmentedVariableObject still does a hack where it creates a blank symbol table on-demand.
        This is needed because that's what JSGlobalObject and all of its many subclasses want. That's
        harmless; I mainly needed a prior symbol tables for JSEnvironmentRecords anyway.

        * bytecode/BytecodeList.json:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        (JSC::BytecodeGenerator::emitPushCatchScope):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_push_name_scope):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_push_name_scope):
        * jit/JITOperations.cpp:
        (JSC::pushNameScope):
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        * runtime/JSCatchScope.h:
        (JSC::JSCatchScope::JSCatchScope):
        (JSC::JSCatchScope::create):
        * runtime/JSEnvironmentRecord.h:
        (JSC::JSEnvironmentRecord::JSEnvironmentRecord):
        * runtime/JSFunctionNameScope.h:
        (JSC::JSFunctionNameScope::JSFunctionNameScope):
        (JSC::JSFunctionNameScope::create):
        * runtime/JSNameScope.cpp:
        (JSC::JSNameScope::create):
        * runtime/JSNameScope.h:
        (JSC::JSNameScope::create):
        (JSC::JSNameScope::finishCreation):
        (JSC::JSNameScope::JSNameScope):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::finishCreation):
        * runtime/JSSymbolTableObject.h:
        (JSC::JSSymbolTableObject::JSSymbolTableObject):
        (JSC::JSSymbolTableObject::finishCreation): Deleted.
        * runtime/SymbolTable.h:
        (JSC::SymbolTable::createNameScopeTable):

2015-02-23  Filip Pizlo  <fpizlo@apple.com>

        Add a comment to clarify that the test was taken from the bug report, in response to
        feedback from Michael Saboff and Benjamin Poulain.
        
        * tests/stress/regress-141883.js:

2015-02-22  Filip Pizlo  <fpizlo@apple.com>

        Function name scope is only created on the function instance that triggered parsing rather than on every function instance that needs it
        https://bugs.webkit.org/show_bug.cgi?id=141881

        Reviewed by Michael Saboff.
        
        Previously we only created the function name scope in a way that made it visible to the
        function that triggered parsing/linking of the executable/codeBlock, and to the linker for
        that code block. This was sort of the bare minimum for the feature to appear to work right to
        synthetic tests.

        There are two valid "times" to create the function name scope. Either it's created for each
        JSFunction instance that needs a name scope, or it's created for each execution of such a
        JSFunction. This change chooses the latter, because it happens to be the easiest to implement
        with what we have right now. I opened a bug for optimizing this if we ever need to:
        https://bugs.webkit.org/show_bug.cgi?id=141887.
        
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):
        * runtime/ArrayPrototype.cpp:
        (JSC::isNumericCompareFunction):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::prepareForExecution):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::addNameScopeIfNeeded): Deleted.
        * runtime/JSFunction.h:
        * tests/stress/function-name-scope.js: Added.
        (check.verify):
        (check):

2015-02-22  Filip Pizlo  <fpizlo@apple.com>

        Crash in DFGFrozenValue
        https://bugs.webkit.org/show_bug.cgi?id=141883

        Reviewed by Benjamin Poulain.
        
        If a value might be a cell, then we have to have Graph freeze it rather than trying to
        create the FrozenValue directly. Creating it directly is just an optimization for when you
        know for sure that it cannot be a cell.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * tests/stress/regress-141883.js: Added. Hacked the original test to be faster while still crashing before this fix.

2015-02-21  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Generate Previews more often for RemoteObject interaction
        https://bugs.webkit.org/show_bug.cgi?id=141875

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Runtime.json:
        Add generatePreview to getProperties.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getInternalProperties):
        * inspector/InjectedScript.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getProperties):
        * inspector/agents/InspectorRuntimeAgent.h:
        Plumb the generatePreview boolean through to the injected script.

        * inspector/InjectedScriptSource.js:
        Add generatePreview for getProperties.
        Fix callFunctionOn to generatePreviews if asked.

2015-02-20  Mark Lam  <mark.lam@apple.com>

        Refactor JSWrapperMap.mm to defer creation of the ObjC JSValue until the latest possible moment.
        <https://webkit.org/b/141856>

        Reviewed by Geoffrey Garen.

        1. Make JSObjCClassInfo's -constructor and -wrapperForObject return a
           JSC::JSObject* just like -prototype.
        2. Defer the creation of the ObjC JSValue from JSC::JSObject* until
           the latest moment when it is needed.  This allows us to not have to
           keep converting back to a JSC::JSObject* in intermediate code.

        * API/JSWrapperMap.mm:
        (makeWrapper):
        (objectWithCustomBrand):
        (constructorWithCustomBrand):
        (allocateConstructorForCustomClass):
        (-[JSObjCClassInfo allocateConstructorAndPrototype]):
        (-[JSObjCClassInfo wrapperForObject:]):
        (-[JSObjCClassInfo constructor]):
        (-[JSWrapperMap jsWrapperForObject:]):

2015-02-20  Filip Pizlo  <fpizlo@apple.com>

        Build fix for gcc.

        * runtime/JSNameScope.cpp:
        (JSC::JSNameScope::create):

2015-02-20  Filip Pizlo  <fpizlo@apple.com>

        Get rid of JSNameScope::m_type
        https://bugs.webkit.org/show_bug.cgi?id=141851

        Reviewed by Geoffrey Garen.
        
        This is a big step towards getting rid of JSEnvironmentRecord::m_registers. To do it we need
        to ensure that subclasses of JSEnvironmentRecord never have additional C++ fields, so that
        JSEnvironmentRecord can always place "registers" right after the end of itself.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::isCatchScope):
        (JSC::DebuggerScope::isFunctionNameScope):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/JSCatchScope.cpp: Added.
        * runtime/JSCatchScope.h: Added.
        (JSC::JSCatchScope::JSCatchScope):
        (JSC::JSCatchScope::create):
        (JSC::JSCatchScope::createStructure):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::addNameScopeIfNeeded):
        * runtime/JSFunctionNameScope.cpp: Added.
        * runtime/JSFunctionNameScope.h: Added.
        (JSC::JSFunctionNameScope::JSFunctionNameScope):
        (JSC::JSFunctionNameScope::create):
        (JSC::JSFunctionNameScope::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::catchScopeStructure):
        (JSC::JSGlobalObject::functionNameScopeStructure):
        (JSC::JSGlobalObject::nameScopeStructure): Deleted.
        * runtime/JSNameScope.cpp:
        (JSC::JSNameScope::create):
        * runtime/JSNameScope.h:
        (JSC::JSNameScope::create):
        (JSC::JSNameScope::JSNameScope):
        (JSC::JSNameScope::createStructure): Deleted.
        (JSC::JSNameScope::isFunctionNameScope): Deleted.
        (JSC::JSNameScope::isCatchScope): Deleted.
        * runtime/JSObject.cpp:
        (JSC::JSObject::isCatchScopeObject):
        (JSC::JSObject::isFunctionNameScopeObject):
        * runtime/JSObject.h:

2015-02-20  Mark Lam  <mark.lam@apple.com>

        [JSObjCClassInfo reallocateConstructorAndOrPrototype] should also reallocate super class prototype chain.
        <https://webkit.org/b/141809>

        Reviewed by Geoffrey Garen.

        A ObjC class that implement the JSExport protocol will have a JS prototype
        chain and constructor automatically synthesized for its JS wrapper object.
        However, if there are no more instances of that ObjC class reachable by a
        JS GC root scan, then its synthesized prototype chain and constructors may
        be released by the GC.  If a new instance of that ObjC class is subsequently
        instantiated, then [JSObjCClassInfo reallocateConstructorAndOrPrototype]
        should re-construct the prototype chain and constructor (if they were
        previously released).  However, the current implementation only
        re-constructs the immediate prototype, but not every other prototype
        object upstream in the prototype chain.

        To fix this, we do the following:
        1. We no longer allocate the JSObjCClassInfo's prototype and constructor
           eagerly.  Hence, -initWithContext:forClass: will no longer call
           -allocateConstructorAndPrototypeWithSuperClassInfo:.
        2. Instead, we'll always access the prototype and constructor thru
           accessor methods.  The accessor methods will call
           -allocateConstructorAndPrototype: if needed.
        3. -allocateConstructorAndPrototype: will fetch the needed superClassInfo
           from the JSWrapperMap itself.  This makes it so that we no longer
           need to pass the superClassInfo all over.
        4. -allocateConstructorAndPrototype: will get the super class prototype
           by invoking -prototype: on the superClassInfo, thereby allowing the
           super class to allocate its prototype and constructor if needed and
           fixing the issue in this bug.

        5. Also removed the GC warning comments, and ensured that needed JS
           objects are kept alive by having a local var pointing to it from the
           stack (which makes a GC root).

        * API/JSWrapperMap.mm:
        (-[JSObjCClassInfo initWithContext:forClass:]):
        (-[JSObjCClassInfo allocateConstructorAndPrototype]):
        (-[JSObjCClassInfo wrapperForObject:]):
        (-[JSObjCClassInfo constructor]):
        (-[JSObjCClassInfo prototype]):
        (-[JSWrapperMap classInfoForClass:]):
        (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Deleted.
        (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Deleted.
        (-[JSObjCClassInfo reallocateConstructorAndOrPrototype]): Deleted.
        * API/tests/Regress141809.h: Added.
        * API/tests/Regress141809.mm: Added.
        (-[TestClassB name]):
        (-[TestClassC name]):
        (runRegress141809):
        * API/tests/testapi.mm:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-02-20  Alexey Proskuryakov  <ap@apple.com>

        Remove svn:keywords property.

        As far as I can tell, the property had no effect on any of these files, but also,
        when it has effect it's likely harmful.

        * builtins/ArrayConstructor.js: Removed property svn:keywords.

2015-02-20  Michael Saboff  <msaboff@apple.com>

        DFG JIT needs to check for stack overflow at the start of Program and Eval execution
        https://bugs.webkit.org/show_bug.cgi?id=141676

        Reviewed by Filip Pizlo.

        Added stack check to the beginning of the code the DFG copmiler emits for Program and Eval nodes.
        To aid in testing the code, I replaced the EvalCodeCache::maxCacheableSourceLength const
        a options in runtime/Options.h.  The test script, run-jsc-stress-tests, sets that option
        to a huge value when running with the "Eager" options.  This allows the updated test to 
        reliably exercise the code in questions.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        Added stack check.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        * runtime/Options.h:
        Replaced EvalCodeCache::imaxCacheableSourceLength with Options::maximumEvalCacheableSourceLength
        so that it can be configured when running the related test.

2015-02-20  Eric Carlson  <eric.carlson@apple.com>

        [iOS] cleanup AirPlay code
        https://bugs.webkit.org/show_bug.cgi?id=141811

        Reviewed by Jer Noble.

        * Configurations/FeatureDefines.xcconfig: IOS_AIRPLAY -> WIRELESS_PLAYBACK_TARGET.

2015-02-19  Dean Jackson  <dino@apple.com>

        ES6: Implement Array.from()
        https://bugs.webkit.org/show_bug.cgi?id=141054
        <rdar://problem/19654521>

        Reviewed by Filip Pizlo.

        Implement the Array.from() ES6 method
        as defined in Section 22.1.2.1 of the specification.

        Given that we can't rely on the built-in
        global functions or objects to be untainted,
        I had to expose a few of them directly to
        the function via private names. In particular:
        - Math.floor -> @floor
        - Math.abs -> @abs
        - Number -> @Number
        - Array -> @Array
        - isFinite -> @isFinite

        * builtins/ArrayConstructor.js: Added.
        (from): Implementation of Array.from in JavaScript.
        * runtime/ArrayConstructor.cpp: Add "from" to the lookup
        table for the constructor object.
        * runtime/CommonIdentifiers.h: Add the private versions
        of the identifiers listed above.
        * runtime/JSGlobalObject.cpp: Add the implementations of
        those identifiers to the global object (using their
        private names).
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalPrivateFuncAbs): Implementation of the abs function.
        (JSC::globalPrivateFuncFloor): Implementation of the floor function.
        * runtime/JSGlobalObjectFunctions.h:

2015-02-19  Benjamin Poulain  <bpoulain@apple.com>

        Refine the FTL part of ArithPow
        https://bugs.webkit.org/show_bug.cgi?id=141792

        Reviewed by Filip Pizlo.

        This patch refines the FTL lowering of ArithPow. This was left out
        of the original patch to keep it simpler.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileArithPow):
        Two improvements here:
        1) Do not generate the NaN check unless we know the exponent might be a NaN.
        2) Use one BasicBlock per check with the appropriate weight. Now that we have
           one branch per test, move the Infinity check before the check for 1 since
           it is the less common case.

        * tests/stress/math-pow-becomes-custom-function.js: Added.
        Test for changing the Math.pow() function after it has been optimized.

        * tests/stress/math-pow-nan-behaviors.js:
        The previous tests were only going as far as the DFGAbstractInterpreter
        were the operations were replaced by the equivalent constant.

        I duplicated the test functions to also test the dynamic behavior of DFG
        and FTL.

        * tests/stress/math-pow-with-constants.js:
        Add cases covering exponent constants. LLVM removes many value
        checks for those.

        * tests/stress/math-pow-with-never-NaN-exponent.js: Added.
        Test for the new optimization removing the NaN check.

2015-02-19  Csaba Osztrogonác  <ossy@webkit.org>

        REGRESSION(r180279): It broke 20 tests on ARM Linux
        https://bugs.webkit.org/show_bug.cgi?id=141771

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation): Align 64-bit values to respect ARM EABI.

2015-02-18  Benjamin Poulain  <bpoulain@apple.com>

        Remove BytecodeGenerator's numberMap, it is dead code
        https://bugs.webkit.org/show_bug.cgi?id=141779

        Reviewed by Filip Pizlo.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        The JSValueMap seems better in every way.

        The emitLoad() taking a double was the only way to use numberMap
        and that code has no caller.

2015-02-18  Michael Saboff  <msaboff@apple.com>

        Rollout r180247 & r180249 from trunk
        https://bugs.webkit.org/show_bug.cgi?id=141773

        Reviewed by Filip Pizlo.

        Theses changes makes sense to fix the crash reported in https://bugs.webkit.org/show_bug.cgi?id=141730
        only for branches.  The change to fail the FTL compile but continue running is not comprehensive
        enough for general use on trunk.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
        (JSC::FTL::LowerDFGToLLVM::compilePhi):
        (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
        (JSC::FTL::LowerDFGToLLVM::compileValueRep):
        (JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
        (JSC::FTL::LowerDFGToLLVM::compilePutLocal):
        (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
        (JSC::FTL::LowerDFGToLLVM::compileArithMod):
        (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
        (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
        (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
        (JSC::FTL::LowerDFGToLLVM::compileGetById):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
        (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
        (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
        (JSC::FTL::LowerDFGToLLVM::compileNewArray):
        (JSC::FTL::LowerDFGToLLVM::compileToString):
        (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
        (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
        (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::LowerDFGToLLVM::compare):
        (JSC::FTL::LowerDFGToLLVM::boolify):
        (JSC::FTL::LowerDFGToLLVM::opposite):
        (JSC::FTL::LowerDFGToLLVM::lowJSValue):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::isArrayType):
        (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
        (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
        (JSC::FTL::LowerDFGToLLVM::setInt52):
        (JSC::FTL::lowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::loweringFailed): Deleted.
        * ftl/FTLLowerDFGToLLVM.h:

2015-02-18  Filip Pizlo  <fpizlo@apple.com>

        DFG should really support varargs
        https://bugs.webkit.org/show_bug.cgi?id=141332

        Reviewed by Oliver Hunt.
        
        This adds comprehensive vararg call support to the DFG and FTL compilers. Previously, if a
        function had a varargs call, then it could only be compiled if that varargs call was just
        forwarding arguments and we were inlining the function rather than compiling it directly. Also,
        only varargs calls were dealt with; varargs constructs were not.
        
        This lifts all of those restrictions. Every varargs call or construct can now be compiled by both
        the DFG and the FTL. Those calls can also be inlined, too - provided that profiling gives us a
        sensible bound on arguments list length. When we inline a varargs call, the act of loading the
        varargs is now made explicit in IR. I believe that we have enough IR machinery in place that we
        would be able to do the arguments forwarding optimization as an IR transformation. This patch
        doesn't implement that yet, and keeps the old bytecode-based varargs argument forwarding
        optimization for now.
        
        There are three major IR features introduced in this patch:
        
        CallVarargs/ConstructVarargs: these are like Call/Construct except that they take an arguments
        array rather than a list of arguments. Currently, they splat this arguments array onto the stack
        using the same basic technique as the baseline JIT has always done. Except, these nodes indicate
        that we are not interested in doing the non-escaping "arguments" optimization.
        
        CallForwardVarargs: this is a form of CallVarargs that just does the non-escaping "arguments"
        optimization, aka forwarding arguments. It's somewhat lazy that this doesn't include
        ConstructForwardVarargs, but the reason is that once we eliminate the lazy tear-off for
        arguments, this whole thing will have to be tweaked - and for now forwarding on construct is just
        not important in benchmarks. ConstructVarargs will still do forwarding, just not inlined.
        
        LoadVarargs: loads all elements out of an array onto the stack in a manner suitable for a varargs
        call. This is used only when a varargs call (or construct) was inlined. The bytecode parser will
        make room on the stack for the arguments, and will use LoadVarars to put those arguments into
        place.
        
        In the future, we can consider adding strength reductions like:
        
        - If CallVarargs/ConstructVarargs see an array of known size with known elements, turn them into
          Call/Construct.
        
        - If CallVarargs/ConstructVarargs are passed an unmodified, unescaped Arguments object, then
          turn them into CallForwardVarargs/ConstructForwardVarargs.
        
        - If LoadVarargs sees an array of known size, then turn it into a sequence of GetByVals and
          PutLocals.
        
        - If LoadVarargs sees an unmodified, unescaped Arguments object, then turn it into something like
          LoadForwardVarargs.
        
        - If CallVarargs/ConstructVarargs/LoadVarargs see the result of a splice (or other Array
          prototype function), then do the splice and varargs loading in one go (maybe via a new node
          type).

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::rshiftPtr):
        (JSC::MacroAssembler::urshiftPtr):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::urshift64):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::urshift64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::shrq_i8r):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::CallLinkInfo):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        (JSC::CallLinkStatus::setProvenConstantCallee):
        (JSC::CallLinkStatus::dump):
        * bytecode/CallLinkStatus.h:
        (JSC::CallLinkStatus::maxNumArguments):
        (JSC::CallLinkStatus::setIsProved): Deleted.
        * bytecode/CodeOrigin.cpp:
        (WTF::printInternal):
        * bytecode/CodeOrigin.h:
        (JSC::InlineCallFrame::varargsKindFor):
        (JSC::InlineCallFrame::specializationKindFor):
        (JSC::InlineCallFrame::isVarargs):
        (JSC::InlineCallFrame::isNormalCall): Deleted.
        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * bytecode/ValueRecovery.cpp:
        (JSC::ValueRecovery::dumpInContext):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::emitFunctionChecks):
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleMinMax):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::removeLastNodeFromGraph): Deleted.
        (JSC::DFG::ByteCodeParser::undoFunctionChecks): Deleted.
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::functionCapabilityLevel):
        (JSC::DFG::mightCompileFunctionFor):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCommon.cpp:
        (WTF::printInternal):
        * dfg/DFGCommon.h:
        (JSC::DFG::canInline):
        (JSC::DFG::leastUpperBound):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::isLiveInBytecode):
        (JSC::DFG::Graph::valueProfileFor):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::valueProfileFor): Deleted.
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor): Deleted.
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCallVarargsData):
        (JSC::DFG::Node::callVarargsData):
        (JSC::DFG::Node::hasLoadVarargsData):
        (JSC::DFG::Node::loadVarargsData):
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::dumpAndVerifyGraph):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::writeTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSSAConversionPhase.cpp:
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::isFlushed):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        (JSC::DFG::StackLayoutPhase::assign):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateCPS):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::functionType):
        (JSC::FTL::buildCall):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfCall):
        (JSC::FTL::sizeOfCallVarargs):
        (JSC::FTL::sizeOfCallForwardVarargs):
        (JSC::FTL::sizeOfConstructVarargs):
        (JSC::FTL::sizeOfIn):
        (JSC::FTL::sizeOfICFor):
        (JSC::FTL::sizeOfCheckIn): Deleted.
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLJSCall.cpp:
        (JSC::FTL::JSCall::JSCall):
        * ftl/FTLJSCallBase.cpp:
        * ftl/FTLJSCallBase.h:
        * ftl/FTLJSCallVarargs.cpp: Added.
        (JSC::FTL::JSCallVarargs::JSCallVarargs):
        (JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
        (JSC::FTL::JSCallVarargs::emit):
        (JSC::FTL::JSCallVarargs::link):
        * ftl/FTLJSCallVarargs.h: Added.
        (JSC::FTL::JSCallVarargs::node):
        (JSC::FTL::JSCallVarargs::stackmapID):
        (JSC::FTL::JSCallVarargs::operator<):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentsLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::LowerDFGToLLVM::compileLoadVarargs):
        (JSC::FTL::LowerDFGToLLVM::compileIn):
        (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
        (JSC::FTL::LowerDFGToLLVM::vmCall):
        (JSC::FTL::LowerDFGToLLVM::vmCallNoExceptions):
        (JSC::FTL::LowerDFGToLLVM::callCheck):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::call):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * ftl/FTLState.h:
        * interpreter/Interpreter.cpp:
        (JSC::sizeOfVarargs):
        (JSC::sizeFrameForVarargs):
        * interpreter/Interpreter.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::readInlinedFrame):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitExceptionCheck):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::addressFor):
        (JSC::AssemblyHelpers::calleeFrameSlot):
        (JSC::AssemblyHelpers::calleeArgumentSlot):
        (JSC::AssemblyHelpers::calleeFrameTagSlot):
        (JSC::AssemblyHelpers::calleeFramePayloadSlot):
        (JSC::AssemblyHelpers::calleeArgumentTagSlot):
        (JSC::AssemblyHelpers::calleeArgumentPayloadSlot):
        (JSC::AssemblyHelpers::calleeFrameCallerFrame):
        (JSC::AssemblyHelpers::selectScratchGPR):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/GPRInfo.h:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        (JSC::JIT::compileOpCall):
        * jit/JITOperations.h:
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SetupVarargsFrame.h:
        * runtime/Arguments.h:
        (JSC::Arguments::create):
        (JSC::Arguments::registerArraySizeInBytes):
        (JSC::Arguments::finishCreation):
        * runtime/Options.h:
        * tests/stress/construct-varargs-inline-smaller-Foo.js: Added.
        (Foo):
        (bar):
        (checkEqual):
        (test):
        * tests/stress/construct-varargs-inline.js: Added.
        (Foo):
        (bar):
        (checkEqual):
        (test):
        * tests/stress/construct-varargs-no-inline.js: Added.
        (Foo):
        (bar):
        (checkEqual):
        (test):
        * tests/stress/get-argument-by-val-in-inlined-varargs-call-out-of-bounds.js: Added.
        (foo):
        (bar):
        * tests/stress/get-argument-by-val-safe-in-inlined-varargs-call-out-of-bounds.js: Added.
        (foo):
        (bar):
        * tests/stress/get-my-argument-by-val-creates-arguments.js: Added.
        (blah):
        (foo):
        (bar):
        (checkEqual):
        (test):
        * tests/stress/load-varargs-then-inlined-call-exit-in-foo.js: Added.
        (foo):
        (bar):
        (checkEqual):
        * tests/stress/load-varargs-then-inlined-call-inlined.js: Added.
        (foo):
        (bar):
        (baz):
        (checkEqual):
        (test):
        * tests/stress/load-varargs-then-inlined-call.js: Added.
        (foo):
        (bar):
        (checkEqual):
        (test):

2015-02-17  Michael Saboff  <msaboff@apple.com>

        Unreviewed, Restoring the C LOOP insta-crash fix in r180184.

        Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
        After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).

        * llint/LowLevelInterpreter.asm: Fixed a typo.

2015-02-18  Csaba Osztrogonác  <ossy@webkit.org>

        URTBF after r180258 to fix Windows build.

        * runtime/MathCommon.cpp:
        (JSC::mathPowInternal):

2015-02-18  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r180235): It broke the !ENABLE(PROMISES) build
        https://bugs.webkit.org/show_bug.cgi?id=141746

        Unreviewed build fix.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Wrap JSPromise related code in ENABLE(PROMISES) guard.

2015-02-18  Benjamin Poulain  <benjamin@webkit.org>

        Fix the C-Loop LLInt build
        https://bugs.webkit.org/show_bug.cgi?id=141618

        Reviewed by Filip Pizlo.

        I broke C-Loop when moving the common code of pow()
        to JITOperations because that file is #ifdefed out
        when the JITs are disabled.

        It would be weird to move it back to MathObject since
        the function needs to know about the calling conventions.

        To avoid making a mess, I just gave the function its own file
        that is used by both the runtime and the JIT.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreterInlines.h:
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * runtime/MathCommon.cpp: Added.
        (JSC::fdlibmScalbn):
        (JSC::fdlibmPow):
        (JSC::isDenormal):
        (JSC::isEdgeCase):
        (JSC::mathPowInternal):
        (JSC::operationMathPow):
        * runtime/MathCommon.h: Added.
        * runtime/MathObject.cpp:

2015-02-17  Benjamin Poulain  <bpoulain@apple.com>

        Clean up OSRExit's considerAddingAsFrequentExitSite()
        https://bugs.webkit.org/show_bug.cgi?id=141690

        Reviewed by Anders Carlsson.

        Looks like some code was removed from CodeBlock::tallyFrequentExitSites()
        and the OSRExit were left untouched.

        This patch cleans up the two loops and remove the boolean return
        on considerAddingAsFrequentExitSite().

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::tallyFrequentExitSites):
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitBase.cpp:
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):

2015-02-17  Alexey Proskuryakov  <ap@apple.com>

        Debug build fix after r180247.

        * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::loweringFailed):

2015-02-17  Commit Queue  <commit-queue@webkit.org>

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

        Caused infinite recursion on js/function-apply-aliased.html
        (Requested by ap_ on #webkit).

        Reverted changeset:

        "REGRESSION(r180060): C Loop crashes"
        https://bugs.webkit.org/show_bug.cgi?id=141671
        http://trac.webkit.org/changeset/180184

2015-02-17  Michael Saboff  <msaboff@apple.com>

        CrashTracer: DFG_CRASH beneath JSC::FTL::LowerDFGToLLVM::compileNode
        https://bugs.webkit.org/show_bug.cgi?id=141730

        Reviewed by Geoffrey Garen.

        Added a new failure handler, loweringFailed(), to LowerDFGToLLVM that reports failures
        while processing DFG lowering.  For debug builds, the failures are logged identical
        to the way the DFG_CRASH() reports them.  For release builds, the failures are reported
        and that FTL compilation is terminated, but the process is allowed to continue.
        Wrapped calls to loweringFailed() in a macro LOWERING_FAILED so the function and
        line number are reported at the point of the inconsistancy.

        Converted instances of DFG_CRASH to LOWERING_FAILED.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl): Added lowerDFGToLLVM() failure check that
        will fail the FTL compile.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        Added new member variable, m_loweringSucceeded, to stop compilation on the first
        reported failure.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        * ftl/FTLLowerDFGToLLVM.h:
        Added check for compilation failures and now report those failures via a boolean
        return value.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
        (JSC::FTL::LowerDFGToLLVM::compilePhi):
        (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
        (JSC::FTL::LowerDFGToLLVM::compileValueRep):
        (JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
        (JSC::FTL::LowerDFGToLLVM::compilePutLocal):
        (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
        (JSC::FTL::LowerDFGToLLVM::compileArithMod):
        (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
        (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
        (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
        (JSC::FTL::LowerDFGToLLVM::compileGetById):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
        (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
        (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
        (JSC::FTL::LowerDFGToLLVM::compileNewArray):
        (JSC::FTL::LowerDFGToLLVM::compileToString):
        (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
        (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
        (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::LowerDFGToLLVM::compare):
        (JSC::FTL::LowerDFGToLLVM::boolify):
        (JSC::FTL::LowerDFGToLLVM::opposite):
        (JSC::FTL::LowerDFGToLLVM::lowJSValue):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::isArrayType):
        (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
        (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
        (JSC::FTL::LowerDFGToLLVM::setInt52):
        Changed DFG_CRASH() to LOWERING_FAILED().  Updated related control flow as appropriate.

        (JSC::FTL::LowerDFGToLLVM::loweringFailed): New error reporting member function.

2015-02-17  Filip Pizlo  <fpizlo@apple.com>

        StackLayoutPhase should use CodeBlock::usesArguments rather than FunctionExecutable::usesArguments
        https://bugs.webkit.org/show_bug.cgi?id=141721
        rdar://problem/17198633

        Reviewed by Michael Saboff.
        
        I've seen cases where the two are out of sync.  We know we can trust the CodeBlock::usesArguments because
        we use it everywhere else.
        
        No test because I could never reproduce the crash.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::usesArguments):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):

2015-02-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Improved Console Support for Bound Functions
        https://bugs.webkit.org/show_bug.cgi?id=141635

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Expose internal properties of a JSBoundFunction.

2015-02-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ES6: Improved Console Support for Promise Objects
        https://bugs.webkit.org/show_bug.cgi?id=141634

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getInternalProperties):
        * inspector/InjectedScriptSource.js:
        Include internal properties in previews. Share code
        with normal internal property handling.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::constructInternalProperty):
        (Inspector::JSInjectedScriptHost::getInternalProperties):
        Provide internal state of Promises.

        * inspector/protocol/Runtime.json:
        Provide an optional field to distinguish if a PropertyPreview
        is for an Internal property or not.

2015-02-17  Filip Pizlo  <fpizlo@apple.com>

        Throwing from an FTL call IC slow path may result in tag registers being clobbered on 64-bit CPUs
        https://bugs.webkit.org/show_bug.cgi?id=141717
        rdar://problem/19863382

        Reviewed by Geoffrey Garen.
        
        The best solution is to ensure that the engine catching an exception restores tag registers.
        
        Each of these new test cases reliably crashed prior to this patch and they don't crash at all now.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/throw-from-ftl-call-ic-slow-path-cells.js: Added.
        * tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js: Added.
        * tests/stress/throw-from-ftl-call-ic-slow-path.js: Added.

2015-02-17  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Add the necessary setupArgumentsWithExecState after bug141332
        https://bugs.webkit.org/show_bug.cgi?id=141714

        Reviewed by Michael Saboff.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2015-02-15  Sam Weinig  <sam@webkit.org>

        Add experimental <attachment> element support
        https://bugs.webkit.org/show_bug.cgi?id=141626

        Reviewed by Tim Horton.

        * Configurations/FeatureDefines.xcconfig:

2015-02-16  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r180060): C Loop crashes
        https://bugs.webkit.org/show_bug.cgi?id=141671

        Reviewed by Geoffrey Garen.

        Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
        After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).
        Fixed the processing of an out of stack exception in llint_stack_check to not get the caller's
        frame.  This isn't needed, since this helper is only called to check the stack on entry.  Any
        exception will be handled by a call ancestor.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_stack_check): Changed to use the current frame for processing an exception.
        * llint/LowLevelInterpreter.asm: Fixed a typo.

2015-02-16  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Scope details sidebar should label objects with constructor names
        https://bugs.webkit.org/show_bug.cgi?id=139449

        Reviewed by Timothy Hatcher.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::internalConstructorName):
        * runtime/Structure.cpp:
        (JSC::Structure::toStructureShape):
        Share calculatedClassName.

        * runtime/JSObject.h:        
        * runtime/JSObject.cpp:
        (JSC::JSObject::calculatedClassName):
        Elaborate on a way to get an Object's class name.

2015-02-16  Filip Pizlo  <fpizlo@apple.com>

        DFG SSA should use GetLocal for arguments, and the GetArgument node type should be removed
        https://bugs.webkit.org/show_bug.cgi?id=141623

        Reviewed by Oliver Hunt.
        
        During development of https://bugs.webkit.org/show_bug.cgi?id=141332, I realized that I
        needed to use GetArgument for loading something that has magically already appeared on the
        stack, so currently trunk sort of allows this. But then I realized three things:
        
        - A GetArgument with a non-JSValue flush format means speculating that the value on the
          stack obeys that format, rather than just assuming that that it already has that format.
          In bug 141332, I want it to assume rather than speculate. That also happens to be more
          intuitive; I don't think I was wrong to expect that.
        
        - The node I really want is GetLocal. I'm just getting the value of the local and I don't
          want to do anything else.
        
        - Maybe it would be easier if we just used GetLocal for all of the cases where we currently
          use GetArgument.
        
        This changes the FTL to do argument speculations in the prologue just like the DFG does.
        This brings some consistency to our system, and allows us to get rid of the GetArgument
        node. The speculations that the FTL must do are now made explicit in the m_argumentFormats
        vector in DFG::Graph. This has natural DCE behavior: even if all uses of the argument are
        dead we will still speculate. We already have safeguards to ensure we only speculate if
        there are uses that benefit from speculation (which is a much more conservative criterion
        than DCE).
        
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGFlushFormat.h:
        (JSC::DFG::typeFilterFor):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::valueProfileFor):
        (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGNode.cpp:
        (JSC::DFG::Node::hasVariableAccessData):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
        (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
        (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPutLocalSinkingPhase.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):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
        (JSC::FTL::LowerDFGToLLVM::compileGetArgument): Deleted.
        * tests/stress/dead-speculating-argument-use.js: Added.
        (foo):
        (o.valueOf):

2015-02-15  Filip Pizlo  <fpizlo@apple.com>

        Rare case profiling should actually work
        https://bugs.webkit.org/show_bug.cgi?id=141632

        Reviewed by Michael Saboff.
        
        This simple adjustment appears to be a 2% speed-up on Octane. Over time, the slow case
        heuristic has essentially stopped working because the typical execution count threshold for a
        bytecode instruction is around 66 while the slow case threshold is 100: virtually
        guaranteeing that the DFG will never think that a bytecode instruction has taken the slow
        case even if it took it every single time. So, this changes the slow case threshold to 20.
        
        I checked if we could lower this down further, like to 10. That is worse than 20, and about
        as bad as 100.

        * runtime/Options.h:

2015-02-15  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: remove unused XHR replay code
        https://bugs.webkit.org/show_bug.cgi?id=141622

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Network.json: remove XHR replay methods.

2015-02-15  David Kilzer  <ddkilzer@apple.com>

        REGRESSION (r180082): WebCore Debug builds fail on Mavericks due to weak export symbols
        <http://webkit.org/b/141607>

        More work towards fixing the Mavericks Debug build.

        * inspector/ScriptDebugServer.h:
        (Inspector::ScriptDebugServer::Task):
        * inspector/agents/InspectorDebuggerAgent.h:
        (Inspector::InspectorDebuggerAgent::Listener):
        - Remove subclass exports. They did not help.

        * runtime/JSCJSValue.h:
        (JSC::JSValue::toFloat): Do not mark inline method for export.

2015-02-09  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: remove some unnecessary Inspector prefixes from class names in Inspector namespace
        https://bugs.webkit.org/show_bug.cgi?id=141372

        Reviewed by Joseph Pecoraro.

        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::addToFrontend):
        (Inspector::ConsoleMessage::updateRepeatCountInConsole):
        * inspector/ConsoleMessage.h:
        * inspector/InspectorAgentBase.h:
        * inspector/InspectorAgentRegistry.cpp:
        (Inspector::AgentRegistry::AgentRegistry):
        (Inspector::AgentRegistry::append):
        (Inspector::AgentRegistry::appendExtraAgent):
        (Inspector::AgentRegistry::didCreateFrontendAndBackend):
        (Inspector::AgentRegistry::willDestroyFrontendAndBackend):
        (Inspector::AgentRegistry::discardAgents):
        (Inspector::InspectorAgentRegistry::InspectorAgentRegistry): Deleted.
        (Inspector::InspectorAgentRegistry::append): Deleted.
        (Inspector::InspectorAgentRegistry::appendExtraAgent): Deleted.
        (Inspector::InspectorAgentRegistry::didCreateFrontendAndBackend): Deleted.
        (Inspector::InspectorAgentRegistry::willDestroyFrontendAndBackend): Deleted.
        (Inspector::InspectorAgentRegistry::discardAgents): Deleted.
        * inspector/InspectorAgentRegistry.h:
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::BackendDispatcher::CallbackBase::CallbackBase):
        (Inspector::BackendDispatcher::CallbackBase::isActive):
        (Inspector::BackendDispatcher::CallbackBase::sendFailure):
        (Inspector::BackendDispatcher::CallbackBase::sendIfActive):
        (Inspector::BackendDispatcher::create):
        (Inspector::BackendDispatcher::registerDispatcherForDomain):
        (Inspector::BackendDispatcher::dispatch):
        (Inspector::BackendDispatcher::sendResponse):
        (Inspector::BackendDispatcher::reportProtocolError):
        (Inspector::BackendDispatcher::getInteger):
        (Inspector::BackendDispatcher::getDouble):
        (Inspector::BackendDispatcher::getString):
        (Inspector::BackendDispatcher::getBoolean):
        (Inspector::BackendDispatcher::getObject):
        (Inspector::BackendDispatcher::getArray):
        (Inspector::BackendDispatcher::getValue):
        (Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase): Deleted.
        (Inspector::InspectorBackendDispatcher::CallbackBase::isActive): Deleted.
        (Inspector::InspectorBackendDispatcher::CallbackBase::sendFailure): Deleted.
        (Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive): Deleted.
        (Inspector::InspectorBackendDispatcher::create): Deleted.
        (Inspector::InspectorBackendDispatcher::registerDispatcherForDomain): Deleted.
        (Inspector::InspectorBackendDispatcher::dispatch): Deleted.
        (Inspector::InspectorBackendDispatcher::sendResponse): Deleted.
        (Inspector::InspectorBackendDispatcher::reportProtocolError): Deleted.
        (Inspector::InspectorBackendDispatcher::getInteger): Deleted.
        (Inspector::InspectorBackendDispatcher::getDouble): Deleted.
        (Inspector::InspectorBackendDispatcher::getString): Deleted.
        (Inspector::InspectorBackendDispatcher::getBoolean): Deleted.
        (Inspector::InspectorBackendDispatcher::getObject): Deleted.
        (Inspector::InspectorBackendDispatcher::getArray): Deleted.
        (Inspector::InspectorBackendDispatcher::getValue): Deleted.
        * inspector/InspectorBackendDispatcher.h:
        (Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher):
        (Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher):
        (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher): Deleted.
        (Inspector::InspectorSupplementalBackendDispatcher::~InspectorSupplementalBackendDispatcher): Deleted.
        * inspector/InspectorFrontendChannel.h:
        (Inspector::FrontendChannel::~FrontendChannel):
        (Inspector::InspectorFrontendChannel::~InspectorFrontendChannel): Deleted.
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
        (Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend):
        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorAgent::willDestroyFrontendAndBackend):
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorConsoleAgent::willDestroyFrontendAndBackend):
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorDebuggerAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::pause):
        (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
        (Inspector::InspectorDebuggerAgent::didPause):
        (Inspector::InspectorDebuggerAgent::breakProgram):
        (Inspector::InspectorDebuggerAgent::clearBreakDetails):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
        (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend):
        (Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend):
        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * inspector/augmentable/AlternateDispatchableAgent.h:
        * inspector/augmentable/AugmentableInspectorController.h:
        * inspector/remote/RemoteInspectorDebuggable.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.h:
        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.cpp_type_for_formal_out_parameter):
        (CppGenerator.cpp_type_for_stack_out_parameter):
        * inspector/scripts/codegen/cpp_generator_templates.py:
        (AlternateBackendDispatcher):
        (Alternate):
        (void):
        (AlternateInspectorBackendDispatcher): Deleted.
        (AlternateInspector): Deleted.
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.Alternate):
        (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command):
        (CppBackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector): Deleted.
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator._generate_handler_class_destructor_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator._generate_event):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::connect):
        (JSC::JSGlobalObjectDebuggable::disconnect):
        * runtime/JSGlobalObjectDebuggable.h:

2015-02-14  David Kilzer  <ddkilzer@apple.com>

        REGRESSION (r180082): WebCore Debug builds fail on Mavericks due to weak export symbols
        <http://webkit.org/b/141607>

        Work towards fixing the Mavericks Debug build.

        * inspector/ScriptDebugServer.h:
        (Inspector::ScriptDebugServer::Task): Export class.
        * inspector/agents/InspectorDebuggerAgent.h:
        (Inspector::InspectorDebuggerAgent::Listener): Export class.
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::setConsoleClient): Do not mark inline
        method for export.

2015-02-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Symbol RemoteObject should not send sub-type
        https://bugs.webkit.org/show_bug.cgi?id=141604

        Reviewed by Brian Burg.

        * inspector/InjectedScriptSource.js:

2015-02-13  Benjamin Poulain  <bpoulain@apple.com>

        Attempt to fix 32bits build after r180098

        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        I copied the attribute from the MathObject version of that function when I moved
        it over. DFG has no version of a function call taking those attributes.

2015-02-13  Joseph Pecoraro  <pecoraro@apple.com>

        JSContext Inspector: Do not stash console messages for non-debuggable JSContext
        https://bugs.webkit.org/show_bug.cgi?id=141589

        Reviewed by Timothy Hatcher.

        Consider developer extras disabled for JSContext inspection if the
        RemoteInspector server is not enabled (typically a non-debuggable
        process rejected by webinspectord) or if remote debugging on the
        JSContext was explicitly disabled via SPI.

        When developer extras are disabled, console message will not be stashed.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::developerExtrasEnabled):
        * inspector/JSGlobalObjectInspectorController.h:

2015-02-13  Benjamin Poulain  <bpoulain@apple.com>

        Add a DFG node for the Pow Intrinsics
        https://bugs.webkit.org/show_bug.cgi?id=141540

        Reviewed by Filip Pizlo.

        Add a DFG Node for PowIntrinsic. This patch covers the basic cases
        need to avoid massive regression. I will iterate over the node to cover
        the missing types.

        With this patch I get the following progressions on benchmarks:
        -LongSpider's math-partial-sums: +5%.
        -Kraken's imaging-darkroom: +17%
        -AsmBench's cray.c: +6.6%
        -CompressionBench: +2.2% globally.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        Cover a couple of trivial cases:
        -If the exponent is zero, the result is always one, regardless of the base.
        -If both arguments are constants, compute the result at compile time.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        We only support 2 basic cases at this time:
        -Math.pow(double, int)
        -Math.pow(double, double).

        I'll cover Math.pow(int, int) in a follow up.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToArithSqrt):
        (JSC::DFG::Node::arithNodeFlags):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::compileArithPowIntegerFastPath):
        (JSC::DFG::SpeculativeJIT::compileArithPow):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithPow):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doublePow):
        (JSC::FTL::Output::doublePowi):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncPow):
        (JSC::isDenormal): Deleted.
        (JSC::isEdgeCase): Deleted.
        (JSC::mathPow): Deleted.

        * tests/stress/math-pow-basics.js: Added.
        * tests/stress/math-pow-integer-exponent-fastpath.js: Added.
        * tests/stress/math-pow-nan-behaviors.js: Added.
        * tests/stress/math-pow-with-constants.js: Added.
        Start some basic testing of Math.pow().
        Due to the various transform, the value change when the code tiers up,
        I covered this by checking for approximate values.

2015-02-13  Benjamin Poulain  <bpoulain@apple.com>

        ArithSqrt should not be conditional on supportsFloatingPointSqrt
        https://bugs.webkit.org/show_bug.cgi?id=141546

        Reviewed by Geoffrey Garen and Filip Pizlo.

        Just fallback to the function call in the DFG codegen.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSqrt):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * tests/stress/math-sqrt-basics.js: Added.
        Basic coverage.

        * tests/stress/math-sqrt-basics-disable-architecture-specific-optimizations.js: Added.
        Same tests but forcing the function call.

2015-02-13  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r180060) New js/regress-141098 test crashes when LLInt is disabled.
        https://bugs.webkit.org/show_bug.cgi?id=141577

        Reviewed by Benjamin Poulain.

        Changed the prologue of the baseline JIT to check for stack space for all
        types of code blocks.  Previously, it was only checking Function.  Now
        it checks Program and Eval as well.

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

2015-02-13  Benjamin Poulain  <bpoulain@apple.com>

        Generate incq instead of addq when the immediate value is one
        https://bugs.webkit.org/show_bug.cgi?id=141548

        Reviewed by Gavin Barraclough.

        JSC emits "addq #1 (rXX)" *a lot*.
        This patch replace that by incq, which is one byte shorter
        and is the adviced form.

        Sunspider: +0.47%
        Octane: +0.28%
        Kraken: +0.44%
        AsmBench, CompressionBench: neutral.

        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::add64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::incq_m):

2015-02-13  Benjamin Poulain  <benjamin@webkit.org>

        Little clean up of Bytecode Generator's Label
        https://bugs.webkit.org/show_bug.cgi?id=141557

        Reviewed by Michael Saboff.

        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/BytecodeGenerator.cpp:
        Label was a friend of BytecodeGenerator in order to access
        m_instructions. There is no need for that, BytecodeGenerator
        has a public getter.

        * bytecompiler/Label.h:
        (JSC::Label::Label):
        (JSC::Label::setLocation):
        (JSC::BytecodeGenerator::newLabel):
        Make it explicit that the generator must exist.

2015-02-13  Michael Saboff  <msaboff@apple.com>

        Google doc spreadsheet reproducibly crashes when sorting
        https://bugs.webkit.org/show_bug.cgi?id=141098

        Reviewed by Oliver Hunt.

        Moved the stack check to before the callee registers are allocated in the
        prologue() by movving it from the functionInitialization() macro.  This
        way we can check the stack before moving the stack pointer, avoiding a
        crash during a "call" instruction.  Before this change, we weren't even
        checking the stack for program and eval execution.

        Made a couple of supporting changes.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::llint_stack_check): We can't just go up one frame as we
        may be processing an exception to an entry frame.

        * llint/LowLevelInterpreter.asm:

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        (llint_throw_from_slow_path_trampoline): Changed method to get the vm
        from the code block to not use the codeBlock, since we may need to
        continue from an exception in a native function.

2015-02-12  Benjamin Poulain  <benjamin@webkit.org>

        Simplify the initialization of BytecodeGenerator a bit
        https://bugs.webkit.org/show_bug.cgi?id=141505

        Reviewed by Anders Carlsson.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        Setup the default initialization at the declaration level
        instead of the constructor.

        Also made m_scopeNode and m_codeType const to make it explicit
        that they are invariant after construction.

        * parser/Nodes.cpp:
        * runtime/Executable.cpp:
        Remove 2 useless #includes.

2015-02-12  Benjamin Poulain  <benjamin@webkit.org>

        Move the generators for GetScope and SkipScope to the common core in DFGSpeculativeJIT
        https://bugs.webkit.org/show_bug.cgi?id=141506

        Reviewed by Michael Saboff.

        The generators for the nodes GetScope and SkipScope were
        completely identical between 32 and 64bits.

        This patch moves the duplicated code to DFGSpeculativeJIT.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetScope):
        (JSC::DFG::SpeculativeJIT::compileSkipScope):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2015-02-11  Brent Fulgham  <bfulgham@apple.com>

        [Win] [64-bit] Work around MSVC2013 Runtime Bug
        https://bugs.webkit.org/show_bug.cgi?id=141498
        <rdar://problem/19803642>

        Reviewed by Anders Carlsson.

        Disable FMA3 instruction use in the MSVC math library to
        work around a VS2013 runtime crash. We can remove this
        workaround when we switch to VS2015.

        * API/tests/testapi.c: Call _set_FMA3_enable(0) to disable
        FMA3 support.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add new files.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
        * JavaScriptCore.vcxproj/JavaScriptCoreDLL.cpp: Added.
        * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Call _set_FMA3_enable(0)
        to disable FMA3 support.
        * jsc.cpp: Ditto.
        * testRegExp.cpp: Ditto.

2015-02-11  Filip Pizlo  <fpizlo@apple.com>

        The callee frame helpers in DFG::SpeculativeJIT should be available to other JITs
        https://bugs.webkit.org/show_bug.cgi?id=141493

        Reviewed by Michael Saboff.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::calleeFrameSlot): Deleted.
        (JSC::DFG::SpeculativeJIT::calleeArgumentSlot): Deleted.
        (JSC::DFG::SpeculativeJIT::calleeFrameTagSlot): Deleted.
        (JSC::DFG::SpeculativeJIT::calleeFramePayloadSlot): Deleted.
        (JSC::DFG::SpeculativeJIT::calleeArgumentTagSlot): Deleted.
        (JSC::DFG::SpeculativeJIT::calleeArgumentPayloadSlot): Deleted.
        (JSC::DFG::SpeculativeJIT::calleeFrameCallerFrame): Deleted.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::calleeFrameSlot):
        (JSC::AssemblyHelpers::calleeArgumentSlot):
        (JSC::AssemblyHelpers::calleeFrameTagSlot):
        (JSC::AssemblyHelpers::calleeFramePayloadSlot):
        (JSC::AssemblyHelpers::calleeArgumentTagSlot):
        (JSC::AssemblyHelpers::calleeArgumentPayloadSlot):
        (JSC::AssemblyHelpers::calleeFrameCallerFrame):

2015-02-11  Filip Pizlo  <fpizlo@apple.com>

        SetupVarargsFrame should not assume that an inline stack frame would have identical layout to a normal stack frame
        https://bugs.webkit.org/show_bug.cgi?id=141485

        Reviewed by Oliver Hunt.
        
        The inlineStackOffset argument was meant to make it easy for the DFG to use this helper for
        vararg calls from inlined code, but that doesn't work since the DFG inline call frame
        doesn't actually put the argument count at the JSStack::ArgumentCount offset. In fact there
        is really no such thing as an inlineStackOffset except when we OSR exit; while the code is
        running the stack layout is compacted so that the stackOffset is not meaningful.

        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SetupVarargsFrame.h:

2015-02-10  Filip Pizlo  <fpizlo@apple.com>

        Split FTL::JSCall into the part that knows about call inline caching and the part that interacts with LLVM patchpoints
        https://bugs.webkit.org/show_bug.cgi?id=141455

        Reviewed by Mark Lam.
        
        The newly introduced FTL::JSCallBase can be used to build other things, like the FTL portion
        of https://bugs.webkit.org/show_bug.cgi?id=141332.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::specializationKindFor):
        (JSC::CallLinkInfo::specializationKind):
        * ftl/FTLJSCall.cpp:
        (JSC::FTL::JSCall::JSCall):
        (JSC::FTL::JSCall::emit): Deleted.
        (JSC::FTL::JSCall::link): Deleted.
        * ftl/FTLJSCall.h:
        * ftl/FTLJSCallBase.cpp: Added.
        (JSC::FTL::JSCallBase::JSCallBase):
        (JSC::FTL::JSCallBase::emit):
        (JSC::FTL::JSCallBase::link):
        * ftl/FTLJSCallBase.h: Added.

2015-02-10  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix build.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2015-02-10  Filip Pizlo  <fpizlo@apple.com>

        op_call_varargs should only load the length once
        https://bugs.webkit.org/show_bug.cgi?id=141440
        rdar://problem/19761683

        Reviewed by Michael Saboff.
        
        Refactors the pair of calls that set up the varargs frame so that the first call returns the
        length, and the second call uses the length returned by the first one. It turns out that this
        gave me an opportunity to shorten a lot of the code.

        * interpreter/Interpreter.cpp:
        (JSC::sizeFrameForVarargs):
        (JSC::loadVarargs):
        (JSC::setupVarargsFrame):
        (JSC::setupVarargsFrameAndSetThis):
        * interpreter/Interpreter.h:
        (JSC::calleeFrameForVarargs):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetVarargsFrame):
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SetupVarargsFrame.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Arguments.cpp:
        (JSC::Arguments::copyToArguments):
        * runtime/Arguments.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::copyToArguments):
        * runtime/JSArray.h:
        * runtime/VM.h:
        * tests/stress/call-varargs-length-effects.js: Added.
        (foo):
        (bar):

2015-02-10  Michael Saboff  <msaboff@apple.com>

        Crash in JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq
        https://bugs.webkit.org/show_bug.cgi?id=139398

        Reviewed by Filip Pizlo.

        Due to CFA analysis, the CompareStrictEq node was determined to be unreachable, but later
        was determined to be reachable.  When we go to lower to LLVM, the edges for the CompareStrictEq
        node are UntypedUse which we can't compile.  Fixed this by checking that the IR before
        lowering can still be handled by the FTL.

        Had to add GetArgument as a node that the FTL can compile as the SSA conversion phase converts
        a SetArgument to a GetArgument.  Before this change FTL::canCompile() would never see a GetArgument
        node.  With the check right before lowering, we see this node.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl): Added a final FTL::canCompile() check before lowering
        to verify that after all the transformations we still have valid IR for the FTL.
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile): Added GetArgument as a node the FTL can compile.

2015-02-10  Filip Pizlo  <fpizlo@apple.com>

        Remove unused DFG::SpeculativeJIT::calleeFrameOffset().

        Rubber stamped by Michael Saboff.
        
        Not only was this not used, I believe that the math was wrong. The callee frame doesn't
        actually land past m_nextMachineLocal; instead it lands just below wherever we put SP and
        that decision is made elsewhere. Also, it makes no sense to subtract 1 from
        m_nextMachineLocal when trying to deduce the number of in-use stack slots.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::calleeFrameOffset): Deleted.

2015-02-10  Saam Barati  <saambarati1@gmail.com>

        Parser::parseVarDeclarationList gets the wrong JSToken for the last identifier
        https://bugs.webkit.org/show_bug.cgi?id=141272

        Reviewed by Oliver Hunt.

        This patch fixes a bug where the wrong text location would be 
        assigned to a variable declaration inside a ForIn/ForOf loop. 
        It also fixes a bug in the type profiler where the type profiler 
        emits the wrong text offset for a ForIn loop's variable declarator 
        when it's not a pattern node.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitLoopHeader):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVarDeclarationList):
        * tests/typeProfiler/loop.js:
        (testForIn):
        (testForOf):

2015-02-09  Saam Barati  <saambarati1@gmail.com>

        JSC's Type Profiler doesn't profile the type of the looping variable in ForOf/ForIn loops
        https://bugs.webkit.org/show_bug.cgi?id=141241

        Reviewed by Filip Pizlo.

        Type information is now recorded for ForIn and ForOf statements. 
        It was an oversight to not have these statements profiled before.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitLoopHeader):
        (JSC::ForOfNode::emitBytecode):
        * tests/typeProfiler/loop.js: Added.
        (testForIn):
        (testForOf):

2015-02-09  Filip Pizlo  <fpizlo@apple.com>

        DFG::StackLayoutPhase should always set the scopeRegister to VirtualRegister() because the DFG doesn't do anything to make its value valid
        https://bugs.webkit.org/show_bug.cgi?id=141412

        Reviewed by Michael Saboff.
        
        StackLayoutPhase was attempting to ensure that the register that
        CodeBlock::scopeRegister() points to is the right one for the DFG. But the DFG did nothing
        else to maintain the validity of the scopeRegister(). It wasn't captured as far as I can
        tell. StackLayoutPhase didn't explicitly mark it live. PreciseLocalClobberize didn't mark
        it as being live. So, by the time we got here the register referred to by
        CodeBlock::scopeRegister() would have been junk. Moreover, CodeBlock::scopeRegister() was
        not used for DFG code blocks, and was hardly ever used outside of bytecode generation.
        
        So, this patch just removes the code to manipulate this field and replaces it with an
        unconditional setScopeRegister(VirtualRegister()). Setting it to the invalid register
        ensures that any attempst to read the scopeRegister in a DFG or FTL frame immediately
        punts.

        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):

2015-02-09  Filip Pizlo  <fpizlo@apple.com>

        Varargs frame set-up should be factored out for use by other JITs
        https://bugs.webkit.org/show_bug.cgi?id=141388

        Reviewed by Michael Saboff.
        
        Previously the code that dealt with varargs always assumed that we were setting up a varargs call
        frame by literally following the execution semantics of op_call_varargs. This isn't how it'll
        happen once the DFG and FTL do varargs calls, or when varargs calls get inlined. The DFG and FTL
        don't literally execute bytecode; for example their stack frame layout has absolutely nothing in
        common with what the bytecode says, and that will never change.
        
        This patch makes two changes:
        
        Setting up the varargs callee frame can be done in smaller steps: particularly in the case of a
        varargs call that gets inlined, we aren't going to actually want to set up a callee frame in
        full - we just want to put the arguments somewhere, and that place will not have much (if
        anything) in common with the call frame format. This patch factors that out into something called
        a loadVarargs. The thing we used to call loadVarargs is now called setupVarargsFrame. This patch
        also separates loading varargs from setting this, since the fact that those two things are done
        together is a detail made explicit in bytecode but it's not at all required in the higher-tier
        engines. In the process of factoring this code out, I found a bunch of off-by-one errors in the
        various calculations. I fixed them. The distance from the caller's frame pointer to the callee
        frame pointer is always:
        
            numUsedCallerSlots + argCount + 1 + CallFrameSize
        
        where numUsedCallerSlots is toLocal(firstFreeRegister) - 1, which simplifies down to just
        -firstFreeRegister. The code now speaks of numUsedCallerSlots rather than firstFreeRegister,
        since the latter is a bytecode peculiarity that doesn't apply in the DFG or FTL. In the DFG, the
        internally-computed frame size, minus the parameter slots, will be used for numUsedCallerSlots.
        In the FTL, we will essentially compute numUsedCallerSlots dynamically by subtracting SP from FP.
        Eventually, LLVM might give us some cleaner way of doing this, but it probably doesn't matter
        very much.
        
        The arguments forwarding optimization is factored out of the Baseline JIT: the DFG and FTL will
        want to do this optimization as well, but it involves quite a bit of code. So, this code is now
        factored out into SetupVarargsFrame.h|cpp, so that other JITs can use it. In the process of factoring
        this code out I noticed that the 32-bit and 64-bit code is nearly identical, so I combined them.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.h:
        (JSC::ExecState::r):
        (JSC::ExecState::uncheckedR):
        * bytecode/VirtualRegister.h:
        (JSC::VirtualRegister::operator+):
        (JSC::VirtualRegister::operator-):
        (JSC::VirtualRegister::operator+=):
        (JSC::VirtualRegister::operator-=):
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        (JSC::sizeFrameForVarargs):
        (JSC::loadVarargs):
        (JSC::setupVarargsFrame):
        (JSC::setupVarargsFrameAndSetThis):
        * interpreter/Interpreter.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
        (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileSetupVarargsFrame):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        (JSC::JIT::emitGetFromCallFrameHeaderPtr): Deleted.
        (JSC::JIT::emitGetFromCallFrameHeader32): Deleted.
        (JSC::JIT::emitGetFromCallFrameHeader64): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/SetupVarargsFrame.cpp: Added.
        (JSC::emitSetupVarargsFrameFastCase):
        * jit/SetupVarargsFrame.h: Added.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Arguments.cpp:
        (JSC::Arguments::copyToArguments):
        * runtime/Arguments.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::copyToArguments):
        * runtime/JSArray.h:

2015-02-09  Filip Pizlo  <fpizlo@apple.com>

        DFG call codegen should resolve the callee operand as late as possible
        https://bugs.webkit.org/show_bug.cgi?id=141398

        Reviewed by Mark Lam.
        
        This is mostly a benign restructuring to help with the implementation of
        https://bugs.webkit.org/show_bug.cgi?id=141332.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):

2015-02-08  Filip Pizlo  <fpizlo@apple.com>

        DFG should only have two mechanisms for describing effectfulness of nodes; previously there were three
        https://bugs.webkit.org/show_bug.cgi?id=141369

        Reviewed by Michael Saboff.

        We previously used the NodeMightClobber and NodeClobbersWorld NodeFlags to describe
        effectfulness.  Starting over a year ago, we introduced a more powerful mechanism - the
        DFG::clobberize() function.  Now we only have one remaining client of the old NodeFlags,
        and everyone else uses DFG::clobberize().  We should get rid of those NodeFlags and
        finally switch everyone over to DFG::clobberize().
        
        Unfortunately there is still another place where effectfulness of nodes is described: the
        AbstractInterpreter. This is because the AbstractInterpreter has special tuning both for
        compile time performance and there are places where the AI is more precise than
        clobberize() because of its flow-sensitivity.
        
        This means that after this change there will be only two places, rather than three, where
        the effectfulness of a node has to be described:

        - DFG::clobberize()
        - DFG::AbstractInterpreter

        * dfg/DFGClobberize.cpp:
        (JSC::DFG::clobbersWorld):
        * dfg/DFGClobberize.h:
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteLength):
        (JSC::DFG::FixupPhase::convertToGetArrayLength):
        (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::isPredictedNumerical): Deleted.
        (JSC::DFG::Graph::byValIsPure): Deleted.
        (JSC::DFG::Graph::clobbersWorld): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToConstant):
        (JSC::DFG::Node::convertToGetLocalUnlinked):
        (JSC::DFG::Node::convertToGetByOffset):
        (JSC::DFG::Node::convertToMultiGetByOffset):
        (JSC::DFG::Node::convertToPutByOffset):
        (JSC::DFG::Node::convertToMultiPutByOffset):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags):
        * dfg/DFGNodeFlags.h:
        * dfg/DFGNodeType.h:

2015-02-09  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(DFG_JIT) build
        https://bugs.webkit.org/show_bug.cgi?id=141387

        Reviewed by Darin Adler.

        * jit/Repatch.cpp:

2015-02-08  Benjamin Poulain  <benjamin@webkit.org>

        Remove a few duplicate propagation steps from the DFG's PredictionPropagation phase
        https://bugs.webkit.org/show_bug.cgi?id=141363

        Reviewed by Darin Adler.

        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        Some blocks were duplicated, they probably evolved separately
        to the same state.

2015-02-08  Benjamin Poulain  <benjamin@webkit.org>

        Remove useless declarations and a stale comment from DFGByteCodeParser.h
        https://bugs.webkit.org/show_bug.cgi?id=141361

        Reviewed by Darin Adler.

        The comment refers to the original form of the ByteCodeParser:
            parse(Graph&, JSGlobalData*, CodeBlock*, unsigned startIndex);

        That form is long dead, the comment is more misleading than anything.

        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGByteCodeParser.h:

2015-02-08  Benjamin Poulain  <benjamin@webkit.org>

        Encapsulate DFG::Plan's beforeFTL timestamp
        https://bugs.webkit.org/show_bug.cgi?id=141360

        Reviewed by Darin Adler.

        Make the attribute private, it is an internal state.

        Rename beforeFTL->timeBeforeFTL for readability.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:

2015-02-08  Benjamin Poulain  <bpoulain@apple.com>

        Remove DFGNode::hasArithNodeFlags()
        https://bugs.webkit.org/show_bug.cgi?id=141319

        Reviewed by Michael Saboff.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArithNodeFlags): Deleted.
        Unused code is unused.

2015-02-07  Chris Dumez  <cdumez@apple.com>

        Add Vector::removeFirstMatching() / removeAllMatching() methods taking lambda functions
        https://bugs.webkit.org/show_bug.cgi?id=141321

        Reviewed by Darin Adler.

        Use new Vector::removeFirstMatching() / removeAllMatching() methods.

2015-02-06  Filip Pizlo  <fpizlo@apple.com>

        DFG SSA shouldn't have SetArgument nodes
        https://bugs.webkit.org/show_bug.cgi?id=141342

        Reviewed by Mark Lam.

        I was wondering why we kept the SetArgument around for captured
        variables. It turns out we did so because we thought we had to, even
        though we didn't have to. The node is meaningless in SSA.

        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):

2015-02-06  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to use the DFG SetArgument node to indicate that someone set the value of a local out-of-band
        https://bugs.webkit.org/show_bug.cgi?id=141337

        Reviewed by Mark Lam.

        This mainly involved ensuring that SetArgument behaves just like SetLocal from a CPS standpoint, but with a special case for those SetArguments that
        are associated with the prologue.

        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::run):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeSet):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeSetLocal): Deleted.
        (JSC::DFG::CPSRethreadingPhase::canonicalizeSetArgument): Deleted.

2015-02-06  Mark Lam  <mark.lam@apple.com>

        MachineThreads should be ref counted.
        <https://webkit.org/b/141317>

        Reviewed by Filip Pizlo.

        The VM's MachineThreads registry object is being referenced from other
        threads as a raw pointer.  In a scenario where the VM is destructed on
        the main thread, there is no guarantee that another thread isn't still
        holding a reference to the registry and will eventually invoke
        removeThread() on it on thread exit.  Hence, there's a possible use
        after free scenario here.

        The fix is to make MachineThreads ThreadSafeRefCounted, and have all
        threads that references keep a RefPtr to it to ensure that it stays
        alive until the very last thread is done with it.

        * API/tests/testapi.mm:
        (useVMFromOtherThread): - Renamed to be more descriptive.
        (useVMFromOtherThreadAndOutliveVM):
        - Added a test that has another thread which uses the VM outlive the
          VM to confirm that there is no crash.

          However, I was not actually able to get the VM to crash without this
          patch because I wasn't always able to the thread destructor to be
          called.  With this patch applied, I did verify with some logging that
          the MachineThreads registry is only destructed after all threads
          have removed themselves from it.

        (threadMain): Deleted.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::~Heap):
        (JSC::Heap::gatherStackRoots):
        * heap/Heap.h:
        (JSC::Heap::machineThreads):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::removeCurrentThread):
        * heap/MachineStackMarker.h:

2015-02-06  Commit Queue  <commit-queue@webkit.org>

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

        caused missing symbols in non-WebKit clients of WTF::Vector
        (Requested by kling on #webkit).

        Reverted changeset:

        "Remove WTF::fastMallocGoodSize()."
        https://bugs.webkit.org/show_bug.cgi?id=141020
        http://trac.webkit.org/changeset/179743

2015-02-04  Filip Pizlo  <fpizlo@apple.com>

        Remove BytecodeGenerator::preserveLastVar() and replace it with a more robust mechanism for preserving non-temporary registers
        https://bugs.webkit.org/show_bug.cgi?id=141211

        Reviewed by Mark Lam.

        Previously, the way non-temporary registers were preserved (i.e. not reclaimed anytime
        we did newTemporary()) by calling preserveLastVar() after all non-temps are created. It
        would raise the refcount on the last (highest-numbered) variable created, and rely on
        the fact that register reclamation started at higher-numbered registers and worked its
        way down. So any retained register would block any lower-numbered registers from being
        reclaimed.
        
        Also, preserveLastVar() sets a thing called m_firstConstantIndex. It's unused.
        
        This removes preserveLastVar() and makes addVar() retain each register it creates. This
        is more explicit, since addVar() is the mechanism for creating non-temporary registers.
        
        To make this work I had to remove an assertion that Register::setIndex() can only be
        called when the refcount is zero. This method might be called after a var is created to
        change its index. This previously worked because preserveLastVar() would be called after
        we had already made all index changes, so the vars would still have refcount zero. Now
        they have refcount 1. I think it's OK to lose this assertion; I can't remember this
        assertion ever firing in a way that alerted me to a serious issue.
        
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::preserveLastVar): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::addVar):
        * bytecompiler/RegisterID.h:
        (JSC::RegisterID::setIndex):

2015-02-06  Andreas Kling  <akling@apple.com>

        Remove WTF::fastMallocGoodSize().
        <https://webkit.org/b/141020>

        Reviewed by Anders Carlsson.

        * assembler/AssemblerBuffer.h:
        (JSC::AssemblerData::AssemblerData):
        (JSC::AssemblerData::grow):

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

        CodeCache is not thread safe when adding the same source from two different threads
        https://bugs.webkit.org/show_bug.cgi?id=141275

        Reviewed by Mark Lam.

        The issue for this bug is that one thread, takes a cache miss in CodeCache::getGlobalCodeBlock,
        but in the process creates a cache entry with a nullptr UnlinkedCodeBlockType* which it
        will fill in later in the function.  During the body of that function, it allocates
        objects that may garbage collect.  During that garbage collection, we drop the all locks.
        While the locks are released by the first thread, another thread can enter the VM and might
        have exactly the same source and enter CodeCache::getGlobalCodeBlock() itself.  When it
        looks up the code block, it sees it as a cache it and uses the nullptr UnlinkedCodeBlockType*
        and crashes.  This fixes the problem by not dropping the locks during garbage collection.
        There are other likely scenarios where we have a data structure like this code cache in an
        unsafe state for arbitrary reentrance.

        Moved the functionality of DelayedReleaseScope directly into Heap.  Changed it into
        a simple list that is cleared with the new function Heap::releaseDelayedReleasedObjects.
        Now we accumulate objects to be released and release them when all locks are dropped or
        when destroying the Heap.  This eliminated the dropping and reaquiring of locks associated
        with the old scope form of this list.

        Given that all functionality of DelayedReleaseScope is now used and referenced by Heap
        and the lock management no longer needs to be done, just made the list a member of Heap.
        We do need to guard against the case that releasing an object can create more objects
        by calling into JS.  That is why releaseDelayedReleasedObjects() is written to remove
        an object to release so that we aren't recursively in Vector code.  The other thing we
        do in releaseDelayedReleasedObjects() is to guard against recursive calls to itself using
        the m_delayedReleaseRecursionCount.  We only release at the first entry into the function.
        This case is already tested by testapi.mm.

        * heap/DelayedReleaseScope.h: Removed file

        * API/JSAPIWrapperObject.mm:
        * API/ObjCCallbackFunction.mm:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::doSweep):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::tryAllocate):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::sweep):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::lastChanceToFinalize):
        (JSC::MarkedSpace::didFinishIterating):
        * heap/MarkedSpace.h:
        * heap/Heap.cpp:
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::zombifyDeadObjects):
        Removed references to DelayedReleaseScope and DelayedReleaseScope.h.

        * heap/Heap.cpp:
        (JSC::Heap::Heap): Initialized m_delayedReleaseRecursionCount.
        (JSC::Heap::lastChanceToFinalize): Call releaseDelayedObjectsNow() as the VM is going away.
        (JSC::Heap::releaseDelayedReleasedObjects): New function that released the accumulated
        delayed release objects.

        * heap/Heap.h:
        (JSC::Heap::m_delayedReleaseObjects): List of objects to be released later.
        (JSC::Heap::m_delayedReleaseRecursionCount): Counter to indicate that
        releaseDelayedReleasedObjects is being called recursively.
        * heap/HeapInlines.h:
        (JSC::Heap::releaseSoon): Changed location of list to add delayed release objects.
        
        * runtime/JSLock.cpp:
        (JSC::JSLock::willReleaseLock):
        Call Heap::releaseDelayedObjectsNow() when releasing the lock.

2015-02-05  Youenn Fablet  <youenn.fablet@crf.canon.fr> and Xabier Rodriguez Calvar <calvaris@igalia.com>

        [Streams API] Implement a barebone ReadableStream interface
        https://bugs.webkit.org/show_bug.cgi?id=141045

        Reviewed by Benjamin Poulain.

        * Configurations/FeatureDefines.xcconfig:

2015-02-05  Saam Barati  <saambarati1@gmail.com>

        Crash in uninitialized deconstructing variable.
        https://bugs.webkit.org/show_bug.cgi?id=141070

        Reviewed by Michael Saboff.

        According to the ES6 spec, when a destructuring pattern occurs
        as the left hand side of an assignment inside a var declaration 
        statement, the assignment must also have a right hand side value.
        "var {x} = {};" is a legal syntactic statement, but,
        "var {x};" is a syntactic error.

        Section 13.2.2 of the latest draft ES6 spec specifies this requirement:
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-variable-statement

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVarDeclaration):
        (JSC::Parser<LexerType>::parseVarDeclarationList):
        (JSC::Parser<LexerType>::parseForStatement):
        * parser/Parser.h:

2015-02-04  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Unreviewed, fix a build break on EFL port since r179648.

        * heap/MachineStackMarker.cpp: EFL port doesn't use previousThread variable. 
        (JSC::MachineThreads::tryCopyOtherThreadStacks):

2015-02-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ES6: Improved Console Support for Symbol Objects
        https://bugs.webkit.org/show_bug.cgi?id=141173

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Runtime.json:
        New type, "symbol".

        * inspector/InjectedScriptSource.js:
        Handle Symbol objects in a few places. They don't have properties
        and they cannot be implicitly converted to strings.

2015-02-04  Mark Lam  <mark.lam@apple.com>

        Undo gardening: Restoring the expected ERROR message since that is not the cause of the bot unhappiness.

        Not reviewed.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::tryCopyOtherThreadStacks):

2015-02-04  Mark Lam  <mark.lam@apple.com>

        Gardening: Changed expected ERROR message to WARNING to make test bots happy.

        Rubber stamped by Simon Fraser.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::tryCopyOtherThreadStacks):

2015-02-04  Mark Lam  <mark.lam@apple.com>

        r179576 introduce a deadlock potential during GC thread suspension.
        <https://webkit.org/b/141268>

        Reviewed by Michael Saboff.

        http://trac.webkit.org/r179576 introduced a potential for deadlocking.
        In the GC thread suspension loop, we currently delete
        MachineThreads::Thread that we detect to be invalid.  This is unsafe
        because we may have already suspended some threads, and one of those
        suspended threads may still be holding the C heap lock which we need
        for deleting the invalid thread.

        The fix is to put the invalid threads in a separate toBeDeleted list,
        and delete them only after GC has resumed all threads.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::removeCurrentThread):
        - Undo refactoring removeThreadWithLockAlreadyAcquired() out of
          removeCurrentThread() since it is no longer needed.

        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        - Put invalid Threads on a threadsToBeDeleted list, and delete those
          Threads only after all threads have been resumed.

        (JSC::MachineThreads::removeThreadWithLockAlreadyAcquired): Deleted.
        * heap/MachineStackMarker.h:

2015-02-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Clean up Object Property Descriptor Collection
        https://bugs.webkit.org/show_bug.cgi?id=141222

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        Use a list of options when determining which properties to collect
        instead of a few booleans with overlapping responsibilities.

2015-02-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: console.table with columnName filter for non-existent property should still show column
        https://bugs.webkit.org/show_bug.cgi?id=141066

        Reviewed by Timothy Hatcher.

        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::addToFrontend):
        When a user provides a second argument, e.g. console.table(..., columnNames),
        then pass that second argument to the frontend.

        * inspector/InjectedScriptSource.js:
        Add a FIXME about the old, unused path now.

2015-02-04  Saam Barati  <saambarati1@gmail.com>

        TypeSet can use 1 byte instead of 4 bytes for its m_seenTypes member variable
        https://bugs.webkit.org/show_bug.cgi?id=141204

        Reviewed by Darin Adler.

        There is no need to use 32 bits to store a TypeSet::RuntimeType set 
        bit-vector when the largest value for a single TypeSet::RuntimeType 
        is 0x80. 8 bits is enough to represent the set of seen types.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::doesTypeConformTo):
        * runtime/TypeSet.h:
        (JSC::TypeSet::seenTypes):

2015-02-04  Mark Lam  <mark.lam@apple.com>

        Remove concept of makeUsableFromMultipleThreads().
        <https://webkit.org/b/141221>

        Reviewed by Mark Hahnenberg.

        Currently, we rely on VM::makeUsableFromMultipleThreads() being called before we
        start acquiring the JSLock and entering the VM from different threads.
        Acquisition of the JSLock will register the acquiring thread with the VM's thread
        registry if not already registered.  However, it will only do this if the VM's
        thread specific key has been initialized by makeUsableFromMultipleThreads().

        This is fragile, and also does not read intuitively because one would expect to
        acquire the JSLock before calling any methods on the VM.  This is exactly what
        JSGlobalContextCreateInGroup() did (i.e. acquire the lock before calling
        makeUsableFromMultipleThreads()), but is wrong.  The result is that the invoking
        thread will not have been registered with the VM during that first entry into
        the VM.

        The fix is to make it so that we initialize the VM's thread specific key on
        construction of the VM's MachineThreads registry instead of relying on
        makeUsableFromMultipleThreads() being called.  With this, we can eliminate
        makeUsableFromMultipleThreads() altogether.

        Performance results are neutral in aggregate.

        * API/JSContextRef.cpp:
        (JSGlobalContextCreateInGroup):
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::MachineThreads):
        (JSC::MachineThreads::~MachineThreads):
        (JSC::MachineThreads::addCurrentThread):
        (JSC::MachineThreads::removeThread):
        (JSC::MachineThreads::gatherConservativeRoots):
        (JSC::MachineThreads::makeUsableFromMultipleThreads): Deleted.
        * heap/MachineStackMarker.h:
        * runtime/VM.cpp:
        (JSC::VM::sharedInstance):
        * runtime/VM.h:
        (JSC::VM::makeUsableFromMultipleThreads): Deleted.

2015-02-04  Chris Dumez  <cdumez@apple.com>

        Add removeFirst(value) / removeAll(value) methods to WTF::Vector
        https://bugs.webkit.org/show_bug.cgi?id=141192

        Reviewed by Benjamin Poulain.

        Use new Vector::removeFirst(value) / removeAll(value) API to simplify the
        code a bit.

        * inspector/InspectorValues.cpp:
        (Inspector::InspectorObjectBase::remove):

2015-02-03  Mark Lam  <mark.lam@apple.com>

        Workaround a thread library bug where thread destructors may not get called.
        <https://webkit.org/b/141209>

        Reviewed by Michael Saboff.

        There's a bug where thread destructors may not get called.  As far as
        we know, this only manifests on darwin ports.  We will work around this
        by checking at GC time if the platform thread is still valid.  If not,
        we'll purge it from the VM's registeredThreads list before proceeding
        with thread scanning activity.

        Note: it is important that we do this invalid thread detection during
        suspension, because the validity (and liveness) of the other thread is
        only guaranteed while it is suspended.

        * API/tests/testapi.mm:
        (threadMain):
        - Added a test to enter the VM from another thread before we GC on
          the main thread.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::removeThreadWithLockAlreadyAcquired):
        (JSC::MachineThreads::removeCurrentThread):
        - refactored removeThreadWithLockAlreadyAcquired() out from
          removeCurrentThread() so that we can also call it for purging invalid
          threads.
        (JSC::suspendThread):
        - Added a return status to tell if the suspension succeeded or not.
        (JSC::MachineThreads::tryCopyOtherThreadStacks):
        - Check if the suspension failed, and purge the thread if we can't
          suspend it.  Failure to suspend implies that the thread has
          terminated without calling its destructor.
        * heap/MachineStackMarker.h:

2015-02-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ASSERT mainThreadPthread launching remote debuggable JSContext app with Debug JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=141189

        Reviewed by Michael Saboff.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::singleton):
        Ensure we call WTF::initializeMainThread() on the main thread so that
        we can perform automatic String <-> NSString conversions.

2015-02-03  Brent Fulgham  <bfulgham@apple.com>

        [Win] Project file cleanups after r179429.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2015-02-02  Filip Pizlo  <fpizlo@apple.com>

        arguments[-1] should have well-defined behavior
        https://bugs.webkit.org/show_bug.cgi?id=141183

        Reviewed by Mark Lam.
        
        According to JSC's internal argument numbering, 0 is "this" and 1 is the first argument.
        In the "arguments[i]" expression, "this" is not accessible and i = 0 refers to the first
        argument. Previously we handled the bounds check in "arguments[i]" - where "arguments" is
        statically known to be the current function's arguments object - as follows:
        
            add 1, i
            branchAboveOrEqual i, callFrame.ArgumentCount, slowPath
        
        The problem with this is that if i = -1, this passes the test, and we end up accessing
        what would be the "this" argument slot. That's wrong, since we should really be bottoming
        out in arguments["-1"], which is usually undefined but could be anything. It's even worse
        if the function is inlined or if we're in a constructor - in that case the "this" slot
        could be garbage.
        
        It turns out that we had this bug in all of our engines.
        
        This fixes the issue by changing the algorithm to:
        
            load32 callFrame.ArgumentCount, tmp
            sub 1, tmp
            branchAboveOrEqual i, tmp, slowPath
        
        In some engines, we would have used the modified "i" (the one that had 1 added to it) for
        the subsequent argument load; since we don't do this anymore I also had to change some of
        the offsets on the BaseIndex arguments load.
        
        This also includes tests that are written in such a way as to get coverage on LLInt and
        Baseline JIT (get-my-argument-by-val-wrap-around-no-warm-up), DFG and FTL
        (get-my-argument-by-val-wrap-around), and DFG when we're being paranoid about the user
        overwriting the "arguments" variable (get-my-argument-by-val-safe-wrap-around). This also
        includes off-by-1 out-of-bounds tests for each of these cases, since in the process of
        writing the patch I broke the arguments[arguments.length] case in the DFG and didn't see
        any test failures.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::offsetOfArguments):
        (JSC::AssemblyHelpers::offsetOfArgumentsIncludingThis): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_argument_by_val):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_argument_by_val):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * tests/stress/get-my-argument-by-val-out-of-bounds-no-warm-up.js: Added.
        (foo):
        * tests/stress/get-my-argument-by-val-out-of-bounds.js: Added.
        (foo):
        * tests/stress/get-my-argument-by-val-safe-out-of-bounds.js: Added.
        (foo):
        * tests/stress/get-my-argument-by-val-safe-wrap-around.js: Added.
        (foo):
        * tests/stress/get-my-argument-by-val-wrap-around-no-warm-up.js: Added.
        (foo):
        * tests/stress/get-my-argument-by-val-wrap-around.js: Added.
        (foo):

2015-02-02  Filip Pizlo  <fpizlo@apple.com>

        MultiGetByOffset should be marked NodeMustGenerate
        https://bugs.webkit.org/show_bug.cgi?id=140137

        Reviewed by Michael Saboff.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToGetByOffset): We were sloppy - we should also clear NodeMustGenerate once it's a GetByOffset.
        (JSC::DFG::Node::convertToMultiGetByOffset): Assert that we converted from something that already had NodeMustGenerate.
        * dfg/DFGNodeType.h: We shouldn't DCE a node that does checks and could be effectful in baseline. Making MultiGetByOffset as NodeMustGenerate prevents DCE. FTL could still DCE the actual loads, but the checks will stay.
        * tests/stress/multi-get-by-offset-dce.js: Added. This previously failed because the getter wasn't called.
        (foo):

2015-02-02  Filip Pizlo  <fpizlo@apple.com>

        [FTL] inlined GetMyArgumentByVal with no arguments passed causes instant crash
        https://bugs.webkit.org/show_bug.cgi?id=141180
        rdar://problem/19677552

        Reviewed by Benjamin Poulain.
        
        If we do a GetMyArgumentByVal on an inlined call frame that has no arguments, then the
        bounds check already terminates execution. This means we can skip the part where we
        previously did an out-of-bound array access on the inlined call frame arguments vector.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::safelyInvalidateAfterTermination):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
        (JSC::FTL::LowerDFGToLLVM::terminate):
        (JSC::FTL::LowerDFGToLLVM::didAlreadyTerminate):
        (JSC::FTL::LowerDFGToLLVM::crash):
        * tests/stress/get-my-argument-by-val-inlined-no-formal-parameters.js: Added.
        (foo):
        (bar):

2015-02-02  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r179477): arguments simplification no longer works
        https://bugs.webkit.org/show_bug.cgi?id=141169

        Reviewed by Mark Lam.
        
        The operations involved in callee/scope access don't exit and shouldn't get in the way
        of strength-reducing a Flush to a PhantomLocal. Then the PhantomLocal shouldn't get in
        the way of further such strength-reduction. We also need to canonicalize PhantomLocal
        before running arguments simplification.

        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):

2015-02-02  Filip Pizlo  <fpizlo@apple.com>

        VirtualRegister should really know how to dump itself
        https://bugs.webkit.org/show_bug.cgi?id=141171

        Reviewed by Geoffrey Garen.
        
        Gives VirtualRegister a dump() method that pretty-prints the virtual register. The rest of
        the patch is all about using this new power.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::constantName):
        (JSC::CodeBlock::registerName):
        * bytecode/CodeBlock.h:
        (JSC::missingThisObjectMarker): Deleted.
        * bytecode/VirtualRegister.cpp: Added.
        (JSC::VirtualRegister::dump):
        * bytecode/VirtualRegister.h:
        (WTF::printInternal): Deleted.
        * dfg/DFGArgumentPosition.h:
        (JSC::DFG::ArgumentPosition::dump):
        * dfg/DFGFlushedAt.cpp:
        (JSC::DFG::FlushedAt::dump):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGPutLocalSinkingPhase.cpp:
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::reportValidationContext):
        * dfg/DFGValueSource.cpp:
        (JSC::DFG::ValueSource::dump):
        * dfg/DFGVariableEvent.cpp:
        (JSC::DFG::VariableEvent::dump):
        (JSC::DFG::VariableEvent::dumpSpillInfo):
        * ftl/FTLExitArgumentForOperand.cpp:
        (JSC::FTL::ExitArgumentForOperand::dump):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::dumpInContext):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::BytecodeSequence):

2015-02-02  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the HandleBlock piece of this patch.

        * heap/HandleBlock.h:
        * heap/HandleBlockInlines.h:
        (JSC::HandleBlock::create):
        (JSC::HandleBlock::destroy):
        (JSC::HandleBlock::HandleBlock):
        (JSC::HandleBlock::payloadEnd):
        * heap/HandleSet.cpp:
        (JSC::HandleSet::~HandleSet):
        (JSC::HandleSet::grow):

2015-02-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Support console.table
        https://bugs.webkit.org/show_bug.cgi?id=141058

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        Include the firstLevelKeys filter when generating previews.

        * runtime/ConsoleClient.cpp:
        (JSC::appendMessagePrefix):
        Differentiate console.table logs to system log.

2015-01-31  Filip Pizlo  <fpizlo@apple.com>

        BinarySwitch should be faster on average
        https://bugs.webkit.org/show_bug.cgi?id=141046

        Reviewed by Anders Carlsson.
        
        This optimizes our binary switch using math. It's strictly better than what we had before
        assuming we bottom out in some case (rather than fall through), assuming all cases get
        hit with equal probability. The difference is particularly large for large switch
        statements. For example, a switch statement with 1000 cases would previously require on
        average 13.207 branches to get to some case, while now it just requires 10.464.
        
        This is also a progression for the fall-through case, though we could shave off another
        1/6 branch on average if we wanted to - though it would regress taking a case (not falling
        through) by 1/6 branch. I believe it's better to bias the BinarySwitch for not falling
        through.
        
        This also adds some randomness to the algorithm to minimize the likelihood of us
        generating a switch statement that is always particularly bad for some input. Note that
        the randomness has no effect on average-case performance assuming all cases are equally
        likely.
        
        This ought to have no actual performance change because we don't rely on binary switches
        that much. The main reason why this change is interesting is that I'm finding myself
        increasingly relying on BinarySwitch, and I'd like to know that it's optimal.

        * jit/BinarySwitch.cpp:
        (JSC::BinarySwitch::BinarySwitch):
        (JSC::BinarySwitch::~BinarySwitch):
        (JSC::BinarySwitch::build):
        * jit/BinarySwitch.h:

2015-02-02  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Extend CSS.getSupportedCSSProperties to provide values for properties for CSS Augmented JSContext
        https://bugs.webkit.org/show_bug.cgi?id=141064

        Reviewed by Timothy Hatcher.

        * inspector/protocol/CSS.json:

2015-02-02  Daniel Bates  <dabates@apple.com>

        [iOS] ASSERTION FAILED: m_scriptExecutionContext->isContextThread() in ContextDestructionObserver::observeContext
        https://bugs.webkit.org/show_bug.cgi?id=141057
        <rdar://problem/19068790>

        Reviewed by Alexey Proskuryakov.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedIndicateMessage): Modified to call WTF::callOnWebThreadOrDispatchAsyncOnMainThread().
        (Inspector::dispatchAsyncOnQueueSafeForAnyDebuggable): Deleted; moved logic to common helper function,
        WTF::callOnWebThreadOrDispatchAsyncOnMainThread() so that it can be called from both RemoteInspector::receivedIndicateMessage()
        and CryptoKeyRSA::generatePair().

2015-02-02  Saam Barati  <saambarati1@gmail.com>

        Create tests for JSC's Control Flow Profiler
        https://bugs.webkit.org/show_bug.cgi?id=141123

        Reviewed by Filip Pizlo.

        This patch creates a control flow profiler testing API in jsc.cpp 
        that accepts a function and a string as arguments. The string must 
        be a substring of the text of the function argument. The API returns 
        a boolean indicating whether or not the basic block that encloses the 
        substring has executed.

        This patch uses this API to test that the control flow profiler
        behaves as expected on basic block boundaries. These tests do not
        provide full coverage for all JavaScript statements that can create
        basic blocks boundaries. Full coverage will come in a later patch.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionHasBasicBlockExecuted):
        * runtime/ControlFlowProfiler.cpp:
        (JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):
        * runtime/ControlFlowProfiler.h:
        * tests/controlFlowProfiler: Added.
        * tests/controlFlowProfiler.yaml: Added.
        * tests/controlFlowProfiler/driver: Added.
        * tests/controlFlowProfiler/driver/driver.js: Added.
        (assert):
        * tests/controlFlowProfiler/if-statement.js: Added.
        (testIf):
        (noMatches):
        * tests/controlFlowProfiler/loop-statements.js: Added.
        (forRegular):
        (forIn):
        (forOf):
        (whileLoop):
        * tests/controlFlowProfiler/switch-statements.js: Added.
        (testSwitch):
        * tests/controlFlowProfiler/test-jit.js: Added.
        (tierUpToBaseline):
        (tierUpToDFG):
        (baselineTest):
        (dfgTest):

2015-01-28  Filip Pizlo  <fpizlo@apple.com>

        Polymorphic call inlining should be based on polymorphic call inline caching rather than logging
        https://bugs.webkit.org/show_bug.cgi?id=140660

        Reviewed by Geoffrey Garen.
        
        When we first implemented polymorphic call inlining, we did the profiling based on a call
        edge log. The idea was to store each call edge (a tuple of call site and callee) into a
        global log that was processed lazily. Processing the log would give precise counts of call
        edges, and could be used to drive well-informed inlining decisions - polymorphic or not.
        This was a speed-up on throughput tests but a slow-down for latency tests. It was a net win
        nonetheless.
        
        Experience with this code shows three things. First, the call edge profiler is buggy and
        complex. It would take work to fix the bugs. Second, the call edge profiler incurs lots of
        overhead for latency code that we care deeply about. Third, it's not at all clear that
        having call edge counts for every possible callee is any better than just having call edge
        counts for the limited number of callees that an inline cache would catch.
        
        So, this patch removes the call edge profiler and replaces it with a polymorphic call inline
        cache. If we miss the basic call inline cache, we inflate the cache to be a jump to an
        out-of-line stub that cases on the previously known callees. If that misses again, then we
        rewrite that stub to include the new callee. We do this up to some number of callees. If we
        hit the limit then we switch to using a plain virtual call.
        
        Substantial speed-up on V8Spider; undoes the slow-down that the original call edge profiler
        caused. Might be a SunSpider speed-up (below 1%), depending on hardware.
        
        Rolling this back in after fixing https://bugs.webkit.org/show_bug.cgi?id=141107.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CallEdge.h:
        (JSC::CallEdge::count):
        (JSC::CallEdge::CallEdge):
        * bytecode/CallEdgeProfile.cpp: Removed.
        * bytecode/CallEdgeProfile.h: Removed.
        * bytecode/CallEdgeProfileInlines.h: Removed.
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::unlink):
        (JSC::CallLinkInfo::visitWeak):
        * bytecode/CallLinkInfo.h:
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::CallLinkStatus):
        (JSC::CallLinkStatus::computeFor):
        (JSC::CallLinkStatus::computeFromCallLinkInfo):
        (JSC::CallLinkStatus::isClosureCall):
        (JSC::CallLinkStatus::makeClosureCall):
        (JSC::CallLinkStatus::dump):
        (JSC::CallLinkStatus::computeFromCallEdgeProfile): Deleted.
        * bytecode/CallLinkStatus.h:
        (JSC::CallLinkStatus::CallLinkStatus):
        (JSC::CallLinkStatus::isSet):
        (JSC::CallLinkStatus::variants):
        (JSC::CallLinkStatus::size):
        (JSC::CallLinkStatus::at):
        (JSC::CallLinkStatus::operator[]):
        (JSC::CallLinkStatus::canOptimize):
        (JSC::CallLinkStatus::edges): Deleted.
        (JSC::CallLinkStatus::canTrustCounts): Deleted.
        * bytecode/CallVariant.cpp:
        (JSC::variantListWithVariant):
        (JSC::despecifiedVariantList):
        * bytecode/CallVariant.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::linkIncomingPolymorphicCall):
        (JSC::CodeBlock::unlinkIncomingCalls):
        (JSC::CodeBlock::noticeIncomingCall):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isIncomingCallAlreadyLinked): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        (JSC::DFG::TierUpCheckInjectionPhase::removeFTLProfiling): Deleted.
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * jit/BinarySwitch.h:
        * jit/ClosureCallStubRoutine.cpp: Removed.
        * jit/ClosureCallStubRoutine.h: Removed.
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        (JSC::operationLinkPolymorphicCallFor):
        (JSC::operationLinkClosureCallFor): Deleted.
        * jit/JITStubRoutine.h:
        * jit/JITWriteBarrier.h:
        * jit/PolymorphicCallStubRoutine.cpp: Added.
        (JSC::PolymorphicCallNode::~PolymorphicCallNode):
        (JSC::PolymorphicCallNode::unlink):
        (JSC::PolymorphicCallCase::dump):
        (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
        (JSC::PolymorphicCallStubRoutine::~PolymorphicCallStubRoutine):
        (JSC::PolymorphicCallStubRoutine::variants):
        (JSC::PolymorphicCallStubRoutine::edges):
        (JSC::PolymorphicCallStubRoutine::visitWeak):
        (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
        * jit/PolymorphicCallStubRoutine.h: Added.
        (JSC::PolymorphicCallNode::PolymorphicCallNode):
        (JSC::PolymorphicCallCase::PolymorphicCallCase):
        (JSC::PolymorphicCallCase::variant):
        (JSC::PolymorphicCallCase::codeBlock):
        * jit/Repatch.cpp:
        (JSC::linkSlowFor):
        (JSC::linkFor):
        (JSC::revertCall):
        (JSC::unlinkFor):
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        (JSC::linkClosureCall): Deleted.
        * jit/Repatch.h:
        * jit/ThunkGenerators.cpp:
        (JSC::linkPolymorphicCallForThunkGenerator):
        (JSC::linkPolymorphicCallThunkGenerator):
        (JSC::linkPolymorphicCallThatPreservesRegsThunkGenerator):
        (JSC::linkClosureCallForThunkGenerator): Deleted.
        (JSC::linkClosureCallThunkGenerator): Deleted.
        (JSC::linkClosureCallThatPreservesRegsThunkGenerator): Deleted.
        * jit/ThunkGenerators.h:
        (JSC::linkPolymorphicCallThunkGeneratorFor):
        (JSC::linkClosureCallThunkGeneratorFor): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::prepareToDiscardCode):
        (JSC::VM::ensureCallEdgeLog): Deleted.
        * runtime/VM.h:

2015-01-30  Filip Pizlo  <fpizlo@apple.com>

        Converting Flushes and PhantomLocals to Phantoms requires an OSR availability analysis rather than just using the SetLocal's child
        https://bugs.webkit.org/show_bug.cgi?id=141107

        Reviewed by Michael Saboff.
        
        See the bugzilla for a discussion of the problem. This addresses the problem by ensuring
        that Flushes are always strength-reduced to PhantomLocals, and CPS rethreading does a mini
        OSR availability analysis to determine the right MovHint value to use for the Phantom.

        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::clearVariables):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
        (JSC::DFG::CPSRethreadingPhase::clearVariablesAtHeadAndTail): Deleted.
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertPhantomToPhantomLocal):
        (JSC::DFG::Node::convertFlushToPhantomLocal):
        (JSC::DFG::Node::convertToPhantomLocal): Deleted.
        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        * tests/stress/inline-call-that-doesnt-use-all-args.js: Added.
        (foo):
        (bar):
        (baz):

2015-01-31  Michael Saboff  <msaboff@apple.com>

        Crash (DFG assertion) beneath AbstractInterpreter::verifyEdge() @ http://experilous.com/1/planet-generator/2014-09-28/version-1
        https://bugs.webkit.org/show_bug.cgi?id=141111

        Reviewed by Filip Pizlo.

        In LowerDFGToLLVM::compileNode(), if we determine while compiling a node that we would have
        exited, we don't need to process the OSR availability or abstract interpreter.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::safelyInvalidateAfterTermination): Broke this out a a separate
        method since we need to call it at the top and near the bottom of compileNode().
        (JSC::FTL::LowerDFGToLLVM::compileNode):

2015-01-31  Sam Weinig  <sam@webkit.org>

        Remove even more Mountain Lion support
        https://bugs.webkit.org/show_bug.cgi?id=141124

        Reviewed by Alexey Proskuryakov.

        * API/tests/DateTests.mm:
        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/Version.xcconfig:
        * jit/ExecutableAllocatorFixedVMPool.cpp:

2015-01-31  Commit Queue  <commit-queue@webkit.org>

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

        "caused a memory use regression" (Requested by Guest45 on
        #webkit).

        Reverted changeset:

        "Use FastMalloc (bmalloc) instead of BlockAllocator for GC
        pages"
        https://bugs.webkit.org/show_bug.cgi?id=140900
        http://trac.webkit.org/changeset/179426

2015-01-30  Daniel Bates  <dabates@apple.com>

        Clean up: Remove unnecessary <dispatch/dispatch.h> header from RemoteInspectorDebuggableConnection.h
        https://bugs.webkit.org/show_bug.cgi?id=141067

        Reviewed by Timothy Hatcher.

        Remove the header <dispatch/dispatch.h> from RemoteInspectorDebuggableConnection.h as we
        do not make use of its functionality. Instead, include this header in RemoteInspectorDebuggableConnection.mm
        and RemoteInspector.mm. The latter depended on <dispatch/dispatch.h> being included via
        header RemoteInspectorDebuggableConnection.h.

        * inspector/remote/RemoteInspector.mm: Include header <dispatch/dispatch.h>.
        * inspector/remote/RemoteInspectorDebuggableConnection.h: Remove header <dispatch/dispatch.h>.
        * inspector/remote/RemoteInspectorDebuggableConnection.mm: Include header <dispatch/dispatch.h>.

2015-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        Implement ES6 Symbol
        https://bugs.webkit.org/show_bug.cgi?id=140435

        Reviewed by Geoffrey Garen.

        This patch implements ES6 Symbol. In this patch, we don't support
        Symbol.keyFor, Symbol.for, Object.getOwnPropertySymbols. They will be
        supported in the subsequent patches.

        Since ES6 Symbol is introduced as new primitive value, we implement
        Symbol as a derived class from JSCell. And now JSValue accepts Symbol*
        as a new primitive value.

        Symbol has a *unique* flagged StringImpl* as an `uid`. Which pointer
        value represents the Symbol's identity. So don't compare Symbol's
        JSCell pointer value for comparison.
        This enables re-producing Symbol primitive value from StringImpl* uid
        by executing`Symbol::create(vm, uid)`. This is needed to produce
        Symbol primitive values from stored StringImpl* in `Object.getOwnPropertySymbols`.

        And Symbol.[[Description]] is folded into the string value of Symbol's uid.
        By doing so, we can represent ES6 Symbol without extending current PropertyTable key; StringImpl*.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.order:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createBuiltinExecutable):
        * builtins/BuiltinNames.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        * interpreter/Interpreter.cpp:
        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::getByVal):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createUndefinedVariableError):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::synthesizePrototype):
        (JSC::JSValue::dumpInContextAssumingStructure):
        (JSC::JSValue::toStringSlowCase):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::isSymbol):
        (JSC::JSValue::isPrimitive):
        (JSC::JSValue::toPropertyKey):

        It represents ToPropertyKey abstract operation in the ES6 spec.
        It cleans up the old implementation's `isName` checks.
        And to prevent performance regressions in
            js/regress/fold-get-by-id-to-multi-get-by-offset-rare-int.html
            js/regress/fold-get-by-id-to-multi-get-by-offset.html
        we annnotate this function as ALWAYS_INLINE.

        (JSC::JSValue::getPropertySlot):
        (JSC::JSValue::get):
        (JSC::JSValue::equalSlowCaseInline):
        (JSC::JSValue::strictEqualSlowCaseInline):
        * runtime/JSCell.cpp:
        (JSC::JSCell::put):
        (JSC::JSCell::putByIndex):
        (JSC::JSCell::toPrimitive):
        (JSC::JSCell::getPrimitiveNumber):
        (JSC::JSCell::toNumber):
        (JSC::JSCell::toObject):
        * runtime/JSCell.h:
        * runtime/JSCellInlines.h:
        (JSC::JSCell::isSymbol):
        (JSC::JSCell::toBoolean):
        (JSC::JSCell::pureToBoolean):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::symbolPrototype):
        (JSC::JSGlobalObject::symbolObjectStructure):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Stringifier):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/JSType.h:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::isName): Deleted.
        * runtime/MapData.cpp:
        (JSC::MapData::find):
        (JSC::MapData::add):
        (JSC::MapData::remove):
        (JSC::MapData::replaceAndPackBackingStore):
        * runtime/MapData.h:
        (JSC::MapData::clear):
        * runtime/NameInstance.h: Removed.
        * runtime/NamePrototype.cpp: Removed.
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorDefineProperty):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncHasOwnProperty):
        (JSC::objectProtoFuncDefineGetter):
        (JSC::objectProtoFuncDefineSetter):
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
        (JSC::objectProtoFuncPropertyIsEnumerable):
        * runtime/Operations.cpp:
        (JSC::jsTypeStringForValue):
        (JSC::jsIsObjectType):
        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):
        (JSC::PrivateName::operator==):
        (JSC::PrivateName::operator!=):
        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::find):
        (JSC::PropertyTable::get):
        * runtime/PropertyName.h:
        (JSC::PropertyName::PropertyName):
        (JSC::PropertyName::publicName):
        * runtime/SmallStrings.h:
        * runtime/StringConstructor.cpp:
        (JSC::callStringConstructor):

        In ES6, String constructor accepts Symbol to execute `String(symbol)`.

        * runtime/Structure.cpp:
        (JSC::Structure::getPropertyNamesFromStructure):
        * runtime/StructureInlines.h:
        (JSC::Structure::prototypeForLookup):
        * runtime/Symbol.cpp: Added.
        (JSC::Symbol::Symbol):
        (JSC::SymbolObject::create):
        (JSC::Symbol::toPrimitive):
        (JSC::Symbol::toBoolean):
        (JSC::Symbol::getPrimitiveNumber):
        (JSC::Symbol::toObject):
        (JSC::Symbol::toNumber):
        (JSC::Symbol::destroy):
        (JSC::Symbol::descriptiveString):
        * runtime/Symbol.h: Added.
        (JSC::Symbol::createStructure):
        (JSC::Symbol::create):
        (JSC::Symbol::privateName):
        (JSC::Symbol::finishCreation):
        (JSC::asSymbol):
        * runtime/SymbolConstructor.cpp: Renamed from Source/JavaScriptCore/runtime/NameConstructor.cpp.
        (JSC::SymbolConstructor::SymbolConstructor):
        (JSC::SymbolConstructor::finishCreation):
        (JSC::callSymbol):
        (JSC::SymbolConstructor::getConstructData):
        (JSC::SymbolConstructor::getCallData):
        * runtime/SymbolConstructor.h: Renamed from Source/JavaScriptCore/runtime/NameConstructor.h.
        (JSC::SymbolConstructor::create):
        (JSC::SymbolConstructor::createStructure):
        * runtime/SymbolObject.cpp: Renamed from Source/JavaScriptCore/runtime/NameInstance.cpp.
        (JSC::SymbolObject::SymbolObject):
        (JSC::SymbolObject::finishCreation):
        (JSC::SymbolObject::defaultValue):

        Now JSC doesn't support @@toPrimitive. So instead of it, we implement
        Symbol.prototype[@@toPrimitive] as ES5 Symbol.[[DefaultValue]].

        * runtime/SymbolObject.h: Added.
        (JSC::SymbolObject::create):
        (JSC::SymbolObject::internalValue):
        (JSC::SymbolObject::createStructure):
        * runtime/SymbolPrototype.cpp: Added.
        (JSC::SymbolPrototype::SymbolPrototype):
        (JSC::SymbolPrototype::finishCreation):
        (JSC::SymbolPrototype::getOwnPropertySlot):
        (JSC::symbolProtoFuncToString):
        (JSC::symbolProtoFuncValueOf):
        * runtime/SymbolPrototype.h: Renamed from Source/JavaScriptCore/runtime/NamePrototype.h.
        (JSC::SymbolPrototype::create):
        (JSC::SymbolPrototype::createStructure):

        SymbolPrototype object is ordinary JS object. Not wrapper object of Symbol.
        It is tested in js/symbol-prototype-is-ordinary-object.html.

        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2015-01-30  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the HandleBlock piece of this patch.

        * heap/HandleBlock.h:
        * heap/HandleBlockInlines.h:
        (JSC::HandleBlock::create):
        (JSC::HandleBlock::destroy):
        (JSC::HandleBlock::HandleBlock):
        (JSC::HandleBlock::payloadEnd):
        * heap/HandleSet.cpp:
        (JSC::HandleSet::~HandleSet):
        (JSC::HandleSet::grow):

2015-01-30  Geoffrey Garen  <ggaren@apple.com>

        GC marking threads should clear malloc caches
        https://bugs.webkit.org/show_bug.cgi?id=141097

        Reviewed by Sam Weinig.

        Follow-up based on Mark Hahnenberg's review: Release after the copy
        phase, rather than after any phase, since we'd rather not release
        between marking and copying.

        * heap/GCThread.cpp:
        (JSC::GCThread::waitForNextPhase):
        (JSC::GCThread::gcThreadMain):

2015-01-30  Geoffrey Garen  <ggaren@apple.com>

        GC marking threads should clear malloc caches
        https://bugs.webkit.org/show_bug.cgi?id=141097

        Reviewed by Andreas Kling.

        This is an attempt to ameliorate a potential memory use regression
        caused by https://bugs.webkit.org/show_bug.cgi?id=140900
        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages.

        FastMalloc may accumulate a per-thread cache on each of the 8-ish
        GC marking threads, which can be expensive.

        * heap/GCThread.cpp:
        (JSC::GCThread::waitForNextPhase): Scavenge the current thread before
        going to sleep. There's probably not too much value to keeping our
        per-thread cache between GCs, and it has some memory footprint.

2015-01-30  Chris Dumez  <cdumez@apple.com>

        Rename shared() static member functions to singleton() for singleton classes.
        https://bugs.webkit.org/show_bug.cgi?id=141088

        Reviewed by Ryosuke Niwa and Benjamin Poulain.

        Rename shared() static member functions to singleton() for singleton
        classes as per the recent coding style change.

        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::singleton):
        (Inspector::RemoteInspector::start):
        (Inspector::RemoteInspector::shared): Deleted.
        * inspector/remote/RemoteInspectorDebuggable.cpp:
        (Inspector::RemoteInspectorDebuggable::~RemoteInspectorDebuggable):
        (Inspector::RemoteInspectorDebuggable::init):
        (Inspector::RemoteInspectorDebuggable::update):
        (Inspector::RemoteInspectorDebuggable::setRemoteDebuggingAllowed):
        (Inspector::RemoteInspectorDebuggable::pauseWaitingForAutomaticInspection):
        (Inspector::RemoteInspectorDebuggable::unpauseForInitializedInspector):
        * inspector/remote/RemoteInspectorDebuggableConnection.mm:
        (Inspector::RemoteInspectorDebuggableConnection::setup):
        (Inspector::RemoteInspectorDebuggableConnection::sendMessageToFrontend):

2015-01-30  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the CopyWorkListSegment piece of this patch.

        * heap/CopiedBlockInlines.h:
        (JSC::CopiedBlock::reportLiveBytes):
        * heap/CopyWorkList.h:
        (JSC::CopyWorkListSegment::create):
        (JSC::CopyWorkListSegment::destroy):
        (JSC::CopyWorkListSegment::CopyWorkListSegment):
        (JSC::CopyWorkList::CopyWorkList):
        (JSC::CopyWorkList::~CopyWorkList):
        (JSC::CopyWorkList::append):

2015-01-29  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r179357 and r179358.
        https://bugs.webkit.org/show_bug.cgi?id=141062

        Suspect this caused WebGL tests to start flaking (Requested by
        kling on #webkit).

        Reverted changesets:

        "Polymorphic call inlining should be based on polymorphic call
        inline caching rather than logging"
        https://bugs.webkit.org/show_bug.cgi?id=140660
        http://trac.webkit.org/changeset/179357

        "Unreviewed, fix no-JIT build."
        http://trac.webkit.org/changeset/179358

2015-01-29  Geoffrey Garen  <ggaren@apple.com>

        Removed op_ret_object_or_this
        https://bugs.webkit.org/show_bug.cgi?id=141048

        Reviewed by Michael Saboff.

        op_ret_object_or_this was one opcode that would keep us out of the
        optimizing compilers.

        We don't need a special-purpose opcode; we can just use a branch.

        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isTerminal): Removed.
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset): Removed.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Removed.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitReturn): Use an explicit branch to determine
        if we need to substitute 'this' for the return value. Our engine no longer
        benefits from fused opcodes that dispatch less in the interpreter.

        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emit_op_ret_object_or_this): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_ret_object_or_this): Deleted.
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm: Removed.

2015-01-29  Ryosuke Niwa  <rniwa@webkit.org>

        Implement ES6 class syntax without inheritance support
        https://bugs.webkit.org/show_bug.cgi?id=140918

        Reviewed by Geoffrey Garen.

        Added the most basic support for ES6 class syntax. After this patch, we support basic class definition like:
        class A {
            constructor() { }
            someMethod() { }
        }

        We'll add the support for "extends" keyword and automatically generating a constructor in follow up patches.
        We also don't support block scoping of a class declaration.

        We support both class declaration and class expression. A class expression is implemented by the newly added
        ClassExprNode AST node. A class declaration is implemented by ClassDeclNode, which is a thin wrapper around
        AssignResolveNode.

        Tests: js/class-syntax-declaration.html
               js/class-syntax-expression.html

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectLiteralNode::emitBytecode): Create a new object instead of delegating the work to PropertyListNode.
        Also fixed the 5-space indentation.
        (JSC::PropertyListNode::emitBytecode): Don't create a new object now that ObjectLiteralNode does this.
        (JSC::ClassDeclNode::emitBytecode): Added. Just let the AssignResolveNode node emit the byte code.
        (JSC::ClassExprNode::emitBytecode): Create the class constructor and add static methods to the constructor by
        emitting the byte code for PropertyListNode. Add instance methods to the class's prototype object the same way.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createClassExpr): Added. Creates a ClassExprNode.
        (JSC::ASTBuilder::createClassDeclStatement): Added. Creates a AssignResolveNode and wraps it by a ClassDeclNode.

        * parser/NodeConstructors.h:
        (JSC::ClassDeclNode::ClassDeclNode): Added.
        (JSC::ClassExprNode::ClassExprNode): Added.

        * parser/Nodes.h:
        (JSC::ClassExprNode): Added.
        (JSC::ClassDeclNode): Added.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseStatement): Added the support for class declaration.
        (JSC::stringForFunctionMode): Return "method" for MethodMode.
        (JSC::Parser<LexerType>::parseClassDeclaration): Added. Uses parseClass to create a class expression and wraps
        it with ClassDeclNode as described above.
        (JSC::Parser<LexerType>::parseClass): Parses a class expression.
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseGetterSetter): Extracted from parseProperty to share the code between parseProperty
        and parseClass.
        (JSC::Parser<LexerType>::parsePrimaryExpression): Added the support for class expression.

        * parser/Parser.h:
        (FunctionParseMode): Added MethodMode.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createClassExpr): Added.
        (JSC::SyntaxChecker::createClassDeclStatement): Added.

2015-01-29  Geoffrey Garen  <ggaren@apple.com>

        Try to fix the Windows build.

        Not reviewed.

        * heap/WeakBlock.h: Use the fully qualified name when declaring our friend.

2015-01-29  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the WeakBlock piece of this patch.

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::destroy):
        (JSC::WeakBlock::WeakBlock):
        * heap/WeakBlock.h:
        * heap/WeakSet.cpp:
        (JSC::WeakSet::~WeakSet):
        (JSC::WeakSet::addAllocator):
        (JSC::WeakSet::removeAllocator):

2015-01-29  Geoffrey Garen  <ggaren@apple.com>

        Use Vector instead of GCSegmentedArray in CodeBlockSet
        https://bugs.webkit.org/show_bug.cgi?id=141044

        Reviewed by Ryosuke Niwa.

        This is allowed now that we've gotten rid of fastMallocForbid.

        4kB was a bit overkill for just storing a few pointers.

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::CodeBlockSet):
        * heap/CodeBlockSet.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):

2015-01-29  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix no-JIT build.

        * jit/PolymorphicCallStubRoutine.cpp:

2015-01-28  Filip Pizlo  <fpizlo@apple.com>

        Polymorphic call inlining should be based on polymorphic call inline caching rather than logging
        https://bugs.webkit.org/show_bug.cgi?id=140660

        Reviewed by Geoffrey Garen.
        
        When we first implemented polymorphic call inlining, we did the profiling based on a call
        edge log. The idea was to store each call edge (a tuple of call site and callee) into a
        global log that was processed lazily. Processing the log would give precise counts of call
        edges, and could be used to drive well-informed inlining decisions - polymorphic or not.
        This was a speed-up on throughput tests but a slow-down for latency tests. It was a net win
        nonetheless.
        
        Experience with this code shows three things. First, the call edge profiler is buggy and
        complex. It would take work to fix the bugs. Second, the call edge profiler incurs lots of
        overhead for latency code that we care deeply about. Third, it's not at all clear that
        having call edge counts for every possible callee is any better than just having call edge
        counts for the limited number of callees that an inline cache would catch.
        
        So, this patch removes the call edge profiler and replaces it with a polymorphic call inline
        cache. If we miss the basic call inline cache, we inflate the cache to be a jump to an
        out-of-line stub that cases on the previously known callees. If that misses again, then we
        rewrite that stub to include the new callee. We do this up to some number of callees. If we
        hit the limit then we switch to using a plain virtual call.
        
        Substantial speed-up on V8Spider; undoes the slow-down that the original call edge profiler
        caused. Might be a SunSpider speed-up (below 1%), depending on hardware.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CallEdge.h:
        (JSC::CallEdge::count):
        (JSC::CallEdge::CallEdge):
        * bytecode/CallEdgeProfile.cpp: Removed.
        * bytecode/CallEdgeProfile.h: Removed.
        * bytecode/CallEdgeProfileInlines.h: Removed.
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::unlink):
        (JSC::CallLinkInfo::visitWeak):
        * bytecode/CallLinkInfo.h:
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::CallLinkStatus):
        (JSC::CallLinkStatus::computeFor):
        (JSC::CallLinkStatus::computeFromCallLinkInfo):
        (JSC::CallLinkStatus::isClosureCall):
        (JSC::CallLinkStatus::makeClosureCall):
        (JSC::CallLinkStatus::dump):
        (JSC::CallLinkStatus::computeFromCallEdgeProfile): Deleted.
        * bytecode/CallLinkStatus.h:
        (JSC::CallLinkStatus::CallLinkStatus):
        (JSC::CallLinkStatus::isSet):
        (JSC::CallLinkStatus::variants):
        (JSC::CallLinkStatus::size):
        (JSC::CallLinkStatus::at):
        (JSC::CallLinkStatus::operator[]):
        (JSC::CallLinkStatus::canOptimize):
        (JSC::CallLinkStatus::edges): Deleted.
        (JSC::CallLinkStatus::canTrustCounts): Deleted.
        * bytecode/CallVariant.cpp:
        (JSC::variantListWithVariant):
        (JSC::despecifiedVariantList):
        * bytecode/CallVariant.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::linkIncomingPolymorphicCall):
        (JSC::CodeBlock::unlinkIncomingCalls):
        (JSC::CodeBlock::noticeIncomingCall):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::isIncomingCallAlreadyLinked): Deleted.
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        (JSC::DFG::TierUpCheckInjectionPhase::removeFTLProfiling): Deleted.
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * jit/BinarySwitch.h:
        * jit/ClosureCallStubRoutine.cpp: Removed.
        * jit/ClosureCallStubRoutine.h: Removed.
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        (JSC::operationLinkPolymorphicCallFor):
        (JSC::operationLinkClosureCallFor): Deleted.
        * jit/JITStubRoutine.h:
        * jit/JITWriteBarrier.h:
        * jit/PolymorphicCallStubRoutine.cpp: Added.
        (JSC::PolymorphicCallNode::~PolymorphicCallNode):
        (JSC::PolymorphicCallNode::unlink):
        (JSC::PolymorphicCallCase::dump):
        (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
        (JSC::PolymorphicCallStubRoutine::~PolymorphicCallStubRoutine):
        (JSC::PolymorphicCallStubRoutine::variants):
        (JSC::PolymorphicCallStubRoutine::edges):
        (JSC::PolymorphicCallStubRoutine::visitWeak):
        (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
        * jit/PolymorphicCallStubRoutine.h: Added.
        (JSC::PolymorphicCallNode::PolymorphicCallNode):
        (JSC::PolymorphicCallCase::PolymorphicCallCase):
        (JSC::PolymorphicCallCase::variant):
        (JSC::PolymorphicCallCase::codeBlock):
        * jit/Repatch.cpp:
        (JSC::linkSlowFor):
        (JSC::linkFor):
        (JSC::revertCall):
        (JSC::unlinkFor):
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        (JSC::linkClosureCall): Deleted.
        * jit/Repatch.h:
        * jit/ThunkGenerators.cpp:
        (JSC::linkPolymorphicCallForThunkGenerator):
        (JSC::linkPolymorphicCallThunkGenerator):
        (JSC::linkPolymorphicCallThatPreservesRegsThunkGenerator):
        (JSC::linkClosureCallForThunkGenerator): Deleted.
        (JSC::linkClosureCallThunkGenerator): Deleted.
        (JSC::linkClosureCallThatPreservesRegsThunkGenerator): Deleted.
        * jit/ThunkGenerators.h:
        (JSC::linkPolymorphicCallThunkGeneratorFor):
        (JSC::linkClosureCallThunkGeneratorFor): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::prepareToDiscardCode):
        (JSC::VM::ensureCallEdgeLog): Deleted.
        * runtime/VM.h:

2015-01-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ES6: Improved Console Format for Set and Map Objects (like Arrays)
        https://bugs.webkit.org/show_bug.cgi?id=122867

        Reviewed by Timothy Hatcher.

        Add new Runtime.RemoteObject object subtypes for "map", "set", and "weakmap".

        Upgrade Runtime.ObjectPreview to include type/subtype information. Now,
        an ObjectPreview can be used for any value, in place of a RemoteObject,
        and not capture / hold a reference to the value. The value will be in
        the string description.

        Adding this information to ObjectPreview can duplicate some information
        in the protocol messages if a preview is provided, but simplifies
        previews, so that all the information you need for any RemoteObject
        preview is available. To slim messages further, make "overflow" and
        "properties" only available on previews that may contain properties.
        So, not primitives or null.

        Finally, for "Map/Set/WeakMap" add an "entries" list to the preview
        that will return previews with "key" and "value" properties depending
        on the collection type. To get live, non-preview objects from a
        collection, use Runtime.getCollectionEntries.

        In order to keep the WeakMap's values Weak the frontend may provide
        a unique object group name when getting collection entries. It may
        then release that object group, e.g. when not showing the WeakMap's
        values to the user, and thus remove the strong reference to the keys
        so they may be garbage collected.

        * runtime/WeakMapData.h:
        (JSC::WeakMapData::begin):
        (JSC::WeakMapData::end):
        Expose iterators so the Inspector may access WeakMap keys/values.

        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapEntries):
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        Discern "map", "set", and "weakmap" object subtypes.

        (Inspector::JSInjectedScriptHost::weakMapEntries):
        Return a list of WeakMap entries. These are strong references
        that the Inspector code is responsible for releasing.

        * inspector/protocol/Runtime.json:
        Update types and expose the new getCollectionEntries command.

        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getCollectionEntries):
        * inspector/InjectedScript.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getInternalProperties):
        (Inspector::InjectedScript::getCollectionEntries):
        Pass through to the InjectedScript and call getCollectionEntries.

        * inspector/scripts/codegen/generator.py:
        Add another type with runtime casting.

        * inspector/InjectedScriptSource.js:
        - Implement getCollectionEntries to get a range of values from a
        collection. The non-Weak collections have an order to their keys (in
        order of added) so range'd gets are okay. WeakMap does not have an
        order, so only allow fetching a number of values.
        - Update preview generation to address the Runtime.ObjectPreview
        type changes.

2015-01-28  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Re-landing just the GCArraySegment piece of this patch.

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::CodeBlockSet):
        * heap/CodeBlockSet.h:
        * heap/GCSegmentedArray.h:
        (JSC::GCArraySegment::GCArraySegment):
        * heap/GCSegmentedArrayInlines.h:
        (JSC::GCSegmentedArray<T>::GCSegmentedArray):
        (JSC::GCSegmentedArray<T>::~GCSegmentedArray):
        (JSC::GCSegmentedArray<T>::clear):
        (JSC::GCSegmentedArray<T>::expand):
        (JSC::GCSegmentedArray<T>::refill):
        (JSC::GCArraySegment<T>::create):
        (JSC::GCArraySegment<T>::destroy):
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        * heap/MarkStack.cpp:
        (JSC::MarkStackArray::MarkStackArray):
        * heap/MarkStack.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):

2015-01-29  Csaba Osztrogonác  <ossy@webkit.org>

        Move HAVE_DTRACE definition back to Platform.h
        https://bugs.webkit.org/show_bug.cgi?id=141033

        Reviewed by Dan Bernstein.

        * Configurations/Base.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-01-28  Geoffrey Garen  <ggaren@apple.com>

        Removed fastMallocForbid / fastMallocAllow
        https://bugs.webkit.org/show_bug.cgi?id=141012

        Reviewed by Mark Hahnenberg.

        Copy non-current thread stacks before scanning them instead of scanning
        them in-place.

        This operation is uncommon (i.e., never in the web content process),
        and even in a stress test with 4 threads it only copies about 27kB,
        so I think the performance cost is OK.

        Scanning in-place requires a complex dance where we constrain our GC
        data structures not to use malloc, free, or any other interesting functions
        that might acquire locks. We've gotten this wrong many times in the past,
        and I just got it wrong again yesterday. Since this code path is rarely
        tested, I want it to just make sense, and not depend on or constrain the
        details of the rest of the GC heap's design.

        * heap/MachineStackMarker.cpp:
        (JSC::otherThreadStack): Factored out a helper function for dealing with
        unaligned and/or backwards pointers.

        (JSC::MachineThreads::tryCopyOtherThreadStack): This is now the only
        constrained function, and it only calls memcpy and low-level thread APIs.

        (JSC::MachineThreads::tryCopyOtherThreadStacks): The design here is that
        you do one pass over all the threads to compute their combined size,
        and then a second pass to do all the copying. In theory, the threads may
        grow in between passes, in which case you'll continue until the threads
        stop growing. In practice, you never continue.

        (JSC::growBuffer): Helper function for growing.

        (JSC::MachineThreads::gatherConservativeRoots):
        (JSC::MachineThreads::gatherFromOtherThread): Deleted.
        * heap/MachineStackMarker.h: Updated for interface changes.

2015-01-28  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: remove CSS.setPropertyText, CSS.toggleProperty and related dead code
        https://bugs.webkit.org/show_bug.cgi?id=140961

        Reviewed by Timothy Hatcher.

        * inspector/protocol/CSS.json: Remove unused protocol methods.

2015-01-28  Dana Burkart  <dburkart@apple.com>

        Move ASan flag settings from DebugRelease.xcconfig to Base.xcconfig
        https://bugs.webkit.org/show_bug.cgi?id=136765

        Reviewed by Alexey Proskuryakov.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:

2015-01-27  Filip Pizlo  <fpizlo@apple.com>

        ExitSiteData saying m_takesSlowPath shouldn't mean early returning takesSlowPath() since for the non-LLInt case we later set m_couldTakeSlowPath, which is more precise
        https://bugs.webkit.org/show_bug.cgi?id=140980

        Reviewed by Oliver Hunt.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):

2015-01-27  Filip Pizlo  <fpizlo@apple.com>

        Move DFGBinarySwitch out of the DFG so that all of the JITs can use it
        https://bugs.webkit.org/show_bug.cgi?id=140959

        Rubber stamped by Geoffrey Garen.
        
        I want to use this for polymorphic stubs for https://bugs.webkit.org/show_bug.cgi?id=140660.
        This code no longer has DFG dependencies so this is a very clean move.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGBinarySwitch.cpp: Removed.
        * dfg/DFGBinarySwitch.h: Removed.
        * dfg/DFGSpeculativeJIT.cpp:
        * jit/BinarySwitch.cpp: Copied from Source/JavaScriptCore/dfg/DFGBinarySwitch.cpp.
        * jit/BinarySwitch.h: Copied from Source/JavaScriptCore/dfg/DFGBinarySwitch.h.

2015-01-27  Commit Queue  <commit-queue@webkit.org>

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

        Caused numerous layout test failures (Requested by mattbaker_
        on #webkit).

        Reverted changeset:

        "Use FastMalloc (bmalloc) instead of BlockAllocator for GC
        pages"
        https://bugs.webkit.org/show_bug.cgi?id=140900
        http://trac.webkit.org/changeset/179192

2015-01-27  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r178591): 20% regression in Octane box2d
        https://bugs.webkit.org/show_bug.cgi?id=140948

        Reviewed by Geoffrey Garen.

        Added check that we have a lexical environment to the arguments is captured check.
        It doesn't make sense to resolve "arguments" when it really isn't captured.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::willResolveToArgumentsRegister):

2015-01-26  Geoffrey Garen  <ggaren@apple.com>

        Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
        https://bugs.webkit.org/show_bug.cgi?id=140900

        Reviewed by Mark Hahnenberg.

        Removes some more custom allocation code.

        Looks like a speedup. (See results attached to bugzilla.)

        Will hopefully reduce memory use by improving sharing between the GC and
        malloc heaps.

        * API/JSBase.cpp:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj: Feed the compiler.

        * heap/BlockAllocator.cpp: Removed.
        * heap/BlockAllocator.h: Removed. No need for a custom allocator anymore.

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::CodeBlockSet):
        * heap/CodeBlockSet.h: Feed the compiler.

        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::createNoZeroFill):
        (JSC::CopiedBlock::create):
        (JSC::CopiedBlock::CopiedBlock):
        (JSC::CopiedBlock::isOversize):
        (JSC::CopiedBlock::payloadEnd):
        (JSC::CopiedBlock::capacity):
        * heap/CopiedBlockInlines.h:
        (JSC::CopiedBlock::reportLiveBytes): Each copied block now tracks its
        own size, since we can't rely on Region to tell us our size anymore.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::~CopiedSpace):
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocateOversize):
        * heap/CopiedSpaceInlines.h:
        (JSC::CopiedSpace::recycleEvacuatedBlock):
        (JSC::CopiedSpace::recycleBorrowedBlock):
        (JSC::CopiedSpace::allocateBlockForCopyingPhase):
        (JSC::CopiedSpace::allocateBlock):
        (JSC::CopiedSpace::startedCopying): Deallocate blocks directly, rather
        than pushing them onto the block allocator's free list; the block
        allocator doesn't exist anymore.

        * heap/CopyWorkList.h:
        (JSC::CopyWorkListSegment::create):
        (JSC::CopyWorkListSegment::CopyWorkListSegment):
        (JSC::CopyWorkList::~CopyWorkList):
        (JSC::CopyWorkList::append):
        (JSC::CopyWorkList::CopyWorkList): Deleted.
        * heap/GCSegmentedArray.h:
        (JSC::GCArraySegment::GCArraySegment):
        * heap/GCSegmentedArrayInlines.h:
        (JSC::GCSegmentedArray<T>::GCSegmentedArray):
        (JSC::GCSegmentedArray<T>::~GCSegmentedArray):
        (JSC::GCSegmentedArray<T>::clear):
        (JSC::GCSegmentedArray<T>::expand):
        (JSC::GCSegmentedArray<T>::refill):
        (JSC::GCArraySegment<T>::create):
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData):
        * heap/GCThreadSharedData.h: Feed the compiler.

        * heap/HandleBlock.h:
        * heap/HandleBlockInlines.h:
        (JSC::HandleBlock::create):
        (JSC::HandleBlock::HandleBlock):
        (JSC::HandleBlock::payloadEnd):
        * heap/HandleSet.cpp:
        (JSC::HandleSet::~HandleSet):
        (JSC::HandleSet::grow): Same as above.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        * heap/Heap.h: Removed the block allocator since it is unused now.

        * heap/HeapBlock.h:
        (JSC::HeapBlock::destroy):
        (JSC::HeapBlock::HeapBlock):
        (JSC::HeapBlock::region): Deleted. Removed the Region pointer from each
        HeapBlock since a HeapBlock is just a normal allocation now.

        * heap/HeapInlines.h:
        (JSC::Heap::blockAllocator): Deleted.

        * heap/HeapTimer.cpp:
        * heap/MarkStack.cpp:
        (JSC::MarkStackArray::MarkStackArray):
        * heap/MarkStack.h: Feed the compiler.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock): No need to use a custom code path
        based on size, since we use a general purpose allocator now.

        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):
        (JSC::MarkedBlock::MarkedBlock):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::capacity): Track block size explicitly, like CopiedBlock.

        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::freeBlock):
        * heap/MarkedSpace.h:

        * heap/Region.h: Removed.

        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor): Removed reference to block allocator.

        * heap/SuperRegion.cpp: Removed.
        * heap/SuperRegion.h: Removed.

        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::WeakBlock):
        * heap/WeakBlock.h:
        * heap/WeakSet.cpp:
        (JSC::WeakSet::~WeakSet):
        (JSC::WeakSet::addAllocator):
        (JSC::WeakSet::removeAllocator): Removed reference to block allocator.

2015-01-27  Csaba Osztrogonác  <ossy@webkit.org>

        [ARM] Typo fix after r176083
        https://bugs.webkit.org/show_bug.cgi?id=140937

        Reviewed by Anders Carlsson.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::ldrh):

2015-01-27  Csaba Osztrogonác  <ossy@webkit.org>

        [Win] Unreviewed gardening, skip failing tests.

        * tests/exceptionFuzz.yaml: Skip exception fuzz tests due to bug140928.
        * tests/mozilla/mozilla-tests.yaml: Skip ecma/Date/15.9.5.28-1.js due to bug140927.

2015-01-26  Csaba Osztrogonác  <ossy@webkit.org>

        [Win] Enable JSC stress tests by default
        https://bugs.webkit.org/show_bug.cgi?id=128307

        Unreviewed typo fix after r179165.

        * tests/mozilla/mozilla-tests.yaml:

2015-01-26  Csaba Osztrogonác  <ossy@webkit.org>

        [Win] Enable JSC stress tests by default
        https://bugs.webkit.org/show_bug.cgi?id=128307

        Reviewed by Brent Fulgham.

        * tests/mozilla/mozilla-tests.yaml: Skipped on Windows.
        * tests/stress/ftl-arithcos.js: Skipped on Windows.

2015-01-26  Ryosuke Niwa  <rniwa@webkit.org>

        Parse a function expression as a primary expression
        https://bugs.webkit.org/show_bug.cgi?id=140908

        Reviewed by Mark Lam.

        Moved the code to generate an AST node for a function expression from parseMemberExpression
        to parsePrimaryExpression to match the ES6 specification terminology:
        https://people.mozilla.org/~jorendorff/es6-draft.html#sec-primary-expression

        There should be no behavior change from this change since parsePrimaryExpression is only
        called in parseMemberExpression other than the fact failIfStackOverflow() is called.

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

2015-01-26  Myles C. Maxfield  <mmaxfield@apple.com>

        [iOS] [SVG -> OTF Converter] Flip the switch off on iOS
        https://bugs.webkit.org/show_bug.cgi?id=140860

        Reviewed by Darin Adler.

        The fonts it makes are grotesque. (See what I did there? Typographic
        humor is the best humor.)

        * Configurations/FeatureDefines.xcconfig:

2015-01-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Rename InjectedScriptHost::type to subtype
        https://bugs.webkit.org/show_bug.cgi?id=140841

        Reviewed by Timothy Hatcher.

        We were using this to set the subtype of an "object" type RemoteObject
        so we should clean up the name and call it subtype.

        * inspector/InjectedScriptHost.h:
        * inspector/InjectedScriptSource.js:
        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::subtype):
        (Inspector::JSInjectedScriptHost::type): Deleted.
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        (Inspector::jsInjectedScriptHostPrototypeFunctionSubtype):
        (Inspector::jsInjectedScriptHostPrototypeFunctionType): Deleted.

2015-01-23  Michael Saboff  <msaboff@apple.com>

        LayoutTests/js/script-tests/reentrant-caching.js crashing on 32 bit builds
        https://bugs.webkit.org/show_bug.cgi?id=140843

        Reviewed by Oliver Hunt.

        When we are in vmEntryToJavaScript, we keep the stack pointer at an
        alignment sutiable for pointing to a call frame header, which is the
        alignment post making a call.  We adjust the sp when calling to JS code,
        but don't adjust it before calling the out of stack handler.

        * llint/LowLevelInterpreter32_64.asm:
        Moved stack point down 8 bytes to get it aligned.

2015-01-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Object Previews in the Console
        https://bugs.webkit.org/show_bug.cgi?id=129204

        Reviewed by Timothy Hatcher.

        Update the very old, unused object preview code. Part of this comes from
        the earlier WebKit legacy implementation, and the Blink implementation.

        A RemoteObject may include a preview, if it is asked for, and if the
        RemoteObject is an object. Previews are a shallow (single level) list
        of a limited number of properties on the object. The previewed
        properties are always stringified (even if primatives). Previews are
        limited to just 5 properties or 100 indices. Previews are marked
        as lossless if they are a complete snapshot of the object.

        There is a path to make previews two levels deep, that is currently
        unused but should soon be used for tables (e.g. IndexedDB).

        * inspector/InjectedScriptSource.js:
        - Move some code off of InjectedScript to be generic functions
        usable by RemoteObject as well.
        - Update preview generation to use 

        * inspector/protocol/Runtime.json:
        - Add a new type, "accessor" for preview objects. This represents
        a getter / setter. We currently don't get the value.

2015-01-23  Michael Saboff  <msaboff@apple.com>

        Immediate crash when setting JS breakpoint
        https://bugs.webkit.org/show_bug.cgi?id=140811

        Reviewed by Mark Lam.

        When the DFG stack layout phase doesn't allocate a register for the scope register,
        it incorrectly sets the scope register in the code block to a bad value, one with
        an offset of 0.  Changed it so that we set the code block's scope register to the 
        invalid VirtualRegister instead.

        No tests needed as adding the ASSERT in setScopeRegister() was used to find the bug.
        We crash with that ASSERT in testapi and likely many other tests as well.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setScopeRegister):
        (JSC::CodeBlock::scopeRegister):
        Added ASSERTs to catch any future improper setting of the code block's scope register.

        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):

2015-01-22  Mark Hahnenberg  <mhahnenb@gmail.com>

        EdenCollections unnecessarily visit SmallStrings
        https://bugs.webkit.org/show_bug.cgi?id=140762

        Reviewed by Geoffrey Garen.

        * heap/Heap.cpp:
        (JSC::Heap::copyBackingStores): Also added a GCPhase for copying
        backing stores, which is a significant portion of garbage collection.
        (JSC::Heap::visitSmallStrings): Check to see if we need to visit
        SmallStrings based on the collection type.
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::SmallStrings):
        (JSC::SmallStrings::visitStrongReferences): Set the fact that we have
        visited the SmallStrings since the last modification.
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::needsToBeVisited): If we're doing a
        FullCollection, we need to visit. Otherwise, it depends on whether
        we've been visited since the last modification/allocation.

2015-01-22  Ryosuke Niwa  <rniwa@webkit.org>

        Add a build flag for ES6 class syntax
        https://bugs.webkit.org/show_bug.cgi?id=140760

        Reviewed by Michael Saboff.

        Added ES6_CLASS_SYNTAX build flag and used it in tokenizer to recognize
        "class", "extends", "static" and "super" keywords.

        * Configurations/FeatureDefines.xcconfig:
        * parser/Keywords.table:
        * parser/ParserTokens.h:

2015-01-22  Commit Queue  <commit-queue@webkit.org>

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

        Broke JSC and bindings tests (Requested by ap_ on #webkit).

        Reverted changeset:

        "put_by_val_direct need to check the property is index or not
        for using putDirect / putDirectIndex"
        https://bugs.webkit.org/show_bug.cgi?id=140426
        http://trac.webkit.org/changeset/178894

2015-01-22  Mark Lam  <mark.lam@apple.com>

        BytecodeGenerator::initializeCapturedVariable() sets a misleading value for the 5th operand of op_put_to_scope.
        <https://webkit.org/b/140743>

        Reviewed by Oliver Hunt.

        BytecodeGenerator::initializeCapturedVariable() was setting the 5th operand to
        op_put_to_scope to an inappropriate value (i.e. 0).  As a result, the execution
        of put_to_scope could store a wrong inferred value into the VariableWatchpointSet
        for which ever captured variable is at local index 0.  In practice, this turns
        out to be the local for the Arguments object.  In this reproduction case in the
        bug, the wrong inferred value written there is the boolean true.

        Subsequently, DFG compilation occurs and CreateArguments is emitted to first do
        a check of the local for the Arguments object.  But because that local has a
        wrong inferred value, the check always discovers a non-null value and we never
        actually create the Arguments object.  Immediately after this, an OSR exit
        occurs leaving the Arguments object local uninitialized.  Later on at arguments
        tear off, we run into a boolean true where we had expected to find an Arguments
        object, which in turn, leads to the crash.

        The fix is to:
        1. In the case where the resolveModeType is LocalClosureVar, change the
           5th operand of op_put_to_scope to be a boolean.  True means that the
           local var is watchable.  False means it is not watchable.  We no longer
           pass the local index (instead of true) and UINT_MAX (instead of false).

           This allows us to express more clearer in the code what that value means,
           as well as remove the redundant way of getting the local's identifier.
           The identifier is always the one passed in the 2nd operand. 

        2. Previously, though intuitively, we know that the watchable variable
           identifier should be the same as the one that is passed in operand 2, this
           relationship was not clear in the code.  By code analysis, I confirmed that 
           the callers of BytecodeGenerator::emitPutToScope() always use the same
           identifier for operand 2 and for filling out the ResolveScopeInfo from
           which we get the watchable variable identifier later.  I've changed the
           code to make this clear now by always using the identifier passed in
           operand 2.

        3. In the case where the resolveModeType is LocalClosureVar,
           initializeCapturedVariable() and emitPutToScope() will now query
           hasWatchableVariable() to determine if the local is watchable or not.
           Accordingly, we pass the boolean result of hasWatchableVariable() as
           operand 5 of op_put_to_scope.

        Also added some assertions.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::initializeCapturedVariable):
        (JSC::BytecodeGenerator::hasConstant):
        (JSC::BytecodeGenerator::emitPutToScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::hasWatchableVariable):
        (JSC::BytecodeGenerator::watchableVariableIdentifier):
        (JSC::BytecodeGenerator::watchableVariable): Deleted.

2015-01-22  Ryosuke Niwa  <rniwa@webkit.org>

        PropertyListNode::emitNode duplicates the code to put a constant property
        https://bugs.webkit.org/show_bug.cgi?id=140761

        Reviewed by Geoffrey Garen.

        Extracted PropertyListNode::emitPutConstantProperty to share the code.

        Also made PropertyListNode::emitBytecode private since nobody is calling this function directly.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        (JSC::PropertyListNode::emitPutConstantProperty): Added.
        * parser/Nodes.h:

2015-01-22  Yusuke Suzuki  <utatane.tea@gmail.com>

        put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
        https://bugs.webkit.org/show_bug.cgi?id=140426

        Reviewed by Geoffrey Garen.

        In the put_by_val_direct operation, we use JSObject::putDirect.
        However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
        This patch changes Identifier::asIndex() to return Optional<uint32_t>.
        It forces callers to check the value is index or not explicitly.
        Additionally, it checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDirectPutById):
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::emitPutTransitionStubAndGetOldStructure):
        * jsc.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Arguments.cpp:
        (JSC::Arguments::getOwnPropertySlot):
        (JSC::Arguments::put):
        (JSC::Arguments::deleteProperty):
        (JSC::Arguments::defineOwnProperty):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSort):
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::putDirectCustomAccessor):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::putDirectMayBeIndex):
        (JSC::JSObject::defineOwnProperty):
        * runtime/JSObject.h:
        (JSC::JSObject::getOwnPropertySlot):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::putDirectInternal):
        * runtime/JSString.cpp:
        (JSC::JSString::getStringPropertyDescriptor):
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        * runtime/PropertyName.h:
        (JSC::toUInt32FromCharacters):
        (JSC::toUInt32FromStringImpl):
        (JSC::PropertyName::asIndex):
        * runtime/PropertyNameArray.cpp:
        (JSC::PropertyNameArray::add):
        * runtime/StringObject.cpp:
        (JSC::StringObject::deleteProperty):
        * runtime/Structure.cpp:
        (JSC::Structure::prototypeChainMayInterceptStoreTo):

2015-01-21  Ryosuke Niwa  <rniwa@webkit.org>

        Consolidate out arguments of parseFunctionInfo into a struct
        https://bugs.webkit.org/show_bug.cgi?id=140754

        Reviewed by Oliver Hunt.

        Introduced ParserFunctionInfo for storing out arguments of parseFunctionInfo.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createGetterOrSetterProperty): This one takes a property name in addition to
        ParserFunctionInfo since the property name and the function name could differ.
        (JSC::ASTBuilder::createFuncDeclStatement):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        * parser/ParserFunctionInfo.h: Added.
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createClassDeclStatement):
        (JSC::SyntaxChecker::createGetterOrSetterProperty):

2015-01-21  Mark Hahnenberg  <mhahnenb@gmail.com>

        Change Heap::m_compiledCode to use a Vector
        https://bugs.webkit.org/show_bug.cgi?id=140717

        Reviewed by Andreas Kling.

        Right now it's a DoublyLinkedList, which is iterated during each
        collection. This contributes to some of the longish Eden pause times.
        A Vector would be more appropriate and would also allow ExecutableBase
        to be 2 pointers smaller.

        * heap/Heap.cpp:
        (JSC::Heap::deleteAllCompiledCode):
        (JSC::Heap::deleteAllUnlinkedFunctionCode):
        (JSC::Heap::clearUnmarkedExecutables):
        * heap/Heap.h:
        * runtime/Executable.h: No longer need to inherit from DoublyLinkedListNode.

2015-01-21  Ryosuke Niwa  <rniwa@webkit.org>

        BytecodeGenerator shouldn't expose all of its member variables
        https://bugs.webkit.org/show_bug.cgi?id=140752

        Reviewed by Mark Lam.

        Added "private:" and removed unused data members as detected by clang.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::lastOpcodeID): Added. Used in BinaryOpNode::emitBytecode.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BinaryOpNode::emitBytecode):

2015-01-21  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ASSERT expanding objects in console PrimitiveBindingTraits<T>::assertValueHasExpectedType
        https://bugs.webkit.org/show_bug.cgi?id=140746

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        Do not add impure properties to the descriptor object that will
        eventually be sent to the frontend.

2015-01-21  Matthew Mirman  <mmirman@apple.com>

        Updated split such that it does not include the empty end of input string match.
        https://bugs.webkit.org/show_bug.cgi?id=138129
        <rdar://problem/18807403>

        Reviewed by Filip Pizlo.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncSplit):
        * tests/stress/empty_eos_regex_split.js: Added.

2015-01-21  Michael Saboff  <msaboff@apple.com>

        Eliminate Scope slot from JavaScript CallFrame
        https://bugs.webkit.org/show_bug.cgi?id=136724

        Reviewed by Geoffrey Garen.

        This finishes the removal of the scope chain slot from the call frame header.

        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * ftl/FTLJSCall.cpp:
        (JSC::FTL::JSCall::emit):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        * interpreter/JSStack.h:
        * interpreter/VMInspector.cpp:
        (JSC::VMInspector::dumpFrame):
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        * jit/Repatch.cpp:
        (JSC::generateByIdStub):
        (JSC::linkClosureCall):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualForThunkGenerator):
        (JSC::nativeForGenerator):
        Deleted ScopeChain slot from JSStack.  Removed all code where ScopeChain was being
        read or set.  In most cases this was where we make JS calls.

        * interpreter/CallFrameClosure.h:
        (JSC::CallFrameClosure::setArgument):
        (JSC::CallFrameClosure::resetCallFrame): Deleted.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * interpreter/ProtoCallFrame.cpp:
        (JSC::ProtoCallFrame::init):
        * interpreter/ProtoCallFrame.h:
        (JSC::ProtoCallFrame::scope): Deleted.
        (JSC::ProtoCallFrame::setScope): Deleted.
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        Removed the related scopeChainValue member from ProtoCallFrame.  Reduced the number of
        registers that needed to be copied from the ProtoCallFrame to a callee's frame
        from 5 to 4.

        * llint/LowLevelInterpreter32_64.asm:
        In addition to the prior changes, also deleted the unused macro getDeBruijnScope.

2015-01-21  Michael Saboff  <msaboff@apple.com>

        Eliminate construct methods from NullGetterFunction and NullSetterFunction classes
        https://bugs.webkit.org/show_bug.cgi?id=140708

        Reviewed by Mark Lam.

        Eliminated construct methods and change getConstructData() for both classes to return
        ConstructTypeNone as they can never be called.

        * runtime/NullGetterFunction.cpp:
        (JSC::NullGetterFunction::getConstructData):
        (JSC::constructReturnUndefined): Deleted.
        * runtime/NullSetterFunction.cpp:
        (JSC::NullSetterFunction::getConstructData):
        (JSC::constructReturnUndefined): Deleted.

2015-01-21  Csaba Osztrogonác  <ossy@webkit.org>

        Remove ENABLE(INSPECTOR) ifdef guards
        https://bugs.webkit.org/show_bug.cgi?id=140668

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:
        * bindings/ScriptValue.cpp:
        (Deprecated::ScriptValue::toInspectorValue):
        * bindings/ScriptValue.h:
        * inspector/ConsoleMessage.cpp:
        * inspector/ConsoleMessage.h:
        * inspector/ContentSearchUtilities.cpp:
        * inspector/ContentSearchUtilities.h:
        * inspector/IdentifiersFactory.cpp:
        * inspector/IdentifiersFactory.h:
        * inspector/InjectedScript.cpp:
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptBase.cpp:
        * inspector/InjectedScriptBase.h:
        * inspector/InjectedScriptHost.cpp:
        * inspector/InjectedScriptHost.h:
        * inspector/InjectedScriptManager.cpp:
        * inspector/InjectedScriptManager.h:
        * inspector/InjectedScriptModule.cpp:
        * inspector/InjectedScriptModule.h:
        * inspector/InspectorAgentRegistry.cpp:
        * inspector/InspectorBackendDispatcher.cpp:
        * inspector/InspectorBackendDispatcher.h:
        * inspector/InspectorProtocolTypes.h:
        * inspector/JSGlobalObjectConsoleClient.cpp:
        * inspector/JSGlobalObjectInspectorController.cpp:
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectScriptDebugServer.cpp:
        * inspector/JSGlobalObjectScriptDebugServer.h:
        * inspector/JSInjectedScriptHost.cpp:
        * inspector/JSInjectedScriptHost.h:
        * inspector/JSInjectedScriptHostPrototype.cpp:
        * inspector/JSInjectedScriptHostPrototype.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        * inspector/JSJavaScriptCallFramePrototype.h:
        * inspector/JavaScriptCallFrame.cpp:
        * inspector/JavaScriptCallFrame.h:
        * inspector/ScriptCallFrame.cpp:
        (Inspector::ScriptCallFrame::buildInspectorObject):
        * inspector/ScriptCallFrame.h:
        * inspector/ScriptCallStack.cpp:
        (Inspector::ScriptCallStack::buildInspectorArray):
        * inspector/ScriptCallStack.h:
        * inspector/ScriptDebugServer.cpp:
        * inspector/agents/InspectorAgent.cpp:
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
        * inspector/agents/JSGlobalObjectConsoleAgent.h:
        * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
        * inspector/agents/JSGlobalObjectDebuggerAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * inspector/scripts/codegen/cpp_generator_templates.py:
        (CppGeneratorTemplates):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::inspectorTypeSet):
        (JSC::StructureShape::inspectorRepresentation):

2015-01-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Clean up InjectedScriptSource.js
        https://bugs.webkit.org/show_bug.cgi?id=140709

        Reviewed by Timothy Hatcher.

        This patch includes some relevant Blink patches and small changes.
        
        Patch by <aandrey@chromium.org>
        DevTools: Remove console last result $_ on console clear.
        https://src.chromium.org/viewvc/blink?revision=179179&view=revision

        Patch by <eustas@chromium.org>
        [Inspect DOM properties] incorrect CSS Selector Syntax
        https://src.chromium.org/viewvc/blink?revision=156903&view=revision

        * inspector/InjectedScriptSource.js:

2015-01-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Cleanup RuntimeAgent a bit
        https://bugs.webkit.org/show_bug.cgi?id=140706

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScript.h:
        * inspector/InspectorBackendDispatcher.h:
        * inspector/ScriptCallFrame.cpp:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::evaluate):
        (Inspector::InspectorRuntimeAgent::getProperties):
        (Inspector::InspectorRuntimeAgent::run):
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        (Inspector::recompileAllJSFunctionsForTypeProfiling):
        (Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):

2015-01-20  Matthew Mirman  <mmirman@apple.com>

        Made Identity in the DFG allocate a new temp register and move 
        the old data to it.
        https://bugs.webkit.org/show_bug.cgi?id=140700
        <rdar://problem/19339106>

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): 
        Added scratch registers for Identity. 
        * tests/mozilla/mozilla-tests.yaml: enabled previously failing test

2015-01-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Expanding event objects in console shows undefined for most values, it should have real values
        https://bugs.webkit.org/show_bug.cgi?id=137306

        Reviewed by Timothy Hatcher.

        Provide another optional parameter to getProperties, to gather a list
        of all own and getter properties.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getProperties):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptSource.js:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getProperties):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Runtime.json:

2015-01-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Should show dynamic specificity values
        https://bugs.webkit.org/show_bug.cgi?id=140647

        Reviewed by Benjamin Poulain.

        * inspector/protocol/CSS.json:
        Clarify CSSSelector optional values and add "dynamic" property indicating
        if the selector can be dynamic based on the element it is matched against.

2015-01-20  Commit Queue  <commit-queue@webkit.org>

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

        Caused 32-bit JSC test failures (Requested by JoePeck on
        #webkit).

        Reverted changeset:

        "put_by_val_direct need to check the property is index or not
        for using putDirect / putDirectIndex"
        https://bugs.webkit.org/show_bug.cgi?id=140426
        http://trac.webkit.org/changeset/178751

2015-01-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
        https://bugs.webkit.org/show_bug.cgi?id=140426

        Reviewed by Geoffrey Garen.

        In the put_by_val_direct operation, we use JSObject::putDirect.
        However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
        This patch changes Identifier::asIndex() to return Optional<uint32_t>.
        It forces callers to check the value is index or not explicitly.
        Additionally, it checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDirectPutById):
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::emitPutTransitionStubAndGetOldStructure):
        * jsc.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Arguments.cpp:
        (JSC::Arguments::getOwnPropertySlot):
        (JSC::Arguments::put):
        (JSC::Arguments::deleteProperty):
        (JSC::Arguments::defineOwnProperty):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSort):
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::put):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::putDirectCustomAccessor):
        (JSC::JSObject::deleteProperty):
        (JSC::JSObject::putDirectMayBeIndex):
        (JSC::JSObject::defineOwnProperty):
        * runtime/JSObject.h:
        (JSC::JSObject::getOwnPropertySlot):
        (JSC::JSObject::getPropertySlot):
        (JSC::JSObject::putDirectInternal):
        * runtime/JSString.cpp:
        (JSC::JSString::getStringPropertyDescriptor):
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/LiteralParser.cpp:
        (JSC::LiteralParser<CharType>::parse):
        * runtime/PropertyName.h:
        (JSC::toUInt32FromCharacters):
        (JSC::toUInt32FromStringImpl):
        (JSC::PropertyName::asIndex):
        * runtime/PropertyNameArray.cpp:
        (JSC::PropertyNameArray::add):
        * runtime/StringObject.cpp:
        (JSC::StringObject::deleteProperty):
        * runtime/Structure.cpp:
        (JSC::Structure::prototypeChainMayInterceptStoreTo):

2015-01-20  Michael Saboff  <msaboff@apple.com>

        REGRESSION(178696): Sporadic crashes while garbage collecting
        https://bugs.webkit.org/show_bug.cgi?id=140688

        Reviewed by Geoffrey Garen.

        Added missing visitor.append(&thisObject->m_nullSetterFunction).

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

2015-01-19  Brian J. Burg  <burg@cs.washington.edu>

        Web Replay: code generator should take supplemental specifications and allow cross-framework references
        https://bugs.webkit.org/show_bug.cgi?id=136312

        Reviewed by Joseph Pecoraro.

        Some types are shared between replay inputs from different frameworks.
        Previously, these type declarations were duplicated in every input
        specification file in which they were used. This caused some type encoding
        traits to be emitted twice if used from WebCore inputs and WebKit2 inputs.

        This patch teaches the replay inputs code generator to accept multiple
        input specification files. Inputs can freely reference types from other
        frameworks without duplicating declarations.

        On the code generation side, the model could contain types and inputs from
        frameworks that are not the target framework. Only generate code for the
        target framework.

        To properly generate cross-framework type encoding traits, use
        Type.encoding_type_argument in more places, and add the export macro for WebCore
        and the Test framework.

        Adjust some tests so that enum coverage is preserved by moving the enum types
        into "Test" (the target framework for tests).

        * JavaScriptCore.vcxproj/copy-files.cmd:
        For Windows, copy over JSInputs.json as if it were a private header.

        * JavaScriptCore.xcodeproj/project.pbxproj: Make JSInputs.json a private header.
        * replay/JSInputs.json:
        Put all primitive types and WTF types in this specification file.

        * replay/scripts/CodeGeneratorReplayInputs.py:
        (Input.__init__):
        (InputsModel.__init__): Keep track of the input's framework.
        (InputsModel.parse_specification): Parse the framework here. Adjust to new format,
        and allow either types or inputs to be missing from a single file.

        (InputsModel.parse_type_with_framework):
        (InputsModel.parse_input_with_framework):
        (Generator.should_generate_item): Added helper method.
        (Generator.generate_header): Filter inputs to generate.
        (Generator.generate_implementation): Filter inputs to generate.
        (Generator.generate_enum_trait_declaration): Filter enums to generate.
        Add WEBCORE_EXPORT macro to enum encoding traits.

        (Generator.generate_for_each_macro): Filter inputs to generate.
        (Generator.generate_enum_trait_implementation): Filter enums to generate.
        (generate_from_specifications): Added.
        (generate_from_specifications.parse_json_from_file):
        (InputsModel.parse_toplevel): Deleted.
        (InputsModel.parse_type_with_framework_name): Deleted.
        (InputsModel.parse_input): Deleted.
        (generate_from_specification): Deleted.
        * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
        * replay/scripts/tests/expected/fail-on-no-inputs.json-error: Removed.
        * replay/scripts/tests/expected/fail-on-no-types.json-error: Removed.
        * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
        * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
        * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
        * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
        * replay/scripts/tests/fail-on-c-style-enum-no-storage.json:
        * replay/scripts/tests/fail-on-duplicate-enum-type.json:
        * replay/scripts/tests/fail-on-duplicate-input-names.json:
        * replay/scripts/tests/fail-on-duplicate-type-names.json:
        * replay/scripts/tests/fail-on-enum-type-missing-values.json:
        * replay/scripts/tests/fail-on-missing-input-member-name.json:
        * replay/scripts/tests/fail-on-missing-input-name.json:
        * replay/scripts/tests/fail-on-missing-input-queue.json:
        * replay/scripts/tests/fail-on-missing-type-mode.json:
        * replay/scripts/tests/fail-on-missing-type-name.json:
        * replay/scripts/tests/fail-on-no-inputs.json:
        Removed, no longer required to be in a single file.

        * replay/scripts/tests/fail-on-no-types.json:
        Removed, no longer required to be in a single file.

        * replay/scripts/tests/fail-on-unknown-input-queue.json:
        * replay/scripts/tests/fail-on-unknown-member-type.json:
        * replay/scripts/tests/fail-on-unknown-type-mode.json:
        * replay/scripts/tests/generate-enum-encoding-helpers-with-guarded-values.json:
        * replay/scripts/tests/generate-enum-encoding-helpers.json:
        * replay/scripts/tests/generate-enum-with-guard.json:
        Include enums that are and are not generated.

        * replay/scripts/tests/generate-enums-with-same-base-name.json:
        * replay/scripts/tests/generate-event-loop-shape-types.json:
        * replay/scripts/tests/generate-input-with-guard.json:
        * replay/scripts/tests/generate-input-with-vector-members.json:
        * replay/scripts/tests/generate-inputs-with-flags.json:
        * replay/scripts/tests/generate-memoized-type-modes.json:

2015-01-20  Tomas Popela  <tpopela@redhat.com>

        [GTK] Cannot compile 2.7.3 on PowerPC machines
        https://bugs.webkit.org/show_bug.cgi?id=140616

        Include climits for INT_MAX and wtf/DataLog.h for dataLogF

        Reviewed by Csaba Osztrogonác.

        * runtime/BasicBlockLocation.cpp:

2015-01-19  Michael Saboff  <msaboff@apple.com>

        A "cached" null setter should throw a TypeException when called in strict mode and doesn't
        https://bugs.webkit.org/show_bug.cgi?id=139418

        Reviewed by Filip Pizlo.

        Made a new NullSetterFunction class similar to NullGetterFunction.  The difference is that 
        NullSetterFunction will throw a TypeError per the ECMA262 spec for a strict mode caller.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Added new files NullSetterFunction.cpp and NullSetterFunction.h.

        * runtime/GetterSetter.h:
        (JSC::GetterSetter::GetterSetter):
        (JSC::GetterSetter::isSetterNull):
        (JSC::GetterSetter::setSetter):
        Change setter instances from using NullGetterFunction to using NullSetterFunction.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::nullSetterFunction):
        Added m_nullSetterFunction and accessor.

        * runtime/NullSetterFunction.cpp: Added.
        (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
        (JSC::GetCallerStrictnessFunctor::operator()):
        (JSC::GetCallerStrictnessFunctor::callerIsStrict):
        (JSC::callerIsStrict):
        Method to determine if the caller is in strict mode.

        (JSC::callReturnUndefined):
        (JSC::constructReturnUndefined):
        (JSC::NullSetterFunction::getCallData):
        (JSC::NullSetterFunction::getConstructData):
        * runtime/NullSetterFunction.h: Added.
        (JSC::NullSetterFunction::create):
        (JSC::NullSetterFunction::createStructure):
        (JSC::NullSetterFunction::NullSetterFunction):
        Class with handlers for a null setter.

2015-01-19  Saam Barati  <saambarati1@gmail.com>

        Web Inspector: Provide a front end for JSC's Control Flow Profiler
        https://bugs.webkit.org/show_bug.cgi?id=138454

        Reviewed by Timothy Hatcher.

        This patch puts the final touches on what JSC needs to provide
        for the Web Inspector to show a UI for the control flow profiler.

        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::recompileAllJSFunctionsForTypeProfiling):
        * runtime/ControlFlowProfiler.cpp:
        (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
        * runtime/FunctionHasExecutedCache.cpp:
        (JSC::FunctionHasExecutedCache::getFunctionRanges):
        (JSC::FunctionHasExecutedCache::getUnexecutedFunctionRanges): Deleted.
        * runtime/FunctionHasExecutedCache.h:

2015-01-19  David Kilzer  <ddkilzer@apple.com>

        [iOS] Only use LLVM static library arguments on 64-bit builds of libllvmForJSC.dylib
        <http://webkit.org/b/140658>

        Reviewed by Filip Pizlo.

        * Configurations/LLVMForJSC.xcconfig: Set OTHER_LDFLAGS_LLVM
        only when building for 64-bit architectures.

2015-01-19  Filip Pizlo  <fpizlo@apple.com>

        ClosureCallStubRoutine no longer needs codeOrigin
        https://bugs.webkit.org/show_bug.cgi?id=140659

        Reviewed by Michael Saboff.
        
        Once upon a time, we would look for the CodeOrigin associated with a return PC. This search
        would start with the CodeBlock according to the caller frame's call frame header. But if the
        call was a closure call, the return PC would be inside some closure call stub. So if the
        CodeBlock search failed, we would search *all* closure call stub routines to see which one
        encompasses the return PC. Then, we would use the CodeOrigin stored in the stub routine
        object. This was all a bunch of madness, and we actually got rid of it - we now determine
        the CodeOrigin for a call frame using the encoded code origin bits inside the tag of the
        argument count.
        
        This patch removes the final vestiges of the madness:
        
        - Remove the totally unused method declaration for the thing that did the closure call stub
          search.
        
        - Remove the CodeOrigin field from the ClosureCallStubRoutine. Except for that crazy search
          that we no longer do, everyone else who finds a ClosureCallStubRoutine will find it via
          the CallLinkInfo. The CallLinkInfo also has the CodeOrigin, so we don't need this field
          anymore.

        * bytecode/CodeBlock.h:
        * jit/ClosureCallStubRoutine.cpp:
        (JSC::ClosureCallStubRoutine::ClosureCallStubRoutine):
        * jit/ClosureCallStubRoutine.h:
        (JSC::ClosureCallStubRoutine::executable):
        (JSC::ClosureCallStubRoutine::codeOrigin): Deleted.
        * jit/Repatch.cpp:
        (JSC::linkClosureCall):

2015-01-19  Saam Barati  <saambarati1@gmail.com>

        Basic block start offsets should never be larger than end offsets in the control flow profiler
        https://bugs.webkit.org/show_bug.cgi?id=140377

        Reviewed by Filip Pizlo.

        The bytecode generator will emit code more than once for some AST nodes. For instance, 
        the finally block of TryNode will emit two code paths for its finally block: one for 
        the normal path, and another for the path where an exception is thrown in the catch block. 
        
        This repeated code emission of the same AST node previously broke how the control 
        flow profiler computed text ranges of basic blocks because when the same AST node 
        is emitted multiple times, there is a good chance that there are ranges that span 
        from the end offset of one of these duplicated nodes back to the start offset of 
        the same duplicated node. This caused a basic block range to report a larger start 
        offset than end offset. This was incorrect. Now, when this situation is encountered 
        while linking a CodeBlock, the faulty range in question is ignored.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        * bytecode/CodeBlock.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitMultiLoopBytecode):
        (JSC::ForOfNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseConditionalExpression):
        * runtime/ControlFlowProfiler.cpp:
        (JSC::ControlFlowProfiler::ControlFlowProfiler):
        * runtime/ControlFlowProfiler.h:
        (JSC::ControlFlowProfiler::dummyBasicBlock):

2015-01-19  Myles C. Maxfield  <mmaxfield@apple.com>

        [SVG -> OTF Converter] Flip the switch on
        https://bugs.webkit.org/show_bug.cgi?id=140592

        Reviewed by Antti Koivisto.

        * Configurations/FeatureDefines.xcconfig:

2015-01-19  Brian J. Burg  <burg@cs.washington.edu>

        Web Replay: convert to is<T> and downcast<T> for decoding replay inputs
        https://bugs.webkit.org/show_bug.cgi?id=140512

        Reviewed by Chris Dumez.

        Generate a SPECIALIZE_TYPE_TRAITS_* chunk of code for each input. This cannot
        be done using REPLAY_INPUT_NAMES_FOR_EACH macro since that doesn't fully qualify
        input types, and the type traits macro is defined in namespace WTF.

        * replay/NondeterministicInput.h: Make overridden methods public.
        * replay/scripts/CodeGeneratorReplayInputs.py:
        (Generator.generate_header):
        (Generator.qualified_input_name): Allow forcing qualification. WTF is never a target framework.
        (Generator.generate_input_type_trait_declaration): Added.
        * replay/scripts/CodeGeneratorReplayInputsTemplates.py: Add a template.
        * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:

2015-01-19  Commit Queue  <commit-queue@webkit.org>

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

        Broke multiple SVG tests on Mountain Lion (Requested by ap on
        #webkit).

        Reverted changeset:

        "[SVG -> OTF Converter] Flip the switch on"
        https://bugs.webkit.org/show_bug.cgi?id=140592
        http://trac.webkit.org/changeset/178653

2015-01-18  Dean Jackson  <dino@apple.com>

        ES6: Support Array.of construction
        https://bugs.webkit.org/show_bug.cgi?id=140605
        <rdar://problem/19513655>

        Reviewed by Geoffrey Garen.

        Add and implementation of Array.of, described in 22.1.2.3 of the ES6
        specification (15 Jan 2015). The Array.of() method creates a new Array
        instance with a variable number of arguments, regardless of number or type
        of the arguments.

        * runtime/ArrayConstructor.cpp:
        (JSC::arrayConstructorOf): Create a new empty Array, then iterate
        over the arguments, setting them to the appropriate index.

2015-01-19  Myles C. Maxfield  <mmaxfield@apple.com>

        [SVG -> OTF Converter] Flip the switch on
        https://bugs.webkit.org/show_bug.cgi?id=140592

        Reviewed by Antti Koivisto.

        * Configurations/FeatureDefines.xcconfig:

2015-01-17  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: highlight data for overlay should use protocol type builders
        https://bugs.webkit.org/show_bug.cgi?id=129441

        Reviewed by Timothy Hatcher.

        Add a new domain for overlay types.

        * CMakeLists.txt:
        * DerivedSources.make:
        * inspector/protocol/OverlayTypes.json: Added.

2015-01-17  Michael Saboff  <msaboff@apple.com>

        Crash in JSScope::resolve() on tools.ups.com
        https://bugs.webkit.org/show_bug.cgi?id=140579

        Reviewed by Geoffrey Garen.

        For op_resolve_scope of a global property or variable that needs to check for the var
        injection check watchpoint, we need to keep the scope around with a Phantom.  The
        baseline JIT slowpath for op_resolve_scope needs the scope value if the watchpoint
        fired.

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

2015-01-16  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: code generator should introduce typedefs for protocol types that are arrays
        https://bugs.webkit.org/show_bug.cgi?id=140557

        Reviewed by Joseph Pecoraro.

        Currently, there is no generated type name for "array" type declarations such as Console.CallStack.
        This makes it longwinded and confusing to use the type in C++ code.

        This patch adds a typedef for array type declarations, so types such as Console::CallStack
        can be referred to directly, rather than using Inspector::Protocol::Array<Console::CallFrame>.

        Some tests were updated to cover array type declarations used as parameters and type members.

        * inspector/ScriptCallStack.cpp: Use the new typedef.
        (Inspector::ScriptCallStack::buildInspectorArray):
        * inspector/ScriptCallStack.h:
        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.cpp_protocol_type_for_type): If an ArrayType is nominal, use the typedef'd name instead.
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (_generate_typedefs_for_domain): Also generate typedefs for array type declarations.
        (_generate_typedefs_for_domain.Inspector):
        * inspector/scripts/codegen/models.py: Save the name of an ArrayType when it is a type declaration.
        (ArrayType.__init__):
        (Protocol.resolve_types):
        (Protocol.lookup_type_reference):
        * inspector/scripts/tests/commands-with-async-attribute.json:
        * inspector/scripts/tests/commands-with-optional-call-return-parameters.json:
        * inspector/scripts/tests/events-with-optional-parameters.json:
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        * inspector/scripts/tests/type-declaration-object-type.json:

2015-01-16  Brian J. Burg  <burg@cs.washington.edu>

        Web Replay: purge remaining PassRefPtr uses and minor cleanup
        https://bugs.webkit.org/show_bug.cgi?id=140456

        Reviewed by Andreas Kling.

        Get rid of PassRefPtr. Introduce default initializers where it makes sense.
        Remove mistaken uses of AtomicString that were not removed as part of r174113.

        * replay/EmptyInputCursor.h:
        * replay/InputCursor.h:
        (JSC::InputCursor::InputCursor):

2015-01-16  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: code generator should fail on duplicate parameter and member names
        https://bugs.webkit.org/show_bug.cgi?id=140555

        Reviewed by Timothy Hatcher.

        * inspector/scripts/codegen/models.py:
        (find_duplicates): Add a helper function to find duplicates in a list.
        (Protocol.parse_type_declaration):
        (Protocol.parse_command):
        (Protocol.parse_event):
        * inspector/scripts/tests/expected/fail-on-duplicate-command-call-parameter-names.json-error: Added.
        * inspector/scripts/tests/expected/fail-on-duplicate-command-return-parameter-names.json-error: Added.
        * inspector/scripts/tests/expected/fail-on-duplicate-event-parameter-names.json-error: Added.
        * inspector/scripts/tests/expected/fail-on-duplicate-type-member-names.json-error: Added.
        * inspector/scripts/tests/fail-on-duplicate-command-call-parameter-names.json: Added.
        * inspector/scripts/tests/fail-on-duplicate-command-return-parameter-names.json: Added.
        * inspector/scripts/tests/fail-on-duplicate-event-parameter-names.json: Added.
        * inspector/scripts/tests/fail-on-duplicate-type-member-names.json: Added.

2015-01-16  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r174226): Header on huffingtonpost.com is too large
        https://bugs.webkit.org/show_bug.cgi?id=140306

        Reviewed by Filip Pizlo.

        BytecodeGenerator::willResolveToArguments() is used to check to see if we can use the
        arguments register or whether we need to resolve "arguments".  If the arguments have
        been captured, then they are stored in the lexical environment and the arguments
        register is not used.

        Changed BytecodeGenerator::willResolveToArguments() to also check to see if the arguments
        register is captured.  Renamed the function to willResolveToArgumentsRegister() to
        better indicate what we are checking.

        Aligned 32 and 64 bit paths in ArgumentsRecoveryGenerator::generateFor() for creating
        an arguments object that was optimized out of an inlined callFrame.  The 32 bit path
        incorrectly calculated the location of the reified callee frame.  This alignment resulted
        in the removal of operationCreateInlinedArgumentsDuringOSRExit()

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::willResolveToArgumentsRegister):
        (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::willResolveToArguments): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::getArgumentByVal):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::ArrayPatternNode::emitDirectBinding):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::ArgumentsRecoveryGenerator::generateFor):
        * dfg/DFGOperations.cpp:
        (JSC::operationCreateInlinedArgumentsDuringOSRExit): Deleted.
        * dfg/DFGOperations.h:
        (JSC::operationCreateInlinedArgumentsDuringOSRExit): Deleted.

2015-01-15  Csaba Osztrogonác  <ossy@webkit.org>

        Remove ENABLE(SQL_DATABASE) guards
        https://bugs.webkit.org/show_bug.cgi?id=140434

        Reviewed by Darin Adler.

        * CMakeLists.txt:
        * Configurations/FeatureDefines.xcconfig:
        * DerivedSources.make:
        * inspector/protocol/Database.json:

2015-01-14  Alexey Proskuryakov  <ap@apple.com>

        Web Inspector and regular console use different source code locations for messages
        https://bugs.webkit.org/show_bug.cgi?id=140478

        Reviewed by Brian Burg.

        * inspector/ConsoleMessage.h: Expose computed source location.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::addMessageToConsole):
        (Inspector::InspectorConsoleAgent::stopTiming):
        (Inspector::InspectorConsoleAgent::count):
        * inspector/agents/InspectorConsoleAgent.h:
        addMessageToConsole() now takes a pre-made ConsoleMessage object.

        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
        (Inspector::JSGlobalObjectConsoleClient::warnUnimplemented):
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::reportAPIException):
        * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
        (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
        Updated for the above changes.

2015-01-15  Mark Lam  <mark.lam@apple.com>

        [Part 2] Argument object created by "Function dot arguments" should use a clone of argument values.
        <https://webkit.org/b/140093>

        Reviewed by Geoffrey Garen.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::createArguments):
        - We should not fetching the lexicalEnvironment here.  The reason we've
          introduced the ClonedArgumentsCreationMode is because the lexicalEnvironment
          may not be available to us at this point.  Instead, we'll just pass a nullptr.

        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOffForCloning):
        * runtime/Arguments.h:
        (JSC::Arguments::finishCreation):
        - Use the new tearOffForCloning() to tear off arguments right out of the values
          passed on the stack.  tearOff() is not appropriate for this purpose because
          it takes slowArgumentsData into account.

2015-01-14  Matthew Mirman  <mmirman@apple.com>

        Removed accidental commit of "invalid_array.js" 
        http://trac.webkit.org/changeset/178439

        * tests/stress/invalid_array.js: Removed.

2015-01-14  Matthew Mirman  <mmirman@apple.com>

        Fixes operationPutByIdOptimizes such that they check that the put didn't
        change the structure of the object who's property access is being
        cached.  Also removes uses of the new base value from the cache generation code.
        https://bugs.webkit.org/show_bug.cgi?id=139500

        Reviewed by Filip Pizlo.

        * jit/JITOperations.cpp:
        (JSC::operationPutByIdStrictOptimize): saved the structure before the put.
        (JSC::operationPutByIdNonStrictOptimize): ditto.
        (JSC::operationPutByIdDirectStrictOptimize): ditto.
        (JSC::operationPutByIdDirectNonStrictOptimize): ditto.
        * jit/Repatch.cpp:
        (JSC::generateByIdStub):
        (JSC::tryCacheGetByID):
        (JSC::tryBuildGetByIDList):
        (JSC::emitPutReplaceStub):
        (JSC::emitPutTransitionStubAndGetOldStructure): Added.
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryBuildPutByIdList):
        (JSC::tryRepatchIn):
        (JSC::emitPutTransitionStub): Deleted.
        * jit/Repatch.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/JSPropertyNameEnumerator.h:
        (JSC::genericPropertyNameEnumerator):
        * runtime/Operations.h:
        (JSC::normalizePrototypeChainForChainAccess): restructured to not use the base value.
        (JSC::normalizePrototypeChain): restructured to not use the base value.
        * tests/mozilla/mozilla-tests.yaml:
        * tests/stress/proto-setter.js: Added.
        * tests/stress/put-by-id-build-list-order-recurse.js: Added.
        Added test that fails without this patch.

2015-01-13  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused ResizeImage and DecodeImageData timeline events
        https://bugs.webkit.org/show_bug.cgi?id=140404

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:

2015-01-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        DFG can call PutByValDirect for generic arrays
        https://bugs.webkit.org/show_bug.cgi?id=140389

        Reviewed by Geoffrey Garen.

        Computed properties in object initializers (ES6) use the put_by_val_direct operation.
        However, current DFG asserts that put_by_val_direct is not used for the generic array,
        the assertion failure is raised.
        This patch allow DFG to use put_by_val_direct to generic arrays.

        And fix the DFG put_by_val_direct implementation for string properties.
        At first, put_by_val_direct is inteded to be used for spread elements.
        So the property keys were limited to numbers (indexes).
        But now, it's also used for computed properties in object initializers.

        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2015-01-13  Geoffrey Garen  <ggaren@apple.com>

        Out of bounds access in BytecodeGenerator::emitGetById under DotAccessorNode::emitBytecode
        https://bugs.webkit.org/show_bug.cgi?id=140397

        Reviewed by Geoffrey Garen.

        Patch by Alexey Proskuryakov.

        Reviewed, performance tested, and ChangeLogged by Geoffrey Garen.

        No performance change.

        No test, since this is a small past-the-end read, which is very
        difficult to turn into a reproducible failing test -- and existing tests
        crash reliably using ASan.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::DeleteBracketNode::emitBytecode):
        (JSC::DeleteDotNode::emitBytecode):
        (JSC::PrefixNode::emitResolve):
        (JSC::UnaryOpNode::emitBytecode):
        (JSC::BitwiseNotNode::emitBytecode):
        (JSC::BinaryOpNode::emitBytecode):
        (JSC::EqualNode::emitBytecode):
        (JSC::StrictEqualNode::emitBytecode):
        (JSC::ThrowableBinaryOpNode::emitBytecode):
        (JSC::AssignDotNode::emitBytecode):
        (JSC::AssignBracketNode::emitBytecode): Use RefPtr in more places. Any
        register used across a call to a function that might allocate a new
        temporary register must be held in a RefPtr.

2015-01-12  Michael Saboff  <msaboff@apple.com>

        Local JSArray* "keys" in objectConstructorKeys() is not marked during garbage collection
        https://bugs.webkit.org/show_bug.cgi?id=140348

        Reviewed by Mark Lam.

        We used to read registers in MachineThreads::gatherFromCurrentThread(), but that is too late
        because those registers may have been spilled on the stack and replaced with other values by
        the time we call down to gatherFromCurrentThread().

        Now we get the register contents at the same place that we demarcate the current top of
        stack using the address of a local variable, in Heap::markRoots().  The register contents
        buffer is passed along with the demarcation pointer.  These need to be done at this level 
        in the call tree and no lower, as markRoots() calls various functions that visit object
        pointers that may be latter proven dead.  Any of those pointers that are left on the
        stack or in registers could be incorrectly marked as live if we scan the stack contents
        from a called function or one of its callees.  The stack demarcation pointer and register
        saving need to be done in the same function so that we have a consistent stack, active
        and spilled registers.

        Because we don't want to make unnecessary calls to get the register contents, we use
        a macro to allocated, and possibly align, the register structure and get the actual
        register contents.


        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::gatherStackRoots):
        * heap/Heap.h:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::gatherFromCurrentThread):
        (JSC::MachineThreads::gatherConservativeRoots):
        * heap/MachineStackMarker.h:

2015-01-12  Benjamin Poulain  <benjamin@webkit.org>

        Add basic pattern matching support to the url filters
        https://bugs.webkit.org/show_bug.cgi?id=140283

        Reviewed by Andreas Kling.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        Make YarrParser.h private in order to use it from WebCore.

2015-01-12  Geoffrey Garen  <ggaren@apple.com>

        Out of bounds read in IdentifierArena::makeIdentifier
        https://bugs.webkit.org/show_bug.cgi?id=140376

        Patch by Alexey Proskuryakov.

        Reviewed and ChangeLogged by Geoffrey Garen.

        No test, since this is a small past-the-end read, which is very
        difficult to turn into a reproducible failing test -- and existing tests
        crash reliably using ASan.

        * parser/ParserArena.h:
        (JSC::IdentifierArena::makeIdentifier):
        (JSC::IdentifierArena::makeIdentifierLCharFromUChar): Check for a
        zero-length string input, like we do in the literal parser, since it is
        not valid to dereference characters in a zero-length string.

        A zero-length string is allowed in JavaScript -- for example, "".

2015-01-11  Sam Weinig  <sam@webkit.org>

        Remove support for SharedWorkers
        https://bugs.webkit.org/show_bug.cgi?id=140344

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2015-01-12  Myles C. Maxfield  <mmaxfield@apple.com>

        Allow targetting the SVG->OTF font converter with ENABLE(SVG_OTF_CONVERTER)
        https://bugs.webkit.org/show_bug.cgi?id=136769

        Reviewed by Antti Koivisto.

        * Configurations/FeatureDefines.xcconfig:

2015-01-12  Commit Queue  <commit-queue@webkit.org>

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

        Broke a JSC test (Requested by ap on #webkit).

        Reverted changeset:

        "Local JSArray* "keys" in objectConstructorKeys() is not
        marked during garbage collection"
        https://bugs.webkit.org/show_bug.cgi?id=140348
        http://trac.webkit.org/changeset/178266

2015-01-12  Michael Saboff  <msaboff@apple.com>

        Local JSArray* "keys" in objectConstructorKeys() is not marked during garbage collection
        https://bugs.webkit.org/show_bug.cgi?id=140348

        Reviewed by Mark Lam.

        Move the address of the local variable that is used to demarcate the top of the stack for 
        conservative roots down to MachineThreads::gatherFromCurrentThread() since it also gets
        the register values using setjmp().  That way we don't lose any callee save register
        contents between Heap::markRoots(), where it was set, and gatherFromCurrentThread().
        If we lose any JSObject* that are only in callee save registers, they will be GC'ed
        erroneously.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::gatherStackRoots):
        * heap/Heap.h:
        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::gatherFromCurrentThread):
        (JSC::MachineThreads::gatherConservativeRoots):
        * heap/MachineStackMarker.h:

2015-01-11  Eric Carlson  <eric.carlson@apple.com>

        Fix typo in testate.c error messages
        https://bugs.webkit.org/show_bug.cgi?id=140305

        Reviewed by Geoffrey Garen.

        * API/tests/testapi.c:
        (main): "... script did not timed out ..." -> "... script did not time out ..."

2015-01-09  Michael Saboff  <msaboff@apple.com>

        Breakpoint doesn't fire in this HTML5 game
        https://bugs.webkit.org/show_bug.cgi?id=140269

        Reviewed by Mark Lam.

        When parsing a single line cached function, use the lineStartOffset of the
        location where we found the cached function instead of the cached lineStartOffset.
        The cache location's lineStartOffset has not been adjusted for any possible
        containing functions.

        This change is not needed for multi-line cached functions.  Consider the
        single line source:

        function outer(){function inner1(){doStuff();}; (function inner2() {doMoreStuff()})()}

        The first parser pass, we parse and cache inner1() and inner2() with a lineStartOffset
        of 0.  Later when we parse outer() and find inner1() in the cache, SourceCode start
        character is at outer()'s outermost open brace.  That is what we should use for
        lineStartOffset for inner1().  When done parsing inner1() we set the parsing token
        to the saved location for inner1(), including the lineStartOffset of 0.  We need
        to use the value of lineStartOffset before we started parsing inner1().  That is
        what the fix does.  When we parse inner2() the lineStartOffset will be correct.

        For a multi-line function, the close brace is guaranteed to be on a different line
        than the open brace.  Hence, its lineStartOffset will not change with the change of
        the SourceCode start character

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

2015-01-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Uncaught Exception in ProbeManager deleting breakpoint
        https://bugs.webkit.org/show_bug.cgi?id=140279
        rdar://problem/19422299

        Reviewed by Oliver Hunt.

        * runtime/MapData.cpp:
        (JSC::MapData::replaceAndPackBackingStore):
        The cell table also needs to have its values fixed.

2015-01-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove or use TimelineAgent Resource related event types
        https://bugs.webkit.org/show_bug.cgi?id=140155

        Reviewed by Timothy Hatcher.

        Remove unused / stale Timeline event types.

        * inspector/protocol/Timeline.json:

2015-01-09  Csaba Osztrogonác  <ossy@webkit.org>

        REGRESSION(r177925): It broke the !ENABLE(INSPECTOR) build
        https://bugs.webkit.org/show_bug.cgi?id=140098

        Reviewed by Brian Burg.

        * inspector/InspectorBackendDispatcher.h: Missing ENABLE(INSPECTOR) guard added.

2015-01-08  Mark Lam  <mark.lam@apple.com>

        Argument object created by "Function dot arguments" should use a clone of the argument values.
        <https://webkit.org/b/140093>

        Reviewed by Geoffrey Garen.

        After the change in <https://webkit.org/b/139827>, the dfg-tear-off-arguments-not-activation.js
        test will crash.  The relevant code which manifests the issue is as follows:

            function bar() {
                return foo.arguments;
            }

            function foo(p) {
                var x = 42;
                if (p)
                    return (function() { return x; });
                else
                    return bar();
            }

        In this case, foo() has no knowledge of bar() needing its LexicalEnvironment and
        has dead code eliminated the SetLocal that stores it into its designated local.
        In bar(), the factory for the Arguments object (for creating foo.arguments) tries
        to read foo's LexicalEnvironment from its designated lexicalEnvironment local,
        but instead, finds it to be uninitialized.  This results in a null pointer access
        which causes a crash.

        This can be resolved by having bar() instantiate a clone of the Arguments object
        instead, and populate its elements with values fetched directly from foo's frame.
        There's no need to reference foo's LexicalEnvironment (whether present or not).

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::createArguments):
        * runtime/Arguments.h:
        (JSC::Arguments::finishCreation):

2015-01-08  Mark Lam  <mark.lam@apple.com>

        Make the LLINT and Baseline JIT's op_create_arguments and op_get_argument_by_val use their lexicalEnvironment operand.
        <https://webkit.org/b/140236>

        Reviewed by Geoffrey Garen.

        Will change the DFG to use the operand on a subsequent pass.  For now,
        the DFG uses a temporary thunk (operationCreateArgumentsForDFG()) to
        retain the old behavior of getting the lexicalEnviroment from the
        ExecState.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitGetArgumentByVal):
        (JSC::BytecodeGenerator::createArgumentsIfNecessary):
        - When the lexicalEnvironment is not available, pass the invalid VirtualRegister
          instead of an empty JSValue as the lexicalEnvironment operand.

        * dfg/DFGOperations.cpp:
        - Use the lexicalEnvironment from the ExecState for now.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        - Use the operationCreateArgumentsForDFG() thunk for now.

        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::lexicalEnvironmentOrNullptr):
        * interpreter/CallFrame.h:
        - Added this convenience function to return either the
          lexicalEnvironment or a nullptr so that we don't need to do a
          conditional check on codeBlock->needsActivation() at multiple sites.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::createArguments):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_arguments):
        (JSC::JIT::emitSlow_op_get_argument_by_val):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_arguments):
        (JSC::JIT::emitSlow_op_get_argument_by_val):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Arguments.h:
        (JSC::Arguments::create):
        (JSC::Arguments::finishCreation):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::argumentsGetter):

2015-01-08  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Pause Reason Improvements (Breakpoint, Debugger Statement, Pause on Next Statement)
        https://bugs.webkit.org/show_bug.cgi?id=138991

        Reviewed by Timothy Hatcher.

        * debugger/Debugger.cpp:
        (JSC::Debugger::Debugger):
        (JSC::Debugger::pauseIfNeeded):
        (JSC::Debugger::didReachBreakpoint):
        When actually pausing, if we hit a breakpoint ensure the reason
        is PausedForBreakpoint, otherwise use the current reason.

        * debugger/Debugger.h:
        Make pause reason and pausing breakpoint ID public.

        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::buildAssertPauseReason):
        (Inspector::buildCSPViolationPauseReason):
        (Inspector::InspectorDebuggerAgent::buildBreakpointPauseReason):
        (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason):
        (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
        (Inspector::buildObjectForBreakpointCookie):
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::removeBreakpoint):
        (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
        (Inspector::InspectorDebuggerAgent::pause):
        (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
        (Inspector::InspectorDebuggerAgent::currentCallFrames):
        (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
        Clean up creation of pause reason objects and other cleanup
        of PassRefPtr use and InjectedScript use.

        (Inspector::InspectorDebuggerAgent::didPause):
        Clean up so that we first check for an Exception, and then fall
        back to including a Pause Reason derived from the Debugger.

        * inspector/protocol/Debugger.json:
        Add new DebuggerStatement, Breakpoint, and PauseOnNextStatement reasons.

2015-01-08  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Type check NSArray's in ObjC Interfaces have the right object types
        https://bugs.webkit.org/show_bug.cgi?id=140209

        Reviewed by Timothy Hatcher.

        Check the types of objects in NSArrays for all interfaces (commands, events, types)
        when the user can set an array of objects. Previously we were only type checking
        they were RWIJSONObjects, now we add an explicit check for the exact object type.

        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator._generate_event):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
        (ObjCProtocolTypesImplementationGenerator._generate_setter_for_member):
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator.objc_class_for_array_type):
        (ObjCGenerator):

2015-01-07  Mark Lam  <mark.lam@apple.com>

        Add the lexicalEnvironment as an operand to op_get_argument_by_val.
        <https://webkit.org/b/140233>

        Reviewed by Filip Pizlo.

        This patch only adds the operand to the bytecode.  It is not in use yet.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetArgumentByVal):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2015-01-07  Yusuke Suzuki  <utatane.tea@gmail.com>

        Investigate the character type of repeated string instead of checking is8Bit flag
        https://bugs.webkit.org/show_bug.cgi?id=140139

        Reviewed by Darin Adler.

        Instead of checking is8Bit flag of the repeated string, investigate
        the actual value of the repeated character since i8Bit flag give a false negative case.

        * runtime/StringPrototype.cpp:
        (JSC::repeatCharacter):
        (JSC::stringProtoFuncRepeat):
        (JSC::repeatSmallString): Deleted.

2015-01-07  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ObjC Generate types from the GenericTypes domain
        https://bugs.webkit.org/show_bug.cgi?id=140229

        Reviewed by Timothy Hatcher.

        Generate types from the GenericTypes domain, as they are expected
        by other domains (like Page domain). Also, don't include the @protocol
        forward declaration for a domain if it doesn't have any commands.

        * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
        (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
        (ObjCBackendDispatcherHeaderGenerator): Deleted.
        (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations_for_domains): Deleted.
        * inspector/scripts/codegen/objc_generator.py:
        (ObjCGenerator):
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2015-01-07  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unnecessary copyRef for paramsObject in generated dispatchers
        https://bugs.webkit.org/show_bug.cgi?id=140228

        Reviewed by Timothy Hatcher.

        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:

2015-01-07  Saam Barati  <saambarati1@gmail.com>

        interpret op_profile_type in the LLInt instead of unconditionally calling into the slow path
        https://bugs.webkit.org/show_bug.cgi?id=140165

        Reviewed by Michael Saboff.

        Inlining the functionality of TypeProfilerLog::recordTypeInformationForLocation
        into the LLInt speeds up type profiling.

        * llint/LLIntOffsetsExtractor.cpp:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/TypeProfilerLog.h:
        (JSC::TypeProfilerLog::recordTypeInformationForLocation): Deleted.

2015-01-07  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: purge PassRefPtr from Inspector code and use Ref for typed and untyped protocol objects
        https://bugs.webkit.org/show_bug.cgi?id=140053

        Reviewed by Andreas Kling.

        This patch replaces uses of PassRefPtr with uses of RefPtr&& and WTF::move() in code
        related to Web Inspector. It also converts many uses of RefPtr to Ref where
        references are always non-null. These two refactorings have been combined since
        they tend to require similar changes to the code.

        Creation methods for subclasses of InspectorValue now return a Ref, and callsites
        have been updated to take a Ref instead of RefPtr.

        Builders for typed protocol objects now return a Ref. Since there is no implicit
        call to operator&, callsites now must explicitly call .release() to convert a
        builder object into the corresponding protocol object once required fields are set.
        Update callsites and use auto to eliminate repetition of longwinded protocol types.

        Tests for inspector protocol and replay inputs have been rebaselined.

        * bindings/ScriptValue.cpp:
        (Deprecated::jsToInspectorValue):
        (Deprecated::ScriptValue::toInspectorValue):
        * bindings/ScriptValue.h:
        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::addToFrontend):
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::buildObjectForSearchMatch):
        (Inspector::ContentSearchUtilities::searchInTextByLines):
        * inspector/ContentSearchUtilities.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getFunctionDetails):
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getInternalProperties):
        (Inspector::InjectedScript::wrapCallFrames):
        (Inspector::InjectedScript::wrapObject):
        (Inspector::InjectedScript::wrapTable):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeEvalCall): Split the early exits.
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase):
        (Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive):
        (Inspector::InspectorBackendDispatcher::create):
        (Inspector::InspectorBackendDispatcher::dispatch):
        (Inspector::InspectorBackendDispatcher::sendResponse):
        (Inspector::InspectorBackendDispatcher::reportProtocolError):
        (Inspector::getPropertyValue): Add a comment to clarify what this clever code does.
        (Inspector::InspectorBackendDispatcher::getInteger):
        (Inspector::InspectorBackendDispatcher::getDouble):
        (Inspector::InspectorBackendDispatcher::getString):
        (Inspector::InspectorBackendDispatcher::getBoolean):
        (Inspector::InspectorBackendDispatcher::getObject):
        (Inspector::InspectorBackendDispatcher::getArray):
        (Inspector::InspectorBackendDispatcher::getValue):
        * inspector/InspectorBackendDispatcher.h: Use a typed protocol object to collect
        protocol error strings.
        (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher):
        Convert the supplemental dispatcher's reference to Ref since it is never null.
        * inspector/InspectorEnvironment.h:
        * inspector/InspectorProtocolTypes.h: Get rid of ArrayItemHelper and
        StructItemTraits. Add more versions of addItem to handle pushing various types.
        (Inspector::Protocol::Array::openAccessors):
        (Inspector::Protocol::Array::addItem):
        (Inspector::Protocol::Array::create):
        (Inspector::Protocol::StructItemTraits::push):
        (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast): Assert argument.
        (Inspector::Protocol::StructItemTraits::pushRefPtr): Deleted.
        (Inspector::Protocol::ArrayItemHelper<String>::Traits::pushRaw): Deleted.
        (Inspector::Protocol::ArrayItemHelper<int>::Traits::pushRaw): Deleted.
        (Inspector::Protocol::ArrayItemHelper<double>::Traits::pushRaw): Deleted.
        (Inspector::Protocol::ArrayItemHelper<bool>::Traits::pushRaw): Deleted.
        (Inspector::Protocol::ArrayItemHelper<InspectorValue>::Traits::pushRefPtr): Deleted.
        (Inspector::Protocol::ArrayItemHelper<InspectorObject>::Traits::pushRefPtr): Deleted.
        (Inspector::Protocol::ArrayItemHelper<InspectorArray>::Traits::pushRefPtr): Deleted.
        (Inspector::Protocol::ArrayItemHelper<Protocol::Array<T>>::Traits::pushRefPtr): Deleted.
        * inspector/InspectorValues.cpp: Straighten out getArray and getObject to have
        the same call signature as other getters. Use Ref where possible.
        (Inspector::InspectorObjectBase::getBoolean):
        (Inspector::InspectorObjectBase::getString):
        (Inspector::InspectorObjectBase::getObject):
        (Inspector::InspectorObjectBase::getArray):
        (Inspector::InspectorObjectBase::getValue):
        (Inspector::InspectorObjectBase::writeJSON):
        (Inspector::InspectorArrayBase::get):
        (Inspector::InspectorObject::create):
        (Inspector::InspectorArray::create):
        (Inspector::InspectorValue::null):
        (Inspector::InspectorString::create):
        (Inspector::InspectorBasicValue::create):
        (Inspector::InspectorObjectBase::get): Deleted.
        * inspector/InspectorValues.h:
        (Inspector::InspectorObjectBase::setValue):
        (Inspector::InspectorObjectBase::setObject):
        (Inspector::InspectorObjectBase::setArray):
        (Inspector::InspectorArrayBase::pushValue):
        (Inspector::InspectorArrayBase::pushObject):
        (Inspector::InspectorArrayBase::pushArray):
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
        (Inspector::JSGlobalObjectConsoleClient::count):
        (Inspector::JSGlobalObjectConsoleClient::timeEnd):
        (Inspector::JSGlobalObjectConsoleClient::timeStamp):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::executionStopwatch):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/ScriptCallFrame.cpp:
        (Inspector::ScriptCallFrame::buildInspectorObject):
        * inspector/ScriptCallFrame.h:
        * inspector/ScriptCallStack.cpp:
        (Inspector::ScriptCallStack::create):
        (Inspector::ScriptCallStack::buildInspectorArray):
        * inspector/ScriptCallStack.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::enable):
        (Inspector::InspectorAgent::inspect):
        (Inspector::InspectorAgent::activateExtraDomain):
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
        (Inspector::buildObjectForBreakpointCookie):
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::setBreakpoint):
        (Inspector::InspectorDebuggerAgent::continueToLocation):
        (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
        (Inspector::InspectorDebuggerAgent::currentCallFrames):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        (Inspector::InspectorDebuggerAgent::breakProgram):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::buildErrorRangeObject):
        (Inspector::InspectorRuntimeAgent::callFunctionOn):
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        (Inspector::InspectorRuntimeAgent::getBasicBlocks):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.cpp_type_for_unchecked_formal_in_parameter):
        (CppGenerator.cpp_type_for_type_with_name):
        (CppGenerator.cpp_type_for_formal_async_parameter):
        (CppGenerator.should_use_references_for_type):
        (CppGenerator):
        * inspector/scripts/codegen/cpp_generator_templates.py:
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator.generate_output):
        (CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator.generate_output):
        (_generate_class_for_object_declaration):
        (_generate_unchecked_setter_for_member):
        (_generate_forward_declarations_for_binding_traits):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator._generate_event):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        * replay/EncodedValue.cpp:
        (JSC::EncodedValue::asObject):
        (JSC::EncodedValue::asArray):
        (JSC::EncodedValue::put<EncodedValue>):
        (JSC::EncodedValue::append<EncodedValue>):
        (JSC::EncodedValue::get<EncodedValue>):
        * replay/EncodedValue.h:
        * replay/scripts/CodeGeneratorReplayInputs.py:
        (Type.borrow_type):
        (Type.argument_type):
        (Generator.generate_member_move_expression):
        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::printConsoleMessageWithArguments):
        (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
        (JSC::ConsoleClient::logWithLevel):
        (JSC::ConsoleClient::clear):
        (JSC::ConsoleClient::dir):
        (JSC::ConsoleClient::dirXML):
        (JSC::ConsoleClient::table):
        (JSC::ConsoleClient::trace):
        (JSC::ConsoleClient::assertCondition):
        (JSC::ConsoleClient::group):
        (JSC::ConsoleClient::groupCollapsed):
        (JSC::ConsoleClient::groupEnd):
        * runtime/ConsoleClient.h:
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::allStructureRepresentations):
        (JSC::TypeSet::inspectorTypeSet):
        (JSC::StructureShape::inspectorRepresentation):
        * runtime/TypeSet.h:

2015-01-07  Commit Queue  <commit-queue@webkit.org>

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

        Breaks ObjC Inspector Protocol (Requested by JoePeck on
        #webkit).

        Reverted changeset:

        "Web Inspector: purge PassRefPtr from Inspector code and use
        Ref for typed and untyped protocol objects"
        https://bugs.webkit.org/show_bug.cgi?id=140053
        http://trac.webkit.org/changeset/178039

2015-01-06  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: purge PassRefPtr from Inspector code and use Ref for typed and untyped protocol objects
        https://bugs.webkit.org/show_bug.cgi?id=140053

        Reviewed by Andreas Kling.

        This patch replaces uses of PassRefPtr with uses of RefPtr&& and WTF::move() in code
        related to Web Inspector. It also converts many uses of RefPtr to Ref where
        references are always non-null. These two refactorings have been combined since
        they tend to require similar changes to the code.

        Creation methods for subclasses of InspectorValue now return a Ref, and callsites
        have been updated to take a Ref instead of RefPtr.

        Builders for typed protocol objects now return a Ref. Since there is no implicit
        call to operator&, callsites now must explicitly call .release() to convert a
        builder object into the corresponding protocol object once required fields are set.
        Update callsites and use auto to eliminate repetition of longwinded protocol types.

        Tests for inspector protocol and replay inputs have been rebaselined.

        * bindings/ScriptValue.cpp:
        (Deprecated::jsToInspectorValue):
        (Deprecated::ScriptValue::toInspectorValue):
        * bindings/ScriptValue.h:
        * inspector/ConsoleMessage.cpp:
        (Inspector::ConsoleMessage::addToFrontend):
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::buildObjectForSearchMatch):
        (Inspector::ContentSearchUtilities::searchInTextByLines):
        * inspector/ContentSearchUtilities.h:
        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::getFunctionDetails):
        (Inspector::InjectedScript::getProperties):
        (Inspector::InjectedScript::getInternalProperties):
        (Inspector::InjectedScript::wrapCallFrames):
        (Inspector::InjectedScript::wrapObject):
        (Inspector::InjectedScript::wrapTable):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::makeEvalCall): Split the early exits.
        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase):
        (Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive):
        (Inspector::InspectorBackendDispatcher::create):
        (Inspector::InspectorBackendDispatcher::dispatch):
        (Inspector::InspectorBackendDispatcher::sendResponse):
        (Inspector::InspectorBackendDispatcher::reportProtocolError):
        (Inspector::getPropertyValue): Add a comment to clarify what this clever code does.
        (Inspector::InspectorBackendDispatcher::getInteger):
        (Inspector::InspectorBackendDispatcher::getDouble):
        (Inspector::InspectorBackendDispatcher::getString):
        (Inspector::InspectorBackendDispatcher::getBoolean):
        (Inspector::InspectorBackendDispatcher::getObject):
        (Inspector::InspectorBackendDispatcher::getArray):
        (Inspector::InspectorBackendDispatcher::getValue):
        * inspector/InspectorBackendDispatcher.h: Use a typed protocol object to collect
        protocol error strings.
        (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher):
        Convert the supplemental dispatcher's reference to Ref since it is never null.
        * inspector/InspectorEnvironment.h:
        * inspector/InspectorProtocolTypes.h: Get rid of ArrayItemHelper and
        StructItemTraits. Add more versions of addItem to handle pushing various types.
        (Inspector::Protocol::Array::openAccessors):
        (Inspector::Protocol::Array::addItem):
        (Inspector::Protocol::Array::create):
        (Inspector::Protocol::StructItemTraits::push):
        (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast): Assert argument.
        (Inspector::Protocol::StructItemTraits::pushRefPtr): Deleted.
        (Inspector::Protocol::ArrayItemHelper<String>::Traits::pushRaw): Deleted.
        (Inspector::Protocol::ArrayItemHelper<int>::Traits::pushRaw): Deleted.
        (Inspector::Protocol::ArrayItemHelper<double>::Traits::pushRaw): Deleted.
        (Inspector::Protocol::ArrayItemHelper<bool>::Traits::pushRaw): Deleted.
        (Inspector::Protocol::ArrayItemHelper<InspectorValue>::Traits::pushRefPtr): Deleted.
        (Inspector::Protocol::ArrayItemHelper<InspectorObject>::Traits::pushRefPtr): Deleted.
        (Inspector::Protocol::ArrayItemHelper<InspectorArray>::Traits::pushRefPtr): Deleted.
        (Inspector::Protocol::ArrayItemHelper<Protocol::Array<T>>::Traits::pushRefPtr): Deleted.
        * inspector/InspectorValues.cpp: Straighten out getArray and getObject to have
        the same call signature as other getters. Use Ref where possible.
        (Inspector::InspectorObjectBase::getBoolean):
        (Inspector::InspectorObjectBase::getString):
        (Inspector::InspectorObjectBase::getObject):
        (Inspector::InspectorObjectBase::getArray):
        (Inspector::InspectorObjectBase::getValue):
        (Inspector::InspectorObjectBase::writeJSON):
        (Inspector::InspectorArrayBase::get):
        (Inspector::InspectorObject::create):
        (Inspector::InspectorArray::create):
        (Inspector::InspectorValue::null):
        (Inspector::InspectorString::create):
        (Inspector::InspectorBasicValue::create):
        (Inspector::InspectorObjectBase::get): Deleted.
        * inspector/InspectorValues.h:
        (Inspector::InspectorObjectBase::setValue):
        (Inspector::InspectorObjectBase::setObject):
        (Inspector::InspectorObjectBase::setArray):
        (Inspector::InspectorArrayBase::pushValue):
        (Inspector::InspectorArrayBase::pushObject):
        (Inspector::InspectorArrayBase::pushArray):
        * inspector/JSGlobalObjectConsoleClient.cpp:
        (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
        (Inspector::JSGlobalObjectConsoleClient::count):
        (Inspector::JSGlobalObjectConsoleClient::timeEnd):
        (Inspector::JSGlobalObjectConsoleClient::timeStamp):
        * inspector/JSGlobalObjectConsoleClient.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::executionStopwatch):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/ScriptCallFrame.cpp:
        (Inspector::ScriptCallFrame::buildInspectorObject):
        * inspector/ScriptCallFrame.h:
        * inspector/ScriptCallStack.cpp:
        (Inspector::ScriptCallStack::create):
        (Inspector::ScriptCallStack::buildInspectorArray):
        * inspector/ScriptCallStack.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::enable):
        (Inspector::InspectorAgent::inspect):
        (Inspector::InspectorAgent::activateExtraDomain):
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
        (Inspector::buildObjectForBreakpointCookie):
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::setBreakpoint):
        (Inspector::InspectorDebuggerAgent::continueToLocation):
        (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
        (Inspector::InspectorDebuggerAgent::currentCallFrames):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        (Inspector::InspectorDebuggerAgent::breakProgram):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::buildErrorRangeObject):
        (Inspector::InspectorRuntimeAgent::callFunctionOn):
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        (Inspector::InspectorRuntimeAgent::getBasicBlocks):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/scripts/codegen/cpp_generator.py:
        (CppGenerator.cpp_type_for_unchecked_formal_in_parameter):
        (CppGenerator.cpp_type_for_type_with_name):
        (CppGenerator.cpp_type_for_formal_async_parameter):
        (CppGenerator.should_use_references_for_type):
        (CppGenerator):
        * inspector/scripts/codegen/cpp_generator_templates.py:
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
        (CppBackendDispatcherHeaderGenerator.generate_output):
        (CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
        (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
        (CppProtocolTypesHeaderGenerator.generate_output):
        (_generate_class_for_object_declaration):
        (_generate_unchecked_setter_for_member):
        (_generate_forward_declarations_for_binding_traits):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator._generate_event):
        (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
        (ObjCProtocolTypesImplementationGenerator.generate_output):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        * replay/EncodedValue.cpp:
        (JSC::EncodedValue::asObject):
        (JSC::EncodedValue::asArray):
        (JSC::EncodedValue::put<EncodedValue>):
        (JSC::EncodedValue::append<EncodedValue>):
        (JSC::EncodedValue::get<EncodedValue>):
        * replay/EncodedValue.h:
        * replay/scripts/CodeGeneratorReplayInputs.py:
        (Type.borrow_type):
        (Type.argument_type):
        (Generator.generate_member_move_expression):
        * runtime/ConsoleClient.cpp:
        (JSC::ConsoleClient::printConsoleMessageWithArguments):
        (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
        (JSC::ConsoleClient::logWithLevel):
        (JSC::ConsoleClient::clear):
        (JSC::ConsoleClient::dir):
        (JSC::ConsoleClient::dirXML):
        (JSC::ConsoleClient::table):
        (JSC::ConsoleClient::trace):
        (JSC::ConsoleClient::assertCondition):
        (JSC::ConsoleClient::group):
        (JSC::ConsoleClient::groupCollapsed):
        (JSC::ConsoleClient::groupEnd):
        * runtime/ConsoleClient.h:
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::allStructureRepresentations):
        (JSC::TypeSet::inspectorTypeSet):
        (JSC::StructureShape::inspectorRepresentation):
        * runtime/TypeSet.h:

2015-01-06  Chris Dumez  <cdumez@apple.com>

        Drop ResourceResponseBase::connectionID and connectionReused members
        https://bugs.webkit.org/show_bug.cgi?id=140158

        Reviewed by Sam Weinig.

        Drop ResourceResponseBase::connectionID and connectionReused members.
        Those were needed by the Chromium port but are no longer used.

        * inspector/protocol/Network.json:

2015-01-06  Mark Lam  <mark.lam@apple.com>

        Add the lexicalEnvironment as an operand to op_create_arguments.
        <https://webkit.org/b/140148>

        Reviewed by Geoffrey Garen.

        This patch only adds the operand to the bytecode.  It is not in use yet.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::createArgumentsIfNecessary):
        - Adds the lexicalEnvironment register (if present) as an operand to
          op_create_arguments.  Else, adds a constant empty JSValue.
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2015-01-06  Alexey Proskuryakov  <ap@apple.com>

        ADDRESS_SANITIZER macro is overloaded
        https://bugs.webkit.org/show_bug.cgi?id=140130

        Reviewed by Anders Carlsson.

        * interpreter/JSStack.cpp: (JSC::JSStack::sanitizeStack): Use the new macro.
        This code is nearly unused (only compiled in when JIT is disabled at build time),
        however I've been told that it's best to keep it.

2015-01-06  Mark Lam  <mark.lam@apple.com>

        Fix Use details for op_create_arguments.
        <https://webkit.org/b/140110>

        Rubber stamped by Filip Pizlo.

        The previous patch was wrong about op_create_arguments not using its 1st operand.
        It does read from it (hence, used) to check if the Arguments object has already
        been created or not.  This patch reverts the change for op_create_arguments.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):

2015-01-06  Mark Lam  <mark.lam@apple.com>

        Fix Use details for op_create_lexical_environment and op_create_arguments.
        <https://webkit.org/b/140110>

        Reviewed by Filip Pizlo.

        The current "Use" details for op_create_lexical_environment and
        op_create_arguments are wrong.  op_create_argument uses nothing instead of the
        1st operand (the output local).  op_create_lexical_environment uses its 2nd
        operand (the scope chain) instead of the 1st (the output local).
        This patch fixes them to specify the proper uses.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):

2015-01-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        Implement ES6 String.prototype.repeat(count)
        https://bugs.webkit.org/show_bug.cgi?id=140047

        Reviewed by Darin Adler.

        Introducing ES6 String.prototype.repeat(count) function.

        * runtime/JSString.h:
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::repeatSmallString):
        (JSC::stringProtoFuncRepeat):

2015-01-03  Michael Saboff  <msaboff@apple.com>

        Crash in operationNewFunction when scrolling on Google+
        https://bugs.webkit.org/show_bug.cgi?id=140033

        Reviewed by Oliver Hunt.

        In DFG code, the scope register can be eliminated because all uses have been
        dead code eliminated.  In the case where one of the uses was creating a function
        that is never used, the baseline code will still create the function.  If we OSR
        exit to a path where that function gets created, check the scope register value
        and set the new, but dead, function to undefined instead of creating a new function.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_func_exp):

2015-01-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        String includes methods perform toString on searchString before toInt32 on a offset
        https://bugs.webkit.org/show_bug.cgi?id=140031

        Reviewed by Darin Adler.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncStartsWith):
        (JSC::stringProtoFuncEndsWith):
        (JSC::stringProtoFuncIncludes):

2015-01-01  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Change to return std::unique_ptr<> in fooCreate()
        https://bugs.webkit.org/show_bug.cgi?id=139983

        Reviewed by Darin Adler.

        To avoid unnecessary std::unique_ptr<> casting, fooCreate() returns std::unique_ptr<> directly.

        * create_regex_tables:
        * yarr/YarrPattern.h:
        (JSC::Yarr::YarrPattern::reset):
        (JSC::Yarr::YarrPattern::newlineCharacterClass):
        (JSC::Yarr::YarrPattern::digitsCharacterClass):
        (JSC::Yarr::YarrPattern::spacesCharacterClass):
        (JSC::Yarr::YarrPattern::wordcharCharacterClass):
        (JSC::Yarr::YarrPattern::nondigitsCharacterClass):
        (JSC::Yarr::YarrPattern::nonspacesCharacterClass):
        (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):

2015-01-01  Jeff Miller  <jeffm@apple.com>

        Update user-visible copyright strings to include 2015
        https://bugs.webkit.org/show_bug.cgi?id=139880

        Reviewed by Darin Adler.

        * Info.plist:

2015-01-01  Darin Adler  <darin@apple.com>

        We often misspell identifier as "identifer"
        https://bugs.webkit.org/show_bug.cgi?id=140025

        Reviewed by Michael Saboff.

        * runtime/ArrayConventions.h: Fix it.

2014-12-29  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Move JavaScriptCore/yarr to std::unique_ptr
        https://bugs.webkit.org/show_bug.cgi?id=139621

        Reviewed by Anders Carlsson.

        Final clean up OwnPtr|PassOwnPtr in JavaScriptCore/yarr.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::BytecodePattern):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
        (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
        (JSC::Yarr::YarrGenerator::opCompileBody):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::charClass):
        (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
        (JSC::Yarr::YarrPatternConstructor::reset):
        (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
        (JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd):
        (JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
        (JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin):
        (JSC::Yarr::YarrPatternConstructor::copyDisjunction):
        (JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
        (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
        * yarr/YarrPattern.h:
        (JSC::Yarr::PatternDisjunction::addNewAlternative):
        (JSC::Yarr::YarrPattern::newlineCharacterClass):
        (JSC::Yarr::YarrPattern::digitsCharacterClass):
        (JSC::Yarr::YarrPattern::spacesCharacterClass):
        (JSC::Yarr::YarrPattern::wordcharCharacterClass):
        (JSC::Yarr::YarrPattern::nondigitsCharacterClass):
        (JSC::Yarr::YarrPattern::nonspacesCharacterClass):
        (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):

2014-12-26  Dan Bernstein  <mitz@apple.com>

        <rdar://problem/19348208> REGRESSION (r177027): iOS builds use the wrong toolchain
        https://bugs.webkit.org/show_bug.cgi?id=139950

        Reviewed by David Kilzer.

        * Configurations/Base.xcconfig: Only define TOOLCHAINS when building for OS X, doing so
        in a manner that works with Xcode 5.1.1.

2014-12-22  Mark Lam  <mark.lam@apple.com>

        Use ctiPatchCallByReturnAddress() in JITOperations.cpp.
        <https://webkit.org/b/139892>

        Reviewed by Michael Saboff.

        The code in JITOperations.cpp sometimes calls RepatchBuffer::relinkCallerToFunction()
        directly, and sometimes uses a helper function, ctiPatchCallByReturnAddress().
        This patch changes it to use the helper function consistently.

        * jit/JITOperations.cpp:

2014-12-22  Mark Lam  <mark.lam@apple.com>

        Fix some typos in a comment.
        <https://webkit.org/b/139882>

        Reviewed by Michael Saboff.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):

2014-12-22  Mark Lam  <mark.lam@apple.com>

        Assert that Array elements not copied when changing shape to ArrayStorage type are indeed holes.
        <https://webkit.org/b/138118>

        Reviewed by Michael Saboff.

        * runtime/JSObject.cpp:
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):

2014-12-20  Eric Carlson  <eric.carlson@apple.com>

        [iOS] add optimized fullscreen API
        https://bugs.webkit.org/show_bug.cgi?id=139833
        <rdar://problem/18844486>

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig: Add ENABLE_VIDEO_PRESENTATION_MODE.

2014-12-20  David Kilzer  <ddkilzer@apple.com>

        Switch from using PLATFORM_NAME to SDK selectors in WebCore, WebInspectorUI, WebKit, WebKit2
        <http://webkit.org/b/139463>

        Reviewed by Mark Rowe.

        * Configurations/JavaScriptCore.xcconfig:
        - Simplify SECTORDER_FLAGS.

2014-12-19  Andreas Kling  <akling@apple.com>

        Plug leak below LLVMCopyStringRepOfTargetData().
        <https://webkit.org/b/139832>

        Reviewed by Michael Saboff.

        LLVMCopyStringRepOfTargetData() returns a strdup()'ed string, so make sure
        to free() it after we're done using it.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):

2014-12-19  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: CRASH inspector-protocol/debugger/breakpoint-action-detach.html
        https://bugs.webkit.org/show_bug.cgi?id=139797

        Reviewed by Mark Lam.

        * debugger/Debugger.h:
        * debugger/Debugger.cpp:
        (JSC::Debugger::isAttached):
        Check if we are the debugger for a particular global object.
        (JSC::Debugger::pauseIfNeeded):
        Pass the global object on when hitting a brekapoint.

        * inspector/ScriptDebugServer.h:
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::handleBreakpointHit):
        Stop evaluting breakpoint actions if a previous action caused the
        debugger to detach from this global object.
        (Inspector::ScriptDebugServer::handlePause):
        Standardize on passing JSGlobalObject parameter first.

2014-12-19  Mark Lam  <mark.lam@apple.com>

        [Win] Endless compiler warnings created by DFGEdge.h.
        <https://webkit.org/b/139801>

        Reviewed by Brent Fulgham.

        Add a cast to fix the type just the way the 64-bit version does.

        * dfg/DFGEdge.h:
        (JSC::DFG::Edge::makeWord):

2014-12-19  Commit Queue  <commit-queue@webkit.org>

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

        "Broke Production builds by installing
        libWebCoreTestSupport.dylib in the wrong directory" (Requested
        by ddkilzer on #webkit).

        Reverted changeset:

        "Switch from using PLATFORM_NAME to SDK selectors in WebCore,
        WebInspectorUI, WebKit, WebKit2"
        https://bugs.webkit.org/show_bug.cgi?id=139463
        http://trac.webkit.org/changeset/177574

2014-12-19  Michael Saboff  <msaboff@apple.com>

        REGRESSION(174226): Captured arguments in a using function compiled by the DFG have the initial value when the closure was invoked
        https://bugs.webkit.org/show_bug.cgi?id=139808

        Reviewed by Oliver Hunt.

        There are three changes here.
        1) Create a VariableWatchpointSet for captured arguments variables.
        2) Properly use the VariableWatchpointSet* found in op_put_to_scope in the 64 bit LLInt code.
        3) Add the same putLocalClosureVar path to the 32 bit LLInt code that exists in the 64 bit version.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2014-12-19  David Kilzer  <ddkilzer@apple.com>

        Switch from using PLATFORM_NAME to SDK selectors in WebCore, WebInspectorUI, WebKit, WebKit2
        <http://webkit.org/b/139463>

        Reviewed by Mark Rowe.

        * Configurations/JavaScriptCore.xcconfig:
        - Simplify SECTORDER_FLAGS.

2014-12-18  Brent Fulgham  <bfulgham@apple.com>

        Unreviewed build fix.

        * jsc.cpp: Remove typo.

2014-12-17  Michael Saboff  <msaboff@apple.com>

        Tests with infinite recursion frequently crash
        https://bugs.webkit.org/show_bug.cgi?id=139548

        Reviewed by Geoffrey Garen.

        While unwinding, if the call frame doesn't have a codeblock, then we
        are in native code, handle appropriately.

        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        (JSC::UnwindFunctor::operator()):
        Added checks for null CodeBlock.

        (JSC::Interpreter::unwind): Removed wrong ASSERT.

2014-12-17  Chris Dumez  <cdumez@apple.com>

        [iOS] Make it possible to toggle FeatureCounter support at runtime
        https://bugs.webkit.org/show_bug.cgi?id=139688
        <rdar://problem/19266254>

        Reviewed by Andreas Kling.

        Stop linking against AppSupport framework as the functionality is no
        longer in WTF (it was moved to WebCore).

        * Configurations/JavaScriptCore.xcconfig:

2014-12-17  Brent Fulgham  <bfulgham@apple.com>

        [Win] Correct DebugSuffix builds under MSBuild
        https://bugs.webkit.org/show_bug.cgi?id=139733
        <rdar://problem/19276880>

        Reviewed by Simon Fraser.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj: Make sure to use the
        '_debug' suffix when building the DebugSuffix target.

2014-12-16  Enrica Casucci  <enrica@apple.com>

        Fix iOS builders for 8.0
        https://bugs.webkit.org/show_bug.cgi?id=139495

        Reviewed by Michael Saboff.

        * Configurations/LLVMForJSC.xcconfig:
        * llvm/library/LLVMExports.cpp:
        (initializeAndGetJSCLLVMAPI):

2014-12-16  Commit Queue  <commit-queue@webkit.org>

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

        "Breaks js/regres/elidable-new-object-* tests" (Requested by
        msaboff_ on #webkit).

        Reverted changeset:

        "Fixes operationPutByIdOptimizes such that they check that the
        put didn't"
        https://bugs.webkit.org/show_bug.cgi?id=139500
        http://trac.webkit.org/changeset/177380

2014-12-16  Matthew Mirman  <mmirman@apple.com>

        Fixes operationPutByIdOptimizes such that they check that the put didn't
        change the structure of the object who's property access is being
        cached.
        https://bugs.webkit.org/show_bug.cgi?id=139500

        Reviewed by Geoffrey Garen.

        * jit/JITOperations.cpp:
        (JSC::operationPutByIdStrictOptimize): saved the structure before the put.
        (JSC::operationPutByIdNonStrictOptimize): ditto.
        (JSC::operationPutByIdDirectStrictOptimize): ditto.
        (JSC::operationPutByIdDirectNonStrictOptimize): ditto.
        * jit/Repatch.cpp:
        (JSC::tryCachePutByID): Added argument for the old structure
        (JSC::repatchPutByID): Added argument for the old structure
        * jit/Repatch.h:
        * tests/stress/put-by-id-build-list-order-recurse.js: 
        Added test that fails without this patch.

2014-12-15  Chris Dumez  <cdumez@apple.com>

        [iOS] Add feature counting support
        https://bugs.webkit.org/show_bug.cgi?id=139652
        <rdar://problem/19255690>

        Reviewed by Gavin Barraclough.

        Link against AppSupport framework on iOS as we need it to implement
        the new FeatureCounter API in WTF.

        * Configurations/JavaScriptCore.xcconfig:

2014-12-15  Commit Queue  <commit-queue@webkit.org>

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

        "Breaks API tests and LayoutTests on Yosemite Debug"
        (Requested by msaboff on #webkit).

        Reverted changeset:

        "Make sure range based iteration of Vector<> still receives
        bounds checking"
        https://bugs.webkit.org/show_bug.cgi?id=138821
        http://trac.webkit.org/changeset/177284

2014-12-15  Dániel Bátyai  <dbatyai.u-szeged@partner.samsung.com>

        [EFL] FTL JIT not working on ARM64
        https://bugs.webkit.org/show_bug.cgi?id=139295

        Reviewed by Michael Saboff.

        Added the missing code for stack unwinding and some additional small fixes
        to get FTL working correctly.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLUnwindInfo.cpp:
        (JSC::FTL::UnwindInfo::parse):

2014-12-15  Oliver Hunt  <oliver@apple.com>

        Make sure range based iteration of Vector<> still receives bounds checking
        https://bugs.webkit.org/show_bug.cgi?id=138821

        Reviewed by Mark Lam.

        Update code to deal with slightly changed iterator semantics.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::visitChildren):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::mdNode):
        (JSC::FTL::buildCall):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::sortCompactedVector):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::dumpInternal):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::matchCharacterClass):

2014-12-14  Filip Pizlo  <fpizlo@apple.com>

        PutLocalSinkingPhase has an invalid assertion about incoming values, because both liveness and deferral analyses are conservative
        https://bugs.webkit.org/show_bug.cgi?id=139630

        Reviewed by Oliver Hunt.
        
        Replaces a faulty assertion with code to handle an awesome special case. Also adds a lot of
        comments that reconstruct my reasoning about this code. I had to work hard to remember how
        deferral worked so I wrote my discoveries down.

        * dfg/DFGInsertionSet.h:
        (JSC::DFG::InsertionSet::insertBottomConstantForUse):
        * dfg/DFGPutLocalSinkingPhase.cpp:
        * tests/stress/put-local-conservative.js: Added.
        (foo):
        (.result):
        (bar):

2014-12-14  Andreas Kling  <akling@apple.com>

        Replace PassRef with Ref/Ref&& across the board.
        <https://webkit.org/b/139587>

        Reviewed by Darin Adler.

        * runtime/Identifier.cpp:
        (JSC::Identifier::add):
        (JSC::Identifier::add8):
        * runtime/Identifier.h:
        (JSC::Identifier::add):
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::add):

2014-12-12  Matthew Mirman  <mmirman@apple.com>

        shiftCountWithArrayStorage should exit to slow path if the object has a sparse map.
        https://bugs.webkit.org/show_bug.cgi?id=139598
        <rdar://problem/18779367>

        Reviewed by Filip Pizlo.

        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCountWithArrayStorage): Added check for object having a sparse map.
        * tests/stress/sparse_splice.js: Added.

2014-12-12  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Final clean up OwnPtr in JSC - runtime, ftl, and tool directories
        https://bugs.webkit.org/show_bug.cgi?id=139532

        Reviewed by Mark Lam.

        Final remove OwnPtr, PassOwnPtr in runtime, ftl, and tools directories of JSC.

        * builtins/BuiltinExecutables.h:
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock):
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::IndexedAbstractHeap::atSlow):
        * ftl/FTLAbstractHeap.h:
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLJITFinalizer.h:
        * jsc.cpp:
        (jscmain):
        * parser/Lexer.h:
        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::clearDeletedOffsets):
        (JSC::PropertyTable::addDeletedOffset):
        * runtime/PropertyTable.cpp:
        (JSC::PropertyTable::PropertyTable):
        * runtime/RegExpObject.cpp:
        * runtime/SmallStrings.cpp:
        * runtime/Structure.cpp:
        * runtime/StructureIDTable.cpp:
        (JSC::StructureIDTable::StructureIDTable):
        (JSC::StructureIDTable::resize):
        * runtime/StructureIDTable.h:
        * runtime/StructureTransitionTable.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:
        * tools/CodeProfile.h:
        (JSC::CodeProfile::CodeProfile):
        (JSC::CodeProfile::addChild):

2014-12-11  Dan Bernstein  <mitz@apple.com>

        iOS Simulator production build fix.

        * Configurations/JavaScriptCore.xcconfig: Don’t use an order file when building for the iOS
        Simulator, as we did prior to 177027.

2014-12-11  Joseph Pecoraro  <pecoraro@apple.com>

        Explicitly export somre more RWIProtocol classes.
        rdar://problem/19220408

        Unreviewed build fix.

        * inspector/scripts/codegen/generate_objc_configuration_header.py:
        (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator._generate_event_interfaces):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2014-12-11  Alexey Proskuryakov  <ap@apple.com>

        Explicitly export some RWIProtocol classes
        rdar://problem/19220408

        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator._generate_type_interface):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2014-12-11  Mark Lam  <mark.lam@apple.com>

        Fix broken build after r177146.
        https://bugs.webkit.org/show_bug.cgi?id=139533 

        Not reviewed.

        * interpreter/CallFrame.h:
        (JSC::ExecState::init):
        - Restored CallFrame::init() minus the unused JSScope* arg.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        - Remove JSScope* arg when calling CallFrame::init().

2014-12-11  Michael Saboff  <msaboff@apple.com>

        REGRESSION: Use of undefined CallFrame::ScopeChain value
        https://bugs.webkit.org/show_bug.cgi?id=139533

        Reviewed by Mark Lam.

        Removed CallFrame::scope() and CallFrame::setScope() and eliminated or changed
        all usages of these funcitons.  In some cases the scope is passed in or determined
        another way.  In some cases the scope is used to calculate other values.  Lastly
        were places where these functions where used that are no longer needed.  For
        example when making a call, the caller's ScopeChain was copied to the callee's
        ScopeChain.  This change no longer uses the ScopeChain call frame header slot.
        That slot will be removed in a future patch.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * runtime/JSLexicalEnvironment.h:
        (JSC::JSLexicalEnvironment::create):
        (JSC::JSLexicalEnvironment::JSLexicalEnvironment):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_lexical_environment):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_lexical_environment):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::handleHostCall):
        (JSC::LLInt::setUpCall):
        (JSC::LLInt::llint_throw_stack_overflow_error):
        Pass the current scope value to the helper operationCreateActivation() and
        the call to JSLexicalEnvironment::create() instead of using the stack frame
        scope chain value.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        CreateActivation now has a second child, the scope.

        * interpreter/CallFrame.h:
        (JSC::ExecState::init): Deleted.  This is dead code.
        (JSC::ExecState::scope): Deleted.
        (JSC::ExecState::setScope): Deleted.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters): Changed so we didn't access the scope
        chain slot.  
        
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        Changed process to find JSScope values on the stack or by some other means.

        * runtime/JSWithScope.h:
        (JSC::JSWithScope::JSWithScope): Deleted.
        Eliminated unused constructor.

        * runtime/StrictEvalActivation.cpp:
        (JSC::StrictEvalActivation::StrictEvalActivation):
        * runtime/StrictEvalActivation.h:
        (JSC::StrictEvalActivation::create):
        Changed to pass in the current scope.

2014-12-10  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Use std::unique_ptr instead of OwnPtr in JSC - heap, jit, runtime, and parser directories
        https://bugs.webkit.org/show_bug.cgi?id=139351

        Reviewed by Filip Pizlo.

        As a step to use std::unique_ptr<>, this cleans up OwnPtr and PassOwnPtr.

        * bytecode/SamplingTool.h:
        (JSC::SamplingTool::SamplingTool):
        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::didSurviveGC):
        (JSC::CopiedBlock::pin):
        * heap/CopiedBlockInlines.h:
        (JSC::CopiedBlock::reportLiveBytes):
        * heap/GCActivityCallback.h:
        * heap/GCThread.cpp:
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::markListSet):
        * jit/ExecutableAllocator.cpp:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        * jit/JITThunks.cpp:
        (JSC::JITThunks::JITThunks):
        (JSC::JITThunks::clearHostFunctionStubs):
        * jit/JITThunks.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::pushLabel):
        * parser/ParserArena.cpp:
        * parser/ParserArena.h:
        (JSC::ParserArena::identifierArena):
        * parser/SourceProviderCache.h:
        * runtime/CodeCache.h:
        * runtime/Executable.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::sortVector):
        * runtime/JSGlobalObject.h:

2014-12-10  Geoffrey Garen  <ggaren@apple.com>

        Please disable the webkitFirstVersionWithInitConstructorSupport check on Apple TV
        https://bugs.webkit.org/show_bug.cgi?id=139501

        Reviewed by Gavin Barraclough.

        NSVersionOfLinkTimeLibrary only works if you link directly against
        JavaScriptCore, which is a bit awkward for our Apple TV client to do.

        It's easy enough just to disable this check on Apple TV, since it has no
        backwards compatibility requirement.

        * API/JSWrapperMap.mm:
        (supportsInitMethodConstructors):

2014-12-10  Matthew Mirman  <mmirman@apple.com>

        Fixes operationPutByIds such that they check that the put didn't
        change the structure of the object who's property access is being
        cached.
        https://bugs.webkit.org/show_bug.cgi?id=139196

        Reviewed by Filip Pizlo.

        * jit/JITOperations.cpp:
        (JSC::operationGetByIdOptimize): changed get to getPropertySlot
        (JSC::operationPutByIdStrictBuildList): saved the structure before the put.
        (JSC::operationPutByIdNonStrictBuildList): ditto.
        (JSC::operationPutByIdDirectStrictBuildList): ditto.
        (JSC::operationPutByIdDirectNonStrictBuildList): ditto.
        * jit/Repatch.cpp:
        (JSC::tryCachePutByID): fixed structure() to use the existant vm. 
        (JSC::tryBuildPutByIdList): Added a check that the old structure's id 
        is the same as the new.
        (JSC::buildPutByIdList): Added an argument
        * jit/Repatch.h: 
        (JSC::buildPutByIdList): Added an argument
        * tests/stress/put-by-id-strict-build-list-order.js: Added.

2014-12-10  Csaba Osztrogonác  <ossy@webkit.org>

        URTBF after r177030.

        Fix linking failure occured on ARM buildbots:
        lib/libjavascriptcore_efl.so.1.11.0: undefined reference to `JSC::Structure::get(JSC::VM&, JSC::PropertyName, unsigned int&)'

        * runtime/NullGetterFunction.cpp:

2014-12-09  Michael Saboff  <msaboff@apple.com>

        DFG Tries using an inner object's getter/setter when one hasn't been defined
        https://bugs.webkit.org/show_bug.cgi?id=139229

        Reviewed by Filip Pizlo.

        Added a new NullGetterFunction singleton class to use for getters and setters that
        haven't been set to a user defined value.  The NullGetterFunction callReturnUndefined()
        and createReturnUndefined() methods return undefined.  Changed all null checks of the
        getter and setter pointers to the newly added isGetterNull() and isSetterNull()
        helper methods.  

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Added NullGetterFunction.cpp & .h to build files.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::setDescriptor):
        (JSC::PropertyDescriptor::setAccessorDescriptor):
        Changed checking getter and setter to null to use new isGetterNull() and isSetterNull()
        helpers.

        * inspector/JSInjectedScriptHostPrototype.cpp:
        (Inspector::JSInjectedScriptHostPrototype::finishCreation):
        * inspector/JSJavaScriptCallFramePrototype.cpp:
        * jit/JITOperations.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putIndexedDescriptor):
        (JSC::putDescriptor):
        (JSC::JSObject::defineOwnNonIndexProperty):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        Updated calls to GetterSetter::create(), setGetter(), setSetter(), withGetter()
        and withSetter() to provide a global object.

        * runtime/GetterSetter.cpp:
        (JSC::GetterSetter::withGetter):
        (JSC::GetterSetter::withSetter):
        (JSC::callGetter):
        (JSC::callSetter):
        * runtime/GetterSetter.h:
        (JSC::GetterSetter::GetterSetter):
        (JSC::GetterSetter::create):
        (JSC::GetterSetter::isGetterNull):
        (JSC::GetterSetter::isSetterNull):
        (JSC::GetterSetter::setGetter):
        (JSC::GetterSetter::setSetter):
        Changed to use NullGetterFunction for unspecified getters / setters.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::createThrowTypeError):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::nullGetterFunction):
        (JSC::JSGlobalObject::evalFunction):
        Added m_nullGetterFunction singleton.  Updated calls to GetterSetter::create(),
        setGetter() and setSetter() to provide a global object.

        * runtime/NullGetterFunction.cpp: Added.
        (JSC::callReturnUndefined):
        (JSC::constructReturnUndefined):
        (JSC::NullGetterFunction::getCallData):
        (JSC::NullGetterFunction::getConstructData):
        * runtime/NullGetterFunction.h: Added.
        (JSC::NullGetterFunction::create):
        (JSC::NullGetterFunction::createStructure):
        (JSC::NullGetterFunction::NullGetterFunction):
        New singleton class that returns undefined when called.

2014-12-09  Geoffrey Garen  <ggaren@apple.com>

        Re-enable function.arguments
        https://bugs.webkit.org/show_bug.cgi?id=139452
        <rdar://problem/18848149>

        Reviewed by Sam Weinig.

        Disabling function.arguments broke a few websites, and we don't have
        time right now to work through the details.

        I'm re-enabling function.arguments but leaving in the infrastructure
        to re-disable it, so we can try this experiment again in the future.

        * runtime/Options.h:

2014-12-09  David Kilzer  <ddkilzer@apple.com>

        Switch from using PLATFORM_NAME to SDK selectors in ANGLE, bmalloc, gtest, JavaScriptCore, WTF
        <http://webkit.org/b/139212>

        Reviewed by Joseph Pecoraro.

        * Configurations/Base.xcconfig:
        - Only set GCC_ENABLE_OBJC_GC, GCC_MODEL_TUNING and TOOLCHAINS
          on OS X.
        - Only set LLVM_LOCAL_HEADER_PATH and LLVM_SYSTEM_HEADER_PATH on
          OS X.
        - Set JAVASCRIPTCORE_CONTENTS_DIR and
          JAVASCRIPTCORE_FRAMEWORKS_DIR separately for iOS and OS X.

        * Configurations/DebugRelease.xcconfig:
        - Only set MACOSX_DEPLOYMENT_TARGET and SDKROOT on OS X.

        * Configurations/JSC.xcconfig:
        - Only set CODE_SIGN_ENTITLEMENTS for iOS hardware builds.

        * Configurations/JavaScriptCore.xcconfig:
        - Set OTHER_LDFLAGS separately for iOS and OS X.
        - Set SECTORDER_FLAGS separately for iOS and OS X, but only for
          Production builds.
        - Only set EXCLUDED_SOURCE_FILE_NAMES for iOS.

        * Configurations/LLVMForJSC.xcconfig:
        - Rename LLVM_LIBS_iphoneos to LLVM_LIBS_ios.
        - Set LLVM_LIBRARY_PATHS and OTHER_LDFLAGS_LLVM_ENABLE_FTL_JIT
          separately for iOS hardware and OS X.
        - Fix curly braces in LIBRARY_SEARCH_PATHS.
        - Merge OTHER_LDFLAGS_BASE into OTHER_LDFLAGS. (Could have been
          done before this patch.)

        * Configurations/ToolExecutable.xcconfig:
        - Only set CODE_SIGN_ENTITLEMENTS for iOS, per target.
        - Only set CLANG_ENABLE_OBJC_ARC for i386 on the iOS Simulator.
        - Add missing newline.

        * Configurations/Version.xcconfig:
        - Set SYSTEM_VERSION_PREFIX separately for iOS and OS X.

2014-12-08  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Fix EFL build fix since r177001
        https://bugs.webkit.org/show_bug.cgi?id=139428

        Unreviewed, EFL build fix.

        Do not inherit duplicated class. ExpressionNode is already
        child of ParserArenaFreeable class.

        * parser/Nodes.h:

2014-12-08  Shivakumar JM  <shiva.jm@samsung.com>

        Fix Build Warning in JavaScriptCore ControlFlowProfiler::dumpData() api.
        https://bugs.webkit.org/show_bug.cgi?id=139384

        Reviewed by Mark Lam.

        Fix Build Warning by using dataLog() function instead of dataLogF() function.

        * runtime/ControlFlowProfiler.cpp:
        (JSC::ControlFlowProfiler::dumpData):

2014-12-08  Saam Barati  <saambarati1@gmail.com>

        Web Inspector: Enable runtime API for JSC's control flow profiler
        https://bugs.webkit.org/show_bug.cgi?id=139346

        Reviewed by Joseph Pecoraro.

        This patch creates an API that the Web Inspector can use
        to get information about which basic blocks have exectued
        from JSC's control flow profiler.

        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getBasicBlocks):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/protocol/Runtime.json:

2014-12-08  Geoffrey Garen  <ggaren@apple.com>

        Removed some allocation and cruft from the parser
        https://bugs.webkit.org/show_bug.cgi?id=139416

        Reviewed by Mark Lam.

        Now, the only AST nodes that require a destructor are the ones that
        relate to pickling a function's arguments -- which will required some
        deeper thinking to resolve.

        This is a < 1% parser speedup.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj: Removed NodeInfo because it
        was unused.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::CommaNode::emitBytecode):
        (JSC::SourceElements::lastStatement):
        (JSC::SourceElements::emitBytecode): Updated for interface change to linked list.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::ASTBuilder):
        (JSC::ASTBuilder::varDeclarations):
        (JSC::ASTBuilder::funcDeclarations):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::addVar): Removed the ParserArenaData abstraction because
        it wasn't buying us anything. We can just use Vector directly.

        (JSC::ASTBuilder::createCommaExpr):
        (JSC::ASTBuilder::appendToCommaExpr): Changed to use a linked list instead
        of a vector, to avoid allocating a vector with inline capacity in the
        common case in which an expression is not followed by a vector.

        (JSC::ASTBuilder::Scope::Scope): Use Vector directly to avoid new'ing
        up a Vector*.

        (JSC::ASTBuilder::appendToComma): Deleted.
        (JSC::ASTBuilder::combineCommaNodes): Deleted.

        * parser/Lexer.cpp:

        * parser/NodeConstructors.h:
        (JSC::StatementNode::StatementNode):
        (JSC::CommaNode::CommaNode):
        (JSC::SourceElements::SourceElements): Updated for interface change to linked list.

        * parser/NodeInfo.h: Removed.

        * parser/Nodes.cpp:
        (JSC::SourceElements::append):
        (JSC::SourceElements::singleStatement): Use a linked list instead of a
        vector to track the statements in a list. This removes some allocation
        and it means that we don't need a destructor anymore.

        (JSC::ScopeNode::ScopeNode):
        (JSC::ProgramNode::ProgramNode):
        (JSC::EvalNode::EvalNode):
        (JSC::FunctionNode::FunctionNode): Updated for interface change to reference,
        since these values are never null.

        * parser/Nodes.h:
        (JSC::StatementNode::next):
        (JSC::StatementNode::setNext):
        (JSC::CommaNode::append): Deleted. Updated for interface change to linked list.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::didFinishParsing): Updated for interface change to reference.

        (JSC::Parser<LexerType>::parseVarDeclarationList):
        (JSC::Parser<LexerType>::parseExpression): Track comma expressions as
        an explicit list of CommaNodes, removing a use of vector and a destructor.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createCommaExpr):
        (JSC::SyntaxChecker::appendToCommaExpr):
        (JSC::SyntaxChecker::appendToComma): Deleted. Updated for interface changes.

2014-12-08  Commit Queue  <commit-queue@webkit.org>

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

        "New JSC test in this patch is failing" (Requested by mlam on
        #webkit).

        Reverted changeset:

        "Fixes operationPutByIds such that they check that the put
        didn't"
        https://bugs.webkit.org/show_bug.cgi?id=139196
        http://trac.webkit.org/changeset/176979

2014-12-08  Matthew Mirman  <mmirman@apple.com>

        Fixes operationPutByIds such that they check that the put didn't
        change the structure of the object who's property access is being
        cached.
        https://bugs.webkit.org/show_bug.cgi?id=139196

        Reviewed by Filip Pizlo.

        * jit/JITOperations.cpp:
        (JSC::operationGetByIdOptimize): changed get to getPropertySlot
        (JSC::operationPutByIdStrictBuildList): saved the structure before the put.
        (JSC::operationPutByIdNonStrictBuildList): ditto.
        (JSC::operationPutByIdDirectStrictBuildList): ditto.
        (JSC::operationPutByIdDirectNonStrictBuildList): ditto.
        * jit/Repatch.cpp:
        (JSC::tryCachePutByID): fixed structure() to use the existant vm. 
        (JSC::tryBuildPutByIdList): Added a check that the old structure's id 
        is the same as the new.
        (JSC::buildPutByIdList): Added an argument
        * jit/Repatch.h: 
        (JSC::buildPutByIdList): Added an argument
        * tests/stress/put-by-id-build-list-order-recurse.js: Test that failed before the change
        * tests/stress/put-by-id-strict-build-list-order.js: Added.

 
2014-12-08  Anders Carlsson  <andersca@apple.com>

        Change WTF::currentCPUTime to return std::chrono::microseconds and get rid of currentCPUTimeMS
        https://bugs.webkit.org/show_bug.cgi?id=139410

        Reviewed by Andreas Kling.

        * API/JSContextRef.cpp:
        (JSContextGroupSetExecutionTimeLimit):
        (JSContextGroupClearExecutionTimeLimit):
        * runtime/Watchdog.cpp:
        (JSC::Watchdog::setTimeLimit):
        (JSC::Watchdog::didFire):
        (JSC::Watchdog::startCountdownIfNeeded):
        (JSC::Watchdog::startCountdown):
        * runtime/Watchdog.h:
        * runtime/WatchdogMac.cpp:
        (JSC::Watchdog::startTimer):

2014-12-08  Mark Lam  <mark.lam@apple.com>

        CFA wrongly assumes that a speculation for SlowPutArrayStorageShape disallows ArrayStorageShape arrays.
        <https://webkit.org/b/139327>

        Reviewed by Michael Saboff.

        The code generator and runtime slow paths expects otherwise.  This patch fixes
        CFA to match the code generator's expectation.

        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::arrayModesThatPassFiltering):
        (JSC::DFG::ArrayMode::arrayModesWithIndexingShapes):

2014-12-08  Chris Dumez  <cdumez@apple.com>

        Revert r176293 & r176275

        Unreviewed, revert r176293 & r176275 changing the Vector API to use unsigned type
        instead of size_t. There is some disagreement regarding the long-term direction
        of the API and we shouldn’t leave the API partly transitioned to unsigned type
        while making a decision.

        * bytecode/PreciseJumpTargets.cpp:
        * replay/EncodedValue.h:

2014-12-07  Csaba Osztrogonác  <ossy@webkit.org>

        Remove the unused WTF_USE_GCC_COMPUTED_GOTO_WORKAROUND after r129453.
        https://bugs.webkit.org/show_bug.cgi?id=139373

        Reviewed by Sam Weinig.

        * interpreter/Interpreter.cpp:

2014-12-06  Anders Carlsson  <andersca@apple.com>

        Fix build with newer versions of clang.
        rdar://problem/18978716

        * ftl/FTLJITCode.h:
        Add missing overrides.

2014-12-05  Roger Fong  <roger_fong@apple.com>

        [Win] proj files copying over too many resources..
        https://bugs.webkit.org/show_bug.cgi?id=139315.
        <rdar://problem/19148278>

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj: Only copy resource folders and JavaScriptCore.dll.

2014-12-05  Juergen Ributzka  <juergen@apple.com>

        [JSC][FTL] Add the data layout to the module and fix the pass order.
        https://bugs.webkit.org/show_bug.cgi?id=138748

        Reviewed by Oliver Hunt.

        This adds the data layout to the module, so it can be used by all
        optimization passes in the LLVM optimizer pipeline. This also allows
        FastISel to select more instructions, because less non-legal types are
        generated.
        
        Also fix the order of the alias analysis passes in the optimization
        pipeline.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):

2014-12-05  Geoffrey Garen  <ggaren@apple.com>

        Removed an unused function.

        Reviewed by Michael Saboff.

        Broken out from https://bugs.webkit.org/show_bug.cgi?id=139305.

        * parser/ParserArena.h:

2014-12-05  David Kilzer  <ddkilzer@apple.com>

        FeatureDefines.xcconfig: Workaround bug in Xcode 5.1.1 when defining ENABLE_WEB_REPLAY
        <http://webkit.org/b/139286>

        Reviewed by Daniel Bates.

        * Configurations/FeatureDefines.xcconfig: Switch back to using
        PLATFORM_NAME to workaround a bug in Xcode 5.1.1 on 10.8.

2014-12-04  Mark Rowe  <mrowe@apple.com>

        Build fix after r176836.

        Reviewed by Mark Lam.

        * runtime/VM.h:
        (JSC::VM::controlFlowProfiler): Don't try to export an inline function.
        Doing so results in a weak external symbol being generated.

2014-12-04  Saam Barati  <saambarati1@gmail.com>

        JavaScript Control Flow Profiler
        https://bugs.webkit.org/show_bug.cgi?id=137785

        Reviewed by Filip Pizlo.

        This patch introduces a mechanism for JavaScriptCore to profile
        which basic blocks have executed. This mechanism will then be
        used by the Web Inspector to indicate which basic blocks
        have and have not executed.
        
        The profiling works by compiling in an op_profile_control_flow
        at the start of every basic block. Then, whenever this op code 
        executes, we know that a particular basic block has executed.
        
        When we tier up a CodeBlock that contains an op_profile_control_flow
        that corresponds to an already executed basic block, we don't
        have to emit code for that particular op_profile_control_flow
        because the internal data structures used to keep track of 
        basic block locations has already recorded that the corresponding
        op_profile_control_flow has executed.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/Instruction.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
        (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitProfileControlFlow):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ConditionalNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::CaseClauseNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::ThrowNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        (JSC::ProgramNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * 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/DFGNode.h:
        (JSC::DFG::Node::basicBlockLocation):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_control_flow):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_profile_control_flow):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionFindTypeForExpression):
        (functionReturnTypeFor):
        (functionDumpBasicBlockExecutionRanges):
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::endOffset):
        (JSC::ASTBuilder::setStartOffset):
        * parser/NodeConstructors.h:
        (JSC::Node::Node):
        * parser/Nodes.h:
        (JSC::CaseClauseNode::setStartOffset):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseSwitchClauses):
        (JSC::Parser<LexerType>::parseSwitchDefaultClause):
        (JSC::Parser<LexerType>::parseBlockStatement):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseIfStatement):
        (JSC::Parser<LexerType>::parseExpression):
        (JSC::Parser<LexerType>::parseConditionalExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createGetterOrSetterProperty):
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/BasicBlockLocation.cpp: Added.
        (JSC::BasicBlockLocation::BasicBlockLocation):
        (JSC::BasicBlockLocation::insertGap):
        (JSC::BasicBlockLocation::getExecutedRanges):
        (JSC::BasicBlockLocation::dumpData):
        (JSC::BasicBlockLocation::emitExecuteCode):
        * runtime/BasicBlockLocation.h: Added.
        (JSC::BasicBlockLocation::startOffset):
        (JSC::BasicBlockLocation::endOffset):
        (JSC::BasicBlockLocation::setStartOffset):
        (JSC::BasicBlockLocation::setEndOffset):
        (JSC::BasicBlockLocation::hasExecuted):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        * runtime/ControlFlowProfiler.cpp: Added.
        (JSC::ControlFlowProfiler::~ControlFlowProfiler):
        (JSC::ControlFlowProfiler::getBasicBlockLocation):
        (JSC::ControlFlowProfiler::dumpData):
        (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
        * runtime/ControlFlowProfiler.h: Added. This class is in 
        charge of generating BasicBlockLocations and also
        providing an interface that the Web Inspector can use to ping
        which basic blocks have executed based on the source id of a script.

        (JSC::BasicBlockKey::BasicBlockKey):
        (JSC::BasicBlockKey::isHashTableDeletedValue):
        (JSC::BasicBlockKey::operator==):
        (JSC::BasicBlockKey::hash):
        (JSC::BasicBlockKeyHash::hash):
        (JSC::BasicBlockKeyHash::equal):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::ProgramExecutable):
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/FunctionHasExecutedCache.cpp:
        (JSC::FunctionHasExecutedCache::getUnexecutedFunctionRanges):
        * runtime/FunctionHasExecutedCache.h:
        * runtime/Options.h:
        * runtime/TypeProfiler.cpp:
        (JSC::TypeProfiler::logTypesForTypeLocation):
        (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
        (JSC::TypeProfiler::findLocation):
        (JSC::TypeProfiler::dumpTypeProfilerData):
        * runtime/TypeProfiler.h:
        (JSC::TypeProfiler::functionHasExecutedCache): Deleted.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::enableProfilerWithRespectToCount):
        (JSC::disableProfilerWithRespectToCount):
        (JSC::VM::enableTypeProfiler):
        (JSC::VM::disableTypeProfiler):
        (JSC::VM::enableControlFlowProfiler):
        (JSC::VM::disableControlFlowProfiler):
        (JSC::VM::dumpTypeProfilerData):
        * runtime/VM.h:
        (JSC::VM::functionHasExecutedCache):
        (JSC::VM::controlFlowProfiler):

2014-12-04  Filip Pizlo  <fpizlo@apple.com>

        printInternal(PrintStream& out, JSC::JITCode::JITType type) ends up dumping a literal %s
        https://bugs.webkit.org/show_bug.cgi?id=139274

        Reviewed by Geoffrey Garen.

        * jit/JITCode.cpp:
        (WTF::printInternal):

2014-12-04  Geoffrey Garen  <ggaren@apple.com>

        Removed the concept of ParserArenaRefCounted
        https://bugs.webkit.org/show_bug.cgi?id=139277

        Reviewed by Oliver Hunt.

        This is a step toward a parser speedup.

        Now that we have a clear root node type for each parse tree, there's no
        need to have a concept for "I might be refcounted or arena allocated".
        Instead, we can just use unique_ptr to manage the tree as a whole.

        * API/JSScriptRef.cpp:
        (parseScript):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createBuiltinExecutable): Updated for type change.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock): Use unique_ptr. No need to call
        destroyData() explicitly: the unique_ptr destructor will do everything
        we need, as Bjarne intended.

        * parser/NodeConstructors.h:
        (JSC::ParserArenaRoot::ParserArenaRoot):
        (JSC::ParserArenaRefCounted::ParserArenaRefCounted): Deleted.

        * parser/Nodes.cpp:
        (JSC::ScopeNode::ScopeNode):
        (JSC::ProgramNode::ProgramNode):
        (JSC::EvalNode::EvalNode):
        (JSC::FunctionNode::FunctionNode):
        (JSC::ProgramNode::create): Deleted.
        (JSC::EvalNode::create): Deleted.
        (JSC::FunctionNode::create): Deleted. All special create semantics can
        just go away now that we play by C++ constructor / destructor rules.

        * parser/Nodes.h:
        (JSC::ParserArenaRoot::parserArena):
        (JSC::ParserArenaRoot::~ParserArenaRoot): Just a normal class now, which
        holds onto the whole parse tree by virtue of owning the arena in which
        all the parsed nodes (except for itself) were allocated.

        (JSC::ProgramNode::closedVariables):
        (JSC::ParserArenaRefCounted::~ParserArenaRefCounted): Deleted.

        (JSC::ScopeNode::destroyData): Deleted. No need to destroy anything
        explicitly anymore -- we can just rely on destructors.

        (JSC::ScopeNode::parserArena): Deleted.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        (JSC::parse): unique_ptr all the things.

        * parser/ParserArena.cpp:
        (JSC::ParserArena::reset):
        (JSC::ParserArena::isEmpty):
        (JSC::ParserArena::contains): Deleted.
        (JSC::ParserArena::last): Deleted.
        (JSC::ParserArena::removeLast): Deleted.
        (JSC::ParserArena::derefWithArena): Deleted.
        * parser/ParserArena.h:
        (JSC::ParserArena::swap): Much delete. Such wow.

        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::checkSyntax): unique_ptr all the things.

2014-12-04  Andreas Kling  <akling@apple.com>

        REGRESSION(r173188): Text inserted when trying to delete a word from the Twitter message box.
        <https://webkit.org/b/139076>

        Reviewed by Geoffrey Garen.

        The StringImpl* -> Weak<JSString> cache used by the DOM bindings
        had a bug where the key could become a stale pointer if the cached
        JSString had its internal StringImpl atomicized.

        If a new StringImpl was then later constructed at the exact same
        address as the stale key, before the Weak<JSString> got booted out
        of the string cache, we'd now have a situation where asking the
        string cache for that key would return the old JSString.

        Solve this by not allowing JSString::toExistingAtomicString() to
        change the JSString's internal StringImpl unless it's resolving a
        rope string. (The StringImpl nullity determines rope state.)

        This means that calling toExistingAtomicString() may now have to
        query the AtomicString table on each call rather than just once.
        All clients of this API would be forced to do this regardless,
        since they return value will be used to key into containers with
        AtomicStringImpl* keys.

        No test because this relies on malloc putting two StringImpls
        at the same address at different points in time and we have no
        mechanism to reliably test that.

        * runtime/JSString.h:
        (JSC::JSString::toExistingAtomicString):

2014-12-04  Geoffrey Garen  <ggaren@apple.com>

        Marked some final things final.

        Reviewed by Andreas Kling.

        * parser/Nodes.h:

2014-12-04  Geoffrey Garen  <ggaren@apple.com>

        Split out FunctionNode from FunctionBodyNode
        https://bugs.webkit.org/show_bug.cgi?id=139273

        Reviewed by Andreas Kling.

        This is step toward a parser speedup.

        We used to use FunctionBodyNode for two different purposes:

        (1) "I am the root function you are currently parsing";

        (2) "I am a lazy record of a nested function, which you will parse later".

        This made for awkward lifetime semantics and interfaces.

        Now, case (1) is handled by FunctionBodyNode, and case (2) is handled by
        a new node named FunctionNode.

        Since case (1) no longer needs to handle being the root of the parse
        tree, FunctionBodyNode can be a normal arena-allocated node.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::generateFunctionCodeBlock): Use FunctionNode instead of
        FunctionBodyNode, since we are producing the root of the function parse
        tree.

        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): Removed
        some unused data, and default-initialized other data, which isn't filled
        in meaningfully until recordParse() is called. (The previous values were
        incorrect / meaningless, since the FunctionBodyNode didn't have
        meaningful values in this case.)

        * bytecode/UnlinkedCodeBlock.h: Ditto.

        (JSC::UnlinkedFunctionExecutable::forceUsesArguments): Deleted.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Use FunctionNode instead of
        FunctionBodyNode, since we are generating code starting at the root of
        the parse tree.

        (JSC::BytecodeGenerator::resolveCallee):
        (JSC::BytecodeGenerator::addCallee):
        * bytecompiler/BytecodeGenerator.h: Ditto.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::FunctionBodyNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode): Moved the emitBytecode implementation
        to FunctionNode, since we never generate code for FunctionBodyNode,
        since it's just a placeholder in the AST.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionBody):
        (JSC::ASTBuilder::setUsesArguments): Deleted. Updated for interface
        changes.

        * parser/Nodes.cpp:
        (JSC::FunctionBodyNode::FunctionBodyNode):
        (JSC::FunctionBodyNode::finishParsing):
        (JSC::FunctionBodyNode::setEndPosition):
        (JSC::FunctionNode::FunctionNode):
        (JSC::FunctionNode::create):
        (JSC::FunctionNode::finishParsing):
        (JSC::FunctionBodyNode::create): Deleted.

        * parser/Nodes.h:
        (JSC::FunctionBodyNode::parameters):
        (JSC::FunctionBodyNode::source):
        (JSC::FunctionBodyNode::startStartOffset):
        (JSC::FunctionBodyNode::isInStrictContext):
        (JSC::FunctionNode::parameters):
        (JSC::FunctionNode::ident):
        (JSC::FunctionNode::functionMode):
        (JSC::FunctionNode::startColumn):
        (JSC::FunctionNode::endColumn):
        (JSC::ScopeNode::setSource): Deleted.
        (JSC::FunctionBodyNode::parameterCount): Deleted. Split out the differences
        between FunctionNode and FunctionBodyNode.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createClauseList):
        (JSC::SyntaxChecker::setUsesArguments): Deleted. Removed setUsesArguments
        since it wasn't used.

        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::checkSyntax): Removed a branch that was always
        false.

2014-12-02  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: timeline probe records have inaccurate per-probe hit counts
        https://bugs.webkit.org/show_bug.cgi?id=138976

        Reviewed by Joseph Pecoraro.

        Previously, the DebuggerAgent was responsible for assigning unique ids to samples.
        However, this makes it impossible for the frontend's Timeline manager to associate
        a Probe Sample timeline record with the corresponding probe sample data. The record
        only included the probe batchId (misnamed as hitCount in ScriptDebugServer).

        This patch moves both the batchId and sampleId counters into ScriptDebugServer, so
        any client of ScriptDebugListener will get the correct sampleId for each sample.

        * inspector/ScriptDebugListener.h:
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::ScriptDebugServer):
        (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
        (Inspector::ScriptDebugServer::handleBreakpointHit):
        * inspector/ScriptDebugServer.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        * inspector/agents/InspectorDebuggerAgent.h:

2014-12-04  Oliver Hunt  <oliver@apple.com>

        Serialization of MapData object provides unsafe access to internal types
        https://bugs.webkit.org/show_bug.cgi?id=138653

        Reviewed by Geoffrey Garen.

        Converting these ASSERTs into RELEASE_ASSERTs, as it is now obvious
        that despite trying hard to be safe in all cases it's simply to easy
        to use an iterator in an unsafe state.

        * runtime/MapData.h:
        (JSC::MapData::const_iterator::key):
        (JSC::MapData::const_iterator::value):

2014-12-03  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Move JavaScriptCore/dfg to std::unique_ptr
        https://bugs.webkit.org/show_bug.cgi?id=139169

        Reviewed by Filip Pizlo.

        Use std::unique_ptr<>|std::make_unique<> in JavaScriptCore/dfg directory.

        * dfg/DFGBasicBlock.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::linkFunction):
        * dfg/DFGJITCompiler.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::cancel):
        * dfg/DFGPlan.h:
        * dfg/DFGSlowPathGenerator.h:
        * dfg/DFGWorklist.h:
        * ftl/FTLFail.cpp:
        (JSC::FTL::fail):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):

2014-12-03  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r176479): DFG ASSERTION beneath emitOSRExitCall running Kraken/imaging-gaussian-blur.js.ftl-no-cjit-osr-validation and other tests
        https://bugs.webkit.org/show_bug.cgi?id=139246

        Reviewed by Geoffrey Garen.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
        The DFG_ASSERT that checks liveness at exit time doesn't properly
        handle the case where the local is not available at OSR exit time,
        but the local is live in the bytecode.  This now happens with the
        allocated scope register when we are compiling for FTLForOSREntryMode
        due to DCE done when the control flow was changed and a new entrypoint
        was added in the OSR entrypoint creation phase.  Therefore we silence
        the assert when compiling for FTLForOSREntryMode.

2014-12-03  Geoffrey Garen  <ggaren@apple.com>

        Removed the global parser arena
        https://bugs.webkit.org/show_bug.cgi?id=139236

        Reviewed by Sam Weinig.

        Simplifies parser lifetime logic.

        There's no need to keep a global arena. We can create a new arena
        each time we parse.

        * bytecompiler/BytecodeGenerator.h: Global replace to pass around a
        ParserArena instead of VM*, since the VM no longer owns the arena.
        (JSC::BytecodeGenerator::parserArena):

        * bytecompiler/NodesCodegen.cpp: Ditto.
        (JSC::ArrayNode::toArgumentList):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * parser/ASTBuilder.h: Ditto.
        (JSC::ASTBuilder::ASTBuilder):
        (JSC::ASTBuilder::createSourceElements):
        (JSC::ASTBuilder::createCommaExpr):
        (JSC::ASTBuilder::createLogicalNot):
        (JSC::ASTBuilder::createUnaryPlus):
        (JSC::ASTBuilder::createVoid):
        (JSC::ASTBuilder::thisExpr):
        (JSC::ASTBuilder::createResolve):
        (JSC::ASTBuilder::createObjectLiteral):
        (JSC::ASTBuilder::createArray):
        (JSC::ASTBuilder::createNumberExpr):
        (JSC::ASTBuilder::createString):
        (JSC::ASTBuilder::createBoolean):
        (JSC::ASTBuilder::createNull):
        (JSC::ASTBuilder::createBracketAccess):
        (JSC::ASTBuilder::createDotAccess):
        (JSC::ASTBuilder::createSpreadExpression):
        (JSC::ASTBuilder::createRegExp):
        (JSC::ASTBuilder::createNewExpr):
        (JSC::ASTBuilder::createConditionalExpr):
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createFunctionBody):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createArguments):
        (JSC::ASTBuilder::createArgumentsList):
        (JSC::ASTBuilder::createProperty):
        (JSC::ASTBuilder::createPropertyList):
        (JSC::ASTBuilder::createElementList):
        (JSC::ASTBuilder::createFormalParameterList):
        (JSC::ASTBuilder::createClause):
        (JSC::ASTBuilder::createClauseList):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::createBlockStatement):
        (JSC::ASTBuilder::createExprStatement):
        (JSC::ASTBuilder::createIfStatement):
        (JSC::ASTBuilder::createForLoop):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createForOfLoop):
        (JSC::ASTBuilder::createEmptyStatement):
        (JSC::ASTBuilder::createVarStatement):
        (JSC::ASTBuilder::createEmptyVarExpression):
        (JSC::ASTBuilder::createReturnStatement):
        (JSC::ASTBuilder::createBreakStatement):
        (JSC::ASTBuilder::createContinueStatement):
        (JSC::ASTBuilder::createTryStatement):
        (JSC::ASTBuilder::createSwitchStatement):
        (JSC::ASTBuilder::createWhileStatement):
        (JSC::ASTBuilder::createDoWhileStatement):
        (JSC::ASTBuilder::createLabelStatement):
        (JSC::ASTBuilder::createWithStatement):
        (JSC::ASTBuilder::createThrowStatement):
        (JSC::ASTBuilder::createDebugger):
        (JSC::ASTBuilder::createConstStatement):
        (JSC::ASTBuilder::appendConstDecl):
        (JSC::ASTBuilder::combineCommaNodes):
        (JSC::ASTBuilder::createDeconstructingAssignment):
        (JSC::ASTBuilder::Scope::Scope):
        (JSC::ASTBuilder::createNumber):
        (JSC::ASTBuilder::makeTypeOfNode):
        (JSC::ASTBuilder::makeDeleteNode):
        (JSC::ASTBuilder::makeNegateNode):
        (JSC::ASTBuilder::makeBitwiseNotNode):
        (JSC::ASTBuilder::makeMultNode):
        (JSC::ASTBuilder::makeDivNode):
        (JSC::ASTBuilder::makeModNode):
        (JSC::ASTBuilder::makeAddNode):
        (JSC::ASTBuilder::makeSubNode):
        (JSC::ASTBuilder::makeLeftShiftNode):
        (JSC::ASTBuilder::makeRightShiftNode):
        (JSC::ASTBuilder::makeURightShiftNode):
        (JSC::ASTBuilder::makeBitOrNode):
        (JSC::ASTBuilder::makeBitAndNode):
        (JSC::ASTBuilder::makeBitXOrNode):
        (JSC::ASTBuilder::makeFunctionCallNode):
        (JSC::ASTBuilder::makeBinaryNode):
        (JSC::ASTBuilder::makeAssignNode):
        (JSC::ASTBuilder::makePrefixNode):
        (JSC::ASTBuilder::makePostfixNode):

        * parser/NodeConstructors.h: Ditto.
        (JSC::ParserArenaFreeable::operator new):
        (JSC::ParserArenaDeletable::operator new):
        (JSC::ParserArenaRefCounted::ParserArenaRefCounted):

        * parser/Nodes.cpp: Ditto.
        (JSC::ScopeNode::ScopeNode):
        (JSC::ProgramNode::ProgramNode):
        (JSC::ProgramNode::create):
        (JSC::EvalNode::EvalNode):
        (JSC::EvalNode::create):
        (JSC::FunctionBodyNode::FunctionBodyNode):
        (JSC::FunctionBodyNode::create):

        * parser/Nodes.h: Ditto.
        (JSC::ScopeNode::parserArena):

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseProperty): The parser now owns its own
        arena, and transfers ownership of its contents when invoking the ScopeNode
        constructor.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse): No need to explicitly reset the arena,
        since its lifetime is tied to the parser's lifetime now.

        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createProperty):
        (JSC::SyntaxChecker::createGetterOrSetterProperty):

        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h: The point of the patch: no more global.

2014-12-03  Geoffrey Garen  <ggaren@apple.com>

        The parser should allocate all pieces of the AST
        https://bugs.webkit.org/show_bug.cgi?id=139230

        Reviewed by Oliver Hunt.

        This is a step toward a 14% parsing speedup.

        Previously, allocation was split between the parser and certain node
        constructor functions. This made for some duplicated code and circular
        dependencies.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createGetterOrSetterProperty): No need to pass through
        the VM, since our callee no longer needs to allocate anything.

        (JSC::ASTBuilder::createProperty): Allocate the identifier for our
        callee, since that is simpler than requiring our callee to notice that
        we didn't do so, and do it for us.

        (JSC::ASTBuilder::createForInLoop): Allocate the DeconstructingAssignmentNode
        for our callee, since that is simpler than requiring our callee to notice
        that we didn't do so, and do it for us.

        Also, reuse some code instead of duplicating it.

        (JSC::ASTBuilder::createForOfLoop): Ditto.

        (JSC::ASTBuilder::createArrayPattern):
        (JSC::ASTBuilder::createObjectPattern):
        (JSC::ASTBuilder::createBindingLocation): No need to pass through a VM
        pointer, since our callee no longer needs to allocate anything.

        (JSC::ASTBuilder::createBreakStatement): Deleted.
        (JSC::ASTBuilder::createContinueStatement): Deleted.

        * parser/NodeConstructors.h:
        (JSC::PropertyNode::PropertyNode):
        (JSC::DeconstructionPatternNode::DeconstructionPatternNode):
        (JSC::ArrayPatternNode::ArrayPatternNode):
        (JSC::ArrayPatternNode::create):
        (JSC::ObjectPatternNode::ObjectPatternNode):
        (JSC::ObjectPatternNode::create):
        (JSC::BindingNode::create):
        (JSC::BindingNode::BindingNode):
        (JSC::ContinueNode::ContinueNode): Deleted.
        (JSC::BreakNode::BreakNode): Deleted.
        (JSC::EnumerationNode::EnumerationNode): Deleted.
        (JSC::ForInNode::ForInNode): Deleted.
        (JSC::ForOfNode::ForOfNode): Deleted. Deleted a bunch of special cases
        that don't exist anymore, now that the parser allocates all pieces of
        the AST unconditionally.

        * parser/Nodes.h: Ditto.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseBreakStatement):
        (JSC::Parser<LexerType>::parseContinueStatement): Allocate the null
        identifier for our callee, since that is simpler than requiring our
        callee to notice that we didn't do so, and do it for us.

        (JSC::Parser<LexerType>::parseProperty):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createProperty): No need to pass through a VM
        pointer, since our callee no longer needs to allocate anything.

2014-12-03  Zsolt Borbely  <zsborbely.u-szeged@partner.samsung.com>

        Remove unused JSC runtime options
        https://bugs.webkit.org/show_bug.cgi?id=133070

        Reviewed by Csaba Osztrogonác.

        * runtime/Options.h:

2014-12-02  Mark Lam  <mark.lam@apple.com>

        Rolling out r176592, r176603, r176616, and r176705 until build and perf issues are resolved.
        https://bugs.webkit.org/show_bug.cgi?id=138821

        Not reviewed.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::visitChildren):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::mdNode):
        (JSC::FTL::buildCall):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::sortCompactedVector):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::dumpInternal):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::matchCharacterClass):

2014-12-02  Michael Saboff  <msaboff@apple.com>

        Change CallFrame::globalThisValue() to not use CallFrame::scope()
        https://bugs.webkit.org/show_bug.cgi?id=139202

        Reviewed by Mark Lam.

        Changed to use the globalThis() on the globalObject associated with the
        callee.  Moved the inline definition to JSGlobalObject.h instead of
        including JSGlobalObject.h in JSScope.h.  Also moved it as JSScope
        objects are no longer involved in getting the value.

        * runtime/JSGlobalObject.h:
        (JSC::ExecState::globalThisValue):
        * runtime/JSScope.h:
        (JSC::ExecState::globalThisValue): Deleted.

2014-12-02  Matthew Mirman  <mmirman@apple.com>

        Fixes inline cache fast path accessing nonexistant getters.
        <rdar://problem/18416918>
        https://bugs.webkit.org/show_bug.cgi?id=136961

        Reviewed by Filip Pizlo.

        Fixes a bug in inline caching where getters would have been able to 
        modify the property they are getting during 
        building the inline cache and then accessing that 
        property through the inline cache site causing a recursive 
        inline cache building and allowing the fast path of the cache to 
        try to load a getter for the property that no longer exists.
                
        * jit/JITOperations.cpp: Switched use of get to getPropertySlot.
        * runtime/JSCJSValue.h: 
        added getPropertySlot for when you don't want to perform the get quite yet but want 
        to fill out the slot.
        * runtime/JSCJSValueInlines.h: Added implementation for getPropertySlot
        (JSC::JSValue::get): changed to simply call getPropertySlot
        (JSC::JSValue::getPropertySlot): added.
        * tests/stress/recursive_property_redefine_during_inline_caching.js: Added test case for bug.
        (test):
        
2014-12-01  Michael Saboff  <msaboff@apple.com>

        Remove GetMyScope node from DFG
        https://bugs.webkit.org/show_bug.cgi?id=139166

        Reviewed by Oliver Hunt.

        Eliminated GetMyScope DFG node type.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * 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/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyScope): Deleted.

2014-12-01  Michael Saboff  <msaboff@apple.com>

        Crash (integer overflow) beneath ByteCodeParser::handleGetById typing in search field on weather.com
        https://bugs.webkit.org/show_bug.cgi?id=139165

        Reviewed by Oliver Hunt.

        If we don't have any getById or putById variants, emit non-cached versions of these operations.

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

2014-12-01  Andreas Kling  <akling@apple.com>

        Optimize constructing JSC::Identifier from AtomicString.
        <https://webkit.org/b/139157>

        Reviewed by Michael Saboff.

        Add constructors for Identifier taking AtomicString and AtomicStringImpl.
        This avoids branching on the string's isAtomic flag, which is obviously
        always true for AtomicString & AtomicStringImpl.

        Had to add a Identifier(const char*) constructor to resolve implicit
        ambiguity between String / AtomicString.

        Also made PrivateName::uid() return AtomicStringImpl* to take advantage
        of the new constructor in a few places.

        * runtime/Identifier.h:
        (JSC::Identifier::Identifier):
        * runtime/IdentifierInlines.h:
        (JSC::Identifier::Identifier):
        * runtime/PrivateName.h:
        (JSC::PrivateName::uid):

2014-12-01  Alexey Proskuryakov  <ap@apple.com>

        Several JavaScriptCore date tests are flaky, because they expect time to be frozen during execution
        https://bugs.webkit.org/show_bug.cgi?id=139138

        Reviewed by Mark Lam.

        Merged a fix by Bob Clary.

        * tests/mozilla/ecma/Date/15.9.1.1-1.js:
        * tests/mozilla/ecma/Date/15.9.1.1-2.js:
        * tests/mozilla/ecma/Date/15.9.2.1.js:
        * tests/mozilla/ecma/Date/15.9.2.2-1.js:
        * tests/mozilla/ecma/Date/15.9.2.2-2.js:
        * tests/mozilla/ecma/Date/15.9.2.2-3.js:
        * tests/mozilla/ecma/Date/15.9.2.2-4.js:
        * tests/mozilla/ecma/Date/15.9.2.2-5.js:
        * tests/mozilla/ecma/Date/15.9.2.2-6.js:

2014-11-17  Oliver Hunt  <oliver@apple.com>

        Make sure range based iteration of Vector<> still receives bounds checking
        https://bugs.webkit.org/show_bug.cgi?id=138821

        Reviewed by Mark Lam.

        There are a few uses of begin()/end() that explicitly require pointers,
        so we use getPtr() to extract the underlying pointer generically.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::visitChildren):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::mdNode):
        (JSC::FTL::buildCall):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        * profiler/ProfileNode.cpp:
        (JSC::ProfileNode::debugPrintRecursively):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLengthWithArrayStorage):
        (JSC::JSArray::sortCompactedVector):
        * tools/ProfileTreeNode.h:
        (JSC::ProfileTreeNode::dumpInternal):
        * yarr/YarrJIT.cpp:
        (JSC::Yarr::YarrGenerator::matchCharacterClass):

2014-11-29  Andreas Kling  <akling@apple.com>

        PropertyTable keys should be AtomicStringImpl.
        <https://webkit.org/b/139096>

        Reviewed by Sam Weinig.

        Since PropertyTable keys are really always Identifiers, switch the key
        type from StringImpl* to AtomicStringImpl*.

        We have code in the GetByVal opcode implementations that assumes things
        about this, so this change adds confidence to those algorithms.

        * bytecode/ComplexGetStatus.cpp:
        (JSC::ComplexGetStatus::computeFor):
        * bytecode/ComplexGetStatus.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeFor):
        (JSC::GetByIdStatus::computeForStubInfo):
        * bytecode/GetByIdStatus.h:
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/PutByIdStatus.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGDesiredIdentifiers.cpp:
        (JSC::DFG::DesiredIdentifiers::addLazily):
        (JSC::DFG::DesiredIdentifiers::at):
        * dfg/DFGDesiredIdentifiers.h:
        (JSC::DFG::DesiredIdentifiers::operator[]):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
        * runtime/Identifier.h:
        (JSC::Identifier::impl):
        * runtime/IntendedStructureChain.cpp:
        (JSC::IntendedStructureChain::mayInterceptStoreTo):
        * runtime/IntendedStructureChain.h:
        * runtime/PropertyMapHashTable.h:
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::contains):
        (JSC::StructureTransitionTable::get):
        (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
        (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
        (JSC::Structure::getConcurrently):
        (JSC::Structure::add):
        (JSC::Structure::remove):
        * runtime/Structure.h:
        (JSC::PropertyMapEntry::PropertyMapEntry):
        * runtime/StructureInlines.h:
        (JSC::Structure::getConcurrently):
        * runtime/StructureTransitionTable.h:
        (JSC::StructureTransitionTable::Hash::hash):

2014-11-28  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Use std::unique_ptr<>|make_unique<> in ftl, bytecode of JSC
        https://bugs.webkit.org/show_bug.cgi?id=139063

        Reviewed by Andreas Kling.

        Clean up OwnPtr and PassOwnPtr in JSC.

        * bytecode/StructureStubClearingWatchpoint.cpp:
        (JSC::StructureStubClearingWatchpoint::push):
        * bytecode/StructureStubClearingWatchpoint.h:
        (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * parser/SourceProviderCacheItem.h:

2014-11-27  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Use std::unique_ptr instead of OwnPtr in JSC classes
        https://bugs.webkit.org/show_bug.cgi?id=139009

        Reviewed by Filip Pizlo.

        As a step of using std::unique_ptr<>, this patch replaces OwnPtr with
        std::unique_ptr<>|std::make_unique<>.

        * bytecode/DFGExitProfile.cpp:
        (JSC::DFG::ExitProfile::add):
        * bytecode/DFGExitProfile.h:
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::CompressedLazyOperandValueProfileHolder::add):
        * bytecode/LazyOperandValueProfile.h:
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::stopAllocating):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::clearNewlyAllocated):
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        * runtime/RegExp.cpp:
        (JSC::RegExp::invalidateCode):
        * runtime/RegExp.h:
        * yarr/RegularExpression.cpp:
        (JSC::Yarr::RegularExpression::Private::compile):
        (JSC::Yarr::RegularExpression::isValid):
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::compile):
        (JSC::Yarr::ByteCompiler::regexBegin):
        (JSC::Yarr::byteCompile):
        * yarr/YarrInterpreter.h:
        (JSC::Yarr::BytecodePattern::BytecodePattern):

2014-11-24  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Clean up OwnPtr and PassOwnPtr in JSC - bytecode, jit, inspector, and interpreter
        https://bugs.webkit.org/show_bug.cgi?id=139022

        Reviewed by Filip Pizlo.

        As a step of using std::unique_ptr<>, this patch replaces OwnPtr with
        std::unique_ptr<>|std::make_unique<>.

        * bytecode/DFGExitProfile.cpp:
        (JSC::DFG::ExitProfile::add):
        * bytecode/DFGExitProfile.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::linkFunction):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::JITFinalizer):
        * dfg/DFGJITFinalizer.h:
        * heap/IncrementalSweeper.h:
        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::findMagicComment):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::enableSampler):
        * interpreter/Interpreter.h:
        * jit/ExecutableAllocator.cpp:
        (JSC::ExecutableAllocator::ExecutableAllocator):
        * jit/ExecutableAllocator.h:

2014-11-22  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Clean up OwnPtr and PassOwnPtr in some of JS classes
        https://bugs.webkit.org/show_bug.cgi?id=138724

        Reviewed by Filip Pizlo.

        As a step to use std::unique_ptr<> and std::make_unique<>, this patch replaces
        OwnPtr with std::unique_ptr<>. Besides create() factory function is removed as well.

        * builtins/BuiltinExecutables.h:
        (JSC::BuiltinExecutables::create): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::createRareDataIfNecessary):
        * bytecode/StructureStubInfo.h:
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::hasRareData):
        (JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        * runtime/CodeCache.h:
        (JSC::CodeCache::create): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::clearRareData):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::createRareDataIfNeeded):
        * runtime/RegExpConstructor.h:
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::createSingleCharacterString):
        (JSC::SmallStrings::singleCharacterStringRep):
        * runtime/SmallStrings.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2014-11-21  Michael Saboff  <msaboff@apple.com>

        r176455: ASSERT(!m_vector.isEmpty()) in IntendedStructureChain.cpp(143)
        https://bugs.webkit.org/show_bug.cgi?id=139000

        Reviewed by Darin Adler.

        Check that the chainCount is non-zero before using a StructureChain.

        * bytecode/ComplexGetStatus.cpp:
        (JSC::ComplexGetStatus::computeFor):

2014-11-21  Michael Saboff  <msaboff@apple.com>

        Allocate local ScopeChain register
        https://bugs.webkit.org/show_bug.cgi?id=138793

        Reviewed by Geoffrey Garen.

        Now we allocate the scope register as a local.  The allocated register is stored in the 
        CodeBlock for use by other components.  Update the DFG to work with a local scope register.
        Changed usage of JSStack::ScopeChain access to the CallFrame header to use the allocated
        local register.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        Updated to properly represent the operand inputs and bytecode result.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setScopeRegister):
        (JSC::CodeBlock::scopeRegister):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::setScopeRegister):
        (JSC::UnlinkedCodeBlock::scopeRegister):
        Added scope register member and accessors.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::allocateAndEmitScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::scopeRegister):
        Change m_scopeRegister to an allocated register.  Added allocateAndEmitScope helper to
        allocate the scope register, set the CodeBlock with its value and emit op_get_scope.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::scope): Changed to access the scope using the new convention.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        Changed op_create_lexical_environment to set the scope VirtualRegister operand.
        Filled out op_get_scope processing to emit a GetScope node putting the result in
        the scope VirtualRegister result operand.
        Added Phantoms where appropriate to keep the Scope register alive in places where
        it use is optimized away, but where the baseline JIT would need to use its value.
        Eliminated uses of JSStack::ScopeChain.

        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        Make sure that the scope register stack location is allocated using the same place
        that the codeBlock expects. 

        * dfg/DFGStrengthReductionPhase.cpp:
        (JSC::DFG::StrengthReductionPhase::handleNode):
        Allow strength reduction of Flush to skip of GetScope nodes looking for a prior
        corresponding SetLocal.

        * interpreter/CallFrame.h:
        (JSC::ExecState::scope):
        (JSC::ExecState::setScope):
        Added new scope() and setScope() helpers that take a VirtualRegister offset.

        * interpreter/Interpreter.cpp:
        (JSC::eval):
        Changed eval() to get the scope from the caller's scope register instead of from the
        temporary frame created for eval.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwind):
        Changed unwind() to manipulate the scope n the allocated register instead of from the
        call frame slot.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::readInlinedFrame):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::Frame::callee):
        (JSC::StackVisitor::Frame::scope): Deleted.
        Eliminated the scope member as it needed to change and no StackVisitor users use it.

        * jit/JITOperations.cpp:
        (JSC::operationPushNameScope):
        (JSC::operationPushWithScope):
        * runtime/JSNameScope.h:
        (JSC::JSNameScope::create):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::create): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        Deleted JSNameScope::create() and JSWithScope::create() flavors tht used the ScopeChain slot
        in the CallFrame header.  Changed the only user of these function, op_push_name_scope and
        op_push_with_scope helpers, to use the remaining create variants that require explicit scope.  
        Those operations get the scope from the register pointed to by their scope operands.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        Changed resolveScope to use the allocated register.

2014-11-21  Csaba Osztrogonác  <ossy@webkit.org>

        [JSC] Disable verifyHeap
        https://bugs.webkit.org/show_bug.cgi?id=138962

        Reviewed by Mark Lam.

        * runtime/Options.h:

2014-11-20  Mark Lam  <mark.lam@apple.com>

        Add some comments to describe the DFG UseKind representations.
        <https://webkit.org/b/138934>

        Reviewed by Filip Pizlo.

        * dfg/DFGUseKind.h:
        - Also regrouped the UseKind enums by representation to be more readable.

2014-11-20  Mark Lam  <mark.lam@apple.com>

        Add Heap verification infrastructure.
        <https://webkit.org/b/138851>

        Reviewed by Geoffrey Garen.

        The verification infrastructure code is always built in but disabled by
        default.  When disabled, the cost is minimal:
        1. Heap has a m_verifier field.
        2. GC does a few "if (m_verifier)" checks that should fail.
        3. HeapVerifier takes up code space though not used.

        When enabled:
        1. The HeapVerifier will keep N number of GC cycle data.
           Each GC cycle will contain a "before marking" and "after marking" live
           object list.
           The GC cycles is a circular buffer.  Only data for the last N GC cycles
           will be retained.
        2. During GC, the current GC cycle's live objects lists will be populated
           before and after marking.
        3. The current GC cycle's live object lists will be validated before GC,
           after marking, and after GC.

        Currently, the only validation being done is to verify that object
        butterflies are allocated from valid blocks in the Storage (aka Copied)
        space.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::collect):
        * heap/Heap.h:
        * heap/HeapVerifier.cpp: Added.
        (JSC::LiveObjectList::findObject):
        (JSC::HeapVerifier::HeapVerifier):
        (JSC::HeapVerifier::collectionTypeName):
        (JSC::HeapVerifier::phaseName):
        (JSC::getButterflyDetails):
        (JSC::HeapVerifier::initializeGCCycle):
        (JSC::GatherLiveObjFunctor::GatherLiveObjFunctor):
        (JSC::GatherLiveObjFunctor::operator()):
        (JSC::HeapVerifier::gatherLiveObjects):
        (JSC::HeapVerifier::liveObjectListForGathering):
        (JSC::trimDeadObjectsFromList):
        (JSC::HeapVerifier::trimDeadObjects):
        (JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
        (JSC::HeapVerifier::verify):
        (JSC::HeapVerifier::reportObject):
        (JSC::HeapVerifier::checkIfRecorded):
        * heap/HeapVerifier.h: Added.
        (JSC::LiveObjectData::LiveObjectData):
        (JSC::LiveObjectList::LiveObjectList):
        (JSC::LiveObjectList::reset):
        (JSC::HeapVerifier::GCCycle::GCCycle):
        (JSC::HeapVerifier::GCCycle::collectionTypeName):
        (JSC::HeapVerifier::incrementCycle):
        (JSC::HeapVerifier::currentCycle):
        (JSC::HeapVerifier::cycleForIndex):
        * runtime/Options.h:

2014-11-20  Yusuke Suzuki  <utatane.tea@gmail.com>

        Rename String.prototype.contains to String.prototype.includes
        https://bugs.webkit.org/show_bug.cgi?id=138923

        As per the latest TC39 meeting[1, 2], String.prototype.contains is
        renamed to String.prototype.includes. This is because the name
        `contains` breaks the web since it conflicts with existing `contains`
        implementations in major libraries.

        [1]: https://github.com/mathiasbynens/String.prototype.includes
        [2]: https://github.com/tc39/test262/pull/119

        Reviewed by Geoffrey Garen.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncIncludes):
        (JSC::stringProtoFuncContains): Deleted.

2014-11-19  Mark Lam  <mark.lam@apple.com>

        WTFCrashWithSecurityImplication under SpeculativeJIT::compile() when loading a page from theblaze.com.
        <https://webkit.org/b/137642>

        Reviewed by Filip Pizlo.

        In the DFG, we have a ConstantFolding phase that occurs after all LocalCSE
        phases have already transpired.  Hence, Identity nodes introduced in the
        ConstantFolding phase will be left in the node graph.  Subsequently, the
        DFG code generator asserts that CSE phases have consumed all Identity nodes.
        This turns out to not be true.  Hence, the crash.  We fix this by teaching
        the DFG code generator to emit code for Identity nodes.

        Unlike the DFG, the FTL does not have this issue.  That is because the FTL
        plan has GlobalCSE phases that come after ConstantFolding and any other
        phases that can generate Identity nodes.  Hence, for the FTL, it is true that
        CSE will consume all Identity nodes, and the code generator should not see any
        Identity nodes.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2014-11-19  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: JSContext inspection Resource search does not work
        https://bugs.webkit.org/show_bug.cgi?id=131252

        Reviewed by Timothy Hatcher.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::searchInContent):
        * inspector/protocol/Debugger.json:
        Do some cleanup of the description and implementation of content searching.

2014-11-19  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Provide $exception in the console for the thrown exception value
        https://bugs.webkit.org/show_bug.cgi?id=138726

        Reviewed by Timothy Hatcher.

        * debugger/DebuggerScope.cpp:
        (JSC::DebuggerScope::caughtValue):
        * debugger/DebuggerScope.h:
        Access the caught value if this scope is a catch scope.

        * runtime/JSNameScope.h:
        (JSC::JSNameScope::isFunctionNameScope):
        (JSC::JSNameScope::isCatchScope):
        (JSC::JSNameScope::value):
        Provide an accessor for the single value in the JSNameScope (with / catch block).

        * inspector/InjectedScriptSource.js:
        Save the exception value and expose it via $exception. Since the command line api
        is recreated on each evaluation, $exception is essentially readonly.

        * inspector/ScriptDebugServer.h:
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::dispatchDidPause):
        (Inspector::ScriptDebugServer::exceptionOrCaughtValue):
        When pausing, get the exception or caught value. The exception will be provided
        if we are breaking on an explicit exception. When inside of a catch block, we
        can get the caught value by walking up the scope chain.

        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
        (Inspector::InspectorDebuggerAgent::resume):
        (Inspector::InspectorDebuggerAgent::stepOver):
        (Inspector::InspectorDebuggerAgent::stepInto):
        (Inspector::InspectorDebuggerAgent::stepOut):
        Clearing state can be done in didContinue.

        (Inspector::InspectorDebuggerAgent::didPause):
        Set the exception value explicitly in the injected script when we have it.

        (Inspector::InspectorDebuggerAgent::didContinue):
        Clear state saved when we had paused, including clearly an exception value if needed.

        (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
        (Inspector::InspectorDebuggerAgent::clearExceptionValue):
        Call into the injected script only when needed.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::setExceptionValue):
        (Inspector::InjectedScript::clearExceptionValue):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::clearExceptionValue):
        * inspector/InjectedScriptManager.h:
        Clear on all injected scripts.

2014-11-19  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed build fixes after r176329.

          - export all of the codegen python files as they are included by the main generator
          - update the imports of the main generator to match __init__.py
          - remove bundling the python scripts as framework resources, just have them PrivateHeaders

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/scripts/generate-inspector-protocol-bindings.py:

2014-11-18  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: standardize language-specific protocol generator file, class, and method prefixes
        https://bugs.webkit.org/show_bug.cgi?id=138237

        Reviewed by Joseph Pecoraro.

        Settle on cpp/objc/js file prefixes and Cpp/ObjC/JS class prefixes for generators.
        Move C++-specific static methods into CppGenerator and add cpp_ prefixes where relevant.
        Split the templates file into language-specific template files.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/scripts/codegen/__init__.py:
        * inspector/scripts/codegen/cpp_generator.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generator.py.
        * inspector/scripts/codegen/cpp_generator_templates.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generator_templates.py.
        (CppGeneratorTemplates):
        * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_dispatcher_header.py.
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_dispatcher_implementation.py.
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_frontend_dispatcher_header.py.
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py.
        * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_protocol_types_header.py.
        * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_protocol_types_implementation.py.
        * inspector/scripts/codegen/generate_js_backend_commands.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_commands.py.
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_backend_dispatcher_header.py.
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py.
        * inspector/scripts/codegen/generate_objc_configuration_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_configuration_header.py.
        * inspector/scripts/codegen/generate_objc_configuration_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_configuration_implementation.py.
        * inspector/scripts/codegen/generate_objc_conversion_helpers.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_conversion_helpers.py.
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py.
        * inspector/scripts/codegen/generate_objc_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_header.py.
        * inspector/scripts/codegen/generate_objc_internal_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_internal_header.py.
        * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_types_implementation.py.
        * inspector/scripts/codegen/generator.py:
        * inspector/scripts/codegen/generator_templates.py:
        * inspector/scripts/codegen/objc_generator.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c.py.
        * inspector/scripts/codegen/objc_generator_templates.py: Added.
        * inspector/scripts/generate-inspector-protocol-bindings.py:

2014-11-19  Juergen Ributzka  <juergen@apple.com>

        Update WebKit to build with LLVM TOT
        https://bugs.webkit.org/show_bug.cgi?id=138519

        Reviewed by Alexey Proskuryakov.

        * Configurations/LLVMForJSC.xcconfig:
        * llvm/LLVMAPIFunctions.h:
        * llvm/library/LLVMExports.cpp:
        (initializeAndGetJSCLLVMAPI):

2014-11-18  David Kilzer  <ddkilzer@apple.com>

        FeatureDefines.xcconfig: Switch from using PLATFORM_NAME to SDK selectors
        <http://webkit.org/b/138813>

        Reviewed by Mark Rowe.

        * Configurations/FeatureDefines.xcconfig: Switch to using SDK
        selectors.

2014-11-18  Chris Dumez  <cdumez@apple.com>

        Update the Vector API to deal with unsigned types instead of size_t
        https://bugs.webkit.org/show_bug.cgi?id=138824

        Reviewed by Andreas Kling.

        Update code base to fix build errors related to the typing changes
        in the Vector API (size_t -> unsigned).

        * bytecode/PreciseJumpTargets.cpp:
        * replay/EncodedValue.h:

2014-11-18  Commit Queue  <commit-queue@webkit.org>

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

        Not ready yet (Requested by ap on #webkit).

        Reverted changeset:

        "Update WebKit to build with LLVM TOT"
        https://bugs.webkit.org/show_bug.cgi?id=138519
        http://trac.webkit.org/changeset/176207

2014-11-17  Mark Lam  <mark.lam@apple.com>

        Add printing functionality in JITted code for debugging purposes.
        <https://webkit.org/b/138660>

        Reviewed by Geoffrey Garen.

        Sometimes, for debugging, it'd be nice to be able to just print the
        values of constants or registers used in JITted code, or even just
        a string to log that certain pieces of JITted code have been executed.
        Using the JIT probe mechanism, we can make this happen.

        * assembler/ARMv7Assembler.h:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::CPUState::registerName):
        (JSC::AbstractMacroAssembler::CPUState::registerValue):
        (JSC::AbstractMacroAssembler::print):
        (JSC::AbstractMacroAssembler::PrintArg::PrintArg):
        (JSC::AbstractMacroAssembler::appendPrintArg):
        (JSC::AbstractMacroAssembler::printInternal):
        (JSC::AbstractMacroAssembler::printCallback):
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::printCPURegisters):
        (JSC::MacroAssemblerARM::printRegister):
        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssemblerARMv7::printCPURegisters):
        (JSC::MacroAssemblerARMv7::printRegister):
        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::MacroAssemblerX86Common::printRegister):
        * assembler/MacroAssemblerX86Common.h:

2014-11-17  Anders Carlsson  <andersca@apple.com>

        Fix JavaScriptCore build with newer versions of clang.
        <rdar://problem/18978716>

        * heap/Heap.cpp:
        (JSC::Heap::visitTempSortVectors):
        (JSC::Heap::deleteAllCompiledCode): Deleted.
        * inspector/agents/InspectorConsoleAgent.h:

2014-11-17  Juergen Ributzka  <juergen@apple.com>

        Update WebKit to build with LLVM TOT
        https://bugs.webkit.org/show_bug.cgi?id=138519

        Reviewed by Alexey Proskuryakov.

        * Configurations/LLVMForJSC.xcconfig:
        * llvm/LLVMAPIFunctions.h:
        * llvm/library/LLVMExports.cpp:
        (initializeAndGetJSCLLVMAPI):

2014-11-14  Benjamin Poulain  <bpoulain@apple.com>

        STRH can store values with the wrong offset
        https://bugs.webkit.org/show_bug.cgi?id=138723

        Reviewed by Michael Saboff.

        This is the counterpart of r176083 for the str instruction.

        I believe this code is currently unreachable because there is only one client of strh()
        in the MacroAssembler and it always setup the scale explicitely.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::strh):

2014-11-13  Mark Lam  <mark.lam@apple.com>

        Reduce amount of cut-and-paste needed for probe mechanism implementations.
        <https://webkit.org/b/138671>

        Reviewed by Geoffrey Garen.

        The existing code requires that each MacroAssembler implementation provide
        their own copy of all of the probe implementations even when most of it is
        identical.  This patch hoists the common parts into AbstractMacroAssembler
        (with some minor renaming).  Each target specific MacroAssembler now only
        need to implement a few target specific methods that are expected by and
        documented in AbstractMacroAssembler.h in the ENABLE(MASM_PROBE) section.

        In this patch, I also simplified the X86 and X86_64 ports to use the same
        port implementation.  The ARMv7 probe implementation should not conditionally
        exclude the higher FP registers (since the JIT doesn't).  Fixed the ARMv7
        probe code to include the higher FP registers always. 

        This is all done in preparation to add printing functionality in JITted code
        for debugging.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::Label::Label):
        (JSC::AbstractMacroAssembler::ConvertibleLoadLabel::ConvertibleLoadLabel):
        (JSC::AbstractMacroAssembler::DataLabelPtr::DataLabelPtr):
        (JSC::AbstractMacroAssembler::DataLabel32::DataLabel32):
        (JSC::AbstractMacroAssembler::DataLabelCompact::DataLabelCompact):
        (JSC::AbstractMacroAssembler::Jump::link):
        (JSC::AbstractMacroAssembler::Jump::linkTo):
        (JSC::AbstractMacroAssembler::JumpList::link):
        (JSC::AbstractMacroAssembler::JumpList::linkTo):
        (JSC::AbstractMacroAssembler::ProbeContext::print):
        (JSC::AbstractMacroAssembler::printIndent):
        (JSC::AbstractMacroAssembler::printCPU):
        (JSC::AbstractMacroAssembler::CachedTempRegister::CachedTempRegister):
        - Except for the 3 printing methods (which are for the probe), the rest
          are touched simply because we need to add the MacroAssemblerType to the
          template args.
          The MacroAssemblerType is used by the abstract probe code to call the
          few probe methods that need to have CPU specific implementations.

        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::printCPURegisters):
        - This was refactored from ProbeContext::dumpCPURegisters() which no
          longer exists.
        (JSC::MacroAssemblerARM::ProbeContext::dumpCPURegisters): Deleted.
        (JSC::MacroAssemblerARM::ProbeContext::dump): Deleted.

        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARM64.h:

        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssemblerARMv7::printCPURegisters):
        - This was refactored from ProbeContext::dumpCPURegisters() which no
          longer exists.
        (JSC::MacroAssemblerARMv7::ProbeContext::dumpCPURegisters): Deleted.
        (JSC::MacroAssemblerARMv7::ProbeContext::dump): Deleted.

        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerMIPS.h:
        * assembler/MacroAssemblerSH4.h:
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::trustedImm32FromPtr): Deleted.
        (JSC::MacroAssemblerX86::probe): Deleted.

        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::MacroAssemblerX86Common::printCPURegisters):
        - This was refactored from ProbeContext::dumpCPURegisters() which no
          longer exists.
        (JSC::MacroAssemblerX86Common::probe):
        - This implementation of probe() is based on the one originally in
          MacroAssemblerX86_64.h.  It is generic and should work for both
          32-bit and 64-bit.
        (JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters): Deleted.
        (JSC::MacroAssemblerX86Common::ProbeContext::dump): Deleted.

        * assembler/MacroAssemblerX86Common.h:
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::trustedImm64FromPtr): Deleted.
        (JSC::MacroAssemblerX86_64::probe): Deleted.
        * jit/JITStubsARMv7.h:

2014-11-13  Michael Saboff  <msaboff@apple.com>

        Add scope operand to op_new_func* byte codes
        https://bugs.webkit.org/show_bug.cgi?id=138707

        Reviewed by Mark Lam.

        Added scope operand to op_new_func and op_new_func_expr to replace the implicit use
        of exec->scope().

        * bytecode/BytecodeList.json: Increased size of op_new_func & op_new_func_expr bytecodes.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Added scope operand to dump output.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewFunctionInternal):
        (JSC::BytecodeGenerator::emitNewFunctionExpression):
        Emit scope operand.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        Added new scope source nodes to NewFunction, NewFunctionExpression & NewFunctionNoCheck.
        
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
        (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        Use scope children when making new function JIT_Operation calls.  Use JSScope* value instead of
        exec->scope().

        * dfg/DFGOperations.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_new_func_exp):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        Added new Jsc JIT_Operation parameter type for JSScope* values.  Created declarations and
        definitions for new JIT_Operations with Jsc parameters.  Use the JSScope* parameters in lieu
        of exec->scope() in operationNewFunction().
        Removed comment for unused Jsa (JSLexicalEnvironment*) JIT_Operation parameter type.

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        Use the scope operand instead of exec->scope().

        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        Changed the operand indecies for added scope operand.

2014-11-13  Mark Lam  <mark.lam@apple.com>

        Change X86/64 JIT probes to save/restore xmm regs as double instead of __m128. [Follow up]
        <https://webkit.org/b/138708>

        Reviewed by Michael Saboff.

        Removed a stale comment and a now unnecessary #include. 

        * assembler/X86Assembler.h:

2014-11-13  Commit Queue  <commit-queue@webkit.org>

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

        Broke the build (Requested by ap on #webkit).

        Reverted changeset:

        "Update WebKit to build with LLVM TOT"
        https://bugs.webkit.org/show_bug.cgi?id=138519
        http://trac.webkit.org/changeset/176087

2014-11-13  Mark Lam  <mark.lam@apple.com>

        Change X86/64 JIT probes to save/restore xmm regs as double instead of __m128.
        <https://webkit.org/b/138708>

        Reviewed by Michael Saboff.

        The JIT code only uses the xmm regs as double registers.  This patch changes
        the storage types of the FP registers in X86Assembler.h to double instead of
        __m128, and updates the X86 and X86_64 JIT probe implementations accordingly.

        Also made some minor cosmetic changes in the output of the probe dump functions.

        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
        * assembler/X86Assembler.h:
        * jit/JITStubsX86.h:
        * jit/JITStubsX86Common.h:
        * jit/JITStubsX86_64.h:

2014-11-13  Juergen Ributzka  <juergen@apple.com>

        Update WebKit to build with LLVM TOT
        https://bugs.webkit.org/show_bug.cgi?id=138519

        Reviewed by Geoffrey Garen.

        * Configurations/LLVMForJSC.xcconfig:
        * llvm/LLVMAPIFunctions.h:
        * llvm/library/LLVMExports.cpp:
        (initializeAndGetJSCLLVMAPI):

2014-11-13  Benjamin Poulain  <benjamin@webkit.org>

        ARMv7(s) Assembler: LDRH with immediate offset is loading from the wrong offset
        https://bugs.webkit.org/show_bug.cgi?id=136914

        Reviewed by Michael Saboff.

        TLDR: the immediate offset of half-word load was divided by 2.

        Story time: So I started getting those weird reports of :nth-child() behaving bizarrely
        on ARMv7 and ARMv7s. To make things worse, the behavior changes depending on style updates.

        I started looking the disassembly on the tests cases...

        The first thing I noticed was that the computation of An+B looked wrong. For example,
        in the case of n+6, the instruction should have been:
            subs r1, r1, #6
        but was
            subs r1, r1, #2

        After spending a lot of time trying to find the error in the assembler, I discovered
        the problem was not real, but just a bug in the disassembler.
        This is the first fix: ARMv7DOpcodeAddSubtractImmediate3's immediate3() was truncating
        the value to 2 bits instead of 3 bits.

        The disassembler being fixed, I still have no lead on the weird bug. Some disassembly later,
        I realize the LDRH instruction is not decoded at all. The reason is that both LDRH and STRH
        were under the umbrella ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord but the pattern
        only matched SRTH.

        I fix that next, ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord is split into
        ARMv7DOpcodeStoreRegisterImmediateHalfWord and ARMv7DOpcodeLoadRegisterImmediateHalfWord,
        each with their own pattern and their instruction group.

        Now that I can see the LDRHs correctly, there is something fishy about them, their offset
        is way too small for the data I load.

        This time, looking at the binary, the generated code is indeed incorrect. It turns out that
        the ARMv7 assembler shifted the offset of half-word load as if they were byte load: divided by 4.
        As a result, all the load of half-words with more than zero offset were loading
        values with a smaller offset than what they should have.

        That being fixed, I dump the assembly: still wrong. I am ready to throw my keyboard through
        my screen at that point.

        Looking at the disassembler, there is yet again a bug. The computation of the scale() adjustment
        of the offset was incorrect for anything but word loads.
        I replaced it by a switch-case to make it explicit.

        STRH is likely incorrect too. I'll fix that in a follow up, I want to survey all the 16 bits cases
        that are not directly used by the CSS JIT.

        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::ldrh):
        Fix the immediate scaling. Add an assertion to make sure the alignment of the input is correct.

        * disassembler/ARMv7/ARMv7DOpcode.cpp:
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale):
        Fix the scaling code. Just hardcode instruction-to-scale table.

        * disassembler/ARMv7/ARMv7DOpcode.h:
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3):
        The mask for a 3 bits immediate is not 3 :)

        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale): Deleted.

2014-11-13  Andreas Kling  <akling@apple.com>

        Generate put_by_id for bracket assignment with constant string subscript.
        <https://webkit.org/b/138702>

        Reviewed by Geoffrey Garen.

        Transform o["f"]=x to o.f=x when generating bytecode. This allows our JIT
        to inline-cache those accesses instead of always dropping out to C++.

        Just like the get_by_id transformations, this gets a bunch of use on
        real-web content (and Speedometer) but little/none on raw JS benchmarks.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::AssignBracketNode::emitBytecode):

2014-11-12  Mark Lam  <mark.lam@apple.com>

        Create canonical lists of registers used by both the Assemblers and the JIT probes.
        <https://webkit.org/b/138681>

        Reviewed by Filip Pizlo.

        * assembler/ARMAssembler.h:
        * assembler/ARMv7Assembler.h:
        * assembler/X86Assembler.h:
        - The FP register storage type is still defined as __m128 because the JIT
          probe code still expects that amount of storage to be available.  Will
          change this to double when the JIT probe code is updated accordingly in a
          later patch.

2014-11-12  Andreas Kling  <akling@apple.com>

        Generate get_by_id for bracket access with constant string subscript.
        <https://webkit.org/b/138663>

        Reviewed by Michael Saboff.

        Transform o["f"] into o.f when generating bytecode. This allows our JIT
        to inline-cache those accesses instead of always dropping out to C++.

        This is surprisingly common in real-web content, less so in benchmarks.
        Interestingly, Speedometer does hit the optimization quite a bit.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BracketAccessorNode::emitBytecode):

2014-11-12  Mark Lam  <mark.lam@apple.com>

        Rename USE(MASM_PROBE) to ENABLE(MASM_PROBE).
        <https://webkit.org/b/138661>

        Reviewed by Michael Saboff.

        Also move the switch for enabling the use of MASM_PROBE from JavaScriptCore's
        config.h to WTF's Platform.h.  This ensures that the setting is consistently
        applied even when building WebCore parts as well.

        * assembler/ARMAssembler.h:
        * assembler/ARMv7Assembler.h:
        * assembler/MacroAssemblerARM.cpp:
        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARMv7.cpp:
        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerX86.h:
        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/MacroAssemblerX86Common.h:
        * assembler/MacroAssemblerX86_64.h:
        * assembler/X86Assembler.h:
        * config.h:
        * jit/JITStubs.h:
        * jit/JITStubsARM.h:
        * jit/JITStubsARMv7.h:
        * jit/JITStubsX86.h:
        * jit/JITStubsX86Common.h:
        * jit/JITStubsX86_64.h:

2014-11-12  peavo@outlook.com  <peavo@outlook.com>

        [WinCairo] Incorrect names for test executables in debug mode.
        https://bugs.webkit.org/show_bug.cgi?id=138659

        Reviewed by Alex Christensen.

        In debug mode, jsc.exe, and testapi.exe are not created, causing JSC test failures.

        * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:

2014-11-11  Michael Saboff  <msaboff@apple.com>

        Change DFG to use scope operand for op_resolve_scope
        https://bugs.webkit.org/show_bug.cgi?id=138651

        Reviewed by Geoffrey Garen.

        Changed to use the provided scope VirtualRegister.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getScope): Changed to use an argument scope register.
        (JSC::DFG::ByteCodeParser::parseBlock): Created VirtualRegister from scope operand.

2014-11-11  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Remove IncrementalSweeper::create()
        https://bugs.webkit.org/show_bug.cgi?id=138243

        Reviewed by Filip Pizlo.

        As a step to use std::unique_ptr<> and std::make_unique<>, this patch removes
        IncrementalSweeper::create(), then set constructor of IncrementalSweeper to public.
        Now we begins to use std::make_unique<> to create IncrementalSweeper instance.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::setIncrementalSweeper):
        * heap/Heap.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::create): Deleted.
        * heap/IncrementalSweeper.h:

2014-11-11  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Handle activating extra agents properly after inspector has connected
        https://bugs.webkit.org/show_bug.cgi?id=138639

        Reviewed by Timothy Hatcher.

        Instead of having the protocol configuration directly add the extra agent
        to the inspector registry, isntead go through the augmentable controller.
        The controller will initialize as required if we are already connected or not,
        and will add to the registry.

        The functional change here is that the frontend can be notified to activate
        extra agents multiple times as agents eventually become available.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::activateExtraDomain):
        * inspector/agents/InspectorAgent.h:
        * inspector/augmentable/AugmentableInspectorController.h:
        * inspector/scripts/codegen/generator_templates.py:
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        Rebased results.

2014-11-11  Michael Saboff  <msaboff@apple.com>

        Use scope register when processing op_resolve_scope in LLInt and Baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=138637

        Reviewed by Mark Lam.

        Filled out op_resolve_scope processing to use the scope operand to access the current
        scope chain.

        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        Added scope virtual register parameter to emitResolveClosure().  Added new callOperation() to
        support the additional argument.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitResolveClosure):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitResolveClosure):
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        Added "scope" parameter to emitResolveClosure().  Passed scope register index to slow path.
        Used scope virtual register instead of JSStack::ScopeChain.

2014-11-11  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Don't require a debugger be attached for inspector auto attach
        https://bugs.webkit.org/show_bug.cgi?id=138638

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate):

2014-11-11  Akos Kiss  <akiss@inf.u-szeged.hu>

        Handle cases in StackVisitor::Frame::existingArguments() when lexicalEnvironment and/or unmodifiedArgumentsRegister is not set up yet
        https://bugs.webkit.org/show_bug.cgi?id=138543

        Reviewed by Geoffrey Garen.

        Exception fuzzing may may raise exceptions in places where they would be
        otherwise impossible. Therefore, a callFrame may lack activation even if
        the codeBlock signals need of activation. Also, even if codeBlock
        signals the use of arguments, the unmodifiedArgumentsRegister may not be
        initialized yet (neither locally nor in lexicalEnvironment).

        If codeBlock()->needsActivation() is false, unmodifiedArgumentsRegister
        is already checked for Undefined. This patch applies the same check when
        the condition is true (and also checks whether
        callFrame()->hasActivation()).

        * interpreter/CallFrame.h:
        (JSC::ExecState::hasActivation):
        Moved to interpreter/CallFrameInlines.h.
        * interpreter/CallFrameInlines.h:
        (JSC::CallFrame::hasActivation):
        Fixed to verify that the JSValue returned by uncheckedActivation() is a
        cell.
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::existingArguments):

2014-11-11  Andreas Kling  <akling@apple.com>

        Another assertion fix for debug builds after r175846.

        generateByIdStub() can now be called with an empty prototype chain
        if kind == GetUndefined, so tweak the assertion to cover that.

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

2014-11-10  Andreas Kling  <akling@apple.com>

        Assertion fix for debug builds after r175846.

        PropertySlot::slotBase() will assert if the slot is unset, so reorder
        the tests to check for isCacheableValue() first.

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

2014-11-10  Andreas Kling  <akling@apple.com>

        The JIT should cache property lookup misses.
        <https://webkit.org/b/135578>

        Add support for inline caching of missed property lookups.
        Previously this would banish us to C++ slow path.

        It's implemented as a simple GetById cache that returns jsUndefined()
        as long as the Structure chain check passes. There's no DFG exploitation
        of this knowledge in this patch.

        Test: js/regress/undefined-property-access.js (~5.5x speedup)

        Reviewed by Filip Pizlo.

        * bytecode/PolymorphicGetByIdList.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfo):

            Add GetByIdAccess::SimpleMiss so we can communicate to the DFG that
            the access has been cached.

        * jit/Repatch.cpp:
        (JSC::toString):
        (JSC::kindFor):
        (JSC::generateByIdStub):
        (JSC::tryCacheGetByID):
        (JSC::tryBuildGetByIDList):

            Added a GetUndefined stub kind, just a simple "store jsUndefined()" snippet.
            Use this to cache missed lookups, piggybacking mostly on the GetValue kind.

        * runtime/PropertySlot.h:
        (JSC::PropertySlot::isUnset):

            Exposed the unset state so PropertySlot can communicate that lookup failed.

2014-11-10  Michael Saboff  <msaboff@apple.com>

        Add scope operand to op_create_lexical_environment
        https://bugs.webkit.org/show_bug.cgi?id=138588

        Reviewed by Geoffrey Garen.

        Added a second operand to op_create_lexical_environment that contains the scope register
        to update.  Note that the DFG relies on operationCreateActivation() to update the
        scope register since we can't issue a set() with a non-local, non-argument register.
        This is temporary until the scope register is allocated as a local.

        * bytecode/BytecodeList.json:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        Added the scope register operand.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        Filled in the scope register operand.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_lexical_environment):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_lexical_environment):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        Set the scope register with the result of the appropriate create activation slow call.

2014-11-09  Akos Kiss  <akiss@inf.u-szeged.hu>

        Fix 'noreturn' function does return warning in LLVMOverrides.cpp
        https://bugs.webkit.org/show_bug.cgi?id=138306

        Reviewed by Filip Pizlo.

        Adding NO_RETURN where needed.

        * llvm/library/LLVMExports.cpp:
        (initializeAndGetJSCLLVMAPI):
        * llvm/library/LLVMOverrides.cpp:
        * llvm/library/LLVMTrapCallback.h:

2014-11-07  Dániel Bátyai  <dbatyai.u-szeged@partner.samsung.com>

        Fix an alignment issue with operationPushCatchScope on ARMv7
        https://bugs.webkit.org/show_bug.cgi?id=138510

        Reviewed by Csaba Osztrogonác.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):

2014-11-07  Michael Saboff  <msaboff@apple.com>

        Update scope related slow path code to use scope register added to opcodes
        https://bugs.webkit.org/show_bug.cgi?id=138254

        Reviewed by Mark Lam.

        Updated slow paths for op_pop_scope, op_push_name_scope and op_push_with_scope.
        Added scope register index parameter to the front of the relevant argument lists of the
        slow functions.  In the case of op_push_name_scope for x86 (32 bit), there aren't enough
        registers to accomodate all the parameters.  Therefore, added two new JSVALUE32_64 slow
        paths called operationPushCatchScope() and operationPushFunctionNameScope() to eliminate
        the last "type" argument.
        

        * assembler/MacroAssemblerCodeRef.h:
        (JSC::FunctionPtr::FunctionPtr): Added a new template to take 6 arguments.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        New variants of setupArgumentsWithExecState() and callOperation() to handle the new
        combinations of argument types and counts.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_push_with_scope):
        (JSC::JIT::emit_op_pop_scope):
        (JSC::JIT::emit_op_push_name_scope):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_push_with_scope):
        (JSC::JIT::emit_op_pop_scope):
        (JSC::JIT::emit_op_push_name_scope):
        Use the new slow paths.

        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        Updates to set the scope result using the scope register index.  Added operationPushCatchScope()
        and operationPushFunctionNameScope().

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        Updated the scope slow paths to use the scope register index in the instruction to read and
        write the register instead of using CallFrame::scope() and CallFrame::setScope().

2014-11-07  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Apply std::unique_ptr to slowPathCall()
        https://bugs.webkit.org/show_bug.cgi?id=138489

        Reviewed by Mark Lam.

        As a step to use std::unique_ptr<>, this patch makes slowPathCall() use std::unique_ptr<>,
        std::make_unique<>, and WTF::move(). 

        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::slowPathCall):
        (JSC::DFG::slowPathMove):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
        (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::arrayify):
        (JSC::DFG::SpeculativeJIT::compileIn):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::compile):

2014-11-06  Mark Lam  <mark.lam@apple.com>

        slow_path_get_direct_pname() needs to be hardened against a constant baseValue.
        <https://webkit.org/b/138476>

        Reviewed by Michael Saboff.

        slow_path_get_direct_pname() currently assumes that the baseValue is always a
        non-constant virtual register.  However, this is not always the case like in the
        following:

            function foo() {
                var o = { a:1 };
                for (var n in o)
                    0[n];
            }
            foo();

        This patch fixes it to also check for constant virtual register indexes.

        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2014-11-06  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r174985-174986): Site display disappears 
        https://bugs.webkit.org/show_bug.cgi?id=138082

        Reviewed by Geoffrey Garen.

        In support of the change in WebCore, this adds a new functor class to unwind to our
        caller's frame possibly skipping of intermediate C++ frames.

        * interpreter/StackVisitor.h:
        (JSC::CallerFunctor::CallerFunctor):
        (JSC::CallerFunctor::callerFrame):
        (JSC::CallerFunctor::operator()):

2014-11-06  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Use std::unique_ptr in CodeBlock class
        https://bugs.webkit.org/show_bug.cgi?id=138395

        Reviewed by Darin Adler.

        * bytecode/CodeBlock.h: Use std::unique_ptr.
        (JSC::CodeBlock::setJITCodeMap):
        * jit/CompactJITCodeMap.h: Use std::unique_ptr instead of OwnPtr|PassOwnPtr.
        (JSC::CompactJITCodeMap::CompactJITCodeMap):
        (JSC::CompactJITCodeMap::Encoder::finish): Use std::unique_ptr instead of PassOwnPtr.

2014-11-05  Mark Lam  <mark.lam@apple.com>

        PutById inline caches should have a store barrier when it triggers a structure transition.
        <https://webkit.org/b/138441>

        Reviewed by Geoffrey Garen.

        After r174025, we no longer insert DFG store barriers when the payload of a
        PutById operation is not a cell.  However, this can lead to a crash when we have
        PutById inline cache code transitioning the structure and re-allocating the
        butterfly of an old gen object.  The lack of a store barrier in that inline
        cache results in the old gen object not being noticed during an eden GC scan.
        As a result, its newly allocated butterfly will not be kept alive, which leads
        to a stale butterfly pointer and, eventually, a crash.

        It is also possible that the new structure can be collected by the eden GC if
        (at GC time):
        1. It is in the eden gen.
        2. The inline cache that installed it has been evicted.
        3. There are no live eden gen objects referring to it.

        The chances of this should be more rare than the butterfly re-allocation, but
        it is still possible.  Hence, the fix is to always add a store barrier if the
        inline caches performs a structure transition.

        * jit/Repatch.cpp:
        (JSC::emitPutTransitionStub):
        - Added store barrier code based on SpeculativeJIT::storeToWriteBarrierBuffer()'s
          implementation.

2014-11-05  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Use std::unique_ptr in JSClassRef and JSCallbackObject
        https://bugs.webkit.org/show_bug.cgi?id=138402

        Reviewed by Geoffrey Garen.

        * API/JSCallbackObject.h: Use std::unique_ptr instead of OwnPtr|PassOwnPtr.
        (JSC::JSCallbackObjectData::setPrivateProperty): ditto.
        * API/JSClassRef.cpp: ditto.
        * API/JSClassRef.h: ditto.

2014-11-05  Michael Saboff  <msaboff@apple.com>

        Disable flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=138381

        Reviewed by Mark Lam.

        Disabled these test for ARM64.  Will address the failures and then re-enable.

        * tests/stress/float32-repeat-out-of-bounds.js:
        * tests/stress/int8-repeat-out-of-bounds.js:

2014-11-05  Alexey Proskuryakov  <ap@apple.com>

        Incorrect sandbox_check in RemoteInspector.mm
        https://bugs.webkit.org/show_bug.cgi?id=138408

        Reviewed by Joseph Pecoraro.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::canAccessWebInspectorMachPort):

2014-11-03  Dean Jackson  <dino@apple.com>

        Add ENABLE_FILTERS_LEVEL_2 feature guard.
        https://bugs.webkit.org/show_bug.cgi?id=138362

        Reviewed by Tim Horton.

        Add a new feature define for Level 2 of CSS Filters.
        http://dev.w3.org/fxtf/filters-2/

        * Configurations/FeatureDefines.xcconfig:

2014-11-04  Mark Lam  <mark.lam@apple.com>

        Rename checkMarkByte() to jumpIfIsRememberedOrInEden().
        <https://webkit.org/b/138369>

        Reviewed by Geoffrey Garen.

        Write barriers are needed for GC Eden collections so that we can scan pointers
        pointing from old generation objects to eden generation objects.  The barrier
        currently checks the mark byte in a cell to see if we should skip adding the
        cell to the GC remembered set.  The addition should be skipped if:

        1. The cell is in the young generation.  It has no old to eden pointers by
           definition.
        2. The cell is already in the remembered set.  While it is ok to add the cell
           to the GC remembered set more than once, it would be redundant.  Hence,
           we skip this as an optimization to avoid doing unnecessary work.

        The barrier currently names this check as checkMarkByte().  We should rename it
        to jumpIfIsRememberedOrInEden() to be clearer about its intent.

        Similarly, Jump results of this check are currently named
        ownerNotMarkedOrAlreadyRemembered.  This can be misinterpreted as the owner is
        not marked or not already remembered.  We should rename it to
        ownerIsRememberedOrInEden which is clearer about the intent of the
        check.  What we are really checking for is that the cell is in the eden gen,
        which is implied by it being "not marked".

        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::osrWriteBarrier):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
        (JSC::AssemblyHelpers::checkMarkByte): Deleted.
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitWriteBarrier):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSCell.h:

2014-11-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Pause on exceptions should show the actual exception
        https://bugs.webkit.org/show_bug.cgi?id=63096

        Reviewed by Timothy Hatcher.

        * debugger/Debugger.h:
        Expose accessor for the pause reason to subclasses.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::type):
        New "error" subtype for error objects.

        * inspector/InjectedScriptSource.js:
        When an object is an error object, use toString to provide a richer description.

        * inspector/protocol/Runtime.json:
        Expose a new "error" subtype for Error types (TypeError, ReferenceError, EvalError, etc).

        * inspector/protocol/Debugger.json:
        Provide type checked objects for different Debugger.pause pause reasons.
        An exception provides the thrown object, but assert / CSP pauses provide
        a richer typed object as the auxiliary data.

        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::dispatchDidPause):
        When paused because of an exception, pass the exception on.

        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
        (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
        Provide richer data in pause events.

        * inspector/scripts/codegen/generate_backend_commands.py:
        (BackendCommandsGenerator.generate_domain.is_anonymous_enum_param):
        (BackendCommandsGenerator.generate_domain):
        * inspector/scripts/tests/expected/enum-values.json-result:
        Generate frontend enums for anonymous enum event parameters.

2014-11-04  Michael Saboff  <msaboff@apple.com>

        Disable flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
        https://bugs.webkit.org/show_bug.cgi?id=138381

        Reviewed by Mark Lam.

        Disabled these test for ARM64.  Will address the failures and then re-enable.

        * tests/stress/float32-repeat-out-of-bounds.js:
        * tests/stress/int8-repeat-out-of-bounds.js:

2014-11-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Enum value collisions between different generators
        https://bugs.webkit.org/show_bug.cgi?id=138343

        Reviewed by Brian Burg.

        Each generator was using its own filtered list of domains_to_generate
        to build the shared unique list of enum value encodings. This list
        was slightly different across different generators. Instead always
        use the list of all non-supplemental domains to generate the shared
        list of enum values.

        * inspector/scripts/codegen/generator.py:
        (Generator.non_supplemental_domains):
        (Generator.domains_to_generate):
        (Generator._traverse_and_assign_enum_values):
        * inspector/scripts/tests/enum-values.json: Added.
        * inspector/scripts/tests/expected/enum-values.json-result: Added.

2014-11-03  Akos Kiss  <akiss@inf.u-szeged.hu>

        Workaround for Cortex-A53 erratum 835769
        https://bugs.webkit.org/show_bug.cgi?id=138315

        Reviewed by Filip Pizlo.

        This patch introduces CMake variable and preprocessor macro
        WTF_CPU_ARM64_CORTEXA53 with the aim of enabling Cortex-A53-specific
        code paths, if set true. The patch also implements one case where such
        code paths are needed: the workaround for Cortex-A53 erratum 835769. If
        WTF_CPU_ARM64_CORTEXA53 is set then:
        - CMake checks whether the compiler already has support for a workaround
          and adds -mfix-cortex-a53-835769 to the compiler flags if so,
        - the ARM64 backend of offlineasm inserts a nop between memory and
          multiply-accumulate instructions, and
        - the ARM64 assembler also inserts a nop between memory and (64-bit) 
          multiply-accumulate instructions.

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Assembler::madd):
        Call nopCortexA53Fix835769() to insert a nop if CPU(ARM64_CORTEXA53) and
        if necessary.
        (JSC::ARM64Assembler::msub): Likewise.
        (JSC::ARM64Assembler::smaddl): Likewise.
        (JSC::ARM64Assembler::smsubl): Likewise.
        (JSC::ARM64Assembler::umaddl): Likewise.
        (JSC::ARM64Assembler::umsubl): Likewise.
        (JSC::ARM64Assembler::nopCortexA53Fix835769):
        Added. Insert a nop if the previously emitted instruction was a load, a
        store, or a prefetch, and if the current instruction is 64-bit.
        * offlineasm/arm64.rb:
        Add the arm64CortexA53Fix835769 phase and call it from
        getModifiedListARM64 to insert nopCortexA53Fix835769 between appropriate
        macro instructions. Also, lower nopCortexA53Fix835769 to nop if
        CPU(ARM64_CORTEXA53), to nothing otherwise.
        * offlineasm/instructions.rb:
        Define macro instruction nopFixCortexA53Err835769.

2014-11-03  Commit Queue  <commit-queue@webkit.org>

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

        broke some builds (Requested by msaboff on #webkit).

        Reverted changeset:

        "Update scope related slow path code to use scope register
        added to opcodes"
        https://bugs.webkit.org/show_bug.cgi?id=138254
        http://trac.webkit.org/changeset/175509

2014-11-03  Michael Saboff  <msaboff@apple.com>

        Update scope related slow path code to use scope register added to opcodes
        https://bugs.webkit.org/show_bug.cgi?id=138254

        Reviewed by Mark Lam.

        Updated slow paths for op_pop_scope, op_push_name_scope and op_push_with_scope.
        Added scope register index parameter to the front of the relevant argument lists of the
        slow functions.  In the case of op_push_name_scope for x86 (32 bit), there aren't enough
        registers to accomodate all the parameters.  Therefore, added two new JSVALUE32_64 slow
        paths called operationPushCatchScope() and operationPushFunctionNameScope() to eliminate
        the last "type" argument.
        

        * assembler/MacroAssemblerCodeRef.h:
        (JSC::FunctionPtr::FunctionPtr): Added a new template to take 6 arguments.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        New variants of setupArgumentsWithExecState() and callOperation() to handle the new
        combinations of argument types and counts.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_push_with_scope):
        (JSC::JIT::emit_op_pop_scope):
        (JSC::JIT::emit_op_push_name_scope):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_push_with_scope):
        (JSC::JIT::emit_op_pop_scope):
        (JSC::JIT::emit_op_push_name_scope):
        Use the new slow paths.

        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        Updates to set the scope result using the scope register index.  Added operationPushCatchScope()
        and operationPushFunctionNameScope().

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        Updated the scope slow paths to use the scope register index in the instruction to read and
        write the register instead of using CallFrame::scope() and CallFrame::setScope().

2014-11-03  Michael Saboff  <msaboff@apple.com>

        Add "get scope" byte code
        https://bugs.webkit.org/show_bug.cgi?id=138326

        Reviewed by Mark Lam.

        Added op_get_scope.  Added implementations for the LLInt and baseline JIT.
        Provided nop implementation for DFG and FTL.  The new byte code is emitted
        after op_enter for any function, program or eval.  It is expected that the
        DFG will be implemented such that unneeded op_get_scope would be eliminated
        during DFG compilation.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        Added new op_get_scope bytecode.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitGetScope):
        * bytecompiler/BytecodeGenerator.h:
        Emit new op_get_scope bytecode.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        Added framework for new op_get_scope bytecode.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_scope):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_scope):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        Implementation of op_get_scope bytecode.

2014-11-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Fix RWIProtocol 64-to-32 bit conversion warnings
        https://bugs.webkit.org/show_bug.cgi?id=138325

        Reviewed by Timothy Hatcher.

        * inspector/InspectorValues.h:
        Vector's length really is an unsigned, so a static_cast here is fine.

        * inspector/scripts/codegen/generate_objective_c.py:
        (ObjCGenerator.objc_type_for_raw_name):
        Use int instead of NSInteger for APIs that eventually map to
        InspectorObject's setInteger, which takes an int.

        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        Rebaselined results with the type change.

2014-11-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Show Selector's Specificity
        https://bugs.webkit.org/show_bug.cgi?id=138189

        Reviewed by Timothy Hatcher.

        * inspector/protocol/CSS.json:
        Create a new named type CSSSelector to include a selector's text and specificity.
        The specificity tuple is optional as it may soon be made dynamic in some cases.

2014-11-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ObjC Protocol Interfaces should throw exceptions for nil arguments
        https://bugs.webkit.org/show_bug.cgi?id=138221

        Reviewed by Timothy Hatcher.

        The RWIProtocol APIs will now raise exceptions when:

          - any properties are set on a type with a nil value or key (handled by RWIProtocolJSONObject)
          - required parameters in type constructors have nil value
          - required or optional command return parameters have nil values
          - required or optional event parameters have nil values

        The exceptions include the name of the field when possible.

        * inspector/scripts/codegen/generate_objective_c.py:
        (ObjCGenerator.is_type_objc_pointer_type):
        Provide a quick check to see if type would be a pointer or not
        in the ObjC API. Enums for example are not pointers in the API
        because we manage converting them to/from strings.

        * inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py:
        (ObjectiveCConfigurationImplementationGenerator._generate_success_block_for_command):
        * inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py:
        (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event):
        * inspector/scripts/codegen/generate_objective_c_types_implementation.py:
        (ObjectiveCTypesImplementationGenerator._generate_init_method_for_required_members):
        (ObjectiveCTypesImplementationGenerator._generate_setter_for_member):
        Throw exceptions when nil values are disallowed.

        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        Rebaseline tests which include the exception raise calls.

2014-11-03  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: ALTERNATE_DISPATCHERS Let the frontend know about extra agents
        https://bugs.webkit.org/show_bug.cgi?id=138236

        Reviewed by Brian Burg.

        Inform the frontend about any extra domains the backend may have
        above and beyond the default list of domains for the debuggable type.
        This approach means there is almost no cost to normal debugging.
        When a JSContext is debugged with extra agents, a message is sent
        to the frontend letting it know which domains to then activate,
        and perform any initialization work that may be required.

        * inspector/InspectorAgentBase.h:
        (Inspector::InspectorAgentBase::domainName):
        * inspector/InspectorAgentRegistry.cpp:
        (Inspector::InspectorAgentRegistry::appendExtraAgent):
        * inspector/InspectorAgentRegistry.h:
        * inspector/scripts/codegen/generator_templates.py:
        Provide a way to get a list of just the extra domains.
        To aggregate this list provide a different "append"
        specifically for extra agents.

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        When a frontend connects, inform it of the extra domains.

        * inspector/protocol/Inspector.json:
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::enable):
        (Inspector::InspectorAgent::activateExtraDomains):
        Send an event with the extra domains to activate.

2014-11-01  Michael Saboff  <msaboff@apple.com>

        Add scope operand to op_resolve_scope
        https://bugs.webkit.org/show_bug.cgi?id=138253

        Reviewed by Mark Lam.

        Added scope operand to op_resolve_scope.  Although the scope register is filled in with
        the ScopeChain register, this operand is not used in the processing of the bytecode.
        That will be addressed in a future patch.

        * bytecode/BytecodeList.json: Lengthened the three bytecodes.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Added code to dump the scope operand.

        (JSC::CodeBlock::CodeBlock): 
        (JSC::CodeBlock::finalizeUnconditionally):
        Updated the operand indecies for the processing of op_resolve_scope.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitResolveScope):
        (JSC::BytecodeGenerator::emitGetOwnScope):
        (JSC::BytecodeGenerator::emitReturn):
        Added scope register to these emit functions and the bytecodes they emit.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        Updated the operand indecies for the processing of op_resolve_scope.

2014-11-01  Carlos Garcia Campos  <cgarcia@igalia.com>

        REGRESSION(CMake): Make it possible to build without introspection
        https://bugs.webkit.org/show_bug.cgi?id=138006

        Reviewed by Philippe Normand.

        Do not install introspection files when introspection is disabled.

        * PlatformGTK.cmake:

2014-10-31  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Use std::unique_ptr for TypeCountSet
        https://bugs.webkit.org/show_bug.cgi?id=138242

        Reviewed by Andreas Kling.

        * heap/Heap.cpp:
        (JSC::Heap::protectedObjectTypeCounts):
        Use std::unique_ptr<> instead of PassOwnPtr|OwnPtr.
        (JSC::Heap::objectTypeCounts): ditto.
        * heap/Heap.h:

2014-10-31  Michael Saboff  <msaboff@apple.com>

        Add scope operand to op_push_with_scope, op_push_name_scope and op_pop_scope
        https://bugs.webkit.org/show_bug.cgi?id=138252

        Reviewed by Geoffrey Garen.

        Added scope operand to op_push_with_scope, op_push_name_scope and op_pop_scope.
        Although the scope register is filled in with the ScopeChain register for all 
        three bytecodes, this operand is not used in the processing of the bytecodes.
        That will be addressed in a future patch.

        * bytecode/BytecodeList.json: Lengthened the three bytecodes.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): Added code to dump the scope operand.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitPushWithScope):
        (JSC::BytecodeGenerator::emitPopScope):
        (JSC::BytecodeGenerator::emitComplexPopScopes):
        (JSC::BytecodeGenerator::emitPopScopes):
        (JSC::BytecodeGenerator::emitPushFunctionNameScope):
        (JSC::BytecodeGenerator::emitPushCatchScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::scopeRegister):
        Added scope register to these emit functions and the bytecodes they emit.
        New m_scopeRegister and accessor.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        Created a RegisterID for the ScopeChain register and used it to emit the updated
        bytecodes.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_push_with_scope):
        (JSC::JIT::emit_op_push_name_scope):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_push_with_scope):
        (JSC::JIT::emit_op_push_name_scope):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        Updated the operand indecies for the processing of the updated bytecodes.

2014-10-31  Andreas Kling  <akling@apple.com>

        Make writes to RegExpObject.lastIndex cacheable.
        <https://webkit.org/b/138255>

        Reviewed by Geoffrey Garen.

        We were neglecting to IC the puts to RegExpObject.lastIndex on Octane/regexp,
        and ended up spending 4.5% of a time profile in operationPutByIdNonStrict.

        ~3% progression on Octane/regexp.

        * runtime/RegExpObject.cpp:
        (JSC::regExpObjectSetLastIndexStrict):
        (JSC::regExpObjectSetLastIndexNonStrict):
        (JSC::RegExpObject::put):

2014-10-31  Chris Dumez  <cdumez@apple.com>

        Fix a couple of warnings in JSC reported by clang static analyzer
        https://bugs.webkit.org/show_bug.cgi?id=138240

        Reviewed by Geoffrey Garen.

        Fix a couple of warnings in JSC reported by clang static analyzer about
        value stored in variables never being read. This is addressed by
        reducing the scope of the variable or removing the variable entirely.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
        * runtime/VM.cpp:
        (JSC::VM::throwException):

2014-10-30  Dana Burkart  <dburkart@apple.com>

        <rdar://problem/18821260> Prepare for the mysterious future

        Reviewed by Lucas Forschler.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/Version.xcconfig:

2014-10-30  Saam Barati  <saambarati1@gmail.com>

        AST Nodes should keep track of their end offset
        https://bugs.webkit.org/show_bug.cgi?id=138143

        Reviewed by Filip Pizlo.

        AST nodes nodes now have an int property for their end text 
        offsets. This change lays some foundational work that will be 
        needed in profiling which basic blocks have executed.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::setEndOffset):
        * parser/Nodes.h:
        (JSC::Node::endOffset):
        (JSC::Node::setEndOffset):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseExpression):
        (JSC::Parser<LexerType>::parseProperty):
        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):

2014-10-30  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Generate ObjC inspector protocol types and alternate dispatcher interfaces
        https://bugs.webkit.org/show_bug.cgi?id=138048

        Reviewed by Brian Burg.

        Generate Objective-C interfaces for inspector protocol types, command, and event dispatchers.
        This is very much like the InspectorProtocolTypes, BackendDispatchers, and FrontendDispatchers,
        but with an ObjC spin on things.

        The private API that clients would use is all encapsulated in RWIProtocol.h. It includes the
        types interfaces, command handler protocol, and event dispatcher interface. Where possible the
        API uses real enums, which hides the raw protocol enum strings from clients.

        Inspector protocol types are, like InspectorProtocolObjects, built on top of an InspectorObject.
        This offers the flexibilty of adding arbitrary key/values using the RWIProtocolJSONObject
        interface, which may be required for certain protocol objects like "Network.Headers" which
        have no fields, but expect arbitrary properties to be added.

        Command handler protocols always have two callbacks. An error callback and a success callback.
        The signature is very much like BackendDispatchers. In parameters are passed directly to
        the selectors, and out parameters are defined by the success callback. It will be the client's
        responsibility to call either of these callbacks to complete handling of a request.

        Event dispatcher interfaces are straight forward, just packaging up the arguments and sending
        the message to the frontend.

        ObjC <-> Protocol conversion happens in each of the generated files. In type getters / setters,
        in commands parameters and event parameters. For this to work we generate conversion helpers
        for all enums, ObjC enum <-> protocol strings. For NSArray <-> InspectorArray there are some
        static helpers to do the conversions. We do lose some type safety in these conversions.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/scripts/codegen/__init__.py:
        * inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py:
        (AlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
        * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
        (BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector):
        (BackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
        (BackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
        * inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
        (BackendDispatcherImplementationGenerator._generate_handler_class_destructor_for_domain):
        (BackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
        * inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
        (FrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
        * inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
        (FrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
        * inspector/scripts/codegen/generate_objective_c.py: Added.
        (join_type_and_name):
        (strip_comment_markers):
        (remove_duplicate_from_str):
        (ObjCTypeCategory):
        (ObjCTypeCategory.category_of_type):
        (ObjCGenerator):
        (ObjCGenerator.identifier_to_objc_identifier):
        (ObjCGenerator.objc_identifier_to_identifier):
        (ObjCGenerator.should_generate_domain_types_filter):
        (ObjCGenerator.should_generate_domain_types_filter.should_generate_domain_types):
        (ObjCGenerator.should_generate_domain_command_handler_filter):
        (ObjCGenerator.should_generate_domain_command_handler_filter.should_generate_domain_command_handler):
        (ObjCGenerator.should_generate_domain_event_dispatcher_filter):
        (ObjCGenerator.should_generate_domain_event_dispatcher_filter.should_generate_domain_event_dispatcher):
        (ObjCGenerator.objc_name_for_type):
        (ObjCGenerator.objc_enum_name_for_anonymous_enum_declaration):
        (ObjCGenerator.objc_enum_name_for_anonymous_enum_member):
        (ObjCGenerator.objc_enum_name_for_anonymous_enum_parameter):
        (ObjCGenerator.objc_enum_name_for_non_anonymous_enum):
        (ObjCGenerator.variable_name_prefix_for_domain):
        (ObjCGenerator.objc_accessor_type_for_raw_name):
        (ObjCGenerator.objc_type_for_raw_name):
        (ObjCGenerator.objc_class_for_raw_name):
        (ObjCGenerator.protocol_type_for_raw_name):
        (ObjCGenerator.protocol_type_for_type):
        (ObjCGenerator.objc_class_for_type):
        (ObjCGenerator.objc_accessor_type_for_member):
        (ObjCGenerator.objc_accessor_type_for_member_internal):
        (ObjCGenerator.objc_type_for_member):
        (ObjCGenerator.objc_type_for_member_internal):
        (ObjCGenerator.objc_type_for_param):
        (ObjCGenerator.objc_type_for_param_internal):
        (ObjCGenerator.objc_protocol_export_expression_for_variable):
        (ObjCGenerator.objc_protocol_import_expression_for_member):
        (ObjCGenerator.objc_protocol_import_expression_for_parameter):
        (ObjCGenerator.objc_protocol_import_expression_for_variable):
        (ObjCGenerator.objc_to_protocol_expression_for_member):
        (ObjCGenerator.protocol_to_objc_expression_for_member):
        (ObjCGenerator.objc_setter_method_for_member):
        (ObjCGenerator.objc_setter_method_for_member_internal):
        (ObjCGenerator.objc_getter_method_for_member):
        (ObjCGenerator.objc_getter_method_for_member_internal):
        * inspector/scripts/codegen/generate_objective_c_backend_dispatcher_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
        (ObjectiveCBackendDispatcherHeaderGenerator):
        (ObjectiveCBackendDispatcherHeaderGenerator.output_filename):
        (ObjectiveCBackendDispatcherHeaderGenerator.domains_to_generate):
        (ObjectiveCBackendDispatcherHeaderGenerator.generate_output):
        (ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
        (ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations_for_domains):
        (ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
        (ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
        * inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py: Added.
        (ObjectiveCConfigurationImplementationGenerator):
        (ObjectiveCConfigurationImplementationGenerator.__init__):
        (ObjectiveCConfigurationImplementationGenerator.output_filename):
        (ObjectiveCConfigurationImplementationGenerator.domains_to_generate):
        (ObjectiveCConfigurationImplementationGenerator.generate_output):
        (ObjectiveCConfigurationImplementationGenerator._generate_handler_implementation_for_domain):
        (ObjectiveCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
        (ObjectiveCConfigurationImplementationGenerator._generate_success_block_for_command):
        (ObjectiveCConfigurationImplementationGenerator._generate_conversions_for_command):
        (ObjectiveCConfigurationImplementationGenerator._generate_invocation_for_command):
        * inspector/scripts/codegen/generate_objective_c_configuration_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
        (ObjectiveCConfigurationHeaderGenerator):
        (ObjectiveCConfigurationHeaderGenerator.output_filename):
        (ObjectiveCConfigurationHeaderGenerator.generate_output):
        (ObjectiveCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
        (ObjectiveCConfigurationHeaderGenerator._generate_properties_for_domain):
        * inspector/scripts/codegen/generate_objective_c_configuration_implementation.py: Added.
        (ObjectiveCBackendDispatcherImplementationGenerator):
        (ObjectiveCBackendDispatcherImplementationGenerator.__init__):
        (ObjectiveCBackendDispatcherImplementationGenerator.output_filename):
        (ObjectiveCBackendDispatcherImplementationGenerator.generate_output):
        (ObjectiveCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
        (ObjectiveCBackendDispatcherImplementationGenerator._generate_ivars):
        (ObjectiveCBackendDispatcherImplementationGenerator._generate_dealloc):
        (ObjectiveCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain):
        (ObjectiveCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain):
        * inspector/scripts/codegen/generate_objective_c_conversion_helpers.py: Added.
        (add_whitespace_separator):
        (ObjectiveCConversionHelpersGenerator):
        (ObjectiveCConversionHelpersGenerator.__init__):
        (ObjectiveCConversionHelpersGenerator.output_filename):
        (ObjectiveCConversionHelpersGenerator.domains_to_generate):
        (ObjectiveCConversionHelpersGenerator.generate_output):
        (ObjectiveCConversionHelpersGenerator._generate_enum_conversion_functions):
        (ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_declaration):
        (ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_member):
        (ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_parameter):
        (ObjectiveCConversionHelpersGenerator._generate_enum_objc_to_protocol_string):
        (ObjectiveCConversionHelpersGenerator._generate_enum_from_protocol_string):
        * inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py: Added.
        (ObjectiveCFrontendDispatcherImplementationGenerator):
        (ObjectiveCFrontendDispatcherImplementationGenerator.__init__):
        (ObjectiveCFrontendDispatcherImplementationGenerator.output_filename):
        (ObjectiveCFrontendDispatcherImplementationGenerator.domains_to_generate):
        (ObjectiveCFrontendDispatcherImplementationGenerator.generate_output):
        (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
        (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event):
        (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_signature):
        (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
        * inspector/scripts/codegen/generate_objective_c_header.py: Added.
        (add_whitespace_separator):
        (ObjectiveCHeaderGenerator):
        (ObjectiveCHeaderGenerator.__init__):
        (ObjectiveCHeaderGenerator.output_filename):
        (ObjectiveCHeaderGenerator.generate_output):
        (ObjectiveCHeaderGenerator._generate_forward_declarations):
        (ObjectiveCHeaderGenerator._generate_enums):
        (ObjectiveCHeaderGenerator._generate_types):
        (ObjectiveCHeaderGenerator._generate_anonymous_enum_for_declaration):
        (ObjectiveCHeaderGenerator._generate_anonymous_enum_for_member):
        (ObjectiveCHeaderGenerator._generate_anonymous_enum_for_parameter):
        (ObjectiveCHeaderGenerator._generate_enum):
        (ObjectiveCHeaderGenerator._generate_enum.NS_ENUM):
        (ObjectiveCHeaderGenerator._generate_type_interface):
        (ObjectiveCHeaderGenerator._generate_init_method_for_required_members):
        (ObjectiveCHeaderGenerator._generate_member_property):
        (ObjectiveCHeaderGenerator._generate_command_protocols):
        (ObjectiveCHeaderGenerator._generate_single_command_protocol):
        (ObjectiveCHeaderGenerator._callback_block_for_command):
        (ObjectiveCHeaderGenerator._generate_event_interfaces):
        (ObjectiveCHeaderGenerator._generate_single_event_interface):
        * inspector/scripts/codegen/generate_objective_c_internal_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
        (ObjectiveCTypesInternalHeaderGenerator):
        (ObjectiveCTypesInternalHeaderGenerator.output_filename):
        (ObjectiveCTypesInternalHeaderGenerator.generate_output):
        (ObjectiveCTypesInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
        * inspector/scripts/codegen/generate_objective_c_types_implementation.py: Added.
        (add_whitespace_separator):
        (ObjectiveCTypesImplementationGenerator):
        (ObjectiveCTypesImplementationGenerator.__init__):
        (ObjectiveCTypesImplementationGenerator.output_filename):
        (ObjectiveCTypesImplementationGenerator.domains_to_generate):
        (ObjectiveCTypesImplementationGenerator.generate_output):
        (ObjectiveCTypesImplementationGenerator.generate_type_implementations):
        (ObjectiveCTypesImplementationGenerator.generate_type_implementation):
        (ObjectiveCTypesImplementationGenerator._generate_init_method_for_required_members):
        (ObjectiveCTypesImplementationGenerator._generate_setter_for_member):
        (ObjectiveCTypesImplementationGenerator._generate_getter_for_member):
        * inspector/scripts/codegen/generate_protocol_types_header.py:
        (ProtocolTypesHeaderGenerator._generate_forward_declarations):
        (_generate_typedefs_for_domain):
        (_generate_builders_for_domain):
        * inspector/scripts/codegen/generator.py:
        (Generator.wrap_with_guard_for_domain):
        (Generator):
        (Generator.wrap_with_guard):
        * inspector/scripts/codegen/generator_templates.py:
        (AlternateInspector):
        (ObjCInspector):
        * inspector/scripts/codegen/models.py:
        (Framework.fromString):
        (Frameworks):
        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2014-10-30  Andreas Kling  <akling@apple.com>

        Unreviewed assertion fix.

        RegExpCachedResult::m_reified is now the dedicated member that knows whether
        the result was reified into an array or not. Check that instead of m_result
        which is now single-purpose.

        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::setInput):

2014-10-29  Andreas Kling  <akling@apple.com>

        Use plain JSArray for RegExp matches instead of a lazily populated custom object.
        <https://webkit.org/b/138191>

        Reviewed by Geoffrey Garen.

        We're already offering two RegExp matching APIs, one that collects subpattern
        matches (exec), and one that simply tests for a match (test).
        Given that, it was pretty overkill to lazily populate the resulting array of
        matches, since the user could simply use test() if they didn't need them.

        This allows the JIT to generate better code for RegExp match arrays, and also
        enables some fast paths in the JSC runtime that check if an object isJSArray().

        Looks like ~1.5% improvement on Octane/regexp according to run-jsc-benchmarks.

        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * runtime/JSArray.h:
        (JSC::createArrayButterflyWithExactLength): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/RegExpCachedResult.cpp:
        (JSC::RegExpCachedResult::visitChildren):
        (JSC::RegExpCachedResult::lastResult):
        (JSC::RegExpCachedResult::leftContext):
        (JSC::RegExpCachedResult::rightContext):
        * runtime/RegExpCachedResult.h:
        (JSC::RegExpCachedResult::RegExpCachedResult):
        (JSC::RegExpCachedResult::record):
        (JSC::RegExpCachedResult::input):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::getBackref):
        (JSC::RegExpConstructor::getLastParen):
        (JSC::RegExpConstructor::getLeftContext):
        (JSC::RegExpConstructor::getRightContext):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::createRegExpMatchesArray):
        (JSC::RegExpMatchesArray::RegExpMatchesArray): Deleted.
        (JSC::RegExpMatchesArray::create): Deleted.
        (JSC::RegExpMatchesArray::finishCreation): Deleted.
        (JSC::RegExpMatchesArray::visitChildren): Deleted.
        (JSC::RegExpMatchesArray::reifyAllProperties): Deleted.
        (JSC::RegExpMatchesArray::reifyMatchProperty): Deleted.
        (JSC::RegExpMatchesArray::leftContext): Deleted.
        (JSC::RegExpMatchesArray::rightContext): Deleted.
        * runtime/RegExpMatchesArray.h:
        (JSC::RegExpMatchesArray::createStructure): Deleted.
        (JSC::RegExpMatchesArray::reifyAllPropertiesIfNecessary): Deleted.
        (JSC::RegExpMatchesArray::reifyMatchPropertyIfNecessary): Deleted.
        (JSC::RegExpMatchesArray::getOwnPropertySlot): Deleted.
        (JSC::RegExpMatchesArray::getOwnPropertySlotByIndex): Deleted.
        (JSC::RegExpMatchesArray::put): Deleted.
        (JSC::RegExpMatchesArray::putByIndex): Deleted.
        (JSC::RegExpMatchesArray::deleteProperty): Deleted.
        (JSC::RegExpMatchesArray::deletePropertyByIndex): Deleted.
        (JSC::RegExpMatchesArray::getOwnPropertyNames): Deleted.
        (JSC::RegExpMatchesArray::defineOwnProperty): Deleted.
        (JSC::isRegExpMatchesArray): Deleted.
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::exec):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncMatch):

2014-10-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Fix Type Dependency Issues
        https://bugs.webkit.org/show_bug.cgi?id=125664

        Reviewed by Brian Burg.

        Now that all JSON protocol files are processed together again
        in r174892, we can remove the duplicated types which were only
        needed when the domains were split.

        * inspector/protocol/Console.json:
        * inspector/protocol/Runtime.json:

2014-10-28  Commit Queue  <commit-queue@webkit.org>

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

        Appears to be failing some JS tests (Requested by mlam_ on
        #webkit).

        Reverted changeset:

        "Holes are not copied properly when Arrays change shape to
        ArrayStorage type."
        https://bugs.webkit.org/show_bug.cgi?id=138118
        http://trac.webkit.org/changeset/175249

2014-10-27  Mark Lam  <mark.lam@apple.com>

        Holes are not copied properly when Arrays change shape to ArrayStorage type.
        <https://webkit.org/b/138118>

        Reviewed by Mark Hahnenberg.

        When we convert non-ArrayStorage typed arrays into ArrayStorage typed arrays,
        we skipped the holes.  As a result, the slots in the ArrayStorage vector that
        corresponds to those holes are uninitialize.  This is now fixed.

        * runtime/JSObject.cpp:
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):

2014-10-27  Mark Lam  <mark.lam@apple.com>

        Crash when attempting to perform array iteration on a non-array with numeric keys not initialized.
        <https://webkit.org/b/137814>

        Reviewed by Geoffrey Garen.

        The arrayIteratorNextThunkGenerator() thunk was not checking for the case where
        the butterfly may be NULL.  This was the source of the crash, and is now fixed.

        In addition, it is also not checking for the case where a property named "length"
        may have been set on the iterated object.  The thunk only checks the butterfly's
        publicLength for its iteration operation.  Array objects will work fine with this
        because it always updates its butterfly's publicLength when its length changes.
        In the case of iterable non-Array objects, the "length" property will require a
        look up outside of the scope of this thunk.  The fix is simply to limit the fast
        case checks in this thunk to Array objects.

        * jit/ThunkGenerators.cpp:
        (JSC::arrayIteratorNextThunkGenerator):

2014-10-27  Mark Lam  <mark.lam@apple.com>

        Simplified some JSObject methods for converting arrays to ArrayStorage shape.
        <https://webkit.org/b/138119>

        Reviewed by Filip Pizlo.

        Currently, for each Undecided, Int32, Double, and Contiguous array shapes,
        there are 3 JSObject methods to convert them to ArrayStorage shape:
            ArrayStorage* convert<shape>ToArrayStorage(VM&, NonPropertyTransition, unsigned neededLength);
            ArrayStorage* convert<shape>ToArrayStorage(VM&, NonPropertyTransition);
            ArrayStorage* convert<shape>ToArrayStorage(VM&);

        However, the neededLength that is passed is always m_butterfly->vectorLength().
        Hence, the method that takes a neededLength is really not needed.  This patch
        removes this unneeded verbosity.

        * runtime/JSObject.cpp:
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToArrayStorage):
        - Also reordered the placement of the DeferGC statement so this Int32 function
          will look more similar to the others.
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        * runtime/JSObject.h:

2014-10-25  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: timelines should not count time elapsed while paused in the debugger
        https://bugs.webkit.org/show_bug.cgi?id=136351

        Unreviewed, follow-up fix after r175203. The debugger agent should not assume
        that the inspector environment's stopwatch has already been started.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didPause): Check if the stopwatch isActive() before stopping.

2014-10-18  Brian J. Burg  <burg@cs.washington.edu>

        Web Inspector: timelines should not count time elapsed while paused in the debugger
        https://bugs.webkit.org/show_bug.cgi?id=136351

        Reviewed by Timothy Hatcher.

        Now that we have a stopwatch to provide pause-aware timing data, we can remove the
        profiler's handling of debugger pause/continue callbacks. The debugger agent accounts
        for suspended execution by pausing and resuming the stopwatch.

        * API/JSProfilerPrivate.cpp:
        (JSStartProfiling): Use a fresh stopwatch when profiling from the JSC API.
        * inspector/InspectorEnvironment.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::executionStopwatch):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::handlePause):
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didPause):
        (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
        (Inspector::InspectorDebuggerAgent::didContinue):
        * inspector/agents/InspectorDebuggerAgent.h:
        * profiler/LegacyProfiler.cpp:
        (JSC::LegacyProfiler::profiler): Use nullptr.
        (JSC::LegacyProfiler::startProfiling): Hand off a stopwatch to the profile generator.
        (JSC::LegacyProfiler::stopProfiling): Use nullptr.
        (JSC::LegacyProfiler::didPause): Deleted.
        (JSC::LegacyProfiler::didContinue): Deleted.
        * profiler/LegacyProfiler.h:
        * profiler/Profile.cpp: The root node should always have a start time of 0.0.
        (JSC::Profile::Profile):
        * profiler/ProfileGenerator.cpp: Remove debugger pause/continue callbacks and the
        timestamp member that was used to track time elapsed by the debugger. Just use the
        stopwatch's elapsed times to generate start/elapsed times for function calls.

        (JSC::ProfileGenerator::create):
        (JSC::ProfileGenerator::ProfileGenerator):
        (JSC::AddParentForConsoleStartFunctor::operator()): The parent node of |console.profile|
        should have a start time of 0.0, since it represents the starting node of profiling.

        (JSC::ProfileGenerator::beginCallEntry):
        (JSC::ProfileGenerator::endCallEntry):
        (JSC::ProfileGenerator::didPause): Deleted.
        (JSC::ProfileGenerator::didContinue): Deleted.
        * profiler/ProfileGenerator.h:

2014-10-24  Mark Lam  <mark.lam@apple.com>

        Simplified IndexingType's hasAnyArrayStorage().
        <https://webkit.org/b/138051>

        Reviewed by Michael Saboff.

        IndexingType's hasAnyArrayStorage() currently does subtraction of ArrayStorageShape
        with the purpose of making non-ArrayStorage types underflow (with that subtraction)
        and have a result that exceeds SlowPutArrayStorageShape.  What it is doing is
        basically checking for a shape value that is greater equal to ArrayStorageShape.
        We can just simplify the code as such.

        Also added a comment to describe the structure of the bits in IndexingType.

        * runtime/IndexingType.h:
        (JSC::hasAnyArrayStorage):

2014-10-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Provide a way to have alternate inspector agents
        https://bugs.webkit.org/show_bug.cgi?id=137901

        Reviewed by Brian Burg.

        Provide a way to use alternate inspector agents debugging a JSContext.
        Expose a very slim private API that a client could use to know when
        an inspector has connected/disconnected, and a way to register its
        augmentative agents.

        * Configurations/FeatureDefines.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        New feature guard. New files.

        * API/JSContextRef.cpp:
        (JSGlobalContextGetAugmentableInspectorController):
        * API/JSContextRefInspectorSupport.h: Added.
        Access to the private interface from a JSContext.

        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/augmentable/AugmentableInspectorController.h: Added.
        (Inspector::AugmentableInspectorController::~AugmentableInspectorController):
        (Inspector::AugmentableInspectorController::connected):
        * inspector/augmentable/AugmentableInspectorControllerClient.h: Added.
        (Inspector::AugmentableInspectorControllerClient::~AugmentableInspectorControllerClient):
        * inspector/augmentable/AlternateDispatchableAgent.h: Added.
        (Inspector::AlternateDispatchableAgent::AlternateDispatchableAgent):
        Provide the private APIs a client could use to add alternate agents using alternate backend dispatchers.

        * inspector/scripts/codegen/__init__.py:
        * inspector/scripts/generate-inspector-protocol-bindings.py:
        (generate_from_specification):
        New includes, and use the new generator.
        
        * inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py: Added.
        (AlternateBackendDispatcherHeaderGenerator):
        (AlternateBackendDispatcherHeaderGenerator.__init__):
        (AlternateBackendDispatcherHeaderGenerator.output_filename):
        (AlternateBackendDispatcherHeaderGenerator.generate_output):
        (AlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
        (AlternateBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
        Generate the abstract AlternateInspectorBackendDispatcher interfaces.

        * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
        (BackendDispatcherHeaderGenerator.generate_output):
        (BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains):
        (BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector):
        Forward declare alternate dispatchers, and allow setting an alternate dispatcher on a domain dispatcher.

        * inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
        (BackendDispatcherImplementationGenerator.generate_output):
        (BackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        Check for and dispatch on an AlternateInspectorBackendDispatcher if there is one for this domain.

        * inspector/scripts/codegen/generator_templates.py:
        (AlternateInspectorBackendDispatcher):
        (AlternateInspector):
        Template boilerplate for prelude and postlude.

        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        Rebaseline tests.

2014-10-23  Michael Saboff  <msaboff@apple.com>

        offsets.rb:183:in `buildOffsetsMap': unhandled exception - is offlineasm dependency tracking broken? (132668)
        https://bugs.webkit.org/show_bug.cgi?id=138017

        Reviewed by Mark Lam.

        Removed from the nput file $(SRCROOT)/llint/LowLevelAssembler.asm and output file
        $(BUILT_PRODUCTS_DIR)/LLIntOffsets/LLIntDesiredOffsets.h from the Generate Derived Sources
        build phase in the LLInt Offset target.  There is no need for Xcode to do any dependency
        checking with these files as the ruby script offlineasm/generate_offset_extractor.rb will
        do that for us.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2014-10-23  Michael Saboff  <msaboff@apple.com>

        Change CallFrame::lexicalGlobalObject() to use Callee instead of JSScope
        https://bugs.webkit.org/show_bug.cgi?id=136901

        Reviewed by Mark Lam.

        Implement ExecState::lexicalGlobalObject() using Callee.
        
        * runtime/JSScope.h:
        (JSC::ExecState::lexicalGlobalObject):

2014-10-22  Milan Crha  <mcrha@redhat.com>

        Prefix isnan() with std::.
        <https://webkit.org/b/137966>.

        Reviewed by Carlos Garcia Campos.

        * profiler/ProfileNode.h:
        (JSC::ProfileNode::Call::setStartTime):
        (JSC::ProfileNode::Call::setElapsedTime):

2014-10-22  Mark Lam  <mark.lam@apple.com>

        Refactoring to simplify some code in DatePrototype.cpp.
        <https://webkit.org/b/137997>

        Reviewed by Filip Pizlo.

        A bunch of functions in DatePrototype.cpp have the pattern of loading a
        constant into a local variable only to pass it to a callee function
        immediately after.  There is no other use for that variable.  This adds
        additional verbosity with no added benefit.

        This patch refactors those functions to just pass the constant arg directly.

        * runtime/DatePrototype.cpp:
        (JSC::dateProtoFuncSetMilliSeconds):
        (JSC::dateProtoFuncSetUTCMilliseconds):
        (JSC::dateProtoFuncSetSeconds):
        (JSC::dateProtoFuncSetUTCSeconds):
        (JSC::dateProtoFuncSetMinutes):
        (JSC::dateProtoFuncSetUTCMinutes):
        (JSC::dateProtoFuncSetHours):
        (JSC::dateProtoFuncSetUTCHours):
        (JSC::dateProtoFuncSetDate):
        (JSC::dateProtoFuncSetUTCDate):
        (JSC::dateProtoFuncSetMonth):
        (JSC::dateProtoFuncSetUTCMonth):
        (JSC::dateProtoFuncSetFullYear):
        (JSC::dateProtoFuncSetUTCFullYear):

2014-10-22  Byungseon Shin  <sun.shin@lge.com>

        String(new Date(Mar 30 2014 01:00:00)) is wrong in CET
        https://bugs.webkit.org/show_bug.cgi?id=130967

        Reviewed by Mark Lam.

        By definition of calculateLocalTimeOffset, input time should be UTC time.
        But there are many cases when input time is based on local time.
        So, it gives erroneous results while calculating offset of DST boundary time.
        By adding a argument to distinguish UTC and local time, we can get the correct offset.

        * JavaScriptCore.order:
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        (JSC::callDate):
        (JSC::dateUTC):
        * runtime/DateInstance.cpp:
        (JSC::DateInstance::calculateGregorianDateTime):
        (JSC::DateInstance::calculateGregorianDateTimeUTC):
        * runtime/DatePrototype.cpp:
        (JSC::setNewValueFromTimeArgs):
        (JSC::setNewValueFromDateArgs):
        (JSC::dateProtoFuncSetMilliSeconds):
        (JSC::dateProtoFuncSetUTCMilliseconds):
        (JSC::dateProtoFuncSetSeconds):
        (JSC::dateProtoFuncSetUTCSeconds):
        (JSC::dateProtoFuncSetMinutes):
        (JSC::dateProtoFuncSetUTCMinutes):
        (JSC::dateProtoFuncSetHours):
        (JSC::dateProtoFuncSetUTCHours):
        (JSC::dateProtoFuncSetDate):
        (JSC::dateProtoFuncSetUTCDate):
        (JSC::dateProtoFuncSetMonth):
        (JSC::dateProtoFuncSetUTCMonth):
        (JSC::dateProtoFuncSetFullYear):
        (JSC::dateProtoFuncSetUTCFullYear):
        (JSC::dateProtoFuncSetYear):
        * runtime/JSDateMath.cpp:
        (JSC::localTimeOffset):
        (JSC::gregorianDateTimeToMS):
        (JSC::msToGregorianDateTime):
        (JSC::parseDateFromNullTerminatedCharacters):
        * runtime/JSDateMath.h:
        * runtime/VM.h:
        (JSC::LocalTimeOffsetCache::LocalTimeOffsetCache):
        (JSC::LocalTimeOffsetCache::reset):
        Passing TimeType argument to distingush UTC time and local time.

2014-10-22  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Fix generator importing of protocol type "any", treat as value
        https://bugs.webkit.org/show_bug.cgi?id=137931

        Reviewed by Timothy Hatcher.

        Treat incoming "any" objects as InspectorValues, which can be any type.
        Add the necessary boilerplate to import.

        * inspector/InspectorBackendDispatcher.cpp:
        (Inspector::AsMethodBridges::asValue):
        (Inspector::InspectorBackendDispatcher::getValue):
        * inspector/InspectorBackendDispatcher.h:
        * inspector/scripts/codegen/generator.py:
        (Generator.keyed_get_method_for_type):
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:

2014-10-22  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r174996): Broke C_LOOP
        https://bugs.webkit.org/show_bug.cgi?id=137971

        Reviewed by Mark Lam.

        Removed incorrect move to cfr (CallFrameRegister) before we make the call to a native function.
        After r174996, the source register for the move contained garbage causing the crash.  The move
        to cfr before making the call to the native function is wrong and should have been removed
        some time ago.  This brings the ARM64 / C_LOOP code path inline with the other CPU paths.
        Tested on ARM64 as well as a C_LOOP build.

        * llint/LowLevelInterpreter64.asm:

2014-10-21  Mark Lam  <mark.lam@apple.com>

        Remove erroneous canUseJIT() in the intrinsics version of JITThunks::hostFunctionStub().
        <https://webkit.org/b/137937>

        Reviewed by Michael Saboff.

        This version of JITThunks::hostFunctionStub() can only be called from the intrinsics
        version of VM::getHostFunction() which asserts canUseJIT().  Hence, we can eliminate
        the canUseJIT() check in JITThunks::hostFunctionStub().  We don't handle the
        !canUseJIT() case properly there anyway.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):

2014-10-21  Michael Saboff  <msaboff@apple.com>

        Add operator==(PropertyName, const char*)
        https://bugs.webkit.org/show_bug.cgi?id=137925

        Reviewed by Mark Lam.

        * runtime/PropertyName.h:
        (JSC::operator==): Added to simplify comparison with string literals.


2014-10-21  Michael Saboff  <msaboff@apple.com>

        Change native call frames to use the scope from their Callee instead of their caller's scope
        https://bugs.webkit.org/show_bug.cgi?id=137907

        Reviewed by Mark Lam.

        Changed setting of scope for native CallFrames to use the scope associated with the
        Callee instead of the caller's scope.

        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2014-10-21  Tibor Meszaros  <tmeszaros.u-szeged@partner.samsung.com>

        Add missing ENABLE(FTL_NATIVE_CALL_INLINING) guard to BundlePath.cpp after r174940
        https://bugs.webkit.org/show_bug.cgi?id=137924

        Reviewed by Csaba Osztrogonác.

        * runtime/BundlePath.cpp:

2014-10-21  Dániel Bátyai  <dbatyai.u-szeged@partner.samsung.com>

        Fix FTL Native Inlining for EFL
        https://bugs.webkit.org/show_bug.cgi?id=137774

        Reviewed by Michael Saboff.

        Added required functionality for Native Inlining to EFL, and fixed a bug/typo in the original code,
        which caused incorrect memory allocation.

        * CMakeLists.txt:
        * create-llvm-ir-from-source-file.py: Added.
        * create-symbol-table-index.py: Added.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::getModuleByPathForSymbol):
        (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
        (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
        * runtime/BundlePath.cpp: Added.
        (JSC::bundlePath):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):
        * runtime/MathObject.cpp:

2014-10-21  Milan Crha  <mcrha@redhat.com>

        Move JSC::MacroAssemblerX86Common::s_sse2CheckState definition to MacroAssemblerX86Common.cpp.
        <https://webkit.org/b/137807>

        Reviewed by Csaba Osztrogonác.

        * assembler/MacroAssemblerX86Common.cpp:
        * jit/JIT.cpp:

2014-10-20  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed add back copyright line that was accidentally removed.

        * inspector/scripts/codegen/generator_templates.py:
        (GeneratorTemplates):

2014-10-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: InspectorBackendCommands should include when to activate particular domains
        https://bugs.webkit.org/show_bug.cgi?id=137753

        Reviewed by Timothy Hatcher.

        Add an availability property to domains that only activate for
        particular debuggable types. If missing, the domain is always
        activated. Otherwise it must be a debuggable type string.
        When a frontend is opened for that debuggable type, the domain
        will be activated.

        * inspector/scripts/codegen/models.py:
        (Protocol.parse_domain):
        (Domain.__init__):
        (Domains):
        Parse and validate the Domain's "availability" property.

        * inspector/scripts/codegen/generate_backend_commands.py:
        (BackendCommandsGenerator.generate_domain):
        Emit InspectorBackend.activateDomain with debuggable type filter.

        * inspector/protocol/ApplicationCache.json:
        * inspector/protocol/CSS.json:
        * inspector/protocol/DOM.json:
        * inspector/protocol/DOMDebugger.json:
        * inspector/protocol/DOMStorage.json:
        * inspector/protocol/Database.json:
        * inspector/protocol/IndexedDB.json:
        * inspector/protocol/LayerTree.json:
        * inspector/protocol/Network.json:
        * inspector/protocol/Page.json:
        * inspector/protocol/Replay.json:
        * inspector/protocol/Timeline.json:
        * inspector/protocol/Worker.json:
        These domains only activate for Web debuggables.

        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        Update existing tests that now have activate output.

        * inspector/scripts/tests/expected/fail-on-domain-availability.json-error: Added.
        * inspector/scripts/tests/fail-on-domain-availability.json: Added.
        Add a test for "availability" validation.

2014-10-20  Joseph Pecoraro  <pecoraro@apple.com>

        [Win] Build fix for generated inspector files.

        Rubberstamped by Brent Fulgham.

        * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
        (BackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
        * inspector/scripts/codegen/generator_templates.py:
        (GeneratorTemplates):

2014-10-20  Brent Fulgham  <bfulgham@apple.com>

        [Win] Unreviewed build fix.

        We need to (1) pass the 'windows' argument to our script for checking feature definitions,
        and (2) we must use Cwd::realpath on our path input arguments to avoid Cygwin and Windows
        getting confused about path separators versus escape characters.


        * JavaScriptCore.vcxproj/build-generated-files.pl:

2014-10-20  Mark Lam  <mark.lam@apple.com>

        [Follow up] Web Process crash when starting the web inspector after r174025.
        <https://webkit.org/b/137340>

        Reviewed by Geoffrey Garen.

        Applied Geoff's feedback to clean up some code for better clarity after
        r174856.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::insertCheck):
        * dfg/DFGInsertionSet.h:
        (JSC::DFG::InsertionSet::insertOutOfOrder):

2014-10-20  Mark Lam  <mark.lam@apple.com>

        Factor out JITCode::typeName() for debugging use.
        <https://webkit.org/b/137888>

        Reviewed by Geoffrey Garen.

        JITCode's printInternal() currently decodes the JITType into a string and
        prints it.  This change factors out the part that decodes the JITType into
        JITCode::typeName() so that we can call it from lldb while debugging to
        quickly decode a JITType value.

        * jit/JITCode.cpp:
        (JSC::JITCode::typeName):
        (WTF::printInternal):
        * jit/JITCode.h:

2014-10-20  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed Windows Build Fix #2 after r174892.

        * JavaScriptCore.vcxproj/build-generated-files.pl:
        Define FEATURE_DEFINES for JavaScriptCore's DerivedSources.make.
        This uses the same technique as WebCore.

2014-10-20  Mark Lam  <mark.lam@apple.com>

        Fix placement of a few items in vcxproj ItemGroups.
        <https://webkit.org/b/137886>

        Reviewed by Geoffrey Garen.

        https://webkit.org/b/137873 is likely a cut-and-paste error that manifested
        because we had ClCompile and ClInclude entries mixed up in the wrong ItemGroups.
        We should fix these so that ClCompile entries are in the ClCompile ItemGroup,
        and ClInclude entries in the ClInclude ItemGroup.  This will help reduce the
        chance of future cut-and-paste errors of this nature.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2014-10-20  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed Windows Build Fix after r174892.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        Update file name to the new generated file name.

2014-10-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Rename generated Inspector.json to CombinedDomains.json to prevent name collisions
        https://bugs.webkit.org/show_bug.cgi?id=137825

        Reviewed by Timothy Hatcher.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/copy-files.cmd:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/protocol/Inspector.json: Renamed from Source/JavaScriptCore/inspector/protocol/InspectorDomain.json.

2014-10-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Generate all Inspector domains together in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=137748

        Reviewed by Brian Burg.

        * inspector/protocol/ApplicationCache.json: Renamed from Source/WebCore/inspector/protocol/ApplicationCache.json.
        * inspector/protocol/CSS.json: Renamed from Source/WebCore/inspector/protocol/CSS.json.
        * inspector/protocol/DOM.json: Renamed from Source/WebCore/inspector/protocol/DOM.json.
        * inspector/protocol/DOMDebugger.json: Renamed from Source/WebCore/inspector/protocol/DOMDebugger.json.
        * inspector/protocol/DOMStorage.json: Renamed from Source/WebCore/inspector/protocol/DOMStorage.json.
        * inspector/protocol/Database.json: Renamed from Source/WebCore/inspector/protocol/Database.json.
        * inspector/protocol/IndexedDB.json: Renamed from Source/WebCore/inspector/protocol/IndexedDB.json.
        * inspector/protocol/LayerTree.json: Renamed from Source/WebCore/inspector/protocol/LayerTree.json.
        * inspector/protocol/Network.json: Renamed from Source/WebCore/inspector/protocol/Network.json.
        * inspector/protocol/Page.json: Renamed from Source/WebCore/inspector/protocol/Page.json.
        * inspector/protocol/Replay.json: Renamed from Source/WebCore/inspector/protocol/Replay.json.
        * inspector/protocol/Timeline.json: Renamed from Source/WebCore/inspector/protocol/Timeline.json.
        * inspector/protocol/Worker.json: Renamed from Source/WebCore/inspector/protocol/Worker.json.
        Move all protocol files into this directory.

        * inspector/InspectorProtocolTypesBase.h: Renamed from Source/JavaScriptCore/inspector/InspectorProtocolTypes.h.
        Renamed the base types file to not clash with the generated types file.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.vcxproj/copy-files.cmd:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Update build phases for new JSON files and new filenames.

        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
        Updated names of things now that prefixes are no longer needed.

        * inspector/ConsoleMessage.h:
        * inspector/ContentSearchUtilities.cpp:
        * inspector/ContentSearchUtilities.h:
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptBase.h:
        * inspector/ScriptCallFrame.h:
        * inspector/ScriptCallStack.h:
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::breakpointActionTypeForString):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.h:
        * runtime/TypeProfiler.cpp:
        * runtime/TypeSet.cpp:
        Update includes and update a few function names that are generated.

        * inspector/scripts/codegen/generate_protocol_types_header.py:
        (ProtocolTypesHeaderGenerator.output_filename):
        (ProtocolTypesHeaderGenerator.generate_output):
        Include an export macro for type string constants defined in the implementation file.

        * inspector/scripts/codegen/generate_backend_commands.py:
        (BackendCommandsGenerator.output_filename):
        * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
        (BackendDispatcherHeaderGenerator.output_filename):
        (BackendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
        (BackendDispatcherImplementationGenerator.output_filename):
        (BackendDispatcherImplementationGenerator.generate_output):
        (BackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
        (BackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
        * inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
        (FrontendDispatcherHeaderGenerator.output_filename):
        (FrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
        (FrontendDispatcherImplementationGenerator.output_filename):
        (FrontendDispatcherImplementationGenerator.generate_output):
        (FrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        (_generate_class_for_object_declaration):
        (_generate_builder_setter_for_member):
        (_generate_unchecked_setter_for_member):
        * inspector/scripts/codegen/generate_protocol_types_implementation.py:
        (ProtocolTypesImplementationGenerator.output_filename):
        (ProtocolTypesImplementationGenerator.generate_output):
        (ProtocolTypesImplementationGenerator._generate_enum_mapping):
        * inspector/scripts/codegen/models.py:
        (Framework.fromString):
        (Frameworks):
        * inspector/scripts/generate-inspector-protocol-bindings.py:
        Simplify generator now that prefixes are no longer needed. This updates
        filenames, includes, and the list of supported directories.

2014-10-20  Csaba Osztrogonác  <ossy@webkit.org>

        Remove obsolete comments after r99798
        https://bugs.webkit.org/show_bug.cgi?id=137871

        Reviewed by Darin Adler.

        r99798 removed the comment in MacroAssemblerARMv7::supportsFloatingPointTruncate(),
        so we should remove the stale references to this removed comment.

        * assembler/MacroAssemblerX86.h:
        * assembler/MacroAssemblerX86_64.h:

2014-10-20  Csaba Osztrogonác  <ossy@webkit.org>

        MacroAssemblerX86Common.cpp should be built on Windows too
        https://bugs.webkit.org/show_bug.cgi?id=137873

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2014-10-20  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Remove duplicated source files
        https://bugs.webkit.org/show_bug.cgi?id=137875

        Reviewed by Gyuyoung Kim.

        * CMakeLists.txt:

2014-10-18  Brian J. Burg  <burg@cs.washington.edu>

        Web Replay: code generator shouldn't complain about enums without a storage type if they are in an enclosing scope
        https://bugs.webkit.org/show_bug.cgi?id=137084

        Reviewed by Joseph Pecoraro.

        In order to generate encode/decode method declarations without pulling in lots of headers,
        the generator must forward declare enums (for enum classes or enums with explicit sizes).

        Change the generator to not require an explicit size if an enum is declared inside a struct
        or class definition. In that case, it must pull in headers since scoped enums can't be
        forward declared.

        This patch also fixes some chained if-statements that should be if-else statements.

        Test: updated replay/scripts/tests/generate-enum-encoding-helpers.json to cover the new case.

        * replay/scripts/CodeGeneratorReplayInputs.py:
        (InputsModel.parse_type_with_framework_name.is):
        (InputsModel.parse_type_with_framework_name.is.must):
        (Generator.generate_enum_trait_implementation):
        (InputsModel.parse_type_with_framework_name): Deleted.
        * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
        * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error:
        * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
        (JSC::EncodingTraits<WebCore::MouseButton>::decodeValue):
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
        (JSC::EncodingTraits<WebCore::MouseButton>::decodeValue):
        (JSC::EncodingTraits<WebCore::PlatformEvent::Type>::encodeValue):
        (JSC::EncodingTraits<WebCore::PlatformEvent::Type>::decodeValue):
        * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
        * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
        (JSC::EncodingTraits<WebCore::FormData1::Type>::decodeValue):
        (JSC::EncodingTraits<PlatformEvent1::Type>::decodeValue):
        * replay/scripts/tests/generate-enum-encoding-helpers.json: Added a new input to cover this case.

2014-10-17  Mark Lam  <mark.lam@apple.com>

        Web Process crash when starting the web inspector after r174025.
        <https://webkit.org/b/137340>

        Reviewed by Filip Pizlo.

        After r174025, we can generate a bad graph in the DFG fixup phase like so:

            102:<!0:-> StoreBarrier(Check:KnownCell:@19, ..., bc#44)
            60:<!0:->  PutStructure(Check:KnownCell:@19, ..., bc#44)
            103:<!0:-> Check(Check:NotCell:@54, ..., bc#44)
                    // ^-- PutByOffset's StoreBarrier has been elided and replaced
                    //     with a speculation check which can OSR exit.
            61:<!0:->  PutByOffset(Check:KnownCell:@19, ..., bc#44)

        As a result, the structure change will get executed even if we end up OSR
        exiting before the PutByOffset.  In the baseline JIT code, the structure now
        erroneously tells the put operation that there is a value in that property
        slot when it is actually uninitialized (hence, the crash).

        The fix is to insert the Check at the earliest point possible:

        1. If the checked node is in the same bytecode as the PutByOffset, then
           the earliest point where we can insert the Check is right after the
           checked node.

        2. If the checked node is from a preceding bytecode (before the PutByOffset),
           then the earliest point where we can insert the Check is at the start
           of the current bytecode.

        Also reverted the workaround from r174749: https://webkit.org/b/137758.

        Benchmark results appear to be a wash on aggregate.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::indexOfNode):
        (JSC::DFG::FixupPhase::indexOfFirstNodeOfExitOrigin):
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::insertCheck):
        * dfg/DFGInsertionSet.h:
        (JSC::DFG::InsertionSet::insertOutOfOrder):
        (JSC::DFG::InsertionSet::insertOutOfOrderNode):

2014-10-10  Oliver Hunt  <oliver@apple.com>

        Various arguments optimisations in codegen fail to account for arguments being in lexical record
        https://bugs.webkit.org/show_bug.cgi?id=137617

        Reviewed by Michael Saboff.

        Rework the way we track |arguments| references so that we don't try
        to use the |arguments| reference on the stack if it's not safe.

        To do this without nuking performance it was necessary to update
        the parser to track modification of the |arguments| reference
        itself.

        * bytecode/CodeBlock.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::willResolveToArguments):
        (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::uncheckedRegisterForArguments): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::getArgumentByVal):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::ArrayPatternNode::emitDirectBinding):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::existingArguments):
        * parser/Nodes.h:
        (JSC::ScopeNode::modifiesArguments):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        * parser/Parser.h:
        (JSC::Scope::getCapturedVariables):
        * parser/ParserModes.h:

2014-10-17  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Use WTF::move() instead of std::move() to help ensure move semantics in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=137809

        Reviewed by Csaba Osztrogonác.

        Substitution of WTF::move() for std::move(). Clean up std::move() in JavaScriptCore.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfo):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/PutByIdVariant.cpp:
        (JSC::PutByIdVariant::setter):

2014-10-15  Oliver Hunt  <oliver@apple.com>

        Use a single allocation for the Arguments object
        https://bugs.webkit.org/show_bug.cgi?id=137751

        Reviewed by Filip Pizlo.

        This patch removes the secondary allocation for parameters in the Arguments
        object.  This is faily simple, but we needed to make it possible for the JIT
        to allocate a variable GC object.  To do this i've added a new 
        emitAllocateVariableSizedJSObject function to the JIT that does the work to
        find the correct heap for a variable sized allocation and then bump that
        allocator.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitAllocateArguments):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
        * heap/CopyToken.h:
        * heap/Heap.h:
        (JSC::Heap::subspaceForObjectWithoutDestructor):
        (JSC::Heap::subspaceForObjectNormalDestructor):
        (JSC::Heap::subspaceForObjectsWithImmortalStructure):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::subspaceForObjectsWithNormalDestructor):
        (JSC::MarkedSpace::subspaceForObjectsWithImmortalStructure):
        (JSC::MarkedSpace::subspaceForObjectsWithoutDestructor):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::createArguments):
        * runtime/Arguments.cpp:
        (JSC::Arguments::visitChildren):
        (JSC::Arguments::copyBackingStore):
        (JSC::Arguments::tearOff):
        (JSC::Arguments::allocateRegisterArray): Deleted.
        * runtime/Arguments.h:
        (JSC::Arguments::create):
        (JSC::Arguments::isTornOff):
        (JSC::Arguments::offsetOfRegisterArray):
        (JSC::Arguments::registerArraySizeInBytes):
        (JSC::Arguments::registerArray):
        (JSC::Arguments::allocationSize): Deleted.

2014-10-15  Filip Pizlo  <fpizlo@apple.com>

        Apparently we've had a hole in arguments capture all along
        https://bugs.webkit.org/show_bug.cgi?id=137767

        Reviewed by Oliver Hunt.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArgument):
        * tests/stress/arguments-captured.js: Added.
        (foo):
        (bar):

2014-10-16  Saam Barati  <saambarati1@gmail.com>

        Have the ProfileType node in the DFG convert to a structure check where it can
        https://bugs.webkit.org/show_bug.cgi?id=137596

        Reviewed by Filip Pizlo.

        TypeSet now keeps track of the live set of Structures it has seen.
        It no longer nukes everything during GC. It now only removes unmarked
        structures during GC. This modification allows the ProfileType node 
        to convert into a CheckStructure node safely in the DFG. 

        This change brings up the conversion rate from ProfileType to Check 
        or CheckStructrue from ~45% to ~65%. This change also speeds the 
        type profiler up significantly: consistently between 2x-20x faster. 

        This patch also does some slight refactoring: a few type profiler
        related fields are moved from VM to TypeProfiler.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToCheckStructure):
        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::uniqueIDForVariable):
        * runtime/SymbolTable.h:
        * runtime/TypeLocationCache.cpp:
        (JSC::TypeLocationCache::getTypeLocation):
        * runtime/TypeProfiler.cpp:
        (JSC::TypeProfiler::TypeProfiler):
        (JSC::TypeProfiler::nextTypeLocation):
        (JSC::TypeProfiler::invalidateTypeSetCache):
        (JSC::TypeProfiler::dumpTypeProfilerData):
        * runtime/TypeProfiler.h:
        (JSC::TypeProfiler::getNextUniqueVariableID):
        * runtime/TypeProfilerLog.cpp:
        (JSC::TypeProfilerLog::processLogEntries):
        * runtime/TypeSet.cpp:
        (JSC::TypeSet::addTypeInformation):
        (JSC::TypeSet::invalidateCache):
        * runtime/TypeSet.h:
        (JSC::TypeSet::structureSet):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::enableTypeProfiler):
        (JSC::VM::disableTypeProfiler):
        (JSC::VM::dumpTypeProfilerData):
        (JSC::VM::nextTypeLocation): Deleted.
        (JSC::VM::invalidateTypeSetCache): Deleted.
        * runtime/VM.h:
        (JSC::VM::typeProfiler):
        (JSC::VM::getNextUniqueVariableID): Deleted.
        * tests/typeProfiler/dfg-jit-optimizations.js:

2014-10-16  Adrien Destugues  <pulkomandy@gmail.com>

        Use isnan from std namespace in ProfileGenerator.cpp
        https://bugs.webkit.org/show_bug.cgi?id=137653

        Reviewed by Darin Adler.

        The C++ isnan() function is in the std namespace. The unprefixed isnan
        may be available because of C99 headers leakage in C++, but should not
        be used.

        No new tests: no functional change, build fix on platforms which don't
        export C99 functions in C++.

        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::beginCallEntry):
        (JSC::ProfileGenerator::endCallEntry):
        (JSC::ProfileGenerator::didPause):
        (JSC::ProfileGenerator::didContinue):

2014-10-15  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r174025): remote inspector crashes frequently when executing inspector frontend's JavaScript
        https://bugs.webkit.org/show_bug.cgi?id=137758

        Rubber stamped by Filip Pizlo.

        Reverted r174025 for just PutByOffset Nodes.

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

2014-10-14  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Clean up unnecessary PassOwnPtr.h inclusion
        https://bugs.webkit.org/show_bug.cgi?id=137726

        Reviewed by Chris Dumez.

        * API/JSCallbackObject.h: Remove PassOwnPtr.h inclusion.
        * bytecode/DFGExitProfile.cpp: ditto.

2014-10-14  Brent Fulgham  <bfulgham@apple.com>

        [Win] Unreviewed gardening. Ignore Visual Studio *.sdf files.

        * JavaScriptCore.vcxproj: Modified properties svn:ignore and svn:ignore.
        * JavaScriptCore.vcxproj/jsc: Modified property svn:ignore.

2014-10-14  Matthew Mirman  <mmirman@apple.com>

        Removes references to LLVMJIT which is no longer part of LLVM
        https://bugs.webkit.org/show_bug.cgi?id=137708

        Reviewed by Filip Pizlo.

        * Configurations/LLVMForJSC.xcconfig: removed -lLLVMJIT
        * llvm/LLVMAPIFunctions.h: removed LinkInJIT

2014-10-14  peavo@outlook.com  <peavo@outlook.com>

        [Win32] Thunk is not implemented.
        https://bugs.webkit.org/show_bug.cgi?id=137691

        Reviewed by Mark Lam.

        Thunks for functions with double operands (floor, etc.) are not implemented on Win32.

        * jit/ThunkGenerators.cpp:

2014-10-12  Alexey Proskuryakov  <ap@apple.com>

        Adding svn:ignore so that .pyc files don't show up as new.

        * inspector/scripts/codegen: Added property svn:ignore.

2014-10-10  Commit Queue  <commit-queue@webkit.org>

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

        broke a JSC test (Requested by estes on #webkit).

        Reverted changeset:

        "Various arguments optimisations in codegen fail to account
        for arguments being in lexical record"
        https://bugs.webkit.org/show_bug.cgi?id=137617
        http://trac.webkit.org/changeset/174606

2014-10-10  Oliver Hunt  <oliver@apple.com>

        Various arguments optimisations in codegen fail to account for arguments being in lexical record
        https://bugs.webkit.org/show_bug.cgi?id=137617

        Reviewed by Michael Saboff.

        Rework the way we track |arguments| references so that we don't try
        to use the |arguments| reference on the stack if it's not safe.

        To do this without nuking performance it was necessary to update
        the parser to track modification of the |arguments| reference
        itself.

        * bytecode/CodeBlock.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::willResolveToArguments):
        (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::emitEnumeration):
        (JSC::BytecodeGenerator::uncheckedRegisterForArguments): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::getArgumentByVal):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::ArrayPatternNode::emitDirectBinding):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::existingArguments):
        * parser/Nodes.h:
        (JSC::ScopeNode::modifiesArguments):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner):
        * parser/Parser.h:
        (JSC::Scope::getCapturedVariables):
        * parser/ParserModes.h:

2014-10-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused generator code
        https://bugs.webkit.org/show_bug.cgi?id=137564

        Reviewed by Brian Burg.

        * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
        (BackendDispatcherHeaderGenerator.generate_output): Deleted.
        * inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
        (BackendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
        (FrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
        (FrontendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_protocol_types_header.py:
        (ProtocolTypesHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_protocol_types_implementation.py:
        (ProtocolTypesImplementationGenerator.generate_output):
        inputFilename is now handled by the generic generator base class.

        * inspector/scripts/codegen/models.py:
        (Framework.fromString):
        (Frameworks):
        * inspector/scripts/generate-inspector-protocol-bindings.py:
        The WTF framework is unused. Remove unexpected frameworks.

2014-10-09  Dean Jackson  <dino@apple.com>

        Remove ENABLE_CSS3_CONDITIONAL_RULES
        https://bugs.webkit.org/show_bug.cgi?id=137571

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2014-10-09  Adrien Destugues  <pulkomandy@gmail.com>

        Fix compiler warning on noreturn function
        https://bugs.webkit.org/show_bug.cgi?id=137558

        Reviewed by Darin Adler.

        The function is marked "noreturn", but the stub implementation does
        return. No new tests: function is never called. Only fixes a warning.

        * heap/HeapStatistics.cpp:
        (JSC::HeapStatistics::exitWithFailure):

2014-10-09  Akos Kiss  <akiss@inf.u-szeged.hu>

        Ensure that inline assembly Thunk functions don't conflict with the section designations of the compiler
        https://bugs.webkit.org/show_bug.cgi?id=137434

        Reviewed by Michael Saboff.

        The ARM64 version of the defineUnaryDoubleOpWrapper macro in
        ThunkGenerators.cpp contains inline assembly with .text assembler
        directive followed by a static variable declaration. This macro gets
        expanded several times afterwards, however, only during the compilation
        of the first expansion does gcc insert a .data assembler directive
        before the assembled version of the static variable. Thus, only the
        first variable gets allocated in the .data section, all the others
        remain in .text. If JavaScriptCore is built as a shared library then
        this causes a segmentation fault during dynamic linking.

        This patch puts a .previous directive at the end of the inline assembly
        to ensure that the assumptions of the compiler about the sections are
        not broken and the following variable goes to the right place.

        * jit/ThunkGenerators.cpp:

2014-10-08  Oliver Hunt  <oliver@apple.com>

        Make sure arguments tearoff is performed through the environment record if necessary
        https://bugs.webkit.org/show_bug.cgi?id=137538

        Reviewed by Michael Saboff.

        Fairly simple change.  If we have a lexical record we need to pull the unmodified
        arguments object from the record and then use the standard op_tear_off_arguments
        instruction on the temporary.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitGetOwnScope):
        (JSC::BytecodeGenerator::emitReturn):
        * bytecompiler/BytecodeGenerator.h:

2014-10-08  peavo@outlook.com  <peavo@outlook.com>

        [WinCairo] Enable JIT on 32-bit.
        https://bugs.webkit.org/show_bug.cgi?id=137521

        Reviewed by Mark Lam.

        Enable JIT on Windows 32-bit, but disable it at runtime if SSE2 is not present.

        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl:
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):

2014-10-08  Brent Fulgham  <bfulgham@apple.com>

        [Win] Resolve some static analysis warnings in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=137508

        Reviewed by Geoffrey Garen.

        * API/tests/testapi.c:
        (assertEqualsAsCharactersPtr): MSVC insists on using %Iu as its format specifier
        for size_t. Make the format string conditional on Windows.
        * bytecode/Watchpoint.h:
        (JSC::InlineWatchpointSet::encodeState): Silence warning about left-shifting 'state'
        as a 32-bit value before OR-ing it with a 64-bit value.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Silence warning about operator prescedence
        causing the || operation to take place before the >= test.
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::endBasicBlock): Ditto (|| before !=)
        * testRegExp.cpp:
        (testOneRegExp): Ditto %Iu format specifier.
        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::Interpreter::allocParenthesesDisjunctionContext): Silence warning about
        using a 32-bit value as part of a 64-bit calculation.

2014-10-07  Simon Fraser  <simon.fraser@apple.com>

        Roll-over Changelogs.

        * ChangeLog-2014-10-07: Copied from Source/JavaScriptCore/ChangeLog.

== Rolled over to ChangeLog-2014-10-07 ==