| 2015-11-30 Sukolsak Sakshuwong <sukolsak@gmail.com> |
| |
| Fix coding style of Intl code |
| https://bugs.webkit.org/show_bug.cgi?id=151491 |
| |
| Reviewed by Darin Adler. |
| |
| This patch does three things: |
| 1. Rename pointers and references to ExecState from "exec" to "state". |
| 2. Pass parameters by references instead of pointers if the parameters |
| are required. |
| 3. Remove the word "get" from the names of functions that don't return |
| values through out arguments. |
| |
| * runtime/IntlCollator.cpp: |
| (JSC::IntlCollatorFuncCompare): |
| * runtime/IntlCollatorConstructor.cpp: |
| (JSC::initializeCollator): |
| (JSC::constructIntlCollator): |
| (JSC::callIntlCollator): |
| (JSC::IntlCollatorConstructor::getOwnPropertySlot): |
| (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): |
| * runtime/IntlDateTimeFormat.cpp: |
| (JSC::IntlDateTimeFormatFuncFormatDateTime): |
| * runtime/IntlDateTimeFormatConstructor.cpp: |
| (JSC::constructIntlDateTimeFormat): |
| (JSC::callIntlDateTimeFormat): |
| (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot): |
| (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): |
| * runtime/IntlDateTimeFormatPrototype.cpp: |
| (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot): |
| (JSC::IntlDateTimeFormatPrototypeGetterFormat): |
| (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): |
| * runtime/IntlNumberFormat.cpp: |
| (JSC::IntlNumberFormatFuncFormatNumber): |
| * runtime/IntlNumberFormatConstructor.cpp: |
| (JSC::constructIntlNumberFormat): |
| (JSC::callIntlNumberFormat): |
| (JSC::IntlNumberFormatConstructor::getOwnPropertySlot): |
| (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): |
| * runtime/IntlNumberFormatPrototype.cpp: |
| (JSC::IntlNumberFormatPrototype::getOwnPropertySlot): |
| (JSC::IntlNumberFormatPrototypeGetterFormat): |
| (JSC::IntlNumberFormatPrototypeFuncResolvedOptions): |
| * runtime/IntlObject.cpp: |
| (JSC::intlBooleanOption): |
| (JSC::intlStringOption): |
| (JSC::privateUseLangTag): |
| (JSC::canonicalLangTag): |
| (JSC::grandfatheredLangTag): |
| (JSC::canonicalizeLanguageTag): |
| (JSC::canonicalizeLocaleList): |
| (JSC::lookupSupportedLocales): |
| (JSC::bestFitSupportedLocales): |
| (JSC::supportedLocales): |
| (JSC::getIntlBooleanOption): Deleted. |
| (JSC::getIntlStringOption): Deleted. |
| (JSC::getPrivateUseLangTag): Deleted. |
| (JSC::getCanonicalLangTag): Deleted. |
| (JSC::getGrandfatheredLangTag): Deleted. |
| * runtime/IntlObject.h: |
| |
| 2015-11-30 Benjamin Poulain <bpoulain@apple.com> |
| |
| [JSC] Simplify the loop that remove useless Air instructions |
| https://bugs.webkit.org/show_bug.cgi?id=151652 |
| |
| Reviewed by Andreas Kling. |
| |
| * b3/air/AirEliminateDeadCode.cpp: |
| (JSC::B3::Air::eliminateDeadCode): |
| Use Vector's removeAllMatching() instead of custom code. |
| |
| It is likely faster too since we remove few values and Vector |
| is good at doing that. |
| |
| 2015-11-30 Filip Pizlo <fpizlo@apple.com> |
| |
| B3 should be be clever about choosing which child to reuse for result in two-operand commutative operations |
| https://bugs.webkit.org/show_bug.cgi?id=151321 |
| |
| Reviewed by Geoffrey Garen. |
| |
| When lowering a commutative operation to a two-operand instruction, you have a choice of which |
| child value to move into the result tmp. For example we might have: |
| |
| @x = Add(@y, @z) |
| |
| Assuming no three-operand add is available, we could either lower it to this: |
| |
| Move %y, %x |
| Add %z, %x |
| |
| or to this: |
| |
| Move %z, %x |
| Add %y, %x |
| |
| Which is better depends on the likelihood of coalescing with %x. If it's more likely that %y will |
| coalesce with %x, then we want to use the first form. Otherwise, we should use the second form. |
| |
| This implements two heuristics for selecting the right form, and makes those heuristics reusable |
| within the B3->Air lowering by abstracting it as preferRightForResult(). For non-commutative |
| operations we must use the first form, so the first form is the default. The heuristics are: |
| |
| - If the right child has only one user, then use the second form instead. This is profitable because |
| that means that @z dies at the Add, so using the second form means that the Move will be coalesced |
| away. |
| |
| - If one of the children is a Phi that this operation (the Add in this case) flows into via some |
| Upsilon - possibly transitively through other Phis - then use the form that cases a Move on that |
| child. This overrides everything else, and is meant to optimize variables that accumulate in a |
| loop. |
| |
| This required adding a reusable PhiChildren analysis, so I wrote one. It has an API that is mostly |
| based on iterators, and a higher-level API for looking at transitive children that is based on |
| functors. |
| |
| I was originally implementing this for completeness, but when looking at how it interacted with |
| imaging-gaussian-blur, I realized the need for some heuristic for the loop-accumulator case. This |
| helps a lot on that benchmark. This widens the overall lead that B3 has on imaging-gaussian-blur, but |
| steady-state runs that exclude compile latency still show a slight deficit. That will most likely get |
| fixed by https://bugs.webkit.org/show_bug.cgi?id=151174. |
| |
| No new tests because the commutativity appears to be covered by existing tests, and anyway, there are |
| no correctness implications to commuting a commutative operation. |
| |
| * CMakeLists.txt: |
| * JavaScriptCore.xcodeproj/project.pbxproj: |
| * b3/B3LowerToAir.cpp: |
| (JSC::B3::Air::LowerToAir::LowerToAir): |
| (JSC::B3::Air::LowerToAir::canBeInternal): |
| (JSC::B3::Air::LowerToAir::appendUnOp): |
| (JSC::B3::Air::LowerToAir::preferRightForResult): |
| (JSC::B3::Air::LowerToAir::appendBinOp): |
| (JSC::B3::Air::LowerToAir::lower): |
| * b3/B3PhiChildren.cpp: Added. |
| (JSC::B3::PhiChildren::PhiChildren): |
| (JSC::B3::PhiChildren::~PhiChildren): |
| * b3/B3PhiChildren.h: Added. |
| (JSC::B3::PhiChildren::ValueCollection::ValueCollection): |
| (JSC::B3::PhiChildren::ValueCollection::size): |
| (JSC::B3::PhiChildren::ValueCollection::at): |
| (JSC::B3::PhiChildren::ValueCollection::operator[]): |
| (JSC::B3::PhiChildren::ValueCollection::contains): |
| (JSC::B3::PhiChildren::ValueCollection::iterator::iterator): |
| (JSC::B3::PhiChildren::ValueCollection::iterator::operator*): |
| (JSC::B3::PhiChildren::ValueCollection::iterator::operator++): |
| (JSC::B3::PhiChildren::ValueCollection::iterator::operator==): |
| (JSC::B3::PhiChildren::ValueCollection::iterator::operator!=): |
| (JSC::B3::PhiChildren::ValueCollection::begin): |
| (JSC::B3::PhiChildren::ValueCollection::end): |
| (JSC::B3::PhiChildren::UpsilonCollection::UpsilonCollection): |
| (JSC::B3::PhiChildren::UpsilonCollection::size): |
| (JSC::B3::PhiChildren::UpsilonCollection::at): |
| (JSC::B3::PhiChildren::UpsilonCollection::operator[]): |
| (JSC::B3::PhiChildren::UpsilonCollection::contains): |
| (JSC::B3::PhiChildren::UpsilonCollection::begin): |
| (JSC::B3::PhiChildren::UpsilonCollection::end): |
| (JSC::B3::PhiChildren::UpsilonCollection::values): |
| (JSC::B3::PhiChildren::UpsilonCollection::forAllTransitiveIncomingValues): |
| (JSC::B3::PhiChildren::UpsilonCollection::transitivelyUses): |
| (JSC::B3::PhiChildren::at): |
| (JSC::B3::PhiChildren::operator[]): |
| * b3/B3Procedure.cpp: |
| (JSC::B3::Procedure::Procedure): |
| * b3/B3Procedure.h: |
| * b3/B3UseCounts.cpp: |
| (JSC::B3::UseCounts::UseCounts): |
| * b3/B3UseCounts.h: |
| (JSC::B3::UseCounts::numUses): |
| (JSC::B3::UseCounts::numUsingInstructions): |
| (JSC::B3::UseCounts::operator[]): Deleted. |
| |
| 2015-11-30 Filip Pizlo <fpizlo@apple.com> |
| |
| REGRESSION(r192812): This change seems to have broken the iOS builds (Requested by ryanhaddad on #webkit). |
| https://bugs.webkit.org/show_bug.cgi?id=151669 |
| |
| Unreviewed, fix build. |
| |
| * dfg/DFGCommon.h: |
| |
| 2015-11-30 Saam barati <sbarati@apple.com> |
| |
| implement op_get_rest_length so that we can allocate the rest array with the right size from the start |
| https://bugs.webkit.org/show_bug.cgi?id=151467 |
| |
| Reviewed by Geoffrey Garen and Mark Lam. |
| |
| This patch implements op_get_rest_length which returns the length |
| that the rest parameter array will be. We're implementing this because |
| it might be a constant value in the presence of inlining in the DFG. |
| We will take advantage of this optimization opportunity in a future patch: |
| https://bugs.webkit.org/show_bug.cgi?id=151454 |
| to emit better code for op_copy_rest. |
| |
| op_get_rest_length has two operands: |
| 1) a destination |
| 2) A constant indicating the number of parameters to skip when copying the rest array. |
| |
| op_get_rest_length lowers to a JSConstant node when we're inlined |
| and not a varargs call (in this case, we statically know the arguments |
| length). When that condition isn't met, we lower op_get_rest_length to |
| GetRestArray. GetRestArray produces its result as an int32. |
| |
| * bytecode/BytecodeList.json: |
| * bytecode/BytecodeUseDef.h: |
| (JSC::computeUsesForBytecodeOffset): |
| (JSC::computeDefsForBytecodeOffset): |
| * bytecode/CodeBlock.cpp: |
| (JSC::CodeBlock::dumpBytecode): |
| * bytecompiler/BytecodeGenerator.cpp: |
| (JSC::BytecodeGenerator::emitNewArray): |
| (JSC::BytecodeGenerator::emitNewArrayWithSize): |
| (JSC::BytecodeGenerator::emitNewFunction): |
| (JSC::BytecodeGenerator::emitExpectedFunctionSnippet): |
| (JSC::BytecodeGenerator::emitRestParameter): |
| * bytecompiler/BytecodeGenerator.h: |
| * bytecompiler/NodesCodegen.cpp: |
| (JSC::RestParameterNode::emit): |
| * 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/DFGMayExit.cpp: |
| (JSC::DFG::mayExit): |
| * dfg/DFGNode.h: |
| (JSC::DFG::Node::numberOfArgumentsToSkip): |
| * 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::compileCopyRest): |
| (JSC::DFG::SpeculativeJIT::compileGetRestLength): |
| (JSC::DFG::SpeculativeJIT::compileNotifyWrite): |
| * dfg/DFGSpeculativeJIT.h: |
| (JSC::DFG::SpeculativeJIT::callOperation): |
| * 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::DFG::LowerDFGToLLVM::compileNode): |
| (JSC::FTL::DFG::LowerDFGToLLVM::compileCopyRest): |
| (JSC::FTL::DFG::LowerDFGToLLVM::compileGetRestLength): |
| (JSC::FTL::DFG::LowerDFGToLLVM::compileNewObject): |
| * jit/JIT.cpp: |
| (JSC::JIT::privateCompileMainPass): |
| * jit/JIT.h: |
| * jit/JITOpcodes.cpp: |
| (JSC::JIT::emit_op_copy_rest): |
| (JSC::JIT::emit_op_get_rest_length): |
| * llint/LowLevelInterpreter.asm: |
| * llint/LowLevelInterpreter32_64.asm: |
| * llint/LowLevelInterpreter64.asm: |
| * runtime/CommonSlowPaths.cpp: |
| (JSC::SLOW_PATH_DECL): |
| |
| 2015-11-30 Filip Pizlo <fpizlo@apple.com> |
| |
| MacroAssembler needs an API for disabling scratch registers |
| https://bugs.webkit.org/show_bug.cgi?id=151010 |
| |
| Reviewed by Saam Barati and Michael Saboff. |
| |
| This adds two scope classes, DisallowMacroScratchRegisterUsage and |
| AllowMacroScratchRegisterUsage. The default is that the scratch registers are enabled. Air |
| disables them before generation. |
| |
| Henceforth the pattern inside B3 stackmap generator callbacks will be that you can only use |
| AllowMacroScratchRegisterUsage if you've either supplied the scratch register as a clobbered |
| register and arranged for all of the stackmap values to be late uses, or you're writing a test |
| and you're OK with it being fragile with respect to scratch registers. The latter holds in most |
| of testb3. |
| |
| * JavaScriptCore.xcodeproj/project.pbxproj: |
| * assembler/AbstractMacroAssembler.h: |
| (JSC::optimizeForX86): |
| (JSC::AbstractMacroAssembler::setTempRegisterValid): |
| * assembler/AllowMacroScratchRegisterUsage.h: Added. |
| (JSC::AllowMacroScratchRegisterUsage::AllowMacroScratchRegisterUsage): |
| (JSC::AllowMacroScratchRegisterUsage::~AllowMacroScratchRegisterUsage): |
| * assembler/DisallowMacroScratchRegisterUsage.h: Added. |
| (JSC::DisallowMacroScratchRegisterUsage::DisallowMacroScratchRegisterUsage): |
| (JSC::DisallowMacroScratchRegisterUsage::~DisallowMacroScratchRegisterUsage): |
| * assembler/MacroAssemblerX86Common.h: |
| (JSC::MacroAssemblerX86Common::scratchRegister): |
| (JSC::MacroAssemblerX86Common::loadDouble): |
| (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32): |
| * assembler/MacroAssemblerX86_64.h: |
| (JSC::MacroAssemblerX86_64::add32): |
| (JSC::MacroAssemblerX86_64::and32): |
| (JSC::MacroAssemblerX86_64::or32): |
| (JSC::MacroAssemblerX86_64::sub32): |
| (JSC::MacroAssemblerX86_64::load8): |
| (JSC::MacroAssemblerX86_64::addDouble): |
| (JSC::MacroAssemblerX86_64::convertInt32ToDouble): |
| (JSC::MacroAssemblerX86_64::store32): |
| (JSC::MacroAssemblerX86_64::store8): |
| (JSC::MacroAssemblerX86_64::callWithSlowPathReturnType): |
| (JSC::MacroAssemblerX86_64::call): |
| (JSC::MacroAssemblerX86_64::jump): |
| (JSC::MacroAssemblerX86_64::tailRecursiveCall): |
| (JSC::MacroAssemblerX86_64::makeTailRecursiveCall): |
| (JSC::MacroAssemblerX86_64::branchAdd32): |
| (JSC::MacroAssemblerX86_64::add64): |
| (JSC::MacroAssemblerX86_64::addPtrNoFlags): |
| (JSC::MacroAssemblerX86_64::and64): |
| (JSC::MacroAssemblerX86_64::lshift64): |
| (JSC::MacroAssemblerX86_64::or64): |
| (JSC::MacroAssemblerX86_64::sub64): |
| (JSC::MacroAssemblerX86_64::store64): |
| (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch): |
| (JSC::MacroAssemblerX86_64::branch64): |
| (JSC::MacroAssemblerX86_64::branchPtr): |
| (JSC::MacroAssemblerX86_64::branchTest64): |
| (JSC::MacroAssemblerX86_64::test64): |
| (JSC::MacroAssemblerX86_64::branchPtrWithPatch): |
| (JSC::MacroAssemblerX86_64::branch32WithPatch): |
| (JSC::MacroAssemblerX86_64::storePtrWithPatch): |
| (JSC::MacroAssemblerX86_64::branch8): |
| (JSC::MacroAssemblerX86_64::branchTest8): |
| (JSC::MacroAssemblerX86_64::convertInt64ToDouble): |
| (JSC::MacroAssemblerX86_64::readCallTarget): |
| (JSC::MacroAssemblerX86_64::haveScratchRegisterForBlinding): |
| (JSC::MacroAssemblerX86_64::scratchRegisterForBlinding): |
| (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranchPtrWithPatch): |
| (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranch32WithPatch): |
| (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranchPtrWithPatch): |
| (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranch32WithPatch): |
| (JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch): |
| (JSC::MacroAssemblerX86_64::repatchCall): |
| (JSC::MacroAssemblerX86_64::add64AndSetFlags): |
| * b3/air/AirGenerate.cpp: |
| (JSC::B3::Air::generate): |
| * b3/testb3.cpp: |
| (JSC::B3::testSimplePatchpoint): |
| (JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs): |
| (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs): |
| (JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs): |
| (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs): |
| (JSC::B3::testPatchpointCallArg): |
| (JSC::B3::testPatchpointFixedRegister): |
| (JSC::B3::testPatchpointAny): |
| (JSC::B3::testPatchpointAnyImm): |
| (JSC::B3::testSimpleCheck): |
| (JSC::B3::testCheckLessThan): |
| (JSC::B3::testCheckMegaCombo): |
| (JSC::B3::testCheckAddImm): |
| (JSC::B3::testCheckAddImmCommute): |
| (JSC::B3::testCheckAddImmSomeRegister): |
| (JSC::B3::testCheckAdd): |
| (JSC::B3::testCheckAdd64): |
| (JSC::B3::testCheckAddFoldFail): |
| (JSC::B3::testCheckSubImm): |
| (JSC::B3::testCheckSubBadImm): |
| (JSC::B3::testCheckSub): |
| (JSC::B3::testCheckSub64): |
| (JSC::B3::testCheckSubFoldFail): |
| (JSC::B3::testCheckNeg): |
| (JSC::B3::testCheckNeg64): |
| (JSC::B3::testCheckMul): |
| (JSC::B3::testCheckMulMemory): |
| (JSC::B3::testCheckMul2): |
| (JSC::B3::testCheckMul64): |
| (JSC::B3::testCheckMulFoldFail): |
| (JSC::B3::genericTestCompare): |
| * dfg/DFGCommon.h: |
| * jit/GPRInfo.h: |
| (JSC::GPRInfo::toRegister): |
| (JSC::GPRInfo::reservedRegisters): |
| |
| 2015-11-26 Mark Lam <mark.lam@apple.com> |
| |
| [ARM64] stress/op_div.js is failing on some divide by 0 cases. |
| https://bugs.webkit.org/show_bug.cgi?id=151515 |
| |
| Reviewed by Saam Barati. |
| |
| * dfg/DFGSpeculativeJIT.cpp: |
| (JSC::DFG::SpeculativeJIT::compileArithDiv): |
| - Added a check for the divide by zero case. |
| * tests/stress/op_div.js: |
| - Un-skipped the test. |
| |
| 2015-11-27 Csaba Osztrogonác <ossy@webkit.org> |
| |
| [cmake] Add testb3 to the build system |
| https://bugs.webkit.org/show_bug.cgi?id=151619 |
| |
| Reviewed by Gyuyoung Kim. |
| |
| * shell/CMakeLists.txt: |
| |
| 2015-11-27 Csaba Osztrogonác <ossy@webkit.org> |
| |
| Use mark pragmas only if it is supported |
| https://bugs.webkit.org/show_bug.cgi?id=151621 |
| |
| Reviewed by Mark Lam. |
| |
| * b3/air/AirIteratedRegisterCoalescing.cpp: |
| |
| 2015-11-27 Csaba Osztrogonác <ossy@webkit.org> |
| |
| Fix the ENABLE(B3_JIT) build with GCC in B3Procedure.h |
| https://bugs.webkit.org/show_bug.cgi?id=151620 |
| |
| Reviewed by Mark Lam. |
| |
| * b3/B3Procedure.h: |
| |
| 2015-11-27 Csaba Osztrogonác <ossy@webkit.org> |
| |
| [cmake] Add new B3 source files to the build system |
| https://bugs.webkit.org/show_bug.cgi?id=151618 |
| |
| Reviewed by Gyuyoung Kim. |
| |
| * CMakeLists.txt: |
| |
| 2015-11-26 Carlos Garcia Campos <cgarcia@igalia.com> |
| |
| [GLIB] Implement garbage collector timers |
| https://bugs.webkit.org/show_bug.cgi?id=151391 |
| |
| Reviewed by Žan Doberšek. |
| |
| Add GLib implementation using GSource. |
| |
| * heap/EdenGCActivityCallback.cpp: |
| * heap/FullGCActivityCallback.cpp: |
| * heap/GCActivityCallback.cpp: |
| (JSC::GCActivityCallback::GCActivityCallback): |
| (JSC::GCActivityCallback::scheduleTimer): |
| (JSC::GCActivityCallback::cancelTimer): |
| * heap/GCActivityCallback.h: |
| * heap/Heap.cpp: |
| (JSC::Heap::Heap): |
| * heap/HeapTimer.cpp: |
| (JSC::HeapTimer::HeapTimer): |
| (JSC::HeapTimer::~HeapTimer): |
| (JSC::HeapTimer::timerDidFire): |
| * heap/HeapTimer.h: |
| * heap/IncrementalSweeper.cpp: |
| (JSC::IncrementalSweeper::IncrementalSweeper): |
| (JSC::IncrementalSweeper::scheduleTimer): |
| (JSC::IncrementalSweeper::cancelTimer): |
| * heap/IncrementalSweeper.h: |
| |
| 2015-11-24 Caitlin Potter <caitp@igalia.com> |
| |
| [JSC] support Computed Property Names in destructuring Patterns |
| https://bugs.webkit.org/show_bug.cgi?id=151494 |
| |
| Reviewed by Saam Barati. |
| |
| Add support for computed property names in destructuring BindingPatterns |
| and AssignmentPatterns. |
| |
| Productions BindingProperty(1) and AssignmentProperty(2) allow for any valid |
| PropertName(3), including ComputedPropertyName(4) |
| |
| 1: http://tc39.github.io/ecma262/#prod-BindingProperty |
| 2: http://tc39.github.io/ecma262/#prod-AssignmentProperty |
| 3: http://tc39.github.io/ecma262/#prod-PropertyName |
| 4: http://tc39.github.io/ecma262/#prod-ComputedPropertyName |
| |
| * bytecompiler/NodesCodegen.cpp: |
| (JSC::ObjectPatternNode::bindValue): |
| * parser/ASTBuilder.h: |
| (JSC::ASTBuilder::appendObjectPatternEntry): |
| * parser/Nodes.h: |
| (JSC::ObjectPatternNode::appendEntry): |
| * parser/Parser.cpp: |
| (JSC::Parser<LexerType>::parseDestructuringPattern): |
| * parser/SyntaxChecker.h: |
| (JSC::SyntaxChecker::operatorStackPop): |
| * tests/es6.yaml: |
| * tests/es6/destructuring_assignment_computed_properties.js: Added. |
| (test): |
| (test.computeName): |
| (test.loadValue): |
| (test.out.get a): |
| (test.out.set a): |
| (test.out.get b): |
| (test.out.set b): |
| (test.out.get c): |
| (test.out.set c): |
| (test.get var): |
| |
| 2015-11-24 Commit Queue <commit-queue@webkit.org> |
| |
| Unreviewed, rolling out r192536, r192722, and r192743. |
| https://bugs.webkit.org/show_bug.cgi?id=151593 |
| |
| Still causing trouble. (Requested by kling on #webkit). |
| |
| Reverted changesets: |
| |
| "[JSC] JSPropertyNameEnumerator could be destructorless." |
| https://bugs.webkit.org/show_bug.cgi?id=151242 |
| http://trac.webkit.org/changeset/192536 |
| |
| "REGRESSION(r192536): Null pointer dereference in |
| JSPropertyNameEnumerator::visitChildren()." |
| https://bugs.webkit.org/show_bug.cgi?id=151495 |
| http://trac.webkit.org/changeset/192722 |
| |
| "REGRESSION(r192536): Null pointer dereference in |
| JSPropertyNameEnumerator::visitChildren()." |
| https://bugs.webkit.org/show_bug.cgi?id=151495 |
| http://trac.webkit.org/changeset/192743 |
| |
| 2015-11-23 Brian Burg <bburg@apple.com> |
| |
| Unreviewed, fix the Mac CMake build after r192793. |
| |
| * PlatformMac.cmake: |
| |
| 2015-11-20 Brian Burg <bburg@apple.com> |
| |
| Web Inspector: RemoteInspector should track targets and connections for remote automation |
| https://bugs.webkit.org/show_bug.cgi?id=151042 |
| |
| Reviewed by Joseph Pecoraro. |
| |
| Refactor RemoteInspector so it can be used to send listings of different target types. |
| First, rename Debuggable to RemoteInspectionTarget, and pull things not specific to |
| remote inspection into the base class RemoteControllableTarget and its Connection class. |
| |
| Add a new RemoteControllableTarget called RemoteAutomationTarget, used by UIProcess |
| to support remote UI automation via webinspectord. On the protocol side, this target |
| uses a new WIRTypeKey called WIRTypeAutomation to distiguish the listing from |
| Web and JavaScript listings and avoid inventing a new listing mechanism. |
| |
| * API/JSContextRef.cpp: |
| (JSGlobalContextGetDebuggerRunLoop): |
| (JSGlobalContextSetDebuggerRunLoop): |
| * JavaScriptCore.xcodeproj/project.pbxproj: |
| * inspector/InspectorFrontendChannel.h: |
| * inspector/remote/RemoteAutomationTarget.cpp: Added. |
| (Inspector::RemoteAutomationTarget::setAutomationAllowed): Added. |
| * inspector/remote/RemoteAutomationTarget.h: Added. |
| * inspector/remote/RemoteConnectionToTarget.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.h. |
| (Inspector::RemoteTargetBlock::RemoteTargetBlock): |
| (Inspector::RemoteTargetBlock::~RemoteTargetBlock): |
| (Inspector::RemoteTargetBlock::operator=): |
| (Inspector::RemoteTargetBlock::operator()): |
| * inspector/remote/RemoteConnectionToTarget.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.mm. |
| (Inspector::RemoteTargetHandleRunSourceGlobal): |
| (Inspector::RemoteTargetQueueTaskOnGlobalQueue): |
| (Inspector::RemoteTargetInitializeGlobalQueue): |
| (Inspector::RemoteTargetHandleRunSourceWithInfo): |
| (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget): |
| (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget): |
| (Inspector::RemoteConnectionToTarget::destination): |
| (Inspector::RemoteConnectionToTarget::connectionIdentifier): |
| (Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget): |
| (Inspector::RemoteConnectionToTarget::setup): |
| (Inspector::RemoteConnectionToTarget::targetClosed): |
| (Inspector::RemoteConnectionToTarget::close): |
| (Inspector::RemoteConnectionToTarget::sendMessageToTarget): |
| (Inspector::RemoteConnectionToTarget::sendMessageToFrontend): |
| (Inspector::RemoteConnectionToTarget::setupRunLoop): |
| (Inspector::RemoteConnectionToTarget::teardownRunLoop): |
| (Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop): |
| * inspector/remote/RemoteControllableTarget.cpp: Added. |
| (Inspector::RemoteControllableTarget::~RemoteControllableTarget): |
| (Inspector::RemoteControllableTarget::init): |
| (Inspector::RemoteControllableTarget::update): |
| * inspector/remote/RemoteControllableTarget.h: Added. |
| * inspector/remote/RemoteInspectionTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.cpp. |
| (Inspector::RemoteInspectionTarget::remoteControlAllowed): |
| (Inspector::RemoteInspectionTarget::setRemoteDebuggingAllowed): |
| (Inspector::RemoteInspectionTarget::pauseWaitingForAutomaticInspection): |
| (Inspector::RemoteInspectionTarget::unpauseForInitializedInspector): |
| * inspector/remote/RemoteInspectionTarget.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.h. |
| (isType): |
| * inspector/remote/RemoteInspector.h: |
| |
| Code to manage Debuggables now works with RemoteControllableTargets and doesn't |
| care whether the target is for Inspection or Automation. Listing data with target- |
| and type-specific information are captured when clients call into RemoteInspector |
| since that's the easiest time to gather this information on the right thread. |
| Use the is<> / downcast<> machinery when we need a concrete Target type. |
| |
| * inspector/remote/RemoteInspector.mm: |
| (Inspector::RemoteInspector::nextAvailableIdentifier): |
| (Inspector::RemoteInspector::registerTarget): renamed from registerDebuggable. |
| (Inspector::RemoteInspector::unregisterTarget): renamed from unregisterDebuggable. |
| (Inspector::RemoteInspector::updateTarget): renamed from updateDebuggable. |
| (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): |
| (Inspector::RemoteInspector::sendMessageToRemote): |
| (Inspector::RemoteInspector::setupFailed): |
| (Inspector::RemoteInspector::stopInternal): |
| (Inspector::RemoteInspector::setupXPCConnectionIfNeeded): |
| (Inspector::RemoteInspector::xpcConnectionFailed): |
| (Inspector::RemoteInspector::listingForTarget): |
| (Inspector::RemoteInspector::listingForInspectionTarget): |
| (Inspector::RemoteInspector::listingForAutomationTarget): |
| (Inspector::RemoteInspector::pushListingsNow): |
| (Inspector::RemoteInspector::pushListingsSoon): |
| (Inspector::RemoteInspector::receivedSetupMessage): |
| (Inspector::RemoteInspector::receivedDataMessage): |
| (Inspector::RemoteInspector::receivedDidCloseMessage): |
| (Inspector::RemoteInspector::receivedGetListingMessage): |
| (Inspector::RemoteInspector::receivedIndicateMessage): |
| (Inspector::RemoteInspector::receivedConnectionDiedMessage): |
| (Inspector::RemoteInspector::RemoteInspector): Deleted. |
| (Inspector::RemoteInspector::registerDebuggable): Deleted. |
| (Inspector::RemoteInspector::unregisterDebuggable): Deleted. |
| (Inspector::RemoteInspector::updateDebuggable): Deleted. |
| (Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate): Deleted. |
| (Inspector::RemoteInspector::sendMessageToRemoteFrontend): Deleted. |
| (Inspector::RemoteInspector::listingForDebuggable): Deleted. |
| (Inspector::RemoteInspector::pushListingNow): Deleted. |
| (Inspector::RemoteInspector::pushListingSoon): Deleted. |
| * inspector/remote/RemoteInspectorConstants.h: |
| * runtime/JSGlobalObjectDebuggable.cpp: |
| (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemote): |
| (JSC::JSGlobalObjectDebuggable::pauseWaitingForAutomaticInspection): |
| (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): Deleted. |
| * runtime/JSGlobalObjectDebuggable.h: |
| |
| 2015-11-23 Brian Burg <bburg@apple.com> |
| |
| Rename JavaScriptCore builtins files to match exposed object names |
| https://bugs.webkit.org/show_bug.cgi?id=151549 |
| |
| Reviewed by Youenn Fablet. |
| |
| As a subtask of unifying code generation for WebCore and JSC builtins, we need to get rid of |
| differences between builtins filenames (e.g., Promise.prototype.js) and the name of the |
| generated Builtin object (PromisePrototype). |
| |
| If we don't do this, then both build systems need special hacks to normalize the object name |
| from the file name. It's easier to just normalize the filename. |
| |
| * CMakeLists.txt: |
| * DerivedSources.make: |
| * JavaScriptCore.xcodeproj/project.pbxproj: |
| * builtins/ArrayIteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/ArrayIterator.prototype.js. |
| * builtins/ArrayPrototype.js: Renamed from Source/JavaScriptCore/builtins/Array.prototype.js. |
| * builtins/FunctionPrototype.js: Renamed from Source/JavaScriptCore/builtins/Function.prototype.js. |
| * builtins/IteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/Iterator.prototype.js. |
| * builtins/PromiseOperations.js: Renamed from Source/JavaScriptCore/builtins/Operations.Promise.js. |
| * builtins/PromisePrototype.js: Renamed from Source/JavaScriptCore/builtins/Promise.prototype.js. |
| * builtins/StringIteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/StringIterator.prototype.js. |
| * builtins/TypedArrayPrototype.js: Renamed from Source/JavaScriptCore/builtins/TypedArray.prototype.js. |
| |
| 2015-11-23 Andreas Kling <akling@apple.com> |
| |
| REGRESSION(r192536): Null pointer dereference in JSPropertyNameEnumerator::visitChildren(). |
| <https://webkit.org/b/151495> |
| |
| Reviewed by Mark Lam |
| |
| The test I added when fixing this bug the first time caught another bug when |
| run on 32-bit: jsString() can also cause GC, so we have to make sure that |
| JSPropertyNameEnumerator::m_propertyNames is null until after the array it |
| points to has been populated. |
| |
| Test: property-name-enumerator-gc-151495.js |
| |
| * runtime/JSPropertyNameEnumerator.cpp: |
| (JSC::JSPropertyNameEnumerator::finishCreation): |
| |
| == Rolled over to ChangeLog-2015-11-21 == |
