7fbb75b694f40c138ae58e117097fcd52781e22e
[WebKit.git] / Source / JavaScriptCore / ChangeLog
1 2015-07-31  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2
3         Implement WebAssembly module parser
4         https://bugs.webkit.org/show_bug.cgi?id=147293
5
6         Reviewed by Mark Lam.
7
8         Re-landing after fix for the "..\..\jsc.cpp(46): fatal error C1083: Cannot open
9         include file: 'JSWASMModule.h'" issue on Windows.
10
11         Implement WebAssembly module parser for WebAssembly files produced by pack-asmjs
12         <https://github.com/WebAssembly/polyfill-prototype-1>. This patch only checks
13         the magic number at the beginning of the files. Parsing of the rest will be
14         implemented in a subsequent patch.
15
16         * CMakeLists.txt:
17         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
18         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
19         * JavaScriptCore.xcodeproj/project.pbxproj:
20         * jsc.cpp:
21         (GlobalObject::finishCreation):
22         (functionLoadWebAssembly):
23         * parser/SourceProvider.h:
24         (JSC::WebAssemblySourceProvider::create):
25         (JSC::WebAssemblySourceProvider::data):
26         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
27         * runtime/JSGlobalObject.cpp:
28         (JSC::JSGlobalObject::init):
29         (JSC::JSGlobalObject::visitChildren):
30         * runtime/JSGlobalObject.h:
31         (JSC::JSGlobalObject::wasmModuleStructure):
32         * wasm/WASMMagicNumber.h: Added.
33         * wasm/WASMModuleParser.cpp: Added.
34         (JSC::WASMModuleParser::WASMModuleParser):
35         (JSC::WASMModuleParser::parse):
36         (JSC::WASMModuleParser::parseModule):
37         (JSC::parseWebAssembly):
38         * wasm/WASMModuleParser.h: Added.
39         * wasm/WASMReader.cpp: Added.
40         (JSC::WASMReader::readUnsignedInt32):
41         (JSC::WASMReader::readFloat):
42         (JSC::WASMReader::readDouble):
43         * wasm/WASMReader.h: Added.
44         (JSC::WASMReader::WASMReader):
45
46 2015-07-30  Sukolsak Sakshuwong  <sukolsak@gmail.com>
47
48         Add the "wasm" directory to the Additional Include Directories for jsc.exe
49         https://bugs.webkit.org/show_bug.cgi?id=147443
50
51         Reviewed by Mark Lam.
52
53         This patch should fix the "..\..\jsc.cpp(46): fatal error C1083:
54         Cannot open include file: 'JSWASMModule.h'" error in the Windows build.
55
56         * JavaScriptCore.vcxproj/jsc/jscCommon.props:
57
58 2015-07-30  Chris Dumez  <cdumez@apple.com>
59
60         Mark more classes as fast allocated
61         https://bugs.webkit.org/show_bug.cgi?id=147440
62
63         Reviewed by Sam Weinig.
64
65         Mark more classes as fast allocated for performance. We heap-allocate
66         objects of those types throughout the code base.
67
68         * API/JSCallbackObject.h:
69         * API/ObjCCallbackFunction.mm:
70         * bytecode/BytecodeKills.h:
71         * bytecode/BytecodeLivenessAnalysis.h:
72         * bytecode/CallLinkStatus.h:
73         * bytecode/FullBytecodeLiveness.h:
74         * bytecode/SamplingTool.h:
75         * bytecompiler/BytecodeGenerator.h:
76         * dfg/DFGBasicBlock.h:
77         * dfg/DFGBlockMap.h:
78         * dfg/DFGInPlaceAbstractState.h:
79         * dfg/DFGThreadData.h:
80         * heap/HeapVerifier.h:
81         * heap/SlotVisitor.h:
82         * parser/Lexer.h:
83         * runtime/ControlFlowProfiler.h:
84         * runtime/TypeProfiler.h:
85         * runtime/TypeProfilerLog.h:
86         * runtime/Watchdog.h:
87
88 2015-07-29  Filip Pizlo  <fpizlo@apple.com>
89
90         DFG::ArgumentsEliminationPhase should emit a PutStack for all of the GetStacks that the ByteCodeParser emitted
91         https://bugs.webkit.org/show_bug.cgi?id=147433
92         rdar://problem/21668986
93
94         Reviewed by Mark Lam.
95
96         Ideally, the ByteCodeParser would only emit SetArgument nodes for named arguments.  But
97         currently that's not what it does - it emits a SetArgument for every argument that a varargs
98         call may pass.  Each SetArgument gets turned into a GetStack.  This means that if
99         ArgumentsEliminationPhase optimizes away PutStacks for those varargs arguments that didn't
100         get passed or used, we get degenerate IR where we have a GetStack of something that didn't
101         have a PutStack.
102
103         This fixes the bug by removing the code to optimize away PutStacks in
104         ArgumentsEliminationPhase.
105
106         * dfg/DFGArgumentsEliminationPhase.cpp:
107         * tests/stress/varargs-inlining-underflow.js: Added.
108         (baz):
109         (bar):
110         (foo):
111
112 2015-07-29  Andy VanWagoner  <thetalecrafter@gmail.com>
113
114         Implement basic types for ECMAScript Internationalization API
115         https://bugs.webkit.org/show_bug.cgi?id=146926
116
117         Reviewed by Benjamin Poulain.
118
119         Adds basic types for ECMA-402 2nd edition, but does not implement the full locale-aware features yet.
120         http://www.ecma-international.org/ecma-402/2.0/ECMA-402.pdf
121
122         * CMakeLists.txt: Added new Intl files.
123         * Configurations/FeatureDefines.xcconfig: Enable INTL.
124         * DerivedSources.make: Added Intl files.
125         * JavaScriptCore.xcodeproj/project.pbxproj: Added Intl files.
126         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added Intl files.
127         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Added Intl files.
128         * runtime/CommonIdentifiers.h: Added Collator, NumberFormat, and DateTimeFormat.
129         * runtime/DateConstructor.cpp: Made Date.now public.
130         * runtime/DateConstructor.h: Made Date.now public.
131         * runtime/IntlCollator.cpp: Added.
132         (JSC::IntlCollator::create):
133         (JSC::IntlCollator::createStructure):
134         (JSC::IntlCollator::IntlCollator):
135         (JSC::IntlCollator::finishCreation):
136         (JSC::IntlCollator::destroy):
137         (JSC::IntlCollator::visitChildren):
138         (JSC::IntlCollator::setBoundCompare):
139         (JSC::IntlCollatorFuncCompare): Added placeholder implementation using codePointCompare.
140         * runtime/IntlCollator.h: Added.
141         (JSC::IntlCollator::constructor):
142         (JSC::IntlCollator::boundCompare):
143         * runtime/IntlCollatorConstructor.cpp: Added.
144         (JSC::IntlCollatorConstructor::create):
145         (JSC::IntlCollatorConstructor::createStructure):
146         (JSC::IntlCollatorConstructor::IntlCollatorConstructor):
147         (JSC::IntlCollatorConstructor::finishCreation):
148         (JSC::constructIntlCollator): Added Collator constructor (10.1.2).
149         (JSC::callIntlCollator): Added Collator constructor (10.1.2).
150         (JSC::IntlCollatorConstructor::getConstructData):
151         (JSC::IntlCollatorConstructor::getCallData):
152         (JSC::IntlCollatorConstructor::getOwnPropertySlot):
153         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Added placeholder implementation returning [].
154         (JSC::IntlCollatorConstructor::visitChildren):
155         * runtime/IntlCollatorConstructor.h: Added.
156         (JSC::IntlCollatorConstructor::collatorStructure):
157         * runtime/IntlCollatorPrototype.cpp: Added.
158         (JSC::IntlCollatorPrototype::create):
159         (JSC::IntlCollatorPrototype::createStructure):
160         (JSC::IntlCollatorPrototype::IntlCollatorPrototype):
161         (JSC::IntlCollatorPrototype::finishCreation):
162         (JSC::IntlCollatorPrototype::getOwnPropertySlot):
163         (JSC::IntlCollatorPrototypeGetterCompare): Added compare getter (10.3.3)
164         (JSC::IntlCollatorPrototypeFuncResolvedOptions): Added placeholder implementation returning {}.
165         * runtime/IntlCollatorPrototype.h: Added.
166         * runtime/IntlDateTimeFormat.cpp: Added.
167         (JSC::IntlDateTimeFormat::create):
168         (JSC::IntlDateTimeFormat::createStructure):
169         (JSC::IntlDateTimeFormat::IntlDateTimeFormat):
170         (JSC::IntlDateTimeFormat::finishCreation):
171         (JSC::IntlDateTimeFormat::destroy):
172         (JSC::IntlDateTimeFormat::visitChildren):
173         (JSC::IntlDateTimeFormat::setBoundFormat):
174         (JSC::IntlDateTimeFormatFuncFormatDateTime): Added placeholder implementation returning new Date(value).toString().
175         * runtime/IntlDateTimeFormat.h: Added.
176         (JSC::IntlDateTimeFormat::constructor):
177         (JSC::IntlDateTimeFormat::boundFormat):
178         * runtime/IntlDateTimeFormatConstructor.cpp: Added.
179         (JSC::IntlDateTimeFormatConstructor::create):
180         (JSC::IntlDateTimeFormatConstructor::createStructure):
181         (JSC::IntlDateTimeFormatConstructor::IntlDateTimeFormatConstructor):
182         (JSC::IntlDateTimeFormatConstructor::finishCreation):
183         (JSC::constructIntlDateTimeFormat): Added DateTimeFormat constructor (12.1.2).
184         (JSC::callIntlDateTimeFormat): Added DateTimeFormat constructor (12.1.2).
185         (JSC::IntlDateTimeFormatConstructor::getConstructData):
186         (JSC::IntlDateTimeFormatConstructor::getCallData):
187         (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot):
188         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Added placeholder implementation returning [].
189         (JSC::IntlDateTimeFormatConstructor::visitChildren):
190         * runtime/IntlDateTimeFormatConstructor.h: Added.
191         (JSC::IntlDateTimeFormatConstructor::dateTimeFormatStructure):
192         * runtime/IntlDateTimeFormatPrototype.cpp: Added.
193         (JSC::IntlDateTimeFormatPrototype::create):
194         (JSC::IntlDateTimeFormatPrototype::createStructure):
195         (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
196         (JSC::IntlDateTimeFormatPrototype::finishCreation):
197         (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot):
198         (JSC::IntlDateTimeFormatPrototypeGetterFormat): Added format getter (12.3.3).
199         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): Added placeholder implementation returning {}.
200         * runtime/IntlDateTimeFormatPrototype.h: Added.
201         * runtime/IntlNumberFormat.cpp: Added.
202         (JSC::IntlNumberFormat::create):
203         (JSC::IntlNumberFormat::createStructure):
204         (JSC::IntlNumberFormat::IntlNumberFormat):
205         (JSC::IntlNumberFormat::finishCreation):
206         (JSC::IntlNumberFormat::destroy):
207         (JSC::IntlNumberFormat::visitChildren):
208         (JSC::IntlNumberFormat::setBoundFormat):
209         (JSC::IntlNumberFormatFuncFormatNumber): Added placeholder implementation returning Number(value).toString().
210         * runtime/IntlNumberFormat.h: Added.
211         (JSC::IntlNumberFormat::constructor):
212         (JSC::IntlNumberFormat::boundFormat):
213         * runtime/IntlNumberFormatConstructor.cpp: Added.
214         (JSC::IntlNumberFormatConstructor::create):
215         (JSC::IntlNumberFormatConstructor::createStructure):
216         (JSC::IntlNumberFormatConstructor::IntlNumberFormatConstructor):
217         (JSC::IntlNumberFormatConstructor::finishCreation):
218         (JSC::constructIntlNumberFormat): Added NumberFormat constructor (11.1.2).
219         (JSC::callIntlNumberFormat): Added NumberFormat constructor (11.1.2).
220         (JSC::IntlNumberFormatConstructor::getConstructData):
221         (JSC::IntlNumberFormatConstructor::getCallData):
222         (JSC::IntlNumberFormatConstructor::getOwnPropertySlot):
223         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Added placeholder implementation returning [].
224         (JSC::IntlNumberFormatConstructor::visitChildren):
225         * runtime/IntlNumberFormatConstructor.h: Added.
226         (JSC::IntlNumberFormatConstructor::numberFormatStructure):
227         * runtime/IntlNumberFormatPrototype.cpp: Added.
228         (JSC::IntlNumberFormatPrototype::create):
229         (JSC::IntlNumberFormatPrototype::createStructure):
230         (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
231         (JSC::IntlNumberFormatPrototype::finishCreation):
232         (JSC::IntlNumberFormatPrototype::getOwnPropertySlot):
233         (JSC::IntlNumberFormatPrototypeGetterFormat): Added format getter (11.3.3).
234         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions): Added placeholder implementation returning {}.
235         * runtime/IntlNumberFormatPrototype.h: Added.
236         * runtime/IntlObject.cpp:
237         (JSC::IntlObject::create):
238         (JSC::IntlObject::finishCreation): Added Collator, NumberFormat, and DateTimeFormat properties (8.1).
239         (JSC::IntlObject::visitChildren):
240         * runtime/IntlObject.h:
241         (JSC::IntlObject::collatorConstructor):
242         (JSC::IntlObject::collatorPrototype):
243         (JSC::IntlObject::collatorStructure):
244         (JSC::IntlObject::numberFormatConstructor):
245         (JSC::IntlObject::numberFormatPrototype):
246         (JSC::IntlObject::numberFormatStructure):
247         (JSC::IntlObject::dateTimeFormatConstructor):
248         (JSC::IntlObject::dateTimeFormatPrototype):
249         (JSC::IntlObject::dateTimeFormatStructure):
250         * runtime/JSGlobalObject.cpp:
251         (JSC::JSGlobalObject::init):
252
253 2015-07-29  Commit Queue  <commit-queue@webkit.org>
254
255         Unreviewed, rolling out r187550.
256         https://bugs.webkit.org/show_bug.cgi?id=147420
257
258         Broke Windows build (again) (Requested by smfr on #webkit).
259
260         Reverted changeset:
261
262         "Implement WebAssembly module parser"
263         https://bugs.webkit.org/show_bug.cgi?id=147293
264         http://trac.webkit.org/changeset/187550
265
266 2015-07-29  Basile Clement  <basile_clement@apple.com>
267
268         Remove native call inlining
269         https://bugs.webkit.org/show_bug.cgi?id=147417
270
271         Rubber Stamped by Filip Pizlo.
272
273         * CMakeLists.txt:
274         * dfg/DFGAbstractInterpreterInlines.h:
275         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
276         * dfg/DFGByteCodeParser.cpp:
277         (JSC::DFG::ByteCodeParser::handleCall): Deleted.
278         * dfg/DFGClobberize.h:
279         (JSC::DFG::clobberize): Deleted.
280         * dfg/DFGDoesGC.cpp:
281         (JSC::DFG::doesGC): Deleted.
282         * dfg/DFGFixupPhase.cpp:
283         (JSC::DFG::FixupPhase::fixupNode): Deleted.
284         * dfg/DFGNode.h:
285         (JSC::DFG::Node::hasHeapPrediction): Deleted.
286         (JSC::DFG::Node::hasCellOperand): Deleted.
287         * dfg/DFGNodeType.h:
288         * dfg/DFGPredictionPropagationPhase.cpp:
289         (JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
290         * dfg/DFGSafeToExecute.h:
291         (JSC::DFG::safeToExecute): Deleted.
292         * dfg/DFGSpeculativeJIT32_64.cpp:
293         (JSC::DFG::SpeculativeJIT::compile): Deleted.
294         * dfg/DFGSpeculativeJIT64.cpp:
295         (JSC::DFG::SpeculativeJIT::compile): Deleted.
296         * ftl/FTLCapabilities.cpp:
297         (JSC::FTL::canCompile): Deleted.
298         * ftl/FTLLowerDFGToLLVM.cpp:
299         (JSC::FTL::DFG::LowerDFGToLLVM::lower): Deleted.
300         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode): Deleted.
301         (JSC::FTL::DFG::LowerDFGToLLVM::compileNativeCallOrConstruct): Deleted.
302         (JSC::FTL::DFG::LowerDFGToLLVM::getFunctionBySymbol): Deleted.
303         (JSC::FTL::DFG::LowerDFGToLLVM::getModuleByPathForSymbol): Deleted.
304         (JSC::FTL::DFG::LowerDFGToLLVM::didOverflowStack): Deleted.
305         * ftl/FTLState.cpp:
306         (JSC::FTL::State::State): Deleted.
307         * ftl/FTLState.h:
308         * runtime/BundlePath.cpp: Removed.
309         (JSC::bundlePath): Deleted.
310         * runtime/JSDataViewPrototype.cpp:
311         (JSC::getData):
312         (JSC::setData):
313         * runtime/Options.h:
314
315 2015-07-29  Basile Clement  <basile_clement@apple.com>
316
317         Unreviewed, skipping a test that is too complex for its own good
318         https://bugs.webkit.org/show_bug.cgi?id=147167
319
320         * tests/stress/math-pow-coherency.js:
321
322 2015-07-29  Sukolsak Sakshuwong  <sukolsak@gmail.com>
323
324         Implement WebAssembly module parser
325         https://bugs.webkit.org/show_bug.cgi?id=147293
326
327         Reviewed by Mark Lam.
328
329         Reupload the patch, since r187539 should fix the "Cannot open include file:
330         'JSWASMModule.h'" issue in the Windows build.
331
332         * CMakeLists.txt:
333         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
334         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
335         * JavaScriptCore.xcodeproj/project.pbxproj:
336         * jsc.cpp:
337         (GlobalObject::finishCreation):
338         (functionLoadWebAssembly):
339         * parser/SourceProvider.h:
340         (JSC::WebAssemblySourceProvider::create):
341         (JSC::WebAssemblySourceProvider::data):
342         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
343         * runtime/JSGlobalObject.cpp:
344         (JSC::JSGlobalObject::init):
345         (JSC::JSGlobalObject::visitChildren):
346         * runtime/JSGlobalObject.h:
347         (JSC::JSGlobalObject::wasmModuleStructure):
348         * wasm/WASMMagicNumber.h: Added.
349         * wasm/WASMModuleParser.cpp: Added.
350         (JSC::WASMModuleParser::WASMModuleParser):
351         (JSC::WASMModuleParser::parse):
352         (JSC::WASMModuleParser::parseModule):
353         (JSC::parseWebAssembly):
354         * wasm/WASMModuleParser.h: Added.
355         * wasm/WASMReader.cpp: Added.
356         (JSC::WASMReader::readUnsignedInt32):
357         (JSC::WASMReader::readFloat):
358         (JSC::WASMReader::readDouble):
359         * wasm/WASMReader.h: Added.
360         (JSC::WASMReader::WASMReader):
361
362 2015-07-29  Basile Clement  <basile_clement@apple.com>
363
364         Unreviewed, lower the number of test iterations to prevent timing out on Debug builds
365         https://bugs.webkit.org/show_bug.cgi?id=147167
366
367         * tests/stress/math-pow-coherency.js:
368
369 2015-07-28  Sukolsak Sakshuwong  <sukolsak@gmail.com>
370
371         Add the "wasm" directory to Visual Studio project files
372         https://bugs.webkit.org/show_bug.cgi?id=147400
373
374         Reviewed by Simon Fraser.
375
376         This patch should fix the "Cannot open include file: 'JSWASMModule.h'" issue
377         in the Windows build.
378
379         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
380         * JavaScriptCore.vcxproj/copy-files.cmd:
381
382 2015-07-28  Commit Queue  <commit-queue@webkit.org>
383
384         Unreviewed, rolling out r187531.
385         https://bugs.webkit.org/show_bug.cgi?id=147397
386
387         Broke Windows bild (Requested by smfr on #webkit).
388
389         Reverted changeset:
390
391         "Implement WebAssembly module parser"
392         https://bugs.webkit.org/show_bug.cgi?id=147293
393         http://trac.webkit.org/changeset/187531
394
395 2015-07-28  Benjamin Poulain  <bpoulain@apple.com>
396
397         Speed up the Stringifier::toJSON() fast case
398         https://bugs.webkit.org/show_bug.cgi?id=147383
399
400         Reviewed by Andreas Kling.
401
402         * runtime/JSONObject.cpp:
403         (JSC::Stringifier::toJSON):
404         (JSC::Stringifier::toJSONImpl):
405
406 2015-07-28  Sukolsak Sakshuwong  <sukolsak@gmail.com>
407
408         Implement WebAssembly module parser
409         https://bugs.webkit.org/show_bug.cgi?id=147293
410
411         Reviewed by Geoffrey Garen.
412
413         Implement WebAssembly module parser for WebAssembly files produced by pack-asmjs
414         <https://github.com/WebAssembly/polyfill-prototype-1>. This patch only checks
415         the magic number at the beginning of the files. Parsing of the rest will be
416         implemented in a subsequent patch.
417
418         * CMakeLists.txt:
419         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
420         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
421         * JavaScriptCore.xcodeproj/project.pbxproj:
422         * jsc.cpp:
423         (GlobalObject::finishCreation):
424         (functionLoadWebAssembly):
425         * parser/SourceProvider.h:
426         (JSC::WebAssemblySourceProvider::create):
427         (JSC::WebAssemblySourceProvider::data):
428         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
429         * runtime/JSGlobalObject.cpp:
430         (JSC::JSGlobalObject::init):
431         (JSC::JSGlobalObject::visitChildren):
432         * runtime/JSGlobalObject.h:
433         (JSC::JSGlobalObject::wasmModuleStructure):
434         * wasm/WASMMagicNumber.h: Added.
435         * wasm/WASMModuleParser.cpp: Added.
436         (JSC::WASMModuleParser::WASMModuleParser):
437         (JSC::WASMModuleParser::parse):
438         (JSC::WASMModuleParser::parseModule):
439         (JSC::parseWebAssembly):
440         * wasm/WASMModuleParser.h: Added.
441         * wasm/WASMReader.cpp: Added.
442         (JSC::WASMReader::readUnsignedInt32):
443         (JSC::WASMReader::readFloat):
444         (JSC::WASMReader::readDouble):
445         * wasm/WASMReader.h: Added.
446         (JSC::WASMReader::WASMReader):
447
448 2015-07-28  Yusuke Suzuki  <utatane.tea@gmail.com>
449
450         [ES6] Add ENABLE_ES6_MODULES compile time flag with the default value "false"
451         https://bugs.webkit.org/show_bug.cgi?id=147350
452
453         Reviewed by Sam Weinig.
454
455         * Configurations/FeatureDefines.xcconfig:
456
457 2015-07-28  Saam barati  <saambarati1@gmail.com>
458
459         Make the type profiler work with lexical scoping and add tests
460         https://bugs.webkit.org/show_bug.cgi?id=145438
461
462         Reviewed by Geoffrey Garen.
463
464         op_profile_type now knows how to resolve variables allocated within
465         the local scope stack. This means it knows how to resolve "let"
466         and "const" variables. Also, some refactoring was done inside
467         the BytecodeGenerator to make writing code to support the type
468         profiler much simpler and clearer.
469
470         * bytecode/CodeBlock.cpp:
471         (JSC::CodeBlock::CodeBlock):
472         * bytecode/CodeBlock.h:
473         (JSC::CodeBlock::symbolTable): Deleted.
474         * bytecode/UnlinkedCodeBlock.h:
475         (JSC::UnlinkedCodeBlock::addExceptionHandler):
476         (JSC::UnlinkedCodeBlock::exceptionHandler):
477         (JSC::UnlinkedCodeBlock::vm):
478         (JSC::UnlinkedCodeBlock::addArrayProfile):
479         (JSC::UnlinkedCodeBlock::setSymbolTableConstantIndex): Deleted.
480         (JSC::UnlinkedCodeBlock::symbolTableConstantIndex): Deleted.
481         * bytecompiler/BytecodeGenerator.cpp:
482         (JSC::BytecodeGenerator::BytecodeGenerator):
483         (JSC::BytecodeGenerator::emitMove):
484         (JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
485         (JSC::BytecodeGenerator::emitProfileType):
486         (JSC::BytecodeGenerator::emitProfileControlFlow):
487         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
488         * bytecompiler/BytecodeGenerator.h:
489         (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
490         * bytecompiler/NodesCodegen.cpp:
491         (JSC::ThisNode::emitBytecode):
492         (JSC::ResolveNode::emitBytecode):
493         (JSC::BracketAccessorNode::emitBytecode):
494         (JSC::DotAccessorNode::emitBytecode):
495         (JSC::FunctionCallValueNode::emitBytecode):
496         (JSC::FunctionCallResolveNode::emitBytecode):
497         (JSC::FunctionCallBracketNode::emitBytecode):
498         (JSC::FunctionCallDotNode::emitBytecode):
499         (JSC::CallFunctionCallDotNode::emitBytecode):
500         (JSC::ApplyFunctionCallDotNode::emitBytecode):
501         (JSC::PostfixNode::emitResolve):
502         (JSC::PostfixNode::emitBracket):
503         (JSC::PostfixNode::emitDot):
504         (JSC::PrefixNode::emitResolve):
505         (JSC::PrefixNode::emitBracket):
506         (JSC::PrefixNode::emitDot):
507         (JSC::ReadModifyResolveNode::emitBytecode):
508         (JSC::AssignResolveNode::emitBytecode):
509         (JSC::AssignDotNode::emitBytecode):
510         (JSC::ReadModifyDotNode::emitBytecode):
511         (JSC::AssignBracketNode::emitBytecode):
512         (JSC::ReadModifyBracketNode::emitBytecode):
513         (JSC::EmptyVarExpression::emitBytecode):
514         (JSC::EmptyLetExpression::emitBytecode):
515         (JSC::ForInNode::emitLoopHeader):
516         (JSC::ForOfNode::emitBytecode):
517         (JSC::ReturnNode::emitBytecode):
518         (JSC::FunctionNode::emitBytecode):
519         (JSC::BindingNode::bindValue):
520         * dfg/DFGSpeculativeJIT32_64.cpp:
521         (JSC::DFG::SpeculativeJIT::compile):
522         * dfg/DFGSpeculativeJIT64.cpp:
523         (JSC::DFG::SpeculativeJIT::compile):
524         * jit/JITOpcodes.cpp:
525         (JSC::JIT::emit_op_profile_type):
526         * jit/JITOpcodes32_64.cpp:
527         (JSC::JIT::emit_op_profile_type):
528         * llint/LowLevelInterpreter32_64.asm:
529         * llint/LowLevelInterpreter64.asm:
530         * tests/typeProfiler/es6-block-scoping.js: Added.
531         (noop):
532         (arr):
533         (wrapper.changeFoo):
534         (wrapper.scoping):
535         (wrapper.scoping2):
536         (wrapper):
537         * tests/typeProfiler/es6-classes.js: Added.
538         (noop):
539         (wrapper.Animal):
540         (wrapper.Animal.prototype.methodA):
541         (wrapper.Dog):
542         (wrapper.Dog.prototype.methodB):
543         (wrapper):
544
545 2015-07-28  Saam barati  <saambarati1@gmail.com>
546
547         Implement catch scope using lexical scoping constructs introduced with "let" scoping patch
548         https://bugs.webkit.org/show_bug.cgi?id=146979
549
550         Reviewed by Geoffrey Garen.
551
552         Now that BytecodeGenerator has a notion of local scope depth,
553         we can easily implement a catch scope that doesn't claim that
554         all variables are dynamically scoped. This means that functions
555         that use try/catch can have local variable resolution. This also
556         means that all functions that use try/catch don't have all
557         their variables marked as being captured.
558
559         Catch scopes now behave like a "let" scope (sans the TDZ logic) with a 
560         single variable. Catch scopes are now just JSLexicalEnvironments and the 
561         symbol table backing the catch scope knows that it corresponds to a catch scope.
562
563         * CMakeLists.txt:
564         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
565         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
566         * JavaScriptCore.xcodeproj/project.pbxproj:
567         * bytecode/CodeBlock.cpp:
568         (JSC::CodeBlock::dumpBytecode):
569         * bytecode/EvalCodeCache.h:
570         (JSC::EvalCodeCache::isCacheable):
571         * bytecompiler/BytecodeGenerator.cpp:
572         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
573         (JSC::BytecodeGenerator::emitLoadGlobalObject):
574         (JSC::BytecodeGenerator::pushLexicalScope):
575         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
576         (JSC::BytecodeGenerator::popLexicalScope):
577         (JSC::BytecodeGenerator::popLexicalScopeInternal):
578         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
579         (JSC::BytecodeGenerator::variable):
580         (JSC::BytecodeGenerator::resolveType):
581         (JSC::BytecodeGenerator::emitResolveScope):
582         (JSC::BytecodeGenerator::emitPopScope):
583         (JSC::BytecodeGenerator::emitPopWithScope):
584         (JSC::BytecodeGenerator::emitDebugHook):
585         (JSC::BytecodeGenerator::popScopedControlFlowContext):
586         (JSC::BytecodeGenerator::emitPushCatchScope):
587         (JSC::BytecodeGenerator::emitPopCatchScope):
588         (JSC::BytecodeGenerator::beginSwitch):
589         (JSC::BytecodeGenerator::emitPopWithOrCatchScope): Deleted.
590         * bytecompiler/BytecodeGenerator.h:
591         (JSC::BytecodeGenerator::lastOpcodeID):
592         * bytecompiler/NodesCodegen.cpp:
593         (JSC::AssignResolveNode::emitBytecode):
594         (JSC::WithNode::emitBytecode):
595         (JSC::TryNode::emitBytecode):
596         * debugger/DebuggerScope.cpp:
597         (JSC::DebuggerScope::isCatchScope):
598         (JSC::DebuggerScope::isFunctionNameScope):
599         (JSC::DebuggerScope::isFunctionOrEvalScope):
600         (JSC::DebuggerScope::caughtValue):
601         * debugger/DebuggerScope.h:
602         * inspector/ScriptDebugServer.cpp:
603         (Inspector::ScriptDebugServer::exceptionOrCaughtValue):
604         * interpreter/Interpreter.cpp:
605         (JSC::Interpreter::execute):
606         * jit/JITOpcodes.cpp:
607         (JSC::JIT::emit_op_push_name_scope):
608         * jit/JITOpcodes32_64.cpp:
609         (JSC::JIT::emit_op_push_name_scope):
610         * jit/JITOperations.cpp:
611         * jit/JITOperations.h:
612         * parser/ASTBuilder.h:
613         (JSC::ASTBuilder::createContinueStatement):
614         (JSC::ASTBuilder::createTryStatement):
615         * parser/NodeConstructors.h:
616         (JSC::ThrowNode::ThrowNode):
617         (JSC::TryNode::TryNode):
618         (JSC::FunctionParameters::FunctionParameters):
619         * parser/Nodes.h:
620         * parser/Parser.cpp:
621         (JSC::Parser<LexerType>::parseTryStatement):
622         * parser/SyntaxChecker.h:
623         (JSC::SyntaxChecker::createBreakStatement):
624         (JSC::SyntaxChecker::createContinueStatement):
625         (JSC::SyntaxChecker::createTryStatement):
626         (JSC::SyntaxChecker::createSwitchStatement):
627         (JSC::SyntaxChecker::createWhileStatement):
628         (JSC::SyntaxChecker::createWithStatement):
629         * runtime/JSCatchScope.cpp:
630         * runtime/JSCatchScope.h:
631         (JSC::JSCatchScope::JSCatchScope): Deleted.
632         (JSC::JSCatchScope::create): Deleted.
633         (JSC::JSCatchScope::createStructure): Deleted.
634         * runtime/JSFunctionNameScope.h:
635         (JSC::JSFunctionNameScope::JSFunctionNameScope):
636         * runtime/JSGlobalObject.cpp:
637         (JSC::JSGlobalObject::init):
638         (JSC::JSGlobalObject::visitChildren):
639         * runtime/JSGlobalObject.h:
640         (JSC::JSGlobalObject::withScopeStructure):
641         (JSC::JSGlobalObject::strictEvalActivationStructure):
642         (JSC::JSGlobalObject::activationStructure):
643         (JSC::JSGlobalObject::functionNameScopeStructure):
644         (JSC::JSGlobalObject::directArgumentsStructure):
645         (JSC::JSGlobalObject::scopedArgumentsStructure):
646         (JSC::JSGlobalObject::catchScopeStructure): Deleted.
647         * runtime/JSNameScope.cpp:
648         (JSC::JSNameScope::create):
649         (JSC::JSNameScope::toThis):
650         * runtime/JSNameScope.h:
651         * runtime/JSObject.cpp:
652         (JSC::JSObject::toThis):
653         (JSC::JSObject::isFunctionNameScopeObject):
654         (JSC::JSObject::isCatchScopeObject): Deleted.
655         * runtime/JSObject.h:
656         * runtime/JSScope.cpp:
657         (JSC::JSScope::collectVariablesUnderTDZ):
658         (JSC::JSScope::isLexicalScope):
659         (JSC::JSScope::isCatchScope):
660         (JSC::resolveModeName):
661         * runtime/JSScope.h:
662         * runtime/SymbolTable.cpp:
663         (JSC::SymbolTable::SymbolTable):
664         (JSC::SymbolTable::cloneScopePart):
665         * runtime/SymbolTable.h:
666         * tests/stress/const-semantics.js:
667         (.):
668
669 2015-07-28  Filip Pizlo  <fpizlo@apple.com>
670
671         DFG::ArgumentsEliminationPhase has a redundant check for inserting CheckInBounds when converting GetByVal to GetStack in the inline non-varargs case
672         https://bugs.webkit.org/show_bug.cgi?id=147373
673
674         Reviewed by Mark Lam.
675
676         The code was doing a check for "index >= inlineCallFrame->arguments.size() - 1" in code where
677         safeToGetStack is true and we aren't in varargs context, but in a non-varargs context,
678         safeToGetStack can only be true if "index < inlineCallFrame->arguments.size() - 1".
679
680         When converting a GetByVal to GetStack, there are three possibilities:
681
682         1) Impossible to convert. This can happen if the GetByVal is out-of-bounds of the things we
683            know to have stored to the stack. For example, if we inline a function that does
684            "arguments[42]" at a call that passes no arguments.
685
686         2) Possible to convert, but we cannot prove statically that the GetByVal was in bounds. This
687            can happen for "arguments[42]" with no inline call frame (since we don't know statically
688            how many arguments we will be passed) or in a varargs call frame.
689
690         3) Possible to convert, and we know statically that the GetByVal is in bounds. This can
691            happen for "arguments[42]" if we have an inline call frame, and it's not a varargs call
692            frame, and we know that the caller passed 42 or more arguments.
693
694         The way the phase handles this is it first determines that we're not in case (1). This is
695         called safeToGetStack. safeToGetStack is true if we have case (2) or (3). For inline call
696         frames that have no varargs, this means that safeToGetStack is true exactly when the GetByVal
697         is in-bounds (i.e. case (3)).
698
699         But the phase was again doing a check for whether the index is in-bounds for non-varargs
700         inline call frames even when safeToGetStack was true. That check is redundant and should be
701         eliminated, since it makes the code confusing.
702
703         * dfg/DFGArgumentsEliminationPhase.cpp:
704
705 2015-07-28  Filip Pizlo  <fpizlo@apple.com>
706
707         DFG::PutStackSinkingPhase should be more aggressive about its "no GetStack until put" rule
708         https://bugs.webkit.org/show_bug.cgi?id=147371
709
710         Reviewed by Mark Lam.
711
712         Two fixes:
713
714         - Make ConflictingFlush really mean that you can't load from the stack slot. This means not
715           using ConflictingFlush for arguments.
716
717         - Assert that a GetStack never sees ConflictingFlush.
718
719         * dfg/DFGPutStackSinkingPhase.cpp:
720
721 2015-07-28  Basile Clement  <basile_clement@apple.com>
722
723         Misleading error message: "At least one digit must occur after a decimal point"
724         https://bugs.webkit.org/show_bug.cgi?id=146238
725
726         Reviewed by Geoffrey Garen.
727
728         Interestingly, we had a comment explaining what this error message was
729         about that is much clearer than the error message itself. This patch
730         simply replaces the error message with the explanation from the
731         comment.
732
733         * parser/Lexer.cpp:
734         (JSC::Lexer<T>::lex):
735
736 2015-07-28  Basile Clement  <basile_clement@apple.com>
737
738         Simplify call linking
739         https://bugs.webkit.org/show_bug.cgi?id=147363
740
741         Reviewed by Filip Pizlo.
742
743         Previously, we were passing both the CallLinkInfo and a
744         (CodeSpecializationKind, RegisterPreservationMode) pair to the
745         different call linking slow paths. However, the CallLinkInfo already
746         has all of that information, and we don't gain anything by having them
747         in additional static parameters - except possibly a very small
748         performance gain in presence of inlining. However since those are
749         already slow paths, this performance loss (if it exists) will not be
750         visible in practice.
751
752         This patch removes the various specialized thunks and JIT operations
753         for regular and polymorphic call linking with a single thunk and
754         operation for each case. Moreover, it removes the four specialized
755         virtual call thunks and operations with one virtual call thunk for each
756         call link info, allowing for better branch prediction by the CPU and
757         fixing a pre-existing FIXME.
758
759         * bytecode/CallLinkInfo.cpp:
760         (JSC::CallLinkInfo::unlink):
761         (JSC::CallLinkInfo::dummy): Deleted.
762         * bytecode/CallLinkInfo.h:
763         (JSC::CallLinkInfo::CallLinkInfo):
764         (JSC::CallLinkInfo::registerPreservationMode):
765         (JSC::CallLinkInfo::setUpCallFromFTL):
766         (JSC::CallLinkInfo::setSlowStub):
767         (JSC::CallLinkInfo::clearSlowStub):
768         (JSC::CallLinkInfo::slowStub):
769         * dfg/DFGDriver.cpp:
770         (JSC::DFG::compileImpl):
771         * dfg/DFGJITCompiler.cpp:
772         (JSC::DFG::JITCompiler::link):
773         * ftl/FTLJSCallBase.cpp:
774         (JSC::FTL::JSCallBase::link):
775         * jit/JITCall.cpp:
776         (JSC::JIT::compileCallEvalSlowCase):
777         (JSC::JIT::compileOpCall):
778         (JSC::JIT::compileOpCallSlowCase):
779         * jit/JITCall32_64.cpp:
780         (JSC::JIT::compileCallEvalSlowCase):
781         (JSC::JIT::compileOpCall):
782         (JSC::JIT::compileOpCallSlowCase):
783         * jit/JITOperations.cpp:
784         * jit/JITOperations.h:
785         (JSC::operationLinkFor): Deleted.
786         (JSC::operationVirtualFor): Deleted.
787         (JSC::operationLinkPolymorphicCallFor): Deleted.
788         * jit/Repatch.cpp:
789         (JSC::generateByIdStub):
790         (JSC::linkSlowFor):
791         (JSC::linkFor):
792         (JSC::revertCall):
793         (JSC::unlinkFor):
794         (JSC::linkVirtualFor):
795         (JSC::linkPolymorphicCall):
796         * jit/Repatch.h:
797         * jit/ThunkGenerators.cpp:
798         (JSC::linkCallThunkGenerator):
799         (JSC::linkPolymorphicCallThunkGenerator):
800         (JSC::virtualThunkFor):
801         (JSC::linkForThunkGenerator): Deleted.
802         (JSC::linkConstructThunkGenerator): Deleted.
803         (JSC::linkCallThatPreservesRegsThunkGenerator): Deleted.
804         (JSC::linkConstructThatPreservesRegsThunkGenerator): Deleted.
805         (JSC::linkPolymorphicCallForThunkGenerator): Deleted.
806         (JSC::linkPolymorphicCallThatPreservesRegsThunkGenerator): Deleted.
807         (JSC::virtualForThunkGenerator): Deleted.
808         (JSC::virtualCallThunkGenerator): Deleted.
809         (JSC::virtualConstructThunkGenerator): Deleted.
810         (JSC::virtualCallThatPreservesRegsThunkGenerator): Deleted.
811         (JSC::virtualConstructThatPreservesRegsThunkGenerator): Deleted.
812         * jit/ThunkGenerators.h:
813         (JSC::linkThunkGeneratorFor): Deleted.
814         (JSC::linkPolymorphicCallThunkGeneratorFor): Deleted.
815         (JSC::virtualThunkGeneratorFor): Deleted.
816
817 2015-07-28  Basile Clement  <basile_clement@apple.com>
818
819         stress/math-pow-with-constants.js fails in cloop
820         https://bugs.webkit.org/show_bug.cgi?id=147167
821
822         Reviewed by Geoffrey Garen.
823
824         Baseline JIT, DFG and FTL are using a fast exponentiation fast path
825         when computing Math.pow() with an integer exponent that is not taken in
826         the LLInt (or the DFG abstract interpreter). This leads to the result
827         of pow changing depending on the compilation tier or the fact that
828         constant propagation kicks in, which is undesirable.
829
830         This patch adds the fast path to the slow operationMathPow in order to
831         maintain an illusion of consistency.
832
833         * runtime/MathCommon.cpp:
834         (JSC::operationMathPow):
835         * tests/stress/math-pow-coherency.js: Added.
836         (pow42):
837         (build42AsDouble.opaqueAdd):
838         (build42AsDouble):
839         (powDouble42):
840         (clobber):
841         (pow42NoConstantFolding):
842         (powDouble42NoConstantFolding):
843
844 2015-07-28  Joseph Pecoraro  <pecoraro@apple.com>
845
846         Web Inspector: Show Pseudo Elements in DOM Tree
847         https://bugs.webkit.org/show_bug.cgi?id=139612
848
849         Reviewed by Timothy Hatcher.
850
851         * inspector/protocol/DOM.json:
852         Add new properties to DOMNode if it is a pseudo element or if it has
853         pseudo element children. Add new events for if a pseudo element is
854         added or removed dynamically to an existing DOMNode.
855
856 2015-07-27  Filip Pizlo  <fpizlo@apple.com>
857
858         Add logging when executable code gets deallocated
859         https://bugs.webkit.org/show_bug.cgi?id=147355
860
861         Reviewed by Mark Lam.
862
863         * ftl/FTLJITCode.cpp:
864         (JSC::FTL::JITCode::~JITCode): Print something when this is freed.
865         * jit/JITCode.cpp:
866         (JSC::JITCodeWithCodeRef::~JITCodeWithCodeRef): Print something when this is freed.
867
868 2015-07-27  Filip Pizlo  <fpizlo@apple.com>
869
870         DFG::safeToExecute() cases for GetByOffset/PutByOffset don't handle clobbered structure abstract values correctly
871         https://bugs.webkit.org/show_bug.cgi?id=147354
872
873         Reviewed by Michael Saboff.
874
875         If m_structure.isClobbered(), it means that we had a side effect that clobbered
876         the abstract value but it may recover back to its original value at the next
877         invalidation point. Since the invalidation point hasn't been reached yet, we need
878         to conservatively treat the clobbered state as if it was top. At the invalidation
879         point, the clobbered set will return back to being unclobbered.
880
881         In addition to fixing the bug, this introduces isInfinite(), which should be used
882         in places where it's tempting to just use isTop().
883
884         * dfg/DFGSafeToExecute.h:
885         (JSC::DFG::safeToExecute): Fix the bug.
886         * dfg/DFGStructureAbstractValue.cpp:
887         (JSC::DFG::StructureAbstractValue::contains): Switch to using isInfinite().
888         (JSC::DFG::StructureAbstractValue::isSubsetOf): Switch to using isInfinite().
889         (JSC::DFG::StructureAbstractValue::isSupersetOf): Switch to using isInfinite().
890         (JSC::DFG::StructureAbstractValue::overlaps): Switch to using isInfinite().
891         * dfg/DFGStructureAbstractValue.h:
892         (JSC::DFG::StructureAbstractValue::isFinite): New convenience method.
893         (JSC::DFG::StructureAbstractValue::isInfinite): New convenience method.
894         (JSC::DFG::StructureAbstractValue::onlyStructure): Switch to using isInfinite().
895
896 2015-07-27  Yusuke Suzuki  <utatane.tea@gmail.com>
897
898         [ES6] Implement Reflect.enumerate
899         https://bugs.webkit.org/show_bug.cgi?id=147347
900
901         Reviewed by Sam Weinig.
902
903         This patch implements Reflect.enumerate.
904         It returns the iterator that iterates the enumerable keys of the given object.
905         It follows the for-in's enumeration order.
906
907         To implement it, we write down the same logic to the for-in's enumeration code in C++.
908
909         * CMakeLists.txt:
910         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
911         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
912         * JavaScriptCore.xcodeproj/project.pbxproj:
913         * runtime/JSGlobalObject.cpp:
914         (JSC::JSGlobalObject::init):
915         (JSC::JSGlobalObject::visitChildren):
916         * runtime/JSGlobalObject.h:
917         (JSC::JSGlobalObject::propertyNameIteratorStructure):
918         * runtime/JSPropertyNameIterator.cpp: Added.
919         (JSC::JSPropertyNameIterator::JSPropertyNameIterator):
920         (JSC::JSPropertyNameIterator::clone):
921         (JSC::JSPropertyNameIterator::create):
922         (JSC::JSPropertyNameIterator::finishCreation):
923         (JSC::JSPropertyNameIterator::visitChildren):
924         (JSC::JSPropertyNameIterator::next):
925         (JSC::propertyNameIteratorFuncNext):
926         * runtime/JSPropertyNameIterator.h: Added.
927         (JSC::JSPropertyNameIterator::createStructure):
928         * runtime/ReflectObject.cpp:
929         (JSC::reflectObjectEnumerate):
930         * tests/stress/reflect-enumerate.js: Added.
931         (shouldBe):
932         (shouldThrow):
933
934 2015-07-27  Yusuke Suzuki  <utatane.tea@gmail.com>
935
936         [ES6] Implement Reflect.preventExtensions
937         https://bugs.webkit.org/show_bug.cgi?id=147331
938
939         Reviewed by Sam Weinig.
940
941         Implement Reflect.preventExtensions.
942         This is different from Object.preventExensions.
943
944         1. When preventExtensions is called onto the non-object, it raises the TypeError.
945         2. Reflect.preventExtensions does not raise the TypeError when the preventExtensions operation is failed.
946
947         For the (2) case, since there is no Proxy implementation currently, Reflect.preventExtensions always succeed.
948
949         * runtime/ReflectObject.cpp:
950         (JSC::reflectObjectPreventExtensions):
951         * tests/stress/reflect-prevent-extensions.js: Added.
952         (shouldBe):
953         (shouldThrow):
954
955 2015-07-27  Alex Christensen  <achristensen@webkit.org>
956
957         Use Ninja on Windows.
958         https://bugs.webkit.org/show_bug.cgi?id=147228
959
960         Reviewed by Martin Robinson.
961
962         * CMakeLists.txt:
963         Set the working directory when generating LowLevelInterpreterWin.asm to put LowLevelInterpreterWin.asm.sym in the right place.
964
965 2015-07-27  Yusuke Suzuki  <utatane.tea@gmail.com>
966
967         SparseValueMap check is skipped when the butterfly's vectorLength is larger than the access-requested index
968         https://bugs.webkit.org/show_bug.cgi?id=147265
969
970         Reviewed by Geoffrey Garen.
971
972         JSObject's vector holds the indexed values and we leverage it to represent stored values and holes.
973         By checking that the given index is in-bound of the vector's length, we can look up the property fast.
974         And for the sparse array, we have also the separated SparseValueMap to hold the pairs.
975         And we need to take care that the length of the vector should not overlap the indices stored in the SparseValueMap.
976
977         The vector only holds the pure JS values to avoid additional checking for accessors when looking up the value
978         from the vector. To achieve this, we also store the accessors (and attributed properties) to SparseValueMap
979         even the index is less than MIN_SPARSE_ARRAY_INDEX.
980
981         As a result, if the length of the vector overlaps the indices of the accessors stored in the SparseValueMap,
982         we accidentally skip the phase looking up from the SparseValueMap. Instead, we just load from the vector and
983         if the loaded value is an array hole, we decide the given object does not have the value for the given index.
984
985         This patch fixes the problem.
986         When defining the attributed value that index is smaller than the length of the vector, we throw away the vector
987         and change the object to DictionaryIndexingMode. Since we can assume that indexed accessors rarely exist in
988         practice, we expect this does not hurt the performance while keeping the fast property access system without
989         checking the sparse map.
990
991         * runtime/JSObject.cpp:
992         (JSC::JSObject::putDirectIndexBeyondVectorLength):
993         * tests/stress/sparse-map-non-overlapping.js: Added.
994         (shouldBe):
995         (testing):
996         (object.get 1000):
997         * tests/stress/sparse-map-non-skip-getter-overriding.js: Added.
998         (shouldBe):
999         (obj.get 1):
1000         (testing):
1001         * tests/stress/sparse-map-non-skip.js: Added.
1002         (shouldBe):
1003         (testing):
1004         (testing2):
1005         (.get for):
1006
1007 2015-07-27  Saam barati  <saambarati1@gmail.com>
1008
1009         Reduce execution time for "let" and "const" tests
1010         https://bugs.webkit.org/show_bug.cgi?id=147291
1011
1012         Reviewed by Geoffrey Garen.
1013
1014         We don't need to loop so many times for things that will not make it 
1015         into the DFG.  Also, we can loop a lot less for almost all the tests 
1016         because they're mostly testing the bytecode generator.
1017
1018         * tests/stress/const-and-with-statement.js:
1019         * tests/stress/const-exception-handling.js:
1020         * tests/stress/const-loop-semantics.js:
1021         * tests/stress/const-not-strict-mode.js:
1022         * tests/stress/const-semantics.js:
1023         * tests/stress/const-tdz.js:
1024         * tests/stress/lexical-let-and-with-statement.js:
1025         * tests/stress/lexical-let-exception-handling.js:
1026         (assert):
1027         * tests/stress/lexical-let-loop-semantics.js:
1028         (assert):
1029         (shouldThrowTDZ):
1030         (.):
1031         * tests/stress/lexical-let-not-strict-mode.js:
1032         * tests/stress/lexical-let-semantics.js:
1033         (.):
1034         * tests/stress/lexical-let-tdz.js:
1035         (shouldThrowTDZ):
1036         (.):
1037
1038 2015-07-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1039
1040         Rename PropertyNameMode::Both to PropertyNameMode::StringsAndSymbols
1041         https://bugs.webkit.org/show_bug.cgi?id=147311
1042
1043         Reviewed by Sam Weinig.
1044
1045         To make the meaning clear in the user side (PropertyNameArray array(exec, PropertyNameMode::StringsAndSymbols)),
1046         this patch renames PropertyNameMode::Both to PropertyNameMode::StringsAndSymbols.
1047
1048         * bytecode/ObjectAllocationProfile.h:
1049         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
1050         * runtime/EnumerationMode.h:
1051         * runtime/ObjectConstructor.cpp:
1052         (JSC::ownEnumerablePropertyKeys):
1053         (JSC::defineProperties):
1054         (JSC::objectConstructorSeal):
1055         (JSC::objectConstructorFreeze):
1056         (JSC::objectConstructorIsSealed):
1057         (JSC::objectConstructorIsFrozen):
1058         (JSC::ownPropertyKeys):
1059         * runtime/ReflectObject.cpp:
1060         (JSC::reflectObjectOwnKeys):
1061
1062 2015-07-27  Saam barati  <saambarati1@gmail.com>
1063
1064         Added a comment explaining that all "addVar()"s should happen before
1065         emitting bytecode for a function's default parameter expressions
1066
1067         Rubber Stamped by Mark Lam.
1068
1069         * bytecompiler/BytecodeGenerator.cpp:
1070         (JSC::BytecodeGenerator::BytecodeGenerator):
1071
1072 2015-07-26  Sam Weinig  <sam@webkit.org>
1073
1074         Add missing builtin files to the JavaScriptCore Xcode project
1075         https://bugs.webkit.org/show_bug.cgi?id=147312
1076
1077         Reviewed by Darin Adler.
1078
1079         * JavaScriptCore.xcodeproj/project.pbxproj:
1080         Add missing files.
1081
1082 2015-07-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1083
1084         [ES6] Implement Reflect.isExtensible
1085         https://bugs.webkit.org/show_bug.cgi?id=147308
1086
1087         Reviewed by Sam Weinig.
1088
1089         This patch implements Reflect.isExtensible.
1090         It is similar to Object.isExtensible.
1091         The difference is that it raises an error if the first argument is not an object.
1092
1093         * runtime/ReflectObject.cpp:
1094         (JSC::reflectObjectIsExtensible):
1095         * tests/stress/reflect-is-extensible.js: Added.
1096         (shouldBe):
1097         (shouldThrow):
1098
1099 2015-07-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1100
1101         Unreviewed, fix the debug build due to touching the non-declared variable in ASSERT
1102         https://bugs.webkit.org/show_bug.cgi?id=147307
1103
1104         * runtime/ObjectConstructor.cpp:
1105         (JSC::ownPropertyKeys):
1106
1107 2015-07-25  Yusuke Suzuki  <utatane.tea@gmail.com>
1108
1109         [ES6] Implement Reflect.ownKeys
1110         https://bugs.webkit.org/show_bug.cgi?id=147307
1111
1112         Reviewed by Sam Weinig.
1113
1114         This patch implements Reflect.ownKeys.
1115         In this patch, we refactor the existing code to list up own keys in the object.
1116         Such code is used by Object.getOwnPropertyNames, Object.getOwnPropertyKeys, Object.keys and @ownEnumerableKeys.
1117         We factor out the listing up own keys as ownPropertyKeys function and also use it in Reflect.ownKeys.
1118
1119         * runtime/ObjectConstructor.cpp:
1120         (JSC::objectConstructorGetOwnPropertyNames):
1121         (JSC::objectConstructorGetOwnPropertySymbols):
1122         (JSC::objectConstructorKeys):
1123         (JSC::ownEnumerablePropertyKeys):
1124         (JSC::ownPropertyKeys):
1125         * runtime/ObjectConstructor.h:
1126         * runtime/ReflectObject.cpp:
1127         (JSC::reflectObjectOwnKeys):
1128         * tests/stress/reflect-own-keys.js: Added.
1129         (shouldBe):
1130         (shouldThrow):
1131         (shouldBeArray):
1132
1133 2015-07-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1134
1135         [ES6] Implement Reflect.apply
1136         https://bugs.webkit.org/show_bug.cgi?id=147306
1137
1138         Reviewed by Sam Weinig.
1139
1140         Implement Reflect.apply.
1141         The large part of this can be implemented by the @apply builtin annotation.
1142         The only thing which is different from the Funciton.prototype.apply is the third parameter,
1143         "argumentsList" is needed to be an object.
1144
1145         * builtins/ReflectObject.js:
1146         (apply):
1147         (deleteProperty):
1148         * runtime/ReflectObject.cpp:
1149         * tests/stress/reflect-apply.js: Added.
1150         (shouldBe):
1151         (shouldThrow):
1152         (get shouldThrow):
1153         (.get shouldThrow):
1154         (get var.array.get length):
1155         (get var.array.get 0):
1156         (.get var):
1157         * tests/stress/reflect-delete-property.js:
1158
1159 2015-07-25  Yusuke Suzuki  <utatane.tea@gmail.com>
1160
1161         [ES6] Add Reflect namespace and add Reflect.deleteProperty
1162         https://bugs.webkit.org/show_bug.cgi?id=147287
1163
1164         Reviewed by Sam Weinig.
1165
1166         This patch just creates the namespace for ES6 Reflect APIs.
1167         And add template files to implement the actual code.
1168
1169         Not to keep the JS generated properties C array empty,
1170         we added one small method, Reflect.deleteProperty in this patch.
1171
1172         * CMakeLists.txt:
1173         * DerivedSources.make:
1174         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1175         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1176         * JavaScriptCore.xcodeproj/project.pbxproj:
1177         * builtins/ReflectObject.js: Added.
1178         (deleteProperty):
1179         * runtime/CommonIdentifiers.h:
1180         * runtime/JSGlobalObject.cpp:
1181         (JSC::JSGlobalObject::init):
1182         * runtime/ReflectObject.cpp: Added.
1183         (JSC::ReflectObject::ReflectObject):
1184         (JSC::ReflectObject::finishCreation):
1185         (JSC::ReflectObject::getOwnPropertySlot):
1186         * runtime/ReflectObject.h: Added.
1187         (JSC::ReflectObject::create):
1188         (JSC::ReflectObject::createStructure):
1189         * tests/stress/reflect-delete-property.js: Added.
1190         (shouldBe):
1191         (shouldThrow):
1192
1193 2015-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1194
1195         Avoid 2 times name iteration in Object.assign
1196         https://bugs.webkit.org/show_bug.cgi?id=147268
1197
1198         Reviewed by Geoffrey Garen.
1199
1200         Object.assign calls Object.getOwnPropertyNames & Object.getOwnPropertySymbols to collect all the names.
1201         But exposing the private API that collects both at the same time makes the API efficient when the given Object has so many non-indexed properties.
1202         Since Object.assign is so generic API (some form of utility API), the form of the given Object is not expected.
1203         So the taken object may have so many non-indexed properties.
1204
1205         In this patch, we introduce `ownEnumerablePropertyKeys` private function.
1206         It is minor changed version of `[[OwnPropertyKeys]]` in the ES6 spec;
1207         It only includes enumerable properties.
1208
1209         By filtering out the non-enumerable properties in the exposed private function,
1210         we avoid calling @objectGetOwnPropertyDescriptor for each property at the same time.
1211
1212         * builtins/ObjectConstructor.js:
1213         (assign):
1214         * runtime/CommonIdentifiers.h:
1215         * runtime/EnumerationMode.h:
1216         * runtime/JSGlobalObject.cpp:
1217         (JSC::JSGlobalObject::init):
1218         * runtime/ObjectConstructor.cpp:
1219         (JSC::ownEnumerablePropertyKeys):
1220         * runtime/ObjectConstructor.h:
1221         * tests/stress/object-assign-enumerable.js: Added.
1222         (shouldBe):
1223         * tests/stress/object-assign-order.js: Added.
1224         (shouldBe):
1225
1226 2015-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1227
1228         Remove runtime flags for symbols
1229         https://bugs.webkit.org/show_bug.cgi?id=147246
1230
1231         Reviewed by Alex Christensen.
1232
1233         * runtime/ArrayPrototype.cpp:
1234         (JSC::ArrayPrototype::finishCreation):
1235         * runtime/JSGlobalObject.cpp:
1236         (JSC::JSGlobalObject::init): Deleted.
1237         * runtime/JSGlobalObject.h:
1238         * runtime/ObjectConstructor.cpp:
1239         (JSC::ObjectConstructor::finishCreation):
1240         * runtime/RuntimeFlags.h:
1241
1242 2015-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1243
1244         Object.getOwnPropertySymbols on large list takes very long
1245         https://bugs.webkit.org/show_bug.cgi?id=146137
1246
1247         Reviewed by Mark Lam.
1248
1249         Before this patch, Object.getOwnPropertySymbols collects all the names including strings.
1250         And after it's done, filter the names to only retrieve the symbols.
1251         But it's so time consuming if the given object is a large non-holed array since it has
1252         many indexed properties and all the indexes have to be converted to uniqued_strings and
1253         added to the collection of property names (though they may not be of the requested type
1254         and will be filtered out later)
1255
1256         This patch introduces PropertyNameMode.
1257         We leverage this mode in 2 places.
1258
1259         1. PropertyNameArray side
1260         It is set in PropertyNameArray and it filters the incoming added identifiers based on the mode.
1261         It ensures that PropertyNameArray doesn't become so large in the pathological case.
1262         And it ensures that non-expected typed keys by the filter (Symbols or Strings) are never added
1263         to the property name array collections.
1264         However it does not solve the whole problem because the huge array still incurs the many
1265         "indexed property to uniqued string" conversion and the large iteration before adding the keys
1266         to the property name array.
1267
1268         2. getOwnPropertyNames side
1269         So we can use the PropertyNameMode in the caller side (getOwnPropertyNames) as a **hint**.
1270         When the large iteration may occur, the caller side can use the PropertyNameMode as a hint to
1271         avoid the iteration.
1272         But we cannot exclusively rely on these caller side checks because it would require that we
1273         exhaustively add the checks to all custom implementations of getOwnPropertyNames as well.
1274         This process requires manual inspection of many pieces of code, and is error prone. Instead,
1275         we only apply the caller side check in a few strategic places where it is known to yield
1276         performance benefits; and we rely on the filter in PropertyNameArray::add() to reject the wrong
1277         types of properties for all other calls to PropertyNameArray::add().
1278
1279         In this patch, there's a concept in use that is not clear just from reading the code, and hence
1280         should be documented here. When selecting the PropertyNameMode for the PropertyNameArray to be
1281         instantiated, we apply the following logic:
1282
1283         1. Only JavaScriptCore code is aware of ES6 Symbols.
1284         We can assume that pre-existing external code that interfaces JSC are only looking for string named properties. This includes:
1285             a. WebCore bindings
1286             b. Serializer bindings
1287             c. NPAPI bindings
1288             d. Objective C bindings
1289         2. In JSC, code that compute object storage space needs to iterate both Symbol and String named properties. Hence, use PropertyNameMode::Both.
1290         3. In JSC, ES6 APIs that work with Symbols should use PropertyNameMode::Symbols.
1291         4. In JSC, ES6 APIs that work with String named properties should use PropertyNameMode::Strings.
1292
1293         * API/JSObjectRef.cpp:
1294         (JSObjectCopyPropertyNames):
1295         * bindings/ScriptValue.cpp:
1296         (Deprecated::jsToInspectorValue):
1297         * bytecode/ObjectAllocationProfile.h:
1298         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
1299         * runtime/EnumerationMode.h:
1300         (JSC::EnumerationMode::EnumerationMode):
1301         (JSC::EnumerationMode::includeSymbolProperties): Deleted.
1302         * runtime/GenericArgumentsInlines.h:
1303         (JSC::GenericArguments<Type>::getOwnPropertyNames):
1304         * runtime/JSGenericTypedArrayViewInlines.h:
1305         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertyNames):
1306         * runtime/JSLexicalEnvironment.cpp:
1307         (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
1308         * runtime/JSONObject.cpp:
1309         (JSC::Stringifier::Stringifier):
1310         (JSC::Stringifier::Holder::appendNextProperty):
1311         (JSC::Walker::walk):
1312         * runtime/JSObject.cpp:
1313         (JSC::JSObject::getOwnPropertyNames):
1314         * runtime/JSPropertyNameEnumerator.cpp:
1315         (JSC::JSPropertyNameEnumerator::create):
1316         * runtime/JSPropertyNameEnumerator.h:
1317         (JSC::propertyNameEnumerator):
1318         * runtime/JSSymbolTableObject.cpp:
1319         (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
1320         * runtime/ObjectConstructor.cpp:
1321         (JSC::objectConstructorGetOwnPropertyNames):
1322         (JSC::objectConstructorGetOwnPropertySymbols):
1323         (JSC::objectConstructorKeys):
1324         (JSC::defineProperties):
1325         (JSC::objectConstructorSeal):
1326         (JSC::objectConstructorFreeze):
1327         (JSC::objectConstructorIsSealed):
1328         (JSC::objectConstructorIsFrozen):
1329         * runtime/PropertyNameArray.h:
1330         (JSC::PropertyNameArray::PropertyNameArray):
1331         (JSC::PropertyNameArray::mode):
1332         (JSC::PropertyNameArray::addKnownUnique):
1333         (JSC::PropertyNameArray::add):
1334         (JSC::PropertyNameArray::isUidMatchedToTypeMode):
1335         (JSC::PropertyNameArray::includeSymbolProperties):
1336         (JSC::PropertyNameArray::includeStringProperties):
1337         * runtime/StringObject.cpp:
1338         (JSC::StringObject::getOwnPropertyNames):
1339         * runtime/Structure.cpp:
1340         (JSC::Structure::getPropertyNamesFromStructure):
1341
1342 2015-07-24  Saam barati  <saambarati1@gmail.com>
1343
1344         [ES6] Add support for default parameters
1345         https://bugs.webkit.org/show_bug.cgi?id=38409
1346
1347         Reviewed by Filip Pizlo.
1348
1349         This patch implements ES6 default parameters according to the ES6
1350         specification. This patch builds off the components introduced with 
1351         "let" scoping and parsing function parameters in the same parser
1352         arena as the function itself. "let" scoping allows functions with default 
1353         parameter values to place their parameters under the TDZ. Parsing function
1354         parameters in the same parser arena allows the FunctionParameters AST node
1355         refer to ExpressionNodes.
1356
1357         The most subtle part of this patch is how we allocate lexical environments
1358         when functions have default parameter values. If a function has default
1359         parameter values then there must be a separate lexical environment for
1360         its parameters. Then, the function's "var" lexical environment must have
1361         the parameter lexical environment as its parent. The BytecodeGenerator
1362         takes great care to not allocate the "var" lexical environment before its
1363         really needed.
1364
1365         The "arguments" object for a function with default parameters will never be 
1366         a mapped arugments object. It will always be a cloned arugments object.
1367
1368         * bytecompiler/BytecodeGenerator.cpp:
1369         (JSC::BytecodeGenerator::generate):
1370         (JSC::BytecodeGenerator::BytecodeGenerator):
1371         (JSC::BytecodeGenerator::~BytecodeGenerator):
1372         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
1373         (JSC::BytecodeGenerator::initializeNextParameter):
1374         (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
1375         (JSC::BytecodeGenerator::visibleNameForParameter):
1376         (JSC::BytecodeGenerator::emitLoadGlobalObject):
1377         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1378         (JSC::BytecodeGenerator::pushLexicalScope):
1379         (JSC::BytecodeGenerator::popLexicalScope):
1380         * bytecompiler/BytecodeGenerator.h:
1381         (JSC::BytecodeGenerator::lastOpcodeID):
1382         * bytecompiler/NodesCodegen.cpp:
1383         (JSC::FunctionNode::emitBytecode):
1384         * jit/JITOperations.cpp:
1385         * parser/ASTBuilder.h:
1386         (JSC::ASTBuilder::createElementList):
1387         (JSC::ASTBuilder::createFormalParameterList):
1388         (JSC::ASTBuilder::appendParameter):
1389         (JSC::ASTBuilder::createClause):
1390         (JSC::ASTBuilder::createClauseList):
1391         * parser/Nodes.h:
1392         (JSC::FunctionParameters::size):
1393         (JSC::FunctionParameters::at):
1394         (JSC::FunctionParameters::hasDefaultParameterValues):
1395         (JSC::FunctionParameters::append):
1396         * parser/Parser.cpp:
1397         (JSC::Parser<LexerType>::parseVariableDeclarationList):
1398         (JSC::Parser<LexerType>::createBindingPattern):
1399         (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
1400         (JSC::Parser<LexerType>::parseDestructuringPattern):
1401         (JSC::Parser<LexerType>::parseFormalParameters):
1402         (JSC::Parser<LexerType>::parseFunctionParameters):
1403         * parser/Parser.h:
1404         (JSC::Scope::declareParameter):
1405         * parser/SyntaxChecker.h:
1406         (JSC::SyntaxChecker::createElementList):
1407         (JSC::SyntaxChecker::createFormalParameterList):
1408         (JSC::SyntaxChecker::appendParameter):
1409         (JSC::SyntaxChecker::createClause):
1410         (JSC::SyntaxChecker::createClauseList):
1411         * tests/stress/es6-default-parameters.js: Added.
1412         (assert):
1413         (shouldThrow):
1414         (shouldThrowSyntaxError):
1415         (shouldThrowTDZ):
1416         (basic):
1417         (basicFunctionCaptureInDefault.basicFunctionCaptureInDefault.basicCaptured):
1418         (basicCaptured.basicCaptured.tricky):
1419         (strict):
1420         (playground):
1421         (scoping):
1422         (augmentsArguments1):
1423         (augmentsArguments2):
1424         (augmentsArguments3):
1425         (augmentsArguments4):
1426         (augmentsArguments5):
1427
1428 2015-07-24  Xabier Rodriguez Calvar  <calvaris@igalia.com>
1429
1430         Remove JS Promise constructor unused piece of code
1431         https://bugs.webkit.org/show_bug.cgi?id=147262
1432
1433         Reviewed by Geoffrey Garen.
1434
1435         * runtime/JSPromiseConstructor.cpp:
1436         (JSC::constructPromise): Deleted.
1437         * runtime/JSPromiseConstructor.h: Removed JSC::constructPromise.
1438
1439 2015-07-24  Mark Lam  <mark.lam@apple.com>
1440
1441         Add WASM files to vcxproj files.
1442         https://bugs.webkit.org/show_bug.cgi?id=147264
1443
1444         Reviewed by Geoffrey Garen.
1445
1446         This is a follow up to http://trac.webkit.org/changeset/187254 where WASM files
1447         were introduced but were not able to be added to the vcxproj files yet.
1448
1449         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1450         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1451
1452 2015-07-23  Filip Pizlo  <fpizlo@apple.com>
1453
1454         DFG::safeToExecute() is wrong for MultiGetByOffset, doesn't consider the structures of the prototypes that get loaded from
1455         https://bugs.webkit.org/show_bug.cgi?id=147250
1456
1457         Reviewed by Geoffrey Garen.
1458         
1459         This fixes a nasty - but currently benign - bug in DFG::safeToExecute(). That function
1460         will tell you if hoisting a node to some point is safe in the sense that the node will
1461         not crash the VM if it executes at that point. A node may be unsafe to execute if we
1462         cannot prove that at that point, the memory it is loading is not garbage. This is a
1463         necessarily loose notion - for example it's OK to hoist a load if we haven't proved
1464         that the load makes semantic sense at that point, since anyway the place where the node
1465         did get used will still be guarded by any such semantic checks. But because we may also
1466         hoist uses of the load, we need to make sure that it doesn't produce a garbage value.
1467         Also, we need to ensure that the load won't trap. Hence safeToExecute() returns true
1468         anytime we can be sure that a node will not produce a garbage result (i.e. a malformed
1469         JSValue or object pointer) and will not trap when executed at the point in question.
1470         
1471         The bug is that this verification isn't performed for the loads from prototypes inside
1472         MultiGetByOffset. DFG::ByteCodeParser will guard MultiGetByOffset with CheckStructure's
1473         on the prototypes. So, hypothetically, you might end up hoisting a MultiGetByOffset
1474         above those structure checks, which would mean that we might load a value from a memory
1475         location without knowing that the location is valid. It might then return the value
1476         loaded.
1477         
1478         This never happens in practice. Those structure checks are more hoistable that the
1479         MultiGetByOffset, since they read a strict subset of the MultiGetByOffset's abstract
1480         heap reads. Also, we hoist in program order. So, those CheckStructure's will always be
1481         hoisted before the MultiGetByOffset gets hoisted.
1482         
1483         But we should fix this anyway. DFG::safeToExecute() has a clear definition of what a
1484         "true" return means for IR transformations, and it fails in satisfying that definition
1485         for MultiGetByOffset.
1486         
1487         There are various approaches we can use for making this safe. I considered two:
1488         
1489         1) Have MultiGetByOffset refer to the prototypes it is loading from in IR, so that we
1490            can check if it's safe to load from them.
1491         
1492         2) Turn off MultiGetByOffset hoisting when it will emit loads from prototypes, and the
1493            prototype structure isn't being watched.
1494         
1495         I ended up using (2), because it will be the most natural solution once I finish
1496         https://bugs.webkit.org/show_bug.cgi?id=146929. Already now, it's somewhat more natural
1497         than (1) since that requires more extensive IR changes. Also, (2) will give us what we
1498         want in *most* cases: we will usually watch the prototype structure, and we will
1499         usually constant-fold loads from prototypes. Both of these usually-true things would
1500         have to become false for MultiGetByOffset hoisting to be disabled by this change.
1501         
1502         This change also adds my attempt at a test, though it's not really a test of this bug.
1503         This bug is currently benign. But, the test does at least trigger the logic to run,
1504         which is better than nothing.
1505
1506         * dfg/DFGSafeToExecute.h:
1507         (JSC::DFG::safeToExecute):
1508         * tests/stress/multi-get-by-offset-hoist-around-structure-check.js: Added.
1509         (foo):
1510
1511 2015-07-23  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1512
1513         Implement WebAssembly modules
1514         https://bugs.webkit.org/show_bug.cgi?id=147222
1515
1516         Reviewed by Filip Pizlo.
1517
1518         Make JSWASMModule inherit from JSDestructibleObject so that the destructor is called.
1519
1520         * wasm/JSWASMModule.h:
1521
1522 2015-07-23  Alex Christensen  <achristensen@webkit.org>
1523
1524         Remove compile and runtime flags for promises.
1525         https://bugs.webkit.org/show_bug.cgi?id=147244
1526
1527         Reviewed by Yusuke Suzuki.
1528
1529         * API/JSCallbackObjectFunctions.h:
1530         (JSC::JSCallbackObject<Parent>::JSCallbackObject):
1531         * API/JSContextRef.cpp:
1532         (JSGlobalContextCreateInGroup):
1533         * Configurations/FeatureDefines.xcconfig:
1534         * inspector/JSInjectedScriptHost.cpp:
1535         (Inspector::JSInjectedScriptHost::getInternalProperties):
1536         * runtime/JSGlobalObject.cpp:
1537         (JSC::JSGlobalObject::init):
1538         (JSC::JSGlobalObject::visitChildren):
1539         * runtime/JSGlobalObject.h:
1540         (JSC::JSGlobalObject::create):
1541         (JSC::JSGlobalObject::syntaxErrorConstructor):
1542         (JSC::JSGlobalObject::typeErrorConstructor):
1543         (JSC::JSGlobalObject::URIErrorConstructor):
1544         (JSC::JSGlobalObject::promiseConstructor):
1545         (JSC::JSGlobalObject::nullGetterFunction):
1546         (JSC::JSGlobalObject::nullSetterFunction):
1547         (JSC::JSGlobalObject::applyFunction):
1548         (JSC::JSGlobalObject::definePropertyFunction):
1549         (JSC::JSGlobalObject::arrayProtoValuesFunction):
1550         (JSC::JSGlobalObject::initializePromiseFunction):
1551         (JSC::JSGlobalObject::newPromiseDeferredFunction):
1552         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
1553         (JSC::JSGlobalObject::regExpPrototype):
1554         (JSC::JSGlobalObject::errorPrototype):
1555         (JSC::JSGlobalObject::iteratorPrototype):
1556         (JSC::JSGlobalObject::promisePrototype):
1557         (JSC::JSGlobalObject::debuggerScopeStructure):
1558         (JSC::JSGlobalObject::withScopeStructure):
1559         (JSC::JSGlobalObject::iteratorResultStructure):
1560         (JSC::JSGlobalObject::iteratorResultStructureOffset):
1561         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
1562         (JSC::JSGlobalObject::promiseStructure):
1563         * runtime/JSPromise.cpp:
1564         (JSC::JSPromise::result):
1565         * runtime/JSPromise.h:
1566         * runtime/JSPromiseConstructor.cpp:
1567         (JSC::constructPromise):
1568         * runtime/JSPromiseConstructor.h:
1569         * runtime/JSPromiseDeferred.cpp:
1570         (JSC::JSPromiseDeferred::visitChildren):
1571         * runtime/JSPromiseDeferred.h:
1572         * runtime/JSPromisePrototype.cpp:
1573         (JSC::JSPromisePrototype::getOwnPropertySlot):
1574         * runtime/JSPromisePrototype.h:
1575         * runtime/RuntimeFlags.h:
1576         * runtime/VM.cpp:
1577         (JSC::VM::VM):
1578         * runtime/VM.h:
1579
1580 2015-07-23  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1581
1582         Implement WebAssembly modules
1583         https://bugs.webkit.org/show_bug.cgi?id=147222
1584
1585         Reviewed by Mark Lam.
1586
1587         Introducing the boilerplate data structure for the WebAssembly module.
1588         WebAssembly functionality will be added in a subsequent patch.
1589
1590         * CMakeLists.txt:
1591         * JavaScriptCore.xcodeproj/project.pbxproj:
1592         * wasm/JSWASMModule.cpp: Added.
1593         (JSC::JSWASMModule::visitChildren):
1594         * wasm/JSWASMModule.h: Added.
1595         (JSC::JSWASMModule::create):
1596         (JSC::JSWASMModule::createStructure):
1597         (JSC::JSWASMModule::JSWASMModule):
1598
1599 2015-07-23  Devin Rousso  <drousso@apple.com>
1600
1601         Web Inspector: Add a function to CSSCompletions to get a list of supported system fonts
1602         https://bugs.webkit.org/show_bug.cgi?id=147009
1603
1604         Reviewed by Joseph Pecoraro.
1605
1606         * inspector/protocol/CSS.json: Added getSupportedSystemFontFamilyNames function.
1607
1608 2015-07-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1609
1610         Add ENABLE_WEBASSEMBLY feature flag for WebAssembly
1611         https://bugs.webkit.org/show_bug.cgi?id=147212
1612
1613         Reviewed by Filip Pizlo.
1614
1615         * Configurations/FeatureDefines.xcconfig:
1616
1617 2015-07-22  Filip Pizlo  <fpizlo@apple.com>
1618
1619         Simplify DFG::DesiredIdentifiers and make it possible to turn a UniquedStringImpl* into an identifierNumber at any time
1620         https://bugs.webkit.org/show_bug.cgi?id=147218
1621
1622         Reviewed by Sam Weinig.
1623         
1624         I want to be able to take a UniquedStringImpl* and turn it into an identifierNumber at
1625         various points in my work on https://bugs.webkit.org/show_bug.cgi?id=146929. Currently,
1626         most Nodes that deal with identifiers use identifierNumbers and you can only create an
1627         identifierNumber in BytecodeGenerator. DFG::ByteCodeParser does sort of have the
1628         ability to create new identifierNumbers when inlining - it takes the inlined code's
1629         identifiers and either gives them new numbers or reuses numbers from the enclosing
1630         code.
1631         
1632         This patch takes that basic functionality and puts it in
1633         DFG::DesiredIdentifiers::ensure(). Anyone can call this at any time to turn a
1634         UniquedStringImpl* into an identifierNumber. This data structure is already used by
1635         Plan to properly install any newly created identifier table entries into the CodeBlock.
1636
1637         * dfg/DFGByteCodeParser.cpp:
1638         (JSC::DFG::ByteCodeParser::ByteCodeParser):
1639         (JSC::DFG::ByteCodeParser::noticeArgumentsUse):
1640         (JSC::DFG::ByteCodeParser::linkBlocks):
1641         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1642         (JSC::DFG::ByteCodeParser::buildOperandMapsIfNecessary): Deleted.
1643         * dfg/DFGDesiredIdentifiers.cpp:
1644         (JSC::DFG::DesiredIdentifiers::DesiredIdentifiers):
1645         (JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
1646         (JSC::DFG::DesiredIdentifiers::ensure):
1647         (JSC::DFG::DesiredIdentifiers::at):
1648         (JSC::DFG::DesiredIdentifiers::addLazily): Deleted.
1649         * dfg/DFGDesiredIdentifiers.h:
1650
1651 2015-07-22  Filip Pizlo  <fpizlo@apple.com>
1652
1653         Simplify things like CompareEq(@x,@x)
1654         https://bugs.webkit.org/show_bug.cgi?id=145850
1655
1656         Reviewed by Sam Weinig.
1657         
1658         This simplifies x==x to true, except in cases where x might be a double (in which case this
1659         might still be false if x is NaN).
1660
1661         * dfg/DFGAbstractInterpreterInlines.h:
1662         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1663         * tests/stress/nan-equal-untyped.js: Added.
1664         (foo):
1665         (test):
1666         * tests/stress/nan-equal.js: Added.
1667         (foo):
1668
1669 2015-07-22  Joseph Pecoraro  <pecoraro@apple.com>
1670
1671         Web Inspector: Timeline should immediately start moving play head when starting a new recording
1672         https://bugs.webkit.org/show_bug.cgi?id=147210
1673
1674         Reviewed by Timothy Hatcher.
1675
1676         * inspector/protocol/Timeline.json:
1677         Add timestamps to recordingStarted and recordingStopped events.
1678
1679 2015-07-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1680
1681         Introducing construct ability into JS executables
1682         https://bugs.webkit.org/show_bug.cgi?id=147183
1683
1684         Reviewed by Geoffrey Garen.
1685
1686         Decouple the construct ability from the builtin functions.
1687         Currently, all builtin functions are not constructors after r182995.
1688         In that patch, when the given function is builtin JS function, we recognize it as the non-constructor function.
1689
1690         But, we need to relax it to implement some constructors in builtins JS.
1691         By decoupling the construct ability from whether the function is builtin or not, we can provide
1692
1693         1. constructors written in builtin JS
1694         2. non-constructors in normal JS functions
1695
1696         (1) is needed for Promise constructor.
1697         And (2) is needed for method functions and arrow functions.
1698
1699         This patch introduces ConstructAbility into the unlinked function executables.
1700         It holds whether the given JS function has the construct ability or not.
1701         By leveraging this, this patch disables the construct ability of the method definitions, setters, getters and arrow functions.
1702
1703         And at the same time, this patch introduces the annotation for constructor in builtin JS.
1704         We can define the function as follows,
1705
1706             constructor Promise(executor)
1707             {
1708                 ...
1709             }
1710
1711         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1712         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1713         * JavaScriptCore.xcodeproj/project.pbxproj:
1714         * builtins/BuiltinExecutables.cpp:
1715         (JSC::BuiltinExecutables::createDefaultConstructor):
1716         (JSC::BuiltinExecutables::createExecutableInternal):
1717         * builtins/BuiltinExecutables.h:
1718         * builtins/Iterator.prototype.js:
1719         (symbolIterator):
1720         (SymbolIterator): Deleted.
1721         * bytecode/UnlinkedCodeBlock.cpp:
1722         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1723         * bytecode/UnlinkedCodeBlock.h:
1724         * bytecompiler/BytecodeGenerator.h:
1725         (JSC::BytecodeGenerator::makeFunction):
1726         * generate-js-builtins:
1727         (getCopyright):
1728         (Function):
1729         (Function.__init__):
1730         (Function.mangleName):
1731         (getFunctions):
1732         (mangleName): Deleted.
1733         * jit/JITOperations.cpp:
1734         * llint/LLIntSlowPaths.cpp:
1735         (JSC::LLInt::setUpCall):
1736         * parser/Parser.cpp:
1737         (JSC::Parser<LexerType>::parseClass):
1738         * runtime/CodeCache.cpp:
1739         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
1740         * runtime/CommonIdentifiers.h:
1741         * runtime/ConstructAbility.h: Copied from Source/JavaScriptCore/builtins/Iterator.prototype.js.
1742         * runtime/Executable.h:
1743         * runtime/JSFunction.cpp:
1744         (JSC::JSFunction::getConstructData):
1745         * runtime/JSGlobalObject.cpp:
1746         (JSC::JSGlobalObject::init):
1747         * tests/stress/non-constructors.js: Added.
1748         (shouldThrow):
1749         (.prototype.method):
1750         (.prototype.get getter):
1751         (.prototype.set setter):
1752         (.method):
1753         (.get shouldThrow):
1754         (.set shouldThrow):
1755         (set var.test.get getter):
1756         (set var.test.set setter):
1757         (set var.test.normal):
1758         (.set var):
1759         (.set new):
1760
1761 2015-07-22  Csaba Osztrogonác  <ossy@webkit.org>
1762
1763         [JSC] Enable exception fuzzing for GCC too
1764         https://bugs.webkit.org/show_bug.cgi?id=146831
1765
1766         Reviewed by Darin Adler.
1767
1768         * jit/JITOperations.cpp:
1769
1770 2015-07-22  Filip Pizlo  <fpizlo@apple.com>
1771
1772         Fixed pool allocation should always be aligned
1773         https://bugs.webkit.org/show_bug.cgi?id=147201
1774
1775         Reviewed by Simon Fraser.
1776         
1777         Passing an unaligned size to the allocator can cause asserts or even worse things. The
1778         Options reservation value isn't going to be aligned.
1779
1780         * jit/ExecutableAllocatorFixedVMPool.cpp:
1781         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
1782
1783 2015-07-22  Csaba Osztrogonác  <ossy@webkit.org>
1784
1785         Enable STATIC_ASSERT_IS_TRIVIALLY_DESTRUCTIBLE for GCC
1786         https://bugs.webkit.org/show_bug.cgi?id=146829
1787
1788         Reviewed by Brent Fulgham.
1789
1790         * heap/GCAssertions.h:
1791
1792 2015-07-22  Alex Christensen  <achristensen@webkit.org>
1793
1794         Fix quirks in CMake build on Mac and Windows
1795         https://bugs.webkit.org/show_bug.cgi?id=147174
1796
1797         Reviewed by Gyuyoung Kim.
1798
1799         * PlatformMac.cmake:
1800         Add JSRemoteInspector.cpp and remove semicolon from command to make it actually run.
1801
1802 2015-07-21  Yusuke Suzuki  <utatane.tea@gmail.com>
1803
1804         Add newTarget accessor to JS constructor written in C++
1805         https://bugs.webkit.org/show_bug.cgi?id=147160
1806
1807         Reviewed by Geoffrey Garen.
1808
1809         This patch adds `ExecState#newTarget()` which returns `new.target` defined in ECMA262 6th.
1810         It enables some C++ constructors (like Intl.XXX constructors) to leverage this to complete
1811         its implementation.
1812
1813         When the constructor is called, |this| in the arguments is used for storing new.target instead.
1814         So by adding the accessor for |this|, JS constructor written in C++ can access new.target.
1815
1816         And at the same time, this patch extends the existing `construct` to accept new.target value.
1817         It is corresponding to the spec's Construct abstract operation.
1818
1819         * interpreter/CallFrame.h:
1820         (JSC::ExecState::newTarget):
1821         * interpreter/Interpreter.cpp:
1822         (JSC::Interpreter::executeConstruct):
1823         * interpreter/Interpreter.h:
1824         * runtime/ConstructData.cpp:
1825         (JSC::construct):
1826         * runtime/ConstructData.h:
1827         (JSC::construct):
1828
1829 2015-07-21  Filip Pizlo  <fpizlo@apple.com>
1830
1831         Unreviewed, fix a lot of tests. Need to initialize WTF threading sooner.
1832
1833         * jsc.cpp:
1834         (main):
1835
1836 2015-07-21  Filip Pizlo  <fpizlo@apple.com>
1837
1838         Fixed VM pool allocation should have a reserve for allocations that cannot fail
1839         https://bugs.webkit.org/show_bug.cgi?id=147154
1840         rdar://problem/21847618
1841
1842         Reviewed by Geoffrey Garen.
1843         
1844         This adds the notion of a JIT pool reserve fraction. Some fraction, currently 1/4, of
1845         the JIT pool is reserved for allocations that cannot fail. It makes sense to make this
1846         a fraction rather than a constant because each allocation that can fail may cause some
1847         number of allocations that cannot fail (for example, the OSR exit thunks that we
1848         compile when we exit from some CodeBlock cannot fail).
1849         
1850         I've tested this by adding a test mode where we artificially limit the JIT pool size.
1851         Prior to the fix, we had >20 failures. Now we have none.
1852
1853         * heap/GCLogging.cpp:
1854         (WTF::printInternal): I needed a dump method on Options members when debugging this.
1855         * heap/GCLogging.h:
1856         * jit/ExecutableAllocator.h: Raise the ARM64 limit to 32MB because 16MB is cutting it too close.
1857         * jit/ExecutableAllocatorFixedVMPool.cpp:
1858         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Add the ability to artificially limit JIT pool size for testing.
1859         (JSC::ExecutableAllocator::memoryPressureMultiplier): Implement the reserve when computing memory pressure for JIT tier-up heuristics.
1860         (JSC::ExecutableAllocator::allocate): Implement the reserve when allocating can-fail things.
1861         * jsc.cpp: Rewire some options parsing so that CommandLine happens before we create the JIT pool.
1862         (main):
1863         (CommandLine::parseArguments):
1864         (jscmain):
1865         * runtime/Options.cpp: 
1866         (JSC::OptionRange::dump): I needed a dump method on Options members when debugging this.
1867         (JSC::Options::initialize): This can now be called more than once.
1868         * runtime/Options.h:
1869
1870 2015-07-21  Saam barati  <saambarati1@gmail.com>
1871
1872         ObjectPatternNode's entry should use "const Identifier&" instead of "Identifier"
1873         https://bugs.webkit.org/show_bug.cgi?id=147156
1874
1875         Reviewed by Andreas Kling.
1876
1877         * parser/Nodes.h:
1878
1879 2015-07-21  Basile Clement  <basile_clement@apple.com>
1880
1881         Object allocation sinking phase is performing needless HashMap copies
1882         https://bugs.webkit.org/show_bug.cgi?id=147159
1883
1884         Reviewed by Geoffrey Garen.
1885
1886         The points-to analyzer in the object allocation sinking phase is
1887         currently performing copies of its allocation and pointers tables in
1888         several places. While this is not a huge problem since those tables are
1889         usually small and we are in the FTL path anyway, we still shouldn't be
1890         doing such useless copying.
1891
1892         This patch also removes the DFGInsertOSRHintsForUpdate files that are
1893         no longer needed with the new object sinking phase and should have been
1894         removed in r186795.
1895
1896         * CMakeLists.txt:
1897         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1898         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1899         * JavaScriptCore.xcodeproj/project.pbxproj:
1900         * dfg/DFGInsertOSRHintsForUpdate.cpp: Removed.
1901         (JSC::DFG::insertOSRHintsForUpdate): Deleted.
1902         * dfg/DFGInsertOSRHintsForUpdate.h: Removed.
1903         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1904
1905 2015-07-21  Saam barati  <saambarati1@gmail.com>
1906
1907         DestructuringPatternNode and DestructuringAssignmentNode should be ParserArenaFreeable
1908         https://bugs.webkit.org/show_bug.cgi?id=147140
1909
1910         Reviewed by Geoffrey Garen.
1911
1912         The descendants of DestructuringPatternNode that need destruction also
1913         inherit from ParserArenaDeletable.
1914
1915         * parser/Nodes.h:
1916         (JSC::DestructuringPatternNode::~DestructuringPatternNode):
1917         (JSC::ObjectPatternNode::appendEntry):
1918         (JSC::DestructuringAssignmentNode::bindings):
1919
1920 2015-07-21  Keith Miller  <keith_miller@apple.com>
1921
1922         Add support for the new.target syntax.
1923         https://bugs.webkit.org/show_bug.cgi?id=147051
1924
1925         Reviewed by Yusuke Suzuki.
1926
1927         Add support for new.target. Essentially the implementation is, before constructor calls,
1928         the target of a "new" is placed where "this" noramlly goes in the calling convention.
1929         Then in the constructor before object is initialized we move the target of the "new"
1930         into a local variable.
1931
1932         * bytecompiler/BytecodeGenerator.cpp:
1933         (JSC::BytecodeGenerator::BytecodeGenerator):
1934         * bytecompiler/NodesCodegen.cpp:
1935         (JSC::NewTargetNode::emitBytecode):
1936         * parser/ASTBuilder.h:
1937         (JSC::ASTBuilder::newTargetExpr):
1938         * parser/NodeConstructors.h:
1939         (JSC::NewTargetNode::NewTargetNode):
1940         * parser/Nodes.h:
1941         * parser/Parser.cpp:
1942         (JSC::Parser<LexerType>::parseMemberExpression):
1943         * parser/SyntaxChecker.h:
1944         (JSC::SyntaxChecker::newTargetExpr):
1945         * runtime/CommonIdentifiers.h:
1946         * tests/stress/new-target.js: Added.
1947         (test):
1948         (call):
1949         (Constructor.subCall):
1950         (Constructor.SubConstructor):
1951         (Constructor):
1952         (noAssign):
1953         (doWeirdThings):
1954         (SuperClass):
1955         (SubClass):
1956
1957 2015-07-20  Saam barati  <saambarati1@gmail.com>
1958
1959         "let" scoping introduced incoherent story about symbol table cloning
1960         https://bugs.webkit.org/show_bug.cgi?id=147046
1961
1962         Reviewed by Filip Pizlo.
1963
1964         This patch now establishes a clear set of rules for how SymbolTables
1965         are owned by CodeBlock. Every SymbolTable that is used by a bytecode
1966         instruction must live in CodeBlock's constant register pool. When CodeBlock
1967         is being linked, it ensures that every SymbolTable in the constant pool is cloned. 
1968         This leaves no room for an un-cloned symbol table to be used by a bytecode instruction. 
1969         Some instructions may refer to SymbolTable's indirectly through a JSLexicalEnvironment. 
1970         This is fine, all JSLexicalEnvironment's are allocated with references to cloned symbol tables.
1971
1972         Another goal of this patch is to remove the notion that a SymbolTable is 1 to 1 
1973         with a CodeBlock. With lexical scoping, this view of the world is no longer
1974         correct. This patch begins to remove this assumption by making CodeBlock's
1975         symbolTable() getter method private. There is still one place where we need
1976         to purge our codebase of this assumption and that is the type profiler. It 
1977         has not been updated for lexical scoping. After it is updated in 
1978         https://bugs.webkit.org/show_bug.cgi?id=145438
1979         we will be able to remove CodeBlock's symbolTable() getter entirely.
1980
1981         * bytecode/CodeBlock.cpp:
1982         (JSC::CodeBlock::CodeBlock):
1983         (JSC::CodeBlock::nameForRegister):
1984         * bytecode/CodeBlock.h:
1985         (JSC::CodeBlock::addStringSwitchJumpTable):
1986         (JSC::CodeBlock::stringSwitchJumpTable):
1987         (JSC::CodeBlock::evalCodeCache):
1988         (JSC::CodeBlock::symbolTable):
1989         * bytecode/UnlinkedCodeBlock.cpp:
1990         (JSC::UnlinkedFunctionExecutable::visitChildren):
1991         (JSC::UnlinkedFunctionExecutable::link):
1992         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
1993         * bytecode/UnlinkedCodeBlock.h:
1994         (JSC::UnlinkedCodeBlock::addExceptionHandler):
1995         (JSC::UnlinkedCodeBlock::exceptionHandler):
1996         (JSC::UnlinkedCodeBlock::setSymbolTableConstantIndex):
1997         (JSC::UnlinkedCodeBlock::symbolTableConstantIndex):
1998         (JSC::UnlinkedCodeBlock::symbolTable): Deleted.
1999         (JSC::UnlinkedCodeBlock::setSymbolTable): Deleted.
2000         * bytecompiler/BytecodeGenerator.cpp:
2001         (JSC::BytecodeGenerator::generate):
2002         (JSC::BytecodeGenerator::BytecodeGenerator):
2003         (JSC::BytecodeGenerator::pushLexicalScope):
2004         (JSC::BytecodeGenerator::variableForLocalEntry):
2005         (JSC::BytecodeGenerator::createVariable):
2006         (JSC::BytecodeGenerator::resolveType):
2007         (JSC::BytecodeGenerator::emitResolveScope):
2008         * bytecompiler/BytecodeGenerator.h:
2009         (JSC::BytecodeGenerator::thisRegister):
2010         (JSC::BytecodeGenerator::instructions):
2011         (JSC::BytecodeGenerator::symbolTable): Deleted.
2012         * dfg/DFGGraph.h:
2013         (JSC::DFG::Graph::baselineCodeBlockFor):
2014         (JSC::DFG::Graph::isStrictModeFor):
2015         (JSC::DFG::Graph::symbolTableFor): Deleted.
2016         * jit/AssemblyHelpers.h:
2017         (JSC::AssemblyHelpers::baselineCodeBlock):
2018         (JSC::AssemblyHelpers::argumentsStart):
2019         (JSC::AssemblyHelpers::symbolTableFor): Deleted.
2020         * runtime/CommonSlowPaths.cpp:
2021         (JSC::SLOW_PATH_DECL):
2022         * runtime/Executable.cpp:
2023         (JSC::FunctionExecutable::visitChildren):
2024         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation):
2025         (JSC::FunctionExecutable::symbolTable): Deleted.
2026         * runtime/Executable.h:
2027
2028 2015-07-18  Filip Pizlo  <fpizlo@apple.com>
2029
2030         REGRESSION(186691): OSR entry is broken on loop headers that have no live variables
2031         https://bugs.webkit.org/show_bug.cgi?id=147074
2032         rdar://problem/21869970
2033
2034         Reviewed by Michael Saboff.
2035         
2036         The OSR entry must-handle block/value widening introduced in r186691 would cause the
2037         CFA to reexecute if it caused any live local variables to change value. But this fails
2038         if the must-handle block has no live local variables, and the entry block otherwise
2039         appears to be unreachable.
2040         
2041         This fixes the bug by having the change detection include whether the block hadn't been
2042         visited in addition to whether any local variable values got widened.
2043         
2044         This is a ~4% speed-up on SunSpider in browser.
2045
2046         * dfg/DFGCFAPhase.cpp:
2047         (JSC::DFG::CFAPhase::run):
2048
2049 2015-07-20  Mark Lam  <mark.lam@apple.com>
2050
2051         Rollout r187020 and r187021: breaks JSC API tests on debug builds.
2052         https://bugs.webkit.org/show_bug.cgi?id=147110
2053
2054         * heap/MachineStackMarker.cpp:
2055         (JSC::MachineThreads::addCurrentThread):
2056         * runtime/JSLock.cpp:
2057         (JSC::JSLockHolder::~JSLockHolder):
2058         (JSC::JSLock::JSLock):
2059         (JSC::JSLock::willDestroyVM):
2060         (JSC::JSLock::setExclusiveThread):
2061         (JSC::JSLock::lock):
2062         (JSC::JSLock::unlock):
2063         (JSC::JSLock::currentThreadIsHoldingLock):
2064         (JSC::JSLock::dropAllLocks):
2065         * runtime/JSLock.h:
2066         (JSC::JSLock::vm):
2067         (JSC::JSLock::hasExclusiveThread):
2068         (JSC::JSLock::exclusiveThread):
2069         * runtime/VM.h:
2070         (JSC::VM::hasExclusiveThread):
2071         (JSC::VM::exclusiveThread):
2072         (JSC::VM::setExclusiveThread):
2073
2074 2015-07-20  Per Arne Vollan  <peavo@outlook.com>
2075
2076         Unreviewed debug build fix after r187020.
2077
2078         * heap/MachineStackMarker.cpp:
2079         (JSC::MachineThreads::addCurrentThread):
2080         VM::exclusiveThread() has changed return type to ThreadIdentifier.
2081
2082 2015-07-20  Per Arne Vollan  <peavo@outlook.com>
2083
2084         JavaScriptCore performance is very bad on Windows
2085         https://bugs.webkit.org/show_bug.cgi?id=146448
2086
2087         Reviewed by Mark Lam.
2088
2089         Profiling shows that std::this_thread::get_id() is slow on Windows.
2090         Use WTF::currentThread() instead, which calls GetCurrentThreadId().
2091         This is faster on Windows. The issue has been reported to Microsoft,
2092         https://connect.microsoft.com/VisualStudio/feedback/details/1558211.
2093
2094         * runtime/JSLock.cpp:
2095         (JSC::JSLockHolder::~JSLockHolder):
2096         (JSC::JSLock::JSLock):
2097         (JSC::JSLock::willDestroyVM):
2098         (JSC::JSLock::setExclusiveThread):
2099         (JSC::JSLock::lock):
2100         (JSC::JSLock::unlock):
2101         (JSC::JSLock::currentThreadIsHoldingLock):
2102         * runtime/JSLock.h:
2103         (JSC::JSLock::vm):
2104         (JSC::JSLock::hasExclusiveThread):
2105         (JSC::JSLock::exclusiveThread):
2106         * runtime/VM.h:
2107         (JSC::VM::hasExclusiveThread):
2108         (JSC::VM::exclusiveThread):
2109         (JSC::VM::setExclusiveThread):
2110
2111 2015-07-19  Yusuke Suzuki  <utatane.tea@gmail.com>
2112
2113         In strict mode, `Object.keys(arguments)` includes "length"
2114         https://bugs.webkit.org/show_bug.cgi?id=147071
2115
2116         Reviewed by Darin Adler.
2117
2118         ClonedAguments didn't set the "length" with DontEnum.
2119
2120         * runtime/ClonedArguments.cpp:
2121         (JSC::ClonedArguments::createWithInlineFrame):
2122         (JSC::ClonedArguments::createByCopyingFrom):
2123         * tests/stress/arguments-length-always-dont-enum.js: Added.
2124         (shouldBe):
2125         (argsSloppy):
2126         (argsStrict):
2127
2128 2015-07-19  Jordan Harband  <ljharb@gmail.com>
2129
2130         new Date(NaN).toJSON() must return null instead of throwing a TypeError
2131         https://bugs.webkit.org/show_bug.cgi?id=141115
2132
2133         Reviewed by Yusuke Suzuki.
2134
2135         * runtime/DatePrototype.cpp:
2136         (JSC::dateProtoFuncToJSON):
2137
2138 2015-07-19  Saam barati  <saambarati1@gmail.com>
2139
2140         Parser::parseFunctionInfo hits RELEASE_ASSERT for Arrow Functions
2141         https://bugs.webkit.org/show_bug.cgi?id=147090
2142
2143         Reviewed by Yusuke Suzuki.
2144
2145         ArrowFunction's have there ParserFunctionInfo "name" field to 
2146         be a non-null pointer. This is obviously allowed and valid except we 
2147         had a RELEASE_ASSERT that claimed otherwise. This is a mistake. 
2148
2149         Note: ArrowFunction's will never actually have a function name;
2150         there ParserFunctionInfo "name" field will be the empty string. 
2151         This is not be mistaken with the name field being a null pointer.
2152
2153         * parser/Parser.cpp:
2154         (JSC::Parser<LexerType>::parseFunctionInfo):
2155
2156 2015-07-18  Saam barati  <saambarati1@gmail.com>
2157
2158         [ES6] Add support for block scope const
2159         https://bugs.webkit.org/show_bug.cgi?id=31813
2160
2161         Reviewed by Filip Pizlo.
2162
2163         'const' is now implemented in an ES6 spec compliant manner.
2164         'const' variables are always block scoped and always live
2165         either on the stack or in a JSLexicalEnvironment. 'const'
2166         variables never live on the global object.
2167
2168         Inside the BytecodeGenerator, when assigning to a stack
2169         'const' variable or a LocalClosureVar 'const' variable,
2170         we will emit code that just throws a type error.
2171         When assigning to a ClosureVar const variable, CodeBlock linking
2172         will ensure that we perform a dynamic lookup of that variable so
2173         that put_to_scope's slow path throws a type error.
2174
2175         The old 'const' implementation has been removed in this patch.
2176
2177         * bytecode/BytecodeList.json:
2178         * bytecode/BytecodeUseDef.h:
2179         (JSC::computeUsesForBytecodeOffset):
2180         (JSC::computeDefsForBytecodeOffset):
2181         * bytecode/CodeBlock.cpp:
2182         (JSC::CodeBlock::dumpBytecode):
2183         (JSC::CodeBlock::CodeBlock):
2184         * bytecompiler/BytecodeGenerator.cpp:
2185         (JSC::BytecodeGenerator::BytecodeGenerator):
2186         (JSC::BytecodeGenerator::pushLexicalScope):
2187         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
2188         (JSC::BytecodeGenerator::variable):
2189         (JSC::BytecodeGenerator::variableForLocalEntry):
2190         (JSC::BytecodeGenerator::createVariable):
2191         (JSC::BytecodeGenerator::emitResolveScope):
2192         (JSC::BytecodeGenerator::emitInstanceOf):
2193         (JSC::BytecodeGenerator::emitGetById):
2194         (JSC::BytecodeGenerator::isArgumentNumber):
2195         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
2196         (JSC::BytecodeGenerator::emitEnumeration):
2197         (JSC::BytecodeGenerator::variablePerSymbolTable): Deleted.
2198         (JSC::BytecodeGenerator::emitInitGlobalConst): Deleted.
2199         * bytecompiler/BytecodeGenerator.h:
2200         (JSC::Variable::Variable):
2201         (JSC::Variable::isReadOnly):
2202         (JSC::Variable::isSpecial):
2203         (JSC::Variable::isConst):
2204         (JSC::BytecodeGenerator::thisRegister):
2205         (JSC::BytecodeGenerator::emitTypeOf):
2206         (JSC::BytecodeGenerator::emitIn):
2207         * bytecompiler/NodesCodegen.cpp:
2208         (JSC::PostfixNode::emitResolve):
2209         (JSC::PrefixNode::emitResolve):
2210         (JSC::ReadModifyResolveNode::emitBytecode):
2211         (JSC::AssignResolveNode::emitBytecode):
2212         (JSC::CommaNode::emitBytecode):
2213         (JSC::BindingNode::bindValue):
2214         (JSC::ConstDeclNode::emitCodeSingle): Deleted.
2215         (JSC::ConstDeclNode::emitBytecode): Deleted.
2216         (JSC::ConstStatementNode::emitBytecode): Deleted.
2217         * dfg/DFGByteCodeParser.cpp:
2218         (JSC::DFG::ByteCodeParser::parseBlock):
2219         * dfg/DFGCapabilities.cpp:
2220         (JSC::DFG::capabilityLevel):
2221         * jit/JIT.cpp:
2222         (JSC::JIT::privateCompileMainPass):
2223         * jit/JIT.h:
2224         * jit/JITPropertyAccess.cpp:
2225         (JSC::JIT::emit_op_put_to_arguments):
2226         (JSC::JIT::emit_op_init_global_const): Deleted.
2227         * jit/JITPropertyAccess32_64.cpp:
2228         (JSC::JIT::emit_op_put_to_arguments):
2229         (JSC::JIT::emit_op_init_global_const): Deleted.
2230         * llint/LowLevelInterpreter.asm:
2231         * llint/LowLevelInterpreter32_64.asm:
2232         * llint/LowLevelInterpreter64.asm:
2233         * parser/ASTBuilder.h:
2234         (JSC::ASTBuilder::createDeclarationStatement):
2235         (JSC::ASTBuilder::createEmptyVarExpression):
2236         (JSC::ASTBuilder::createDebugger):
2237         (JSC::ASTBuilder::appendStatement):
2238         (JSC::ASTBuilder::createVarStatement): Deleted.
2239         (JSC::ASTBuilder::createLetStatement): Deleted.
2240         (JSC::ASTBuilder::createConstStatement): Deleted.
2241         (JSC::ASTBuilder::appendConstDecl): Deleted.
2242         * parser/NodeConstructors.h:
2243         (JSC::CommaNode::CommaNode):
2244         (JSC::SourceElements::SourceElements):
2245         (JSC::SwitchNode::SwitchNode):
2246         (JSC::BlockNode::BlockNode):
2247         (JSC::ConstStatementNode::ConstStatementNode): Deleted.
2248         (JSC::ConstDeclNode::ConstDeclNode): Deleted.
2249         * parser/Nodes.h:
2250         (JSC::ConstDeclNode::hasInitializer): Deleted.
2251         (JSC::ConstDeclNode::ident): Deleted.
2252         * parser/Parser.cpp:
2253         (JSC::Parser<LexerType>::parseStatementListItem):
2254         (JSC::Parser<LexerType>::parseVariableDeclaration):
2255         (JSC::Parser<LexerType>::parseWhileStatement):
2256         (JSC::Parser<LexerType>::parseVariableDeclarationList):
2257         (JSC::Parser<LexerType>::createBindingPattern):
2258         (JSC::Parser<LexerType>::parseDestructuringPattern):
2259         (JSC::Parser<LexerType>::parseDefaultValueForDestructuringPattern):
2260         (JSC::Parser<LexerType>::parseForStatement):
2261         (JSC::Parser<LexerType>::parseTryStatement):
2262         (JSC::Parser<LexerType>::parseFunctionInfo):
2263         (JSC::Parser<LexerType>::parseFunctionDeclaration):
2264         (JSC::Parser<LexerType>::parseClass):
2265         (JSC::Parser<LexerType>::parseConstDeclaration): Deleted.
2266         (JSC::Parser<LexerType>::parseConstDeclarationList): Deleted.
2267         * parser/Parser.h:
2268         (JSC::isEvalNode):
2269         (JSC::isEvalNode<EvalNode>):
2270         (JSC::isArguments):
2271         (JSC::isEval):
2272         (JSC::isEvalOrArgumentsIdentifier):
2273         (JSC::Scope::Scope):
2274         (JSC::Scope::declareCallee):
2275         (JSC::Scope::declareVariable):
2276         (JSC::Scope::declareLexicalVariable):
2277         (JSC::Scope::hasDeclaredVariable):
2278         (JSC::Scope::allowsVarDeclarations):
2279         (JSC::Scope::allowsLexicalDeclarations):
2280         (JSC::Scope::declareParameter):
2281         (JSC::Scope::declareBoundParameter):
2282         (JSC::Parser::destructuringKindFromDeclarationType):
2283         (JSC::Parser::assignmentContextFromDeclarationType):
2284         (JSC::Parser::isEvalOrArguments):
2285         (JSC::Parser::currentScope):
2286         (JSC::Parser::popScope):
2287         (JSC::Parser::declareVariable):
2288         (JSC::Parser::hasDeclaredVariable):
2289         (JSC::Parser::setStrictMode):
2290         (JSC::Parser::strictMode):
2291         (JSC::Parser::isValidStrictMode):
2292         (JSC::Parser::declareParameter):
2293         (JSC::Parser::declareBoundParameter):
2294         (JSC::Parser::breakIsValid):
2295         * parser/SyntaxChecker.h:
2296         (JSC::SyntaxChecker::createForInLoop):
2297         (JSC::SyntaxChecker::createForOfLoop):
2298         (JSC::SyntaxChecker::createEmptyStatement):
2299         (JSC::SyntaxChecker::createDeclarationStatement):
2300         (JSC::SyntaxChecker::createReturnStatement):
2301         (JSC::SyntaxChecker::createBreakStatement):
2302         (JSC::SyntaxChecker::createVarStatement): Deleted.
2303         (JSC::SyntaxChecker::createLetStatement): Deleted.
2304         * parser/VariableEnvironment.h:
2305         (JSC::VariableEnvironmentEntry::isCaptured):
2306         (JSC::VariableEnvironmentEntry::isConst):
2307         (JSC::VariableEnvironmentEntry::isVar):
2308         (JSC::VariableEnvironmentEntry::isLet):
2309         (JSC::VariableEnvironmentEntry::setIsCaptured):
2310         (JSC::VariableEnvironmentEntry::setIsConst):
2311         (JSC::VariableEnvironmentEntry::setIsVar):
2312         (JSC::VariableEnvironmentEntry::setIsLet):
2313         (JSC::VariableEnvironmentEntry::isConstant): Deleted.
2314         (JSC::VariableEnvironmentEntry::setIsConstant): Deleted.
2315         * runtime/Executable.cpp:
2316         (JSC::ProgramExecutable::initializeGlobalProperties):
2317         * runtime/JSGlobalObject.cpp:
2318         (JSC::JSGlobalObject::defineOwnProperty):
2319         (JSC::JSGlobalObject::addGlobalVar):
2320         (JSC::JSGlobalObject::addFunction):
2321         (JSC::lastInPrototypeChain):
2322         * runtime/JSGlobalObject.h:
2323         (JSC::JSGlobalObject::finishCreation):
2324         (JSC::JSGlobalObject::addVar):
2325         (JSC::JSGlobalObject::addConst): Deleted.
2326         * runtime/JSLexicalEnvironment.cpp:
2327         (JSC::JSLexicalEnvironment::symbolTablePut):
2328         * tests/stress/const-and-with-statement.js: Added.
2329         (truth):
2330         (assert):
2331         (shouldThrowInvalidConstAssignment):
2332         (.):
2333         * tests/stress/const-exception-handling.js: Added.
2334         (truth):
2335         (assert):
2336         (.):
2337         * tests/stress/const-loop-semantics.js: Added.
2338         (truth):
2339         (assert):
2340         (shouldThrowInvalidConstAssignment):
2341         (.):
2342         * tests/stress/const-not-strict-mode.js: Added.
2343         (truth):
2344         (assert):
2345         (shouldThrowTDZ):
2346         (.):
2347         * tests/stress/const-semantics.js: Added.
2348         (truth):
2349         (assert):
2350         (shouldThrowInvalidConstAssignment):
2351         (.):
2352         * tests/stress/const-tdz.js: Added.
2353         (truth):
2354         (assert):
2355         (shouldThrowTDZ):
2356         (.):
2357
2358 2015-07-18  Saam barati  <saambarati1@gmail.com>
2359
2360         lexical scoping is broken with respect to "break" and "continue"
2361         https://bugs.webkit.org/show_bug.cgi?id=147063
2362
2363         Reviewed by Filip Pizlo.
2364
2365         Bug #142944 which introduced "let" and lexical scoping
2366         didn't properly hook into the bytecode generator's machinery
2367         for calculating scope depth deltas for "break" and "continue". This
2368         resulted in the bytecode generator popping an incorrect number
2369         of scopes when lexical scopes were involved.
2370
2371         This patch fixes this problem and generalizes this machinery a bit.
2372         This patch also renames old functions in a sensible way that is more
2373         coherent in a world with lexical scoping.
2374
2375         * bytecompiler/BytecodeGenerator.cpp:
2376         (JSC::BytecodeGenerator::BytecodeGenerator):
2377         (JSC::BytecodeGenerator::newLabelScope):
2378         (JSC::BytecodeGenerator::emitProfileType):
2379         (JSC::BytecodeGenerator::pushLexicalScope):
2380         (JSC::BytecodeGenerator::popLexicalScope):
2381         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
2382         (JSC::BytecodeGenerator::resolveType):
2383         (JSC::BytecodeGenerator::emitResolveScope):
2384         (JSC::BytecodeGenerator::emitGetFromScope):
2385         (JSC::BytecodeGenerator::emitPutToScope):
2386         (JSC::BytecodeGenerator::emitPushWithScope):
2387         (JSC::BytecodeGenerator::emitGetParentScope):
2388         (JSC::BytecodeGenerator::emitPopScope):
2389         (JSC::BytecodeGenerator::emitPopWithOrCatchScope):
2390         (JSC::BytecodeGenerator::emitPopScopes):
2391         (JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
2392         (JSC::BytecodeGenerator::localScopeDepth):
2393         (JSC::BytecodeGenerator::labelScopeDepth):
2394         (JSC::BytecodeGenerator::emitThrowReferenceError):
2395         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
2396         (JSC::BytecodeGenerator::pushScopedControlFlowContext):
2397         (JSC::BytecodeGenerator::popScopedControlFlowContext):
2398         (JSC::BytecodeGenerator::emitPushCatchScope):
2399         (JSC::BytecodeGenerator::currentScopeDepth): Deleted.
2400         * bytecompiler/BytecodeGenerator.h:
2401         (JSC::BytecodeGenerator::hasFinaliser):
2402         (JSC::BytecodeGenerator::scopeDepth): Deleted.
2403         * bytecompiler/NodesCodegen.cpp:
2404         (JSC::ContinueNode::trivialTarget):
2405         (JSC::BreakNode::trivialTarget):
2406         (JSC::ReturnNode::emitBytecode):
2407         (JSC::WithNode::emitBytecode):
2408         (JSC::TryNode::emitBytecode):
2409         * tests/stress/lexical-scoping-break-continue.js: Added.
2410         (assert):
2411         (.):
2412
2413 2015-07-18  Commit Queue  <commit-queue@webkit.org>
2414
2415         Unreviewed, rolling out r186996.
2416         https://bugs.webkit.org/show_bug.cgi?id=147070
2417
2418         Broke JSC tests (Requested by smfr on #webkit).
2419
2420         Reverted changeset:
2421
2422         "lexical scoping is broken with respect to "break" and
2423         "continue""
2424         https://bugs.webkit.org/show_bug.cgi?id=147063
2425         http://trac.webkit.org/changeset/186996
2426
2427 2015-07-18  Saam barati  <saambarati1@gmail.com>
2428
2429         lexical scoping is broken with respect to "break" and "continue"
2430         https://bugs.webkit.org/show_bug.cgi?id=147063
2431
2432         Reviewed by Filip Pizlo.
2433
2434         Bug #142944 which introduced "let" and lexical scoping
2435         didn't properly hook into the bytecode generator's machinery
2436         for calculating scope depth deltas for "break" and "continue". This
2437         resulted in the bytecode generator popping an incorrect number
2438         of scopes when lexical scopes were involved.
2439
2440         This patch fixes this problem and generalizes this machinery a bit.
2441         This patch also renames old functions in a sensible way that is more
2442         coherent in a world with lexical scoping.
2443
2444         * bytecompiler/BytecodeGenerator.cpp:
2445         (JSC::BytecodeGenerator::BytecodeGenerator):
2446         (JSC::BytecodeGenerator::newLabelScope):
2447         (JSC::BytecodeGenerator::emitProfileType):
2448         (JSC::BytecodeGenerator::pushLexicalScope):
2449         (JSC::BytecodeGenerator::popLexicalScope):
2450         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
2451         (JSC::BytecodeGenerator::resolveType):
2452         (JSC::BytecodeGenerator::emitResolveScope):
2453         (JSC::BytecodeGenerator::emitGetFromScope):
2454         (JSC::BytecodeGenerator::emitPutToScope):
2455         (JSC::BytecodeGenerator::emitPushWithScope):
2456         (JSC::BytecodeGenerator::emitGetParentScope):
2457         (JSC::BytecodeGenerator::emitPopScope):
2458         (JSC::BytecodeGenerator::emitPopWithOrCatchScope):
2459         (JSC::BytecodeGenerator::emitPopScopes):
2460         (JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
2461         (JSC::BytecodeGenerator::localScopeDepth):
2462         (JSC::BytecodeGenerator::labelScopeDepth):
2463         (JSC::BytecodeGenerator::emitThrowReferenceError):
2464         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
2465         (JSC::BytecodeGenerator::pushScopedControlFlowContext):
2466         (JSC::BytecodeGenerator::popScopedControlFlowContext):
2467         (JSC::BytecodeGenerator::emitPushCatchScope):
2468         (JSC::BytecodeGenerator::currentScopeDepth): Deleted.
2469         * bytecompiler/BytecodeGenerator.h:
2470         (JSC::BytecodeGenerator::hasFinaliser):
2471         (JSC::BytecodeGenerator::scopeDepth): Deleted.
2472         * bytecompiler/NodesCodegen.cpp:
2473         (JSC::ContinueNode::trivialTarget):
2474         (JSC::BreakNode::trivialTarget):
2475         (JSC::ReturnNode::emitBytecode):
2476         (JSC::WithNode::emitBytecode):
2477         (JSC::TryNode::emitBytecode):
2478         * tests/stress/lexical-scoping-break-continue.js: Added.
2479         (assert):
2480         (.):
2481
2482 2015-07-17  Filip Pizlo  <fpizlo@apple.com>
2483
2484         DFG should have some obvious mitigations against watching structures that are unprofitable to watch
2485         https://bugs.webkit.org/show_bug.cgi?id=147034
2486
2487         Reviewed by Mark Lam and Michael Saboff.
2488         
2489         This implements two guards against the DFG watching structures that are likely to fire
2490         their watchpoints:
2491         
2492         - Don't watch dictionaries or any structure that had a dictionary in its past. Dictionaries
2493           can be flattened, and then they can transform back to dictionaries.
2494         
2495         - Don't watch structures whose past structures were transitioned-away from while their
2496           transition watchpoints were being watched. This property gives us monotonicity: if we
2497           recompile because we watched structure S1 of object O, then we won't make the same mistake
2498           again when object O has structure S2, S3, and so on.
2499         
2500         This is a 1.5% speed-up on Kraken. It does penalize some Octane tests, but it also seems to
2501         help some of them, so on Octane it's basically neutral.
2502
2503         * bytecode/Watchpoint.h:
2504         (JSC::WatchpointSet::invalidate):
2505         (JSC::WatchpointSet::isBeingWatched):
2506         (JSC::WatchpointSet::addressOfState):
2507         (JSC::WatchpointSet::addressOfSetIsNotEmpty):
2508         (JSC::InlineWatchpointSet::touch):
2509         (JSC::InlineWatchpointSet::isBeingWatched):
2510         * runtime/JSGlobalObject.h:
2511         (JSC::JSGlobalObject::createStructure):
2512         (JSC::JSGlobalObject::registerWeakMap):
2513         * runtime/Structure.cpp:
2514         (JSC::Structure::Structure):
2515         (JSC::Structure::toDictionaryTransition):
2516         (JSC::Structure::didTransitionFromThisStructure):
2517         * runtime/Structure.h:
2518
2519 2015-07-16  Filip Pizlo  <fpizlo@apple.com>
2520
2521         Remove DFG::DesiredWriteBarriers because it's just a very difficult way of saying "please barrier the machine code block owner"
2522         https://bugs.webkit.org/show_bug.cgi?id=147030
2523
2524         Reviewed by Andreas Kling.
2525         
2526         All of the users of DesiredWriteBarriers were just using it to request that Plan
2527         finalization executes a barrier on codeBlock->ownerExecutable. Indeed, that's the only
2528         owning cell in the heap that compilation affects. So, we might as well just have Plan
2529         unconditionally execute that barrier and then we don't need DesiredWriteBarriers at
2530         all.
2531
2532         * CMakeLists.txt:
2533         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2534         * JavaScriptCore.xcodeproj/project.pbxproj:
2535         * dfg/DFGByteCodeParser.cpp:
2536         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2537         * dfg/DFGDesiredWriteBarriers.cpp: Removed.
2538         * dfg/DFGDesiredWriteBarriers.h: Removed.
2539         * dfg/DFGGraph.cpp:
2540         (JSC::DFG::Graph::registerFrozenValues):
2541         * dfg/DFGPlan.cpp:
2542         (JSC::DFG::Plan::reallyAdd):
2543         (JSC::DFG::Plan::notifyCompiling):
2544         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
2545         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
2546         (JSC::DFG::Plan::cancel):
2547         * dfg/DFGPlan.h:
2548
2549 2015-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2550
2551         Integrate automatic microtask draining into JSC framework and re-enable Promise
2552         https://bugs.webkit.org/show_bug.cgi?id=146828
2553
2554         Reviewed by Sam Weinig.
2555
2556         Add automatic microtask draining system into JSC framework.
2557         When the depth of VM lock becomes 0, before this, we drain the queued microtasks.
2558         Enqueuing behavior can be injected by the JSGlobalObject's method table.
2559         It is utilized in WebCore to post the microtask to WebCore's event loop.
2560
2561         In the case of JSC interactive shell, VM depth is always greater than 0.
2562         So we manually drains the queued microtasks after evaluating the written line.
2563
2564         Since now JSC framework has the microtask queue, we can drain the queued microtasks.
2565         So re-enable the Promise in the JSC framework context.
2566
2567         * API/JSContextRef.cpp:
2568         (javaScriptRuntimeFlags): Deleted.
2569         * API/tests/testapi.c:
2570         (main):
2571         * API/tests/testapi.mm:
2572         (testObjectiveCAPIMain):
2573         * jsc.cpp:
2574         (runInteractive):
2575         * runtime/JSGlobalObject.cpp:
2576         (JSC::JSGlobalObject::queueMicrotask):
2577         * runtime/JSLock.cpp:
2578         (JSC::JSLock::willReleaseLock):
2579         * runtime/VM.cpp:
2580         (JSC::VM::queueMicrotask):
2581         (JSC::VM::drainMicrotasks):
2582         (JSC::QueuedTask::run):
2583         * runtime/VM.h:
2584         (JSC::QueuedTask::QueuedTask):
2585
2586 2015-07-17  Saam barati  <saambarati1@gmail.com>
2587
2588         Function parameters should be parsed in the same parser arena as the function body
2589         https://bugs.webkit.org/show_bug.cgi?id=145995
2590
2591         Reviewed by Yusuke Suzuki.
2592
2593         This patch changes how functions are parsed in JSC. A function's
2594         parameters are now parsed in the same arena as the function itself.
2595         This allows us to arena allocate all destructuring AST nodes and
2596         the FunctionParameters node. This will help make implementing ES6
2597         default parameter values sane.
2598
2599         A source code that represents a function now includes the text of the function's 
2600         parameters. The starting offset is at the opening parenthesis of the parameter
2601         list or at the starting character of the identifier for arrow functions that
2602         have single arguments and don't start with parenthesis.
2603
2604         For example:
2605
2606         "function (param1, param2) { ... }"
2607                                    ^
2608                                    | This offset used to be the starting offset of a function's SourceCode
2609                   ^
2610                   | This is the new starting offset for a function's SourceCode.
2611
2612         This requires us to change how some offsets are calculated
2613         and also requires us to report some different line numbers for internal
2614         metrics that use a SourceCode's starting line and column numbers.
2615
2616         This patch also does a bit of cleanup with regards to how
2617         functions are parsed in general (especially arrow functions).
2618         It removes some unnecessary #ifdefs and the likes for arrow
2619         to make things clearer and more deliberate.
2620
2621         * API/JSScriptRef.cpp:
2622         (parseScript):
2623         * builtins/BuiltinExecutables.cpp:
2624         (JSC::BuiltinExecutables::createExecutableInternal):
2625         * bytecode/UnlinkedCodeBlock.cpp:
2626         (JSC::generateFunctionCodeBlock):
2627         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2628         (JSC::UnlinkedFunctionExecutable::visitChildren):
2629         (JSC::UnlinkedFunctionExecutable::parameterCount): Deleted.
2630         * bytecode/UnlinkedCodeBlock.h:
2631         * bytecompiler/NodesCodegen.cpp:
2632         (JSC::DestructuringAssignmentNode::emitBytecode):
2633         (JSC::assignDefaultValueIfUndefined):
2634         (JSC::ArrayPatternNode::collectBoundIdentifiers):
2635         (JSC::DestructuringPatternNode::~DestructuringPatternNode): Deleted.
2636         * parser/ASTBuilder.h:
2637         (JSC::ASTBuilder::createClassExpr):
2638         (JSC::ASTBuilder::createFunctionExpr):
2639         (JSC::ASTBuilder::createFunctionBody):
2640         (JSC::ASTBuilder::createArrowFunctionExpr):
2641         (JSC::ASTBuilder::createGetterOrSetterProperty):
2642         (JSC::ASTBuilder::createElementList):
2643         (JSC::ASTBuilder::createFormalParameterList):
2644         (JSC::ASTBuilder::appendParameter):
2645         (JSC::ASTBuilder::createClause):
2646         (JSC::ASTBuilder::createClauseList):
2647         (JSC::ASTBuilder::createFuncDeclStatement):
2648         (JSC::ASTBuilder::createForInLoop):
2649         (JSC::ASTBuilder::createForOfLoop):
2650         (JSC::ASTBuilder::isResolve):
2651         (JSC::ASTBuilder::createDestructuringAssignment):
2652         (JSC::ASTBuilder::createArrayPattern):
2653         (JSC::ASTBuilder::appendArrayPatternSkipEntry):
2654         (JSC::ASTBuilder::appendArrayPatternEntry):
2655         (JSC::ASTBuilder::appendArrayPatternRestEntry):
2656         (JSC::ASTBuilder::finishArrayPattern):
2657         (JSC::ASTBuilder::createObjectPattern):
2658         (JSC::ASTBuilder::appendObjectPatternEntry):
2659         (JSC::ASTBuilder::createBindingLocation):
2660         (JSC::ASTBuilder::setEndOffset):
2661         * parser/Lexer.cpp:
2662         (JSC::Lexer<T>::Lexer):
2663         (JSC::Lexer<T>::nextTokenIsColon):
2664         (JSC::Lexer<T>::setTokenPosition):
2665         (JSC::Lexer<T>::lex):
2666         (JSC::Lexer<T>::clear):
2667         * parser/Lexer.h:
2668         (JSC::Lexer::setIsReparsingFunction):
2669         (JSC::Lexer::isReparsingFunction):
2670         (JSC::Lexer::lineNumber):
2671         (JSC::Lexer::setIsReparsing): Deleted.
2672         (JSC::Lexer::isReparsing): Deleted.
2673         * parser/NodeConstructors.h:
2674         (JSC::TryNode::TryNode):
2675         (JSC::FunctionParameters::FunctionParameters):
2676         (JSC::FuncExprNode::FuncExprNode):
2677         (JSC::FuncDeclNode::FuncDeclNode):
2678         (JSC::ArrayPatternNode::ArrayPatternNode):
2679         (JSC::ObjectPatternNode::ObjectPatternNode):
2680         (JSC::BindingNode::BindingNode):
2681         (JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
2682         (JSC::ParameterNode::ParameterNode): Deleted.
2683         (JSC::ArrayPatternNode::create): Deleted.
2684         (JSC::ObjectPatternNode::create): Deleted.
2685         (JSC::BindingNode::create): Deleted.
2686         * parser/Nodes.cpp:
2687         (JSC::ProgramNode::ProgramNode):
2688         (JSC::EvalNode::EvalNode):
2689         (JSC::FunctionBodyNode::FunctionBodyNode):
2690         (JSC::FunctionBodyNode::finishParsing):
2691         (JSC::FunctionNode::FunctionNode):
2692         (JSC::FunctionNode::finishParsing):
2693         (JSC::FunctionParameters::create): Deleted.
2694         (JSC::FunctionParameters::FunctionParameters): Deleted.
2695         (JSC::FunctionParameters::~FunctionParameters): Deleted.
2696         * parser/Nodes.h:
2697         (JSC::ProgramNode::startColumn):
2698         (JSC::ProgramNode::endColumn):
2699         (JSC::EvalNode::startColumn):
2700         (JSC::EvalNode::endColumn):
2701         (JSC::FunctionParameters::size):
2702         (JSC::FunctionParameters::at):
2703         (JSC::FunctionParameters::append):
2704         (JSC::FuncExprNode::body):
2705         (JSC::DestructuringPatternNode::~DestructuringPatternNode):
2706         (JSC::DestructuringPatternNode::isBindingNode):
2707         (JSC::DestructuringPatternNode::emitDirectBinding):
2708         (JSC::ArrayPatternNode::appendIndex):
2709         (JSC::ObjectPatternNode::appendEntry):
2710         (JSC::BindingNode::boundProperty):
2711         (JSC::BindingNode::divotStart):
2712         (JSC::BindingNode::divotEnd):
2713         (JSC::DestructuringAssignmentNode::bindings):
2714         (JSC::FuncDeclNode::body):
2715         (JSC::ParameterNode::pattern): Deleted.
2716         (JSC::ParameterNode::nextParam): Deleted.
2717         (JSC::FunctionParameters::patterns): Deleted.
2718         * parser/Parser.cpp:
2719         (JSC::Parser<LexerType>::Parser):
2720         (JSC::Parser<LexerType>::~Parser):
2721         (JSC::Parser<LexerType>::parseInner):
2722         (JSC::Parser<LexerType>::allowAutomaticSemicolon):
2723         (JSC::Parser<LexerType>::parseSourceElements):
2724         (JSC::Parser<LexerType>::createBindingPattern):
2725         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
2726         (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
2727         (JSC::Parser<LexerType>::parseSwitchClauses):
2728         (JSC::Parser<LexerType>::parseSwitchDefaultClause):
2729         (JSC::Parser<LexerType>::parseBlockStatement):
2730         (JSC::Parser<LexerType>::parseStatement):
2731         (JSC::Parser<LexerType>::parseFormalParameters):
2732         (JSC::Parser<LexerType>::parseFunctionBody):
2733         (JSC::stringForFunctionMode):
2734         (JSC::Parser<LexerType>::parseFunctionParameters):
2735         (JSC::Parser<LexerType>::parseFunctionInfo):
2736         (JSC::Parser<LexerType>::parseFunctionDeclaration):
2737         (JSC::Parser<LexerType>::parseClass):
2738         (JSC::Parser<LexerType>::parsePrimaryExpression):
2739         (JSC::Parser<LexerType>::parseMemberExpression):
2740         (JSC::Parser<LexerType>::parseArrowFunctionExpression):
2741         (JSC::operatorString):
2742         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBody): Deleted.
2743         * parser/Parser.h:
2744         (JSC::Parser::positionBeforeLastNewline):
2745         (JSC::Parser::locationBeforeLastToken):
2746         (JSC::Parser::findCachedFunctionInfo):
2747         (JSC::Parser::isofToken):
2748         (JSC::Parser::isEndOfArrowFunction):
2749         (JSC::Parser::isArrowFunctionParamters):
2750         (JSC::Parser::tokenStart):
2751         (JSC::Parser::isLETMaskedAsIDENT):
2752         (JSC::Parser::autoSemiColon):
2753         (JSC::Parser::setEndOfStatement):
2754         (JSC::Parser::canRecurse):
2755         (JSC::Parser<LexerType>::parse):
2756         (JSC::parse):
2757         * parser/ParserFunctionInfo.h:
2758         * parser/ParserModes.h:
2759         (JSC::functionNameIsInScope):
2760         * parser/SourceCode.h:
2761         (JSC::makeSource):
2762         (JSC::SourceCode::subExpression):
2763         (JSC::SourceCode::subArrowExpression): Deleted.
2764         * parser/SourceProviderCache.h:
2765         (JSC::SourceProviderCache::get):
2766         * parser/SourceProviderCacheItem.h:
2767         (JSC::SourceProviderCacheItem::endFunctionToken):
2768         (JSC::SourceProviderCacheItem::usedVariables):
2769         (JSC::SourceProviderCacheItem::writtenVariables):
2770         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
2771         * parser/SyntaxChecker.h:
2772         (JSC::SyntaxChecker::SyntaxChecker):
2773         (JSC::SyntaxChecker::createClassExpr):
2774         (JSC::SyntaxChecker::createFunctionExpr):
2775         (JSC::SyntaxChecker::createFunctionBody):
2776         (JSC::SyntaxChecker::createArrowFunctionExpr):
2777         (JSC::SyntaxChecker::setFunctionNameStart):
2778         (JSC::SyntaxChecker::createArguments):
2779         (JSC::SyntaxChecker::createPropertyList):
2780         (JSC::SyntaxChecker::createElementList):
2781         (JSC::SyntaxChecker::createFormalParameterList):
2782         (JSC::SyntaxChecker::appendParameter):
2783         (JSC::SyntaxChecker::createClause):
2784         (JSC::SyntaxChecker::createClauseList):
2785         * runtime/CodeCache.cpp:
2786         (JSC::CodeCache::getGlobalCodeBlock):
2787         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
2788         * runtime/Completion.cpp:
2789         (JSC::checkSyntax):
2790         * runtime/Executable.cpp:
2791         (JSC::ProgramExecutable::checkSyntax):
2792         * tests/controlFlowProfiler/conditional-expression.js:
2793         (testConditionalFunctionCall):
2794
2795 2015-07-16  Filip Pizlo  <fpizlo@apple.com>
2796
2797         Unreviewed, fix build for newer LLVMs.
2798
2799         * llvm/LLVMHeaders.h:
2800         * llvm/library/LLVMExports.cpp:
2801
2802 2015-07-16  Mark Lam  <mark.lam@apple.com>
2803
2804         RegExp::match() should set m_state to ByteCode if compilation fails.
2805         https://bugs.webkit.org/show_bug.cgi?id=147023
2806
2807         Reviewed by Michael Saboff.
2808
2809         A RegExp has a YarrCodeBlock that has 4 MacroAssemblerCodeRefs for compiled code.
2810         If one of these compilations succeeds, RegExp::m_state will be set to JITCode.
2811         Subsequently, if RegExp tries to compile another one of these but fails, m_state
2812         will be left untouched i.e. it still says JITCode.  As a result, when
2813         RegExp::match() later tries to execute the non-existant compiled code, it will
2814         crash.
2815
2816         The fix is to downgrade m_state to ByteCode if RegExp ever fails to compile.
2817         This failure should be rare.  We'll do the minimal work here to fix the issue and
2818         keep an eye on the perf bots.  If perf regresses, we can do some optimization work then.
2819
2820         This issue is difficult to test for since it either requires a low memory condition
2821         to trigger a failed RegExp compilation at the right moment, or for the RegExp to
2822         succeed compilation in the MatchedOnly mode but fail in IncludeSubpatterns mode.
2823         Instead, I manually tested it by instrumenting RegExp::compile() to fail once in every
2824         10 compilation attempts.
2825
2826         * runtime/RegExp.cpp:
2827         (JSC::RegExp::compile):
2828         (JSC::RegExp::compileMatchOnly):
2829
2830 2015-07-15  Brent Fulgham  <bfulgham@apple.com>
2831
2832         [Win] Fix armv7 build.
2833
2834         * jit/CCallHelpers.h:
2835         (JSC::CCallHelpers::setupArgumentsWithExecState): The 64-bit argument
2836         version of poke is not available on armv7 builds.
2837
2838 2015-07-15  Brent Fulgham  <bfulgham@apple.com>
2839
2840         [Win] 64-bit Build Failure
2841         https://bugs.webkit.org/show_bug.cgi?id=146989
2842
2843         Reviewed by Mark Lam.
2844
2845         * jit/CCallHelpers.h:
2846         (JSC::CCallHelpers::setupArgumentsWithExecState): Add missing
2847         declaration for 64-bit type on 4-argument register machines (like
2848         Windows).
2849
2850 2015-07-15  Saam barati  <saambarati1@gmail.com>
2851
2852         [ES6] implement block scoping to enable 'let'
2853         https://bugs.webkit.org/show_bug.cgi?id=142944
2854
2855         Reviewed by Filip Pizlo.
2856
2857         * CMakeLists.txt:
2858         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2859         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2860         * JavaScriptCore.xcodeproj/project.pbxproj:
2861         * builtins/BuiltinExecutables.cpp:
2862         (JSC::BuiltinExecutables::createExecutableInternal):
2863         * bytecode/BytecodeList.json:
2864         This patch adds a new opcode and removes op_pop_scope:
2865         1) op_get_parent_scope returns the parent scope but doesn't 
2866         implicitly write that scope into the scope register. op_pop_scope
2867         is now reduced to op_get_parent_scope followed by op_mov.
2868
2869         * bytecode/BytecodeUseDef.h:
2870         (JSC::computeUsesForBytecodeOffset):
2871         (JSC::computeDefsForBytecodeOffset):
2872         * bytecode/CodeBlock.cpp:
2873         (JSC::CodeBlock::dumpBytecode):
2874         (JSC::CodeBlock::CodeBlock):
2875         (JSC::CodeBlock::stronglyVisitStrongReferences):
2876         * bytecode/CodeBlock.h:
2877         (JSC::CodeBlock::addStringSwitchJumpTable):
2878         (JSC::CodeBlock::stringSwitchJumpTable):
2879         (JSC::CodeBlock::symbolTable):
2880         (JSC::CodeBlock::evalCodeCache):
2881         (JSC::CodeBlock::setConstantRegisters):
2882         (JSC::CodeBlock::replaceConstant):
2883         op_put_to_scope for LocalClosureVar now takes as an argument
2884         the constant index for the Symbol Table it will be putting into.
2885         This argument is only used to communicate from the BytecodeGenerator
2886         to CodeBlock linking time and it is not present in the linked bytecode.
2887
2888         op_put_to_scope for non LocalClosureVar takes, at the same index, an
2889         argument that represents the local scope depth which it uses for
2890         JSScope::abstractResolve to know how many scopes it needs to skip.
2891         Again, this is not in the linked code.
2892         op_get_from_scope and op_resolve_scope also take as an argument
2893         the local scope depth to use in JSScope::abstractResolve. Again,
2894         this is not used in the linked code.
2895
2896         * bytecode/EvalCodeCache.h:
2897         (JSC::EvalCodeCache::tryGet):
2898         (JSC::EvalCodeCache::getSlow):
2899         (JSC::EvalCodeCache::clear):
2900         (JSC::EvalCodeCache::isCacheable):
2901         When direct eval is called and passed a scope that 
2902         corresponds to a lexical scope, we can't safely cache 
2903         that code because we won't be able to guarantee
2904         that the cached code is always executed in the same scope.
2905         Consider this example:
2906         function foo() {
2907             let x = 20;
2908             eval("x;");
2909             if (b) {
2910                 let x = 30;
2911                 if (b) {
2912                     let y = 40;
2913                     eval("x;")
2914                 }
2915             }
2916         }
2917
2918         We can't reuse resolution depth when linking get_from_scope in evals.
2919
2920         * bytecode/UnlinkedCodeBlock.cpp:
2921         (JSC::generateFunctionCodeBlock):
2922         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2923         (JSC::UnlinkedFunctionExecutable::parameterCount):
2924         * bytecode/UnlinkedCodeBlock.h:
2925         Unlinked functions now know the variables that were under TDZ in their parent
2926         scope.
2927
2928         (JSC::UnlinkedCodeBlock::symbolTable):
2929         (JSC::UnlinkedCodeBlock::setSymbolTable):
2930         (JSC::UnlinkedCodeBlock::setSymbolTableConstantIndex):
2931         (JSC::UnlinkedCodeBlock::symbolTableConstantIndex):
2932         (JSC::UnlinkedCodeBlock::vm):
2933         * bytecompiler/BytecodeGenerator.cpp:
2934         (JSC::BytecodeGenerator::generate):
2935         (JSC::BytecodeGenerator::BytecodeGenerator):
2936         (JSC::BytecodeGenerator::~BytecodeGenerator):
2937         (JSC::BytecodeGenerator::newRegister):
2938         (JSC::BytecodeGenerator::reclaimFreeRegisters):
2939         (JSC::BytecodeGenerator::newBlockScopeVariable):
2940         (JSC::BytecodeGenerator::newTemporary):
2941         (JSC::BytecodeGenerator::emitProfileType):
2942         (JSC::BytecodeGenerator::emitLoadGlobalObject):
2943         (JSC::BytecodeGenerator::pushLexicalScope):
2944         (JSC::BytecodeGenerator::popLexicalScope):
2945         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
2946         (JSC::BytecodeGenerator::variable):
2947         (JSC::BytecodeGenerator::variablePerSymbolTable):
2948         (JSC::BytecodeGenerator::variableForLocalEntry):
2949         (JSC::BytecodeGenerator::createVariable):
2950         (JSC::BytecodeGenerator::emitResolveScope):
2951         (JSC::BytecodeGenerator::emitGetFromScope):
2952         (JSC::BytecodeGenerator::emitPutToScope):
2953         (JSC::BytecodeGenerator::initializeVariable):
2954         (JSC::BytecodeGenerator::emitTDZCheck):
2955         (JSC::BytecodeGenerator::needsTDZCheck):
2956         (JSC::BytecodeGenerator::emitTDZCheckIfNecessary):
2957         (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
2958         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
2959         (JSC::BytecodeGenerator::emitNewObject):
2960         (JSC::BytecodeGenerator::emitPushWithScope):
2961         (JSC::BytecodeGenerator::emitGetParentScope):
2962         (JSC::BytecodeGenerator::emitPopScope):
2963         (JSC::BytecodeGenerator::emitDebugHook):
2964         (JSC::BytecodeGenerator::pushFinallyContext):
2965         (JSC::BytecodeGenerator::pushIteratorCloseContext):
2966         (JSC::BytecodeGenerator::emitComplexPopScopes):
2967         (JSC::BytecodeGenerator::emitPopScopes):
2968         (JSC::BytecodeGenerator::popTryAndEmitCatch):
2969         (JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
2970         (JSC::BytecodeGenerator::currentScopeDepth):
2971         (JSC::BytecodeGenerator::emitThrowReferenceError):
2972         (JSC::BytecodeGenerator::emitPushCatchScope):
2973         (JSC::BytecodeGenerator::beginSwitch):
2974         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
2975         (JSC::BytecodeGenerator::emitEnumeration):
2976         * bytecompiler/BytecodeGenerator.h:
2977         (JSC::Variable::Variable):
2978         (JSC::Variable::isResolved):
2979         (JSC::Variable::symbolTableConstantIndex):
2980         (JSC::Variable::ident):
2981         (JSC::BytecodeGenerator::ignoredResult):
2982         (JSC::BytecodeGenerator::tempDestination):
2983         (JSC::BytecodeGenerator::lastOpcodeID):
2984         (JSC::BytecodeGenerator::makeFunction):
2985         (JSC::BytecodeGenerator::symbolTable):
2986         (JSC::BytecodeGenerator::shouldOptimizeLocals): Deleted.
2987         (JSC::BytecodeGenerator::canOptimizeNonLocals): Deleted.
2988         The heart of the changes in this patch are in the bytecode generator.
2989         The bytecode generator now keeps a stack of tuples of 
2990         {symbol table, scope register, flag indicating catch or with scope, symbol table index in constant pool}
2991         that models the runtime scope stack. This symbol table stack is used
2992         in resolving local variables.
2993
2994         Also, the bytecode generator handles pushing and popping of lexical scopes. 
2995         This is relatively straight forward:
2996         Captured 'let' variables end up in the JSLexicalEnvironment scope and non-captured
2997         variables end up on the stack. Some trickiness is involved in generating
2998         code for 'for' loops that have captured variables (I'm talking about variables in the loop
2999         header, not the loop body). Each iteration of the for loop ends up with 
3000         its own JSLexicalEnvironment. Static code must be generated in such a way 
3001         to create this runtime behavior. This is done by emitting instructions to 
3002         push and pop a lexical scope at the end of each loop and copying values
3003         from the previous loop's scope into the new scope. This code must also
3004         ensure that each loop iteration's scope refers to the same underlying 
3005         SymbolTable so that no scope is accidentally mistaken as being a singleton scope.
3006
3007         When the debugger is enabled, all lexically defined variables will end up in the
3008         JSLexicalEnvironment.
3009
3010         * bytecompiler/NodesCodegen.cpp:
3011         (JSC::ResolveNode::emitBytecode):
3012         (JSC::FunctionCallResolveNode::emitBytecode):
3013         (JSC::PostfixNode::emitResolve):
3014         (JSC::DeleteResolveNode::emitBytecode):
3015         (JSC::TypeOfResolveNode::emitBytecode):
3016         (JSC::PrefixNode::emitResolve):
3017         (JSC::ReadModifyResolveNode::emitBytecode):
3018         (JSC::AssignResolveNode::emitBytecode):
3019         (JSC::BlockNode::emitBytecode):
3020         (JSC::ExprStatementNode::emitBytecode):
3021         (JSC::DeclarationStatement::emitBytecode):
3022         (JSC::EmptyVarExpression::emitBytecode):
3023         (JSC::EmptyLetExpression::emitBytecode):
3024         (JSC::ForNode::emitBytecode):
3025         (JSC::ForInNode::emitMultiLoopBytecode):
3026         (JSC::ForOfNode::emitBytecode):
3027         (JSC::SwitchNode::emitBytecode):
3028         (JSC::BindingNode::bindValue):
3029         (JSC::VarStatementNode::emitBytecode): Deleted.
3030         * debugger/DebuggerCallFrame.cpp:
3031         (JSC::DebuggerCallFrame::evaluate):
3032         * debugger/DebuggerScope.cpp:
3033         (JSC::DebuggerScope::getOwnPropertySlot):
3034         (JSC::DebuggerScope::put):
3035         * dfg/DFGByteCodeParser.cpp:
3036         (JSC::DFG::ByteCodeParser::parseBlock):
3037         * dfg/DFGCapabilities.cpp:
3038         (JSC::DFG::capabilityLevel):
3039         * dfg/DFGNode.h:
3040         (JSC::DFG::Node::castConstant):
3041         (JSC::DFG::Node::initializationValueForActivation):
3042         (JSC::DFG::Node::containsMovHint):
3043         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3044         CreateActivation nodes now have a second OpInfo that tracks the 
3045         initial value that needs to be placed in the activation. This initial value 
3046         is also used in allocation sinking to create proper bottom values for all 
3047         scope variables.
3048
3049         * dfg/DFGOperations.cpp:
3050         * dfg/DFGOperations.h:
3051         * dfg/DFGSpeculativeJIT.cpp:
3052         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
3053         * dfg/DFGSpeculativeJIT.h:
3054         (JSC::DFG::SpeculativeJIT::callOperation):
3055         * ftl/FTLIntrinsicRepository.h:
3056         * ftl/FTLLowerDFGToLLVM.cpp:
3057         (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
3058         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
3059         * ftl/FTLOperations.cpp:
3060         (JSC::FTL::operationMaterializeObjectInOSR):
3061         * interpreter/Interpreter.cpp:
3062         (JSC::Interpreter::execute):
3063         * jit/CCallHelpers.h:
3064         (JSC::CCallHelpers::setupArgumentsWithExecState):
3065         * jit/JIT.cpp:
3066         (JSC::JIT::privateCompileMainPass):
3067         * jit/JIT.h:
3068         * jit/JITInlines.h:
3069         (JSC::JIT::callOperation):
3070         * jit/JITOpcodes.cpp:
3071         (JSC::JIT::emit_op_push_with_scope):
3072         (JSC::JIT::compileOpStrictEq):
3073         (JSC::JIT::emit_op_catch):
3074         (JSC::JIT::emit_op_create_lexical_environment):
3075         (JSC::JIT::emit_op_get_parent_scope):
3076         (JSC::JIT::emit_op_switch_imm):
3077         (JSC::JIT::emit_op_enter):
3078         (JSC::JIT::emit_op_get_scope):
3079         (JSC::JIT::emit_op_pop_scope): Deleted.
3080         * jit/JITOpcodes32_64.cpp:
3081         (JSC::JIT::emit_op_push_with_scope):
3082         (JSC::JIT::emit_op_to_number):
3083         (JSC::JIT::emit_op_catch):
3084         (JSC::JIT::emit_op_create_lexical_environment):
3085         (JSC::JIT::emit_op_get_parent_scope):
3086         (JSC::JIT::emit_op_switch_imm):
3087         (JSC::JIT::emit_op_enter):
3088         (JSC::JIT::emit_op_get_scope):
3089         (JSC::JIT::emit_op_pop_scope): Deleted.
3090         * jit/JITOperations.cpp:
3091         (JSC::canAccessArgumentIndexQuickly):
3092         * jit/JITOperations.h:
3093         * llint/LLIntSlowPaths.cpp:
3094         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3095         * llint/LLIntSlowPaths.h:
3096         * llint/LowLevelInterpreter.asm:
3097         * llint/LowLevelInterpreter32_64.asm:
3098         * llint/LowLevelInterpreter64.asm:
3099         * parser/ASTBuilder.h:
3100         (JSC::ASTBuilder::createSourceElements):
3101         (JSC::ASTBuilder::funcDeclarations):
3102         (JSC::ASTBuilder::features):
3103         (JSC::ASTBuilder::numConstants):
3104         (JSC::ASTBuilder::createConditionalExpr):
3105         (JSC::ASTBuilder::createAssignResolve):
3106         (JSC::ASTBuilder::createClassDeclStatement):
3107         (JSC::ASTBuilder::createBlockStatement):
3108         (JSC::ASTBuilder::createIfStatement):
3109         (JSC::ASTBuilder::createForLoop):
3110         (JSC::ASTBuilder::createForInLoop):
3111         (JSC::ASTBuilder::createForOfLoop):
3112         (JSC::ASTBuilder::isBindingNode):
3113         (JSC::ASTBuilder::createEmptyStatement):
3114         (JSC::ASTBuilder::createDeclarationStatement):
3115         (JSC::ASTBuilder::createVarStatement):
3116         (JSC::ASTBuilder::createLetStatement):
3117         (JSC::ASTBuilder::createEmptyVarExpression):
3118         (JSC::ASTBuilder::createEmptyLetExpression):
3119         (JSC::ASTBuilder::createReturnStatement):
3120         (JSC::ASTBuilder::createTryStatement):
3121         (JSC::ASTBuilder::createSwitchStatement):
3122         (JSC::ASTBuilder::appendStatement):
3123         (JSC::ASTBuilder::createCommaExpr):
3124         (JSC::ASTBuilder::appendObjectPatternEntry):
3125         (JSC::ASTBuilder::createBindingLocation):
3126         (JSC::ASTBuilder::setEndOffset):
3127         (JSC::ASTBuilder::Scope::Scope):
3128         (JSC::ASTBuilder::makeAssignNode):
3129         (JSC::ASTBuilder::varDeclarations): Deleted.
3130         (JSC::ASTBuilder::addVar): Deleted.
3131         * parser/Keywords.table:
3132         * parser/NodeConstructors.h:
3133         (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
3134         (JSC::AssignResolveNode::AssignResolveNode):
3135         (JSC::ExprStatementNode::ExprStatementNode):
3136         (JSC::DeclarationStatement::DeclarationStatement):
3137         (JSC::EmptyVarExpression::EmptyVarExpression):
3138         (JSC::EmptyLetExpression::EmptyLetExpression):
3139         (JSC::IfElseNode::IfElseNode):
3140         (JSC::WhileNode::WhileNode):
3141         (JSC::ForNode::ForNode):
3142         (JSC::CaseBlockNode::CaseBlockNode):
3143         (JSC::SwitchNode::SwitchNode):
3144         (JSC::ConstDeclNode::ConstDeclNode):
3145         (JSC::BlockNode::BlockNode):
3146         (JSC::EnumerationNode::EnumerationNode):
3147         (JSC::ForInNode::ForInNode):
3148         (JSC::ForOfNode::ForOfNode):
3149         (JSC::ObjectPatternNode::create):
3150         (JSC::BindingNode::create):
3151         (JSC::BindingNode::BindingNode):
3152         (JSC::VarStatementNode::VarStatementNode): Deleted.
3153         * parser/Nodes.cpp:
3154         (JSC::ScopeNode::ScopeNode):
3155         (JSC::ScopeNode::singleStatement):
3156         (JSC::ProgramNode::ProgramNode):
3157         (JSC::EvalNode::EvalNode):
3158         (JSC::FunctionNode::FunctionNode):
3159         (JSC::FunctionNode::finishParsing):
3160         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
3161         * parser/Nodes.h:
3162         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
3163         (JSC::VariableEnvironmentNode::lexicalVariables):
3164         (JSC::ScopeNode::usesThis):
3165         (JSC::ScopeNode::needsActivationForMoreThanVariables):
3166         (JSC::ScopeNode::needsActivation):
3167         (JSC::ScopeNode::hasCapturedVariables):
3168         (JSC::ScopeNode::captures):
3169         (JSC::ScopeNode::varDeclarations):
3170         (JSC::ScopeNode::functionStack):
3171         (JSC::ScopeNode::neededConstants):
3172         (JSC::ProgramNode::startColumn):
3173         (JSC::ProgramNode::endColumn):
3174         (JSC::EvalNode::startColumn):
3175         (JSC::EvalNode::endColumn):
3176         (JSC::BindingNode::boundProperty):
3177         (JSC::BindingNode::divotStart):
3178         (JSC::BindingNode::divotEnd):
3179         (JSC::ScopeNode::capturedVariableCount): Deleted.
3180         (JSC::ScopeNode::capturedVariables): Deleted.
3181         (JSC::ScopeNode::varStack): Deleted.
3182         There is a new class called 'VariableEnvironmentNode' that has the
3183         necessary fields to model a lexical scope. Multiple AST nodes now 
3184         also inherit from VariableEnvironmentNode.
3185
3186         * parser/Parser.cpp:
3187         (JSC::Parser<LexerType>::parseInner):
3188         (JSC::Parser<LexerType>::didFinishParsing):
3189         (JSC::Parser<LexerType>::parseStatementListItem):
3190         (JSC::Parser<LexerType>::parseVariableDeclaration):
3191         (JSC::Parser<LexerType>::parseWhileStatement):
3192         (JSC::Parser<LexerType>::parseVariableDeclarationList):
3193         (JSC::Parser<LexerType>::createBindingPattern):
3194         (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
3195         (JSC::Parser<LexerType>::parseDestructuringPattern):
3196         (JSC::Parser<LexerType>::parseConstDeclarationList):
3197         (JSC::Parser<LexerType>::parseForStatement):
3198         (JSC::Parser<LexerType>::parseBreakStatement):
3199         (JSC::Parser<LexerType>::parseContinueStatement):
3200         (JSC::Parser<LexerType>::parseSwitchStatement):
3201         (JSC::Parser<LexerType>::parseTryStatement):
3202         (JSC::Parser<LexerType>::parseBlockStatement):
3203         (JSC::Parser<LexerType>::parseStatement):
3204         (JSC::Parser<LexerType>::parseFunctionInfo):
3205         (JSC::Parser<LexerType>::parseClassDeclaration):
3206         (JSC::Parser<LexerType>::parseClass):
3207         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
3208         (JSC::Parser<LexerType>::parseAssignmentExpression):
3209         (JSC::Parser<LexerType>::parseGetterSetter):
3210         (JSC::Parser<LexerType>::parsePrimaryExpression):
3211         (JSC::Parser<LexerType>::parseVarDeclaration): Deleted.
3212         (JSC::Parser<LexerType>::parseVarDeclarationList): Deleted.
3213         * parser/Parser.h:
3214         (JSC::Scope::Scope):
3215         (JSC::Scope::setIsFunction):
3216         (JSC::Scope::isFunction):
3217         (JSC::Scope::isFunctionBoundary):
3218         (JSC::Scope::setIsLexicalScope):
3219         (JSC::Scope::isLexicalScope):
3220         (JSC::Scope::declaredVariables):
3221         (JSC::Scope::finalizeLexicalEnvironment):
3222         (JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates):
3223         (JSC::Scope::declareCallee):
3224         (JSC::Scope::declareVariable):
3225         (JSC::Scope::declareLexicalVariable):
3226         (JSC::Scope::hasDeclaredVariable):
3227         (JSC::Scope::hasLexicallyDeclaredVariable):
3228         (JSC::Scope::hasDeclaredParameter):
3229         (JSC::Scope::declareWrite):
3230         (JSC::Scope::preventAllVariableDeclarations):
3231         (JSC::Scope::preventVarDeclarations):
3232         (JSC::Scope::allowsVarDeclarations):
3233         (JSC::Scope::allowsLexicalDeclarations):
3234         (JSC::Scope::declareParameter):
3235         (JSC::Scope::declareBoundParameter):
3236         (JSC::Scope::useVariable):
3237         (JSC::Scope::setNeedsFullActivation):
3238         (JSC::Scope::needsFullActivation):
3239         (JSC::Scope::hasDirectSuper):
3240         (JSC::Scope::setNeedsSuperBinding):
3241         (JSC::Scope::collectFreeVariables):
3242         (JSC::Scope::getCapturedVars):
3243         (JSC::Scope::copyCapturedVariablesToVector):
3244         (JSC::Parser::AutoCleanupLexicalScope::AutoCleanupLexicalScope):
3245         (JSC::Parser::AutoCleanupLexicalScope::~AutoCleanupLexicalScope):
3246         (JSC::Parser::AutoCleanupLexicalScope::setIsValid):
3247         (JSC::Parser::AutoCleanupLexicalScope::isValid):
3248         (JSC::Parser::AutoCleanupLexicalScope::setPopped):
3249         (JSC::Parser::AutoCleanupLexicalScope::scope):
3250         (JSC::Parser::currentScope):
3251         (JSC::Parser::pushScope):
3252         (JSC::Parser::popScopeInternal):
3253         (JSC::Parser::popScope):
3254         (JSC::Parser::declareVariable):
3255         (JSC::Parser::hasDeclaredVariable):
3256         (JSC::Parser::hasDeclaredParameter):
3257         (JSC::Parser::declareWrite):
3258         (JSC::Parser::findCachedFunctionInfo):
3259         (JSC::Parser::isFunctionBodyNode):
3260         (JSC::Parser::continueIsValid):
3261         (JSC::Parser::pushLabel):
3262         (JSC::Parser::popLabel):
3263         (JSC::Parser::getLabel):
3264         (JSC::Parser::isLETMaskedAsIDENT):
3265         (JSC::Parser<LexerType>::parse):
3266         (JSC::Scope::preventNewDecls): Deleted.
3267         (JSC::Scope::allowsNewDecls): Deleted.
3268         (JSC::Scope::getCapturedVariables): Deleted.
3269         There are basic parser changes that now allow for the 'let'
3270         keyword. The trickiest change is how we will still treat 'let' 
3271         as an identifier for sloppy-mode code sometimes. For example,
3272         "var let = ..." is allowed but "let let" or "const let" is not.
3273
3274         The most significant change to the parser made for this patch
3275         is appropriating the Scope struct to also also model a lexical 
3276         scope. Changes were made in how we track captured variables to 
3277         account for this. In general, I think some of this code could 
3278         benefit from a slight refactoring to make things cleaner.
3279
3280         * parser/ParserTokens.h:
3281         * parser/SyntaxChecker.h:
3282         (JSC::SyntaxChecker::createNewExpr):
3283         (JSC::SyntaxChecker::createConditionalExpr):
3284         (JSC::SyntaxChecker::createAssignResolve):
3285         (JSC::SyntaxChecker::createEmptyVarExpression):
3286         (JSC::SyntaxChecker::createEmptyLetExpression):
3287         (JSC::SyntaxChecker::createClassExpr):
3288         (JSC::SyntaxChecker::createClassDeclStatement):
3289         (JSC::SyntaxChecker::createBlockStatement):
3290         (JSC::SyntaxChecker::createExprStatement):
3291         (JSC::SyntaxChecker::createIfStatement):
3292         (JSC::SyntaxChecker::createForLoop):
3293         (JSC::SyntaxChecker::createForInLoop):
3294         (JSC::SyntaxChecker::createForOfLoop):
3295         (JSC::SyntaxChecker::createEmptyStatement):
3296         (JSC::SyntaxChecker::createVarStatement):
3297         (JSC::SyntaxChecker::createLetStatement):
3298         (JSC::SyntaxChecker::createReturnStatement):
3299         (JSC::SyntaxChecker::createBreakStatement):
3300         (JSC::SyntaxChecker::createContinueStatement):
3301         (JSC::SyntaxChecker::createTryStatement):
3302         (JSC::SyntaxChecker::createSwitchStatement):
3303         (JSC::SyntaxChecker::createWhileStatement):
3304         (JSC::SyntaxChecker::createWithStatement):
3305         (JSC::SyntaxChecker::createDoWhileStatement):
3306         (JSC::SyntaxChecker::createGetterOrSetterProperty):
3307         (JSC::SyntaxChecker::appendStatement):
3308         (JSC::SyntaxChecker::combineCommaNodes):
3309         (JSC::SyntaxChecker::evalCount):
3310         (JSC::SyntaxChecker::appendBinaryExpressionInfo):
3311         (JSC::SyntaxChecker::operatorStackPop):
3312         (JSC::SyntaxChecker::addVar): Deleted.
3313         * parser/VariableEnvironment.cpp: Added.
3314         (JSC::VariableEnvironment::markVariableAsCapturedIfDefined):
3315         (JSC::VariableEnvironment::markVariableAsCaptured):
3316         (JSC::VariableEnvironment::markAllVariablesAsCaptured):
3317         (JSC::VariableEnvironment::hasCapturedVariables):
3318         (JSC::VariableEnvironment::captures):
3319         (JSC::VariableEnvironment::swap):
3320         * parser/VariableEnvironment.h: Added.
3321         (JSC::VariableEnvironmentEntry::isCaptured):
3322         (JSC::VariableEnvironmentEntry::isConstant):
3323         (JSC::VariableEnvironmentEntry::isVar):
3324         (JSC::VariableEnvironmentEntry::isLet):
3325         (JSC::VariableEnvironmentEntry::setIsCaptured):
3326         (JSC::VariableEnvironmentEntry::setIsConstant):
3327         (JSC::VariableEnvironmentEntry::setIsVar):
3328         (JSC::VariableEnvironmentEntry::setIsLet):
3329         (JSC::VariableEnvironmentEntry::clearIsVar):
3330         (JSC::VariableEnvironment::begin):
3331         (JSC::VariableEnvironment::end):
3332         (JSC::VariableEnvironment::add):
3333         (JSC::VariableEnvironment::size):
3334         (JSC::VariableEnvironment::contains):
3335         (JSC::VariableEnvironment::remove):
3336         VariableEnvironment is a new class that keeps track
3337         of the static environment in the parser and the bytecode generator.
3338         VariableEnvironment behaves like SymbolTable but for the bytecode generator.
3339         It keeps track of variable types, i.e, if a variable is a "var", "let", "const" 
3340         and whether or not its captured.
3341
3342         * runtime/CodeCache.cpp:
3343         (JSC::CodeCache::getGlobalCodeBlock):
3344         (JSC::CodeCache::getProgramCodeBlock):
3345         (JSC::CodeCache::getEvalCodeBlock):
3346         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
3347         * runtime/CodeCache.h:
3348         (JSC::CodeCache::clear):
3349         * runtime/CommonSlowPaths.cpp:
3350         (JSC::SLOW_PATH_DECL):
3351         * runtime/CommonSlowPaths.h:
3352         * runtime/ExceptionHelpers.cpp:
3353         (JSC::createErrorForInvalidGlobalAssignment):
3354         (JSC::createTDZError):
3355         (JSC::throwOutOfMemoryError):
3356         * runtime/ExceptionHelpers.h:
3357         * runtime/Executable.cpp:
3358         (JSC::EvalExecutable::create):
3359         (JSC::ProgramExecutable::initializeGlobalProperties):
3360         * runtime/Executable.h:
3361         * runtime/JSCJSValue.h:
3362         (JSC::jsUndefined):
3363         (JSC::jsTDZValue):
3364         (JSC::jsBoolean):
3365         * runtime/JSEnvironmentRecord.h:
3366         (JSC::JSEnvironmentRecord::finishCreationUninitialized):
3367         (JSC::JSEnvironmentRecord::finishCreation):
3368         * runtime/JSGlobalObject.cpp:
3369         (JSC::JSGlobalObject::createProgramCodeBlock):
3370         (JSC::JSGlobalObject::createEvalCodeBlock):
3371         * runtime/JSGlobalObject.h:
3372         (JSC::JSGlobalObject::weakRandomInteger):
3373         * runtime/JSGlobalObjectFunctions.cpp:
3374         (JSC::globalFuncEval):
3375         * runtime/JSLexicalEnvironment.cpp:
3376         (JSC::JSLexicalEnvironment::symbolTableGet):
3377         * runtime/JSLexicalEnvironment.h:
3378         (JSC::JSLexicalEnvironment::create):
3379         * runtime/JSScope.cpp:
3380         (JSC::JSScope::resolve):
3381         (JSC::JSScope::abstractResolve):
3382         (JSC::JSScope::collectVariablesUnderTDZ):
3383         (JSC::JSScope::isLexicalScope):
3384         (JSC::resolveModeName):
3385         * runtime/JSScope.h:
3386         * runtime/PropertySlot.h:
3387         (JSC::PropertySlot::setValue):
3388         * runtime/SymbolTable.cpp:
3389         (JSC::SymbolTable::SymbolTable):
3390         (JSC::SymbolTable::cloneScopePart):
3391         * runtime/SymbolTable.h:
3392         SymbolTable now uses an extra bit to know if it corresponds
3393         to a "let"-like environment or not.
3394
3395         * runtime/WriteBarrier.h:
3396         (JSC::WriteBarrierBase<Unknown>::get):
3397         (JSC::WriteBarrierBase<Unknown>::clear):
3398         (JSC::WriteBarrierBase<Unknown>::setUndefined):
3399         (JSC::WriteBarrierBase<Unknown>::setStartingValue):
3400         (JSC::WriteBarrierBase<Unknown>::isNumber):
3401         (JSC::WriteBarrierBase<Unknown>::isObject):
3402         (JSC::WriteBarrierBase<Unknown>::isNull):
3403         * tests/stress/activation-sink-default-value-tdz-error.js: Added.
3404         (shouldThrowTDZ):
3405         (bar):
3406         (foo.cap):
3407         * tests/stress/activation-sink-osrexit-default-value-tdz-error.js: Added.
3408         (shouldThrowTDZ):
3409         (bar):
3410         * tests/stress/lexical-let-and-with-statement.js: Added.
3411         (truth):
3412         (assert):
3413         (.):
3414         * tests/stress/lexical-let-exception-handling.js: Added.
3415         (truth):
3416         (assert):
3417         (.):
3418         * tests/stress/lexical-let-global-not-captured-variables.js: Added.
3419         (truth):
3420         (assert):
3421         (foo):
3422         (.let.capY):
3423         * tests/stress/lexical-let-loop-semantics.js: Added.
3424         (truth):
3425         (assert):
3426         (shouldThrowTDZ):
3427         (.):
3428         * tests/stress/lexical-let-not-strict-mode.js: Added.
3429         (truth):
3430         (assert):
3431         (shouldThrowTDZ):
3432         (.):
3433         * tests/stress/lexical-let-semantics.js: Added.
3434         (truth):
3435         (assert):
3436         (let.globalFunction):
3437         (let.retGlobalNumberCaptured):
3438         (let.setGlobalNumberCaptured):
3439         (.):
3440         * tests/stress/lexical-let-tdz.js: Added.
3441         (truth):
3442         (assert):
3443         (shouldThrowTDZ):
3444         (.):
3445
3446 2015-07-15  Anders Carlsson  <andersca@apple.com>
3447
3448         Make JavaScriptCore SPI headers used by WebCore SPI headers self-contained
3449         https://bugs.webkit.org/show_bug.cgi?id=146978
3450
3451         Reviewed by Dan Bernstein.
3452
3453         * debugger/DebuggerPrimitives.h:
3454         * disassembler/Disassembler.h:
3455         * heap/Weak.h:
3456         * inspector/InspectorValues.h:
3457         * runtime/JSCJSValue.h:
3458
3459 2015-07-14  Anders Carlsson  <andersca@apple.com>
3460
3461         Assertions.h should include ExportMacros.h
3462         https://bugs.webkit.org/show_bug.cgi?id=146948
3463
3464         Reviewed by Tim Horton.
3465
3466         Remove now unneeded WTF_EXPORT_PRIVATE define.
3467
3468         * API/JSBase.h:
3469
3470 2015-07-14  Matthew Mirman  <mmirman@apple.com>
3471
3472         Repatch. Makes compileArithSub in the DFG ensure that the constant is an int32.
3473         https://bugs.webkit.org/show_bug.cgi?id=146910
3474         rdar://problem/21729083
3475
3476         Reviewed by Filip Pizlo.
3477         
3478         Also fixes the debug build problem where all edges are assumed to 
3479         have UntypedUse before the fixup phase.
3480
3481         * dfg/DFGSpeculativeJIT.cpp:
3482         (JSC::DFG::SpeculativeJIT::compileArithSub):
3483         * dfg/DFGValidate.cpp:
3484         (JSC::DFG::Validate::validateEdgeWithDoubleResultIfNecessary):
3485         * tests/stress/arith-add-with-constants.js: Added some tests for this case.
3486         (arithAdd42WrittenAsInteger):
3487         (testArithAdd42WrittenAsInteger):
3488         (arithSub42WrittenAsDouble):
3489         (testArithSub42WrittenAsDouble):
3490         (doubleConstant):
3491         (testDoubleConstant): Added test for the case of +0.0 and Math.min(0.0)
3492         (arithAdd42WrittenAsDouble): Deleted.
3493         (testArithAdd42WrittenAsDouble): Deleted.
3494
3495 2015-07-14  Matthew Mirman  <mmirman@apple.com>
3496
3497         Unreviewed, rolling out r186805.
3498
3499         Made raytracer on octane 80% slower
3500
3501         Reverted changeset:
3502
3503         "Makes compileArithSub in the DFG ensure that the constant is
3504         an int32."
3505         https://bugs.webkit.org/show_bug.cgi?id=146910
3506         http://trac.webkit.org/changeset/186805
3507
3508 2015-07-13  Matthew Mirman  <mmirman@apple.com>
3509
3510         Makes compileArithSub in the DFG ensure that the constant is an int32.
3511         https://bugs.webkit.org/show_bug.cgi?id=146910
3512         rdar://problem/21729083
3513
3514         Reviewed by Filip Pizlo.
3515         
3516         Also fixes the debug build problem where all edges are assumed to 
3517         have UntypedUse before the fixup phase.
3518
3519         * dfg/DFGSpeculativeJIT.cpp:
3520         (JSC::DFG::SpeculativeJIT::compileArithSub):
3521         * dfg/DFGValidate.cpp:
3522         (JSC::DFG::Validate::validateEdgeWithDoubleResultIfNecessary):
3523         * tests/stress/arith-add-with-constants.js: Added some tests for this case.
3524         (arithAdd42WrittenAsInteger):
3525         (testArithAdd42WrittenAsInteger):
3526         (arithSub42WrittenAsDouble):
3527         (testArithSub42WrittenAsDouble):
3528         (doubleConstant):
3529         (testDoubleConstant): Added test for the case of +0.0 and Math.min(0.0)
3530         (arithAdd42WrittenAsDouble): Deleted.
3531         (testArithAdd42WrittenAsDouble): Deleted.
3532
3533 2015-07-13  Basile Clement  <basile_clement@apple.com>
3534
3535         Object cycles should not prevent allocation elimination/sinking
3536         https://bugs.webkit.org/show_bug.cgi?id=143073
3537
3538         Reviewed by Filip Pizlo.
3539
3540         This patch introduces a new allocation sinking phase that is able to
3541         sink cycles, in DFGAllocationCycleSinkingPhase.cpp. This phase
3542         supersedes the old allocation sinking phase in
3543         DFGObjectAllocationSinkingPhase.cpp, as that previous phase was never
3544         able to sink allocation cycles while the new phase sometimes can; see
3545         DFGAllocationCycleSinkingPhase.cpp for details.
3546
3547         For now, the new sinking phase is kept behind a
3548         JSC_enableAllocationCycleSinking flag that reverts to the old sinking
3549         phase when false (i.e., by default). This also removes the old
3550         JSC_enableObjectAllocationSinking flag. run-javascriptcore-tests
3551         defaults to using the new sinking phase.
3552
3553         * dfg/DFGGraph.h:
3554         (JSC::DFG::Graph::addStructureSet): Allow empty structure sets
3555         * dfg/DFGLazyNode.cpp:
3556         (JSC::DFG::LazyNode::dump): Prettier dump
3557         * dfg/DFGNode.h:
3558         (JSC::DFG::Node::cellOperand): Move to opInfo for MaterializeCreateActivation
3559         (JSC::DFG::Node::hasStructureSet): Add MaterializeNewObject
3560         (JSC::DFG::Node::objectMaterializationData): Move to opInfo2
3561         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: Remove unused header
3562         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3563         (JSC::DFG::ObjectAllocationSinkingPhase::ObjectAllocationSinkingPhase): Deleted.
3564         (JSC::DFG::ObjectAllocationSinkingPhase::run): Deleted.
3565         (JSC::DFG::ObjectAllocationSinkingPhase::performSinking): Deleted.
3566         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints): Deleted.
3567         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints): Deleted.
3568         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations): Deleted.
3569         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields): Deleted.
3570         (JSC::DFG::ObjectAllocationSinkingPhase::resolve): Deleted.
3571         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode): Deleted.
3572         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize): Deleted.
3573         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize): Deleted.
3574         * dfg/DFGObjectAllocationSinkingPhase.h:
3575         * dfg/DFGPromotedHeapLocation.h: Add a hash and a helper function to PromotedLocationDescriptor
3576         (JSC::DFG::PromotedLocationDescriptor::PromotedLocationDescriptor):
3577         (JSC::DFG::PromotedLocationDescriptor::operator bool):
3578         (JSC::DFG::PromotedLocationDescriptor::neededForMaterialization):
3579         (JSC::DFG::PromotedLocationDescriptorHash::hash):
3580         (JSC::DFG::PromotedLocationDescriptorHash::equal):
3581         * dfg/DFGValidate.cpp:
3582         (JSC::DFG::Validate::validateSSA): Assert that most nodes never see a phantom allocation
3583         * ftl/FTLLowerDFGToLLVM.cpp:
3584         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeNewObject): Use the new structureSet() operand
3585         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation): Node has a new child
3586         * ftl/FTLOSRExitCompiler.cpp: Handle materialization cycles
3587         (JSC::FTL::compileStub):
3588         * ftl/FTLOperations.cpp: Handle materialization cycles
3589         (JSC::FTL::operationPopulateObjectInOSR):
3590         (JSC::FTL::operationMaterializeObjectInOSR):
3591         * ftl/FTLOperations.h: Handle materialization cycles
3592         * tests/stress/correctly-sink-object-even-though-it-dies.js: Added.
3593         (clobber):
3594         (foo):
3595         * tests/stress/eliminate-object-read-over-call.js: Added.
3596         (clobber):
3597         (foo):
3598         * tests/stress/materialize-object-on-edge.js: Added.
3599         (call):
3600         (foo):
3601         * tests/stress/object-sinking-stress.js: Added.
3602         (foo):
3603         * tests/stress/sink-object-cycle.js: Added.
3604         (clobber):
3605         (foo):
3606         * tests/stress/sink-object-past-put.js: Added.
3607         (clobber):
3608         (foo):
3609         * tests/stress/sinkable-new-object-in-loop.js: Added.
3610         (foo):
3611
3612 2015-07-13  Daniel Bates  <dabates@apple.com>
3613
3614         Cleanup: Avoid extraneous increment and decrement of reference count of ScriptArguments in ConsoleClient
3615         https://bugs.webkit.org/show_bug.cgi?id=146920
3616
3617         Reviewed by Brian Burg.
3618
3619         Remove local variable RefPtr<ScriptArguments> and copy constructor call with an argument that
3620         was initialized with an rvalue reference. The argument itself is an lvalue reference.
3621
3622         * runtime/ConsoleClient.cpp:
3623         (JSC::ConsoleClient::printConsoleMessageWithArguments):
3624         (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
3625
3626 2015-07-13  Anders Carlsson  <andersca@apple.com>
3627
3628         Apps linked with a deployment target of iOS 7.x or earlier crash when using modern WebKit API
3629         https://bugs.webkit.org/show_bug.cgi?id=146913
3630         rdar://problem/21789252
3631
3632         Reviewed by Dan Bernstein.
3633
3634         Make a top-level symlink from /System/Library/PrivateFrameworks/JavaScriptCore.framework to
3635         /System/Library/Frameworks/JavaScriptCore.framework.
3636     
3637         * JavaScriptCore.xcodeproj/project.pbxproj:
3638
3639 2015-07-12  Filip Pizlo  <fpizlo@apple.com>
3640
3641         If Watchpoint::fire() looks at the state of the world, it should definitely see its set invalidated, and maybe it should see the object of interest in the transitioned-to state
3642         https://bugs.webkit.org/show_bug.cgi?id=146897
3643
3644         Reviewed by Mark Lam.
3645         
3646         The idea is to eventually support adaptive watchpoints. An adaptive watchpoint will be
3647         able to watch for a condition that is more fine-grained than any one watchpoint set. For
3648         example, we might watch a singleton object to see if it ever acquires a property called
3649         "foo". So long as it doesn't have such a property, we don't want to invalidate any code.
3650         But if it gets that property, then we should deoptimize. Current watchpoints will
3651         invalidate code as soon as any property is added (or deleted), because they will use the
3652         transition watchpoint set of the singleton object's structure, and that fires anytime
3653         there is any transition.
3654         
3655         An adaptive watchpoint would remember the singleton object, and when it got fired, it
3656         would check if the object's new structure has the property "foo". If not, it would check
3657         if the object's new structure is watchable (i.e. has a valid transition watchpoint set).
3658         If the property is missing and the structure is watchable, it would add itself to the
3659         watchpoint set of the new structure. Otherwise, it would deoptimize.
3660         
3661         There are two problems with this idea, and this patch fixes these problems. First, we
3662         usually fire the transition watchpoint before we do the structure transition. This means
3663         that if the fire() method looked at the singleton object's structure, it would see the old
3664         structure, not the new one. It would have no way of knowing what the new structure is.
3665         Second, inside the fire() method, the watchpoint set being invalidated still appears
3666         valid, since we change the state after we fire all watchpoints.
3667         
3668         This patch addresses both issues. Now, in the most important case (addPropertyTransition),
3669         we fire the watchpoint set after we have modified the object. This is accomplished using
3670         a deferral scope called DeferredStructureTransitionWatchpointFire. In cases where there is
3671         no deferral, the adaptive watchpoint will conservatively resort to deoptimization because
3672         it would find that the singleton object's structure is no longer watchable. This is
3673         because in the absence of deferral, the singleton object would still have the original
3674         structure, but that structure's watchpoint set would now report itself as having been
3675         invalidated.
3676
3677         * bytecode/Watchpoint.cpp:
3678         (JSC::WatchpointSet::fireAllSlow): Change the state of the set before firing all watchpoints.
3679         (JSC::WatchpointSet::fireAllWatchpoints):
3680         * runtime/JSObject.h:
3681         (JSC::JSObject::putDirectInternal): Use the deferral scope.
3682         * runtime/Structure.cpp:
3683         (JSC::Structure::Structure): Pass the deferral scope to didTransitionFromThisStructure.
3684         (JSC::Structure::addPropertyTransition): Pass the deferral scope to create().
3685         (JSC::StructureFireDetail::dump): This is no longer anonymous.
3686         (JSC::DeferredStructureTransitionWatchpointFire::DeferredStructureTransitionWatchpointFire): Start with a null structure.
3687         (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire): Fire the watchpoint if there is a structure.
3688         (JSC::DeferredStructureTransitionWatchpointFire::add): Add a structure. Logically this is a list of deferred things, but we assert that there only will be one (happens to be true now).
3689         (JSC::Structure::didTransitionFromThisStructure): Defer the watchpoint firing if there is a deferral scope.
3690         * runtime/Structure.h:
3691         (JSC::StructureFireDetail::StructureFireDetail): Move this to the header.
3692         * runtime/StructureInlines.h:
3693         (JSC::Structure::create): Pass the deferral scope to the constructor.
3694
3695 2015-07-12  Filip Pizlo  <fpizlo@apple.com>
3696
3697         Watchpoints should be removed from their owning WatchpointSet before they are fired
3698         https://bugs.webkit.org/show_bug.cgi?id=146895
3699
3700         Reviewed by Sam Weinig.
3701         
3702         This simplifies the WatchpointSet API by making it so that when Watchpoint::fire() is
3703         called, the Watchpoint is no longer in the set. This means that you don't have to remember
3704         to remove it from the set's list (currently we do that implicitly as part of whatever
3705         any particular Watchpoint::fireInternal() does), and you can now write adaptive
3706         watchpoints that re-add themselves to a different set if they determine that the thing
3707         they are actually watching is still intact but now needs to be watched in a different way
3708         (like watching for whether some singleton object has a property of some name).
3709
3710         * bytecode/Watchpoint.cpp:
3711         (JSC::Watchpoint::~Watchpoint): Add a comment about why this is necessary.
3712         (JSC::Watchpoint::fire): Make this out-of-line, private, and make it assert that we're no longer on the list.
3713         (JSC::WatchpointSet::fireAllWatchpoints): Make this remove the watchpoint from the list before firing it.
3714         * bytecode/Watchpoint.h:
3715         (JSC::Watchpoint::fire): Deleted. I moved this to Watchpoint.cpp.
3716
3717 2015-07-10  Filip Pizlo  <fpizlo@apple.com>
3718
3719         DFG::DesiredWatchpoints should accept WatchpointSetType's that aren't necessarily pointers
3720         https://bugs.webkit.org/show_bug.cgi?id=146875
3721
3722         Reviewed by Dan Bernstein.
3723         
3724         In the future we'll want to add a desired watchpoint set that's something like "please
3725         watch property 'Foo' for 'deletion' on structure 'S1'", so that the "set type" is struct
3726         like "struct MySet { StringImpl* property; Mode mode; Structure* structure };".
3727         
3728         This is a very mechanical change for now - all of the current users happen to use sets
3729         that are pointer typed, so it's just a matter of moving some "*"'s around.
3730
3731         * dfg/DFGDesiredWatchpoints.h:
3732         (JSC::DFG::GenericSetAdaptor::add):
3733         (JSC::DFG::GenericSetAdaptor::hasBeenInvalidated):
3734         (JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints):
3735         (JSC::DFG::GenericDesiredWatchpoints::addLazily):
3736         (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
3737         (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
3738         (JSC::DFG::GenericDesiredWatchpoints::isWatched):
3739         (JSC::DFG::DesiredWatchpoints::isWatched):
3740
3741 2015-07-10  Filip Pizlo  <fpizlo@apple.com>
3742
3743         Watchpoints should be allocated with FastMalloc
3744         https://bugs.webkit.org/show_bug.cgi?id=146874
3745
3746         Reviewed by Dan Bernstein.
3747         
3748         This is in preparation for adding new subclasses of Watchpoint. While starting to do this
3749         I realized that the way Watchpoints allocated themselves was unusual.
3750
3751         * bytecode/CodeBlockJettisoningWatchpoint.h:
3752         (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): No need for the default constructor.
3753         * bytecode/Watchpoint.h:
3754         (JSC::Watchpoint::Watchpoint): This should be noncopyable and fast-allocated.
3755         * dfg/DFGCommonData.h: Use a Bag<> instead of SegmentedVector<>. Bag means "malloc things but allow me to free them all at once", which is what we are doing here.
3756         * dfg/DFGDesiredWatchpoints.h:
3757         (JSC::DFG::GenericDesiredWatchpoints::reallyAdd): Use the Bag<> API rather than the very awkward SegmentedVector<> API.
3758
3759 2015-07-10  Filip Pizlo  <fpizlo@apple.com>
3760
3761         AI folding of IsObjectOrNull is broken for non-object types that may be null
3762         https://bugs.webkit.org/show_bug.cgi?id=146867
3763
3764         Reviewed by Ryosuke Niwa.
3765
3766         * dfg/DFGAbstractInterpreterInlines.h:
3767         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Fix the bug and add some text describing what is going on.
3768         * tests/stress/misc-is-object-or-null.js: Added. Test for the bug.
3769         (foo):
3770         * tests/stress/other-is-object-or-null.js: Added. Test for a bug I almost introduced.
3771         (foo):
3772
3773 2015-07-10  Filip Pizlo  <fpizlo@apple.com>
3774
3775         It should be easy to measure total compile times.
3776         https://bugs.webkit.org/show_bug.cgi?id=146857
3777
3778         Reviewed by Sam Weinig.
3779         
3780         This gives DFG::Plan the ability to track total compile times, and return them in a map
3781         of stats that jsc.cpp can display.
3782         
3783         I want to do some work to bring down DFG compile times. This will help me measure whether
3784         I'm making a difference or not.
3785
3786         * dfg/DFGPlan.cpp:
3787         (JSC::DFG::Plan::Plan):
3788         (JSC::DFG::Plan::~Plan):
3789         (JSC::DFG::Plan::computeCompileTimes):
3790         (JSC::DFG::Plan::reportCompileTimes):
3791         (JSC::DFG::Plan::compileInThread):
3792         (JSC::DFG::Plan::compileInThreadImpl):
3793         (JSC::DFG::Plan::cancel):
3794         (JSC::DFG::Plan::compileTimeStats):
3795         (JSC::DFG::dumpAndVerifyGraph): Deleted.
3796         (JSC::DFG::profilerCompilationKindForMode): Deleted.
3797         * dfg/DFGPlan.h:
3798         (JSC::DFG::Plan::compileTimeStats):
3799         * jsc.cpp:
3800         (jscmain):
3801         * runtime/Options.h:
3802
3803 2015-07-04  Filip Pizlo  <fpizlo@apple.com>
3804
3805         DFG fragile frozen values are fundamentally broken
3806         https://bugs.webkit.org/show_bug.cgi?id=146602
3807
3808         Reviewed by Mark Lam.
3809         
3810         This change gets rid of the FragileValue value strength, because it was fundamentally
3811         broken.
3812         
3813         FragileValue was a value known to the compiler but not tracked by the GC in any way -
3814         it wasn't marked and it wasn't weak. This was used to support AI bootstrap for OSR
3815         must-handle values. The philosophy was that if the compiler did use the value for
3816         optimization, it would have been strengthened to a weak value (or maybe even a strong
3817         value, though we probably won't do that). But this was too much of a pipe dream. I've
3818         found at least one case where the compiler did use the value, but never strengthened
3819         it: it would happen if the value ended up in an OSR entry data expected value. Then if
3820         we GCed, we might have killed the value, but OSR entry would still try to use it for
3821         validation. That might have sort of just worked, but it's clearly shady.
3822
3823         The reason why we made must-handle values fragile and not weak is that most of the time
3824         the values disappear from the abstract state: they are LUBed to a non-constant. If we
3825         kept them around as weak, we'd have too many cases of the GC killing the code because
3826         it thought that the value was somehow meaningful to the code when it was only used as a
3827         temporary artifact of optimization.
3828
3829         So, it's true that it's very important for must-handle values not to automatically be
3830         weak or strong. It's also true that the values are necessary for AI bootstrap because
3831         we need to know what values OSR entry will require. But we shouldn't accomplish these
3832         goals by having the compiler hold onto what are essentially dangling pointers.
3833         
3834         This implements a better solution: instead of having InPlaceAbstractState bootstrap the
3835         AI with must-handle values at the beginning, we now widen the valuesAtHead of the
3836         must-handle block after AI converges. This widening is done in CFAPhase. This allows us
3837         to see if the must-handle values are necessary at all. In most cases, the widening
3838         takes a non-constant abstract value and simply amends something to its type based on
3839         the type of the must-handle value, and so the must-handle value never actually shows up
3840         in either the IR or any abstract value. In the unlikely event that the value at head is
3841         bottom, we freeze the must-handle value. This change removes FragileValue, and this
3842         freezing uses WeakValue as the strength. That makes sense: since the abstract value was
3843         bottom, the must-handle value becomes integral to the IR and so it makes no sense for
3844         the GC to keep the resulting CodeBlock alive if that must-handle value dies. This will
3845         sometimes happen for example if you have a very long-running loop whose pre-header
3846         allocates some object, but that pre-header appears to always exit to the optimizing JIT
3847         because it was only profiled once in the LLInt and that profiling appears insufficient
3848         to the DFG. In that case, we'll effectively constant-fold the references to the object
3849         inside the loop, which is both efficient (yay constant folding!) and necessary
3850         (otherwise we wouldn't know what the type of the variable should have been).
3851         
3852         Testing and debugging this is complicated. So, this adds some new capabilities:
3853         
3854         - DFG IR dumps also dump all of the FrozenValues that point to the heap along with
3855           their strengths, so that it's easy to see what GC objects the DFG feels are necessary
3856           for the compilation.
3857         
3858         - DFG OSR entry preparation prints out the OSR entry data structures, so that it's easy
3859           to see what GC pointers (and other things) are used for OSR entry validation. The
3860           printouts are quite detailed, and should also help other kinds of OSR entry
3861           debugging.
3862         
3863         - DFG::Plan now validates whether all of the GC pointers planted in the various JITCode
3864           data structures are also properly registered as either weak or strong pointers in the
3865           CodeBlock. This validation check previously failed due to fragile values ending up in
3866           the OSR entry data structures, both in the newly added test (dead-osr-entry-value.js)
3867           and in some pre-existing tests (like earley-boyer and 3d-raytrace).
3868
3869         * CMakeLists.txt:
3870         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3871         * JavaScriptCore.xcodeproj/project.pbxproj:
3872         * bytecode/CodeBlock.cpp:
3873         (JSC::CodeBlock::stronglyVisitStrongReferences):
3874         * bytecode/CodeOrigin.cpp:
3875         (JSC::InlineCallFrame::visitAggregate):
3876         * bytecode/Operands.h:
3877         (JSC::Operands::operand):
3878         (JSC::Operands::hasOperand):
3879         * bytecode/StructureSet.cpp:
3880         (JSC::StructureSet::dump):
3881         (JSC::StructureSet::validateReferences):
3882         * bytecode/StructureSet.h:
3883         * bytecode/TrackedReferences.cpp: Added.
3884         (JSC::TrackedReferences::TrackedReferences):
3885         (JSC::TrackedReferences::~TrackedReferences):
3886         (JSC::TrackedReferences::add):
3887         (JSC::TrackedReferences::check):
3888         (JSC::TrackedReferences::dump):
3889         * bytecode/TrackedReferences.h: Added.
3890         * dfg/DFGAbstractValue.cpp:
3891         (JSC::DFG::AbstractValue::observeTransitions):
3892         (JSC::DFG::AbstractValue::set):
3893         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
3894         (JSC::DFG::AbstractValue::mergeOSREntryValue):
3895         (JSC::DFG::AbstractValue::filter):
3896         (JSC::DFG::AbstractValue::dumpInContext):
3897         (JSC::DFG::AbstractValue::validateReferences):
3898         (JSC::DFG::AbstractValue::setOSREntryValue): Deleted.
3899         * dfg/DFGAbstractValue.h:
3900         (JSC::DFG::AbstractValue::fullTop):
3901         (JSC::DFG::AbstractValue::merge):
3902         * dfg/DFGByteCodeParser.cpp:
3903         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
3904         * dfg/DFGCFAPhase.cpp:
3905         (JSC::DFG::CFAPhase::run):
3906         * dfg/DFGCommonData.cpp:
3907         (JSC::DFG::CommonData::invalidate):
3908         (JSC::DFG::CommonData::validateReferences):
3909         * dfg/DFGCommonData.h:
3910         (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit):
3911         * dfg/DFGFrozenValue.h:
3912         (JSC::DFG::FrozenValue::FrozenValue):
3913         (JSC::DFG::FrozenValue::strengthenTo):
3914         (JSC::DFG::FrozenValue::pointsToHeap):
3915         (JSC::DFG::FrozenValue::strength):
3916         (JSC::DFG::FrozenValue::freeze):
3917         * dfg/DFGGraph.cpp:
3918         (JSC::DFG::Graph::Graph):
3919         (JSC::DFG::Graph::dump):
3920         (JSC::DFG::Graph::registerFrozenValues):
3921         (JSC::DFG::Graph::visitChildren):
3922         (JSC::DFG::Graph::freeze):
3923         (JSC::DFG::Graph::freezeStrong):
3924         (JSC::DFG::Graph::freezeFragile): Deleted.
3925         * dfg/DFGGraph.h:
3926         * dfg/DFGInPlaceAbstractState.cpp:
3927         (JSC::DFG::InPlaceAbstractState::initialize):
3928         * dfg/DFGJITCode.cpp:
3929         (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
3930         (JSC::DFG::JITCode::validateReferences):
3931         * dfg/DFGJITCode.h:
3932         * dfg/DFGJITCompiler.cpp:
3933         (JSC::DFG::JITCompiler::addressOfDoubleConstant):
3934         (JSC::DFG::JITCompiler::noticeOSREntry):
3935         * dfg/DFGJITCompiler.h:
3936         (JSC::DFG::JITCompiler::branchStructurePtr):
3937         (JSC::DFG::JITCompiler::jitCode):
3938         (JSC::DFG::JITCompiler::noticeOSREntry): Deleted.
3939         * dfg/DFGMinifiedGraph.cpp: Added.
3940         (JSC::DFG::MinifiedGraph::prepareAndShrink):
3941         (JSC::DFG::MinifiedGraph::validateReferences):
3942         * dfg/DFGMinifiedGraph.h:
3943         (JSC::DFG::MinifiedGraph::append):
3944         (JSC::DFG::MinifiedGraph::prepareAndShrink): Deleted.
3945         * dfg/DFGOSREntry.cpp:
3946         (JSC::DFG::OSREntryData::dumpInContext):
3947         (JSC::DFG::OSREntryData::dump):
3948         (JSC::DFG::prepareOSREntry):
3949         * dfg/DFGOSREntry.h:
3950         (JSC::DFG::getOSREntryDataBytecodeIndex):
3951         * dfg/DFGPlan.cpp:
3952         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
3953         * dfg/DFGSpeculativeJIT.cpp:
3954         (JSC::DFG::SpeculativeJIT::linkOSREntries):
3955         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
3956         * dfg/DFGStructureAbstractValue.cpp:
3957         (JSC::DFG::StructureAbstractValue::dump):
3958         (JSC::DFG::StructureAbstractValue::validateReferences):
3959         * dfg/DFGStructureAbstractValue.h:
3960         * dfg/DFGValidate.cpp:
3961         (JSC::DFG::Validate::validate):