[ES6] Add Reflect namespace and add Reflect.deleteProperty
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-07-25  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [ES6] Add Reflect namespace and add Reflect.deleteProperty
4         https://bugs.webkit.org/show_bug.cgi?id=147287
5
6         Reviewed by Sam Weinig.
7
8         This patch just creates the namespace for ES6 Reflect APIs.
9         And add template files to implement the actual code.
10
11         Not to keep the JS generated properties C array empty,
12         we added one small method, Reflect.deleteProperty in this patch.
13
14         * CMakeLists.txt:
15         * DerivedSources.make:
16         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
17         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
18         * JavaScriptCore.xcodeproj/project.pbxproj:
19         * builtins/ReflectObject.js: Added.
20         (deleteProperty):
21         * runtime/CommonIdentifiers.h:
22         * runtime/JSGlobalObject.cpp:
23         (JSC::JSGlobalObject::init):
24         * runtime/ReflectObject.cpp: Added.
25         (JSC::ReflectObject::ReflectObject):
26         (JSC::ReflectObject::finishCreation):
27         (JSC::ReflectObject::getOwnPropertySlot):
28         * runtime/ReflectObject.h: Added.
29         (JSC::ReflectObject::create):
30         (JSC::ReflectObject::createStructure):
31         * tests/stress/reflect-delete-property.js: Added.
32         (shouldBe):
33         (shouldThrow):
34
35 2015-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>
36
37         Avoid 2 times name iteration in Object.assign
38         https://bugs.webkit.org/show_bug.cgi?id=147268
39
40         Reviewed by Geoffrey Garen.
41
42         Object.assign calls Object.getOwnPropertyNames & Object.getOwnPropertySymbols to collect all the names.
43         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.
44         Since Object.assign is so generic API (some form of utility API), the form of the given Object is not expected.
45         So the taken object may have so many non-indexed properties.
46
47         In this patch, we introduce `ownEnumerablePropertyKeys` private function.
48         It is minor changed version of `[[OwnPropertyKeys]]` in the ES6 spec;
49         It only includes enumerable properties.
50
51         By filtering out the non-enumerable properties in the exposed private function,
52         we avoid calling @objectGetOwnPropertyDescriptor for each property at the same time.
53
54         * builtins/ObjectConstructor.js:
55         (assign):
56         * runtime/CommonIdentifiers.h:
57         * runtime/EnumerationMode.h:
58         * runtime/JSGlobalObject.cpp:
59         (JSC::JSGlobalObject::init):
60         * runtime/ObjectConstructor.cpp:
61         (JSC::ownEnumerablePropertyKeys):
62         * runtime/ObjectConstructor.h:
63         * tests/stress/object-assign-enumerable.js: Added.
64         (shouldBe):
65         * tests/stress/object-assign-order.js: Added.
66         (shouldBe):
67
68 2015-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>
69
70         Remove runtime flags for symbols
71         https://bugs.webkit.org/show_bug.cgi?id=147246
72
73         Reviewed by Alex Christensen.
74
75         * runtime/ArrayPrototype.cpp:
76         (JSC::ArrayPrototype::finishCreation):
77         * runtime/JSGlobalObject.cpp:
78         (JSC::JSGlobalObject::init): Deleted.
79         * runtime/JSGlobalObject.h:
80         * runtime/ObjectConstructor.cpp:
81         (JSC::ObjectConstructor::finishCreation):
82         * runtime/RuntimeFlags.h:
83
84 2015-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>
85
86         Object.getOwnPropertySymbols on large list takes very long
87         https://bugs.webkit.org/show_bug.cgi?id=146137
88
89         Reviewed by Mark Lam.
90
91         Before this patch, Object.getOwnPropertySymbols collects all the names including strings.
92         And after it's done, filter the names to only retrieve the symbols.
93         But it's so time consuming if the given object is a large non-holed array since it has
94         many indexed properties and all the indexes have to be converted to uniqued_strings and
95         added to the collection of property names (though they may not be of the requested type
96         and will be filtered out later)
97
98         This patch introduces PropertyNameMode.
99         We leverage this mode in 2 places.
100
101         1. PropertyNameArray side
102         It is set in PropertyNameArray and it filters the incoming added identifiers based on the mode.
103         It ensures that PropertyNameArray doesn't become so large in the pathological case.
104         And it ensures that non-expected typed keys by the filter (Symbols or Strings) are never added
105         to the property name array collections.
106         However it does not solve the whole problem because the huge array still incurs the many
107         "indexed property to uniqued string" conversion and the large iteration before adding the keys
108         to the property name array.
109
110         2. getOwnPropertyNames side
111         So we can use the PropertyNameMode in the caller side (getOwnPropertyNames) as a **hint**.
112         When the large iteration may occur, the caller side can use the PropertyNameMode as a hint to
113         avoid the iteration.
114         But we cannot exclusively rely on these caller side checks because it would require that we
115         exhaustively add the checks to all custom implementations of getOwnPropertyNames as well.
116         This process requires manual inspection of many pieces of code, and is error prone. Instead,
117         we only apply the caller side check in a few strategic places where it is known to yield
118         performance benefits; and we rely on the filter in PropertyNameArray::add() to reject the wrong
119         types of properties for all other calls to PropertyNameArray::add().
120
121         In this patch, there's a concept in use that is not clear just from reading the code, and hence
122         should be documented here. When selecting the PropertyNameMode for the PropertyNameArray to be
123         instantiated, we apply the following logic:
124
125         1. Only JavaScriptCore code is aware of ES6 Symbols.
126         We can assume that pre-existing external code that interfaces JSC are only looking for string named properties. This includes:
127             a. WebCore bindings
128             b. Serializer bindings
129             c. NPAPI bindings
130             d. Objective C bindings
131         2. In JSC, code that compute object storage space needs to iterate both Symbol and String named properties. Hence, use PropertyNameMode::Both.
132         3. In JSC, ES6 APIs that work with Symbols should use PropertyNameMode::Symbols.
133         4. In JSC, ES6 APIs that work with String named properties should use PropertyNameMode::Strings.
134
135         * API/JSObjectRef.cpp:
136         (JSObjectCopyPropertyNames):
137         * bindings/ScriptValue.cpp:
138         (Deprecated::jsToInspectorValue):
139         * bytecode/ObjectAllocationProfile.h:
140         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
141         * runtime/EnumerationMode.h:
142         (JSC::EnumerationMode::EnumerationMode):
143         (JSC::EnumerationMode::includeSymbolProperties): Deleted.
144         * runtime/GenericArgumentsInlines.h:
145         (JSC::GenericArguments<Type>::getOwnPropertyNames):
146         * runtime/JSGenericTypedArrayViewInlines.h:
147         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertyNames):
148         * runtime/JSLexicalEnvironment.cpp:
149         (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
150         * runtime/JSONObject.cpp:
151         (JSC::Stringifier::Stringifier):
152         (JSC::Stringifier::Holder::appendNextProperty):
153         (JSC::Walker::walk):
154         * runtime/JSObject.cpp:
155         (JSC::JSObject::getOwnPropertyNames):
156         * runtime/JSPropertyNameEnumerator.cpp:
157         (JSC::JSPropertyNameEnumerator::create):
158         * runtime/JSPropertyNameEnumerator.h:
159         (JSC::propertyNameEnumerator):
160         * runtime/JSSymbolTableObject.cpp:
161         (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
162         * runtime/ObjectConstructor.cpp:
163         (JSC::objectConstructorGetOwnPropertyNames):
164         (JSC::objectConstructorGetOwnPropertySymbols):
165         (JSC::objectConstructorKeys):
166         (JSC::defineProperties):
167         (JSC::objectConstructorSeal):
168         (JSC::objectConstructorFreeze):
169         (JSC::objectConstructorIsSealed):
170         (JSC::objectConstructorIsFrozen):
171         * runtime/PropertyNameArray.h:
172         (JSC::PropertyNameArray::PropertyNameArray):
173         (JSC::PropertyNameArray::mode):
174         (JSC::PropertyNameArray::addKnownUnique):
175         (JSC::PropertyNameArray::add):
176         (JSC::PropertyNameArray::isUidMatchedToTypeMode):
177         (JSC::PropertyNameArray::includeSymbolProperties):
178         (JSC::PropertyNameArray::includeStringProperties):
179         * runtime/StringObject.cpp:
180         (JSC::StringObject::getOwnPropertyNames):
181         * runtime/Structure.cpp:
182         (JSC::Structure::getPropertyNamesFromStructure):
183
184 2015-07-24  Saam barati  <saambarati1@gmail.com>
185
186         [ES6] Add support for default parameters
187         https://bugs.webkit.org/show_bug.cgi?id=38409
188
189         Reviewed by Filip Pizlo.
190
191         This patch implements ES6 default parameters according to the ES6
192         specification. This patch builds off the components introduced with 
193         "let" scoping and parsing function parameters in the same parser
194         arena as the function itself. "let" scoping allows functions with default 
195         parameter values to place their parameters under the TDZ. Parsing function
196         parameters in the same parser arena allows the FunctionParameters AST node
197         refer to ExpressionNodes.
198
199         The most subtle part of this patch is how we allocate lexical environments
200         when functions have default parameter values. If a function has default
201         parameter values then there must be a separate lexical environment for
202         its parameters. Then, the function's "var" lexical environment must have
203         the parameter lexical environment as its parent. The BytecodeGenerator
204         takes great care to not allocate the "var" lexical environment before its
205         really needed.
206
207         The "arguments" object for a function with default parameters will never be 
208         a mapped arugments object. It will always be a cloned arugments object.
209
210         * bytecompiler/BytecodeGenerator.cpp:
211         (JSC::BytecodeGenerator::generate):
212         (JSC::BytecodeGenerator::BytecodeGenerator):
213         (JSC::BytecodeGenerator::~BytecodeGenerator):
214         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
215         (JSC::BytecodeGenerator::initializeNextParameter):
216         (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
217         (JSC::BytecodeGenerator::visibleNameForParameter):
218         (JSC::BytecodeGenerator::emitLoadGlobalObject):
219         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
220         (JSC::BytecodeGenerator::pushLexicalScope):
221         (JSC::BytecodeGenerator::popLexicalScope):
222         * bytecompiler/BytecodeGenerator.h:
223         (JSC::BytecodeGenerator::lastOpcodeID):
224         * bytecompiler/NodesCodegen.cpp:
225         (JSC::FunctionNode::emitBytecode):
226         * jit/JITOperations.cpp:
227         * parser/ASTBuilder.h:
228         (JSC::ASTBuilder::createElementList):
229         (JSC::ASTBuilder::createFormalParameterList):
230         (JSC::ASTBuilder::appendParameter):
231         (JSC::ASTBuilder::createClause):
232         (JSC::ASTBuilder::createClauseList):
233         * parser/Nodes.h:
234         (JSC::FunctionParameters::size):
235         (JSC::FunctionParameters::at):
236         (JSC::FunctionParameters::hasDefaultParameterValues):
237         (JSC::FunctionParameters::append):
238         * parser/Parser.cpp:
239         (JSC::Parser<LexerType>::parseVariableDeclarationList):
240         (JSC::Parser<LexerType>::createBindingPattern):
241         (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
242         (JSC::Parser<LexerType>::parseDestructuringPattern):
243         (JSC::Parser<LexerType>::parseFormalParameters):
244         (JSC::Parser<LexerType>::parseFunctionParameters):
245         * parser/Parser.h:
246         (JSC::Scope::declareParameter):
247         * parser/SyntaxChecker.h:
248         (JSC::SyntaxChecker::createElementList):
249         (JSC::SyntaxChecker::createFormalParameterList):
250         (JSC::SyntaxChecker::appendParameter):
251         (JSC::SyntaxChecker::createClause):
252         (JSC::SyntaxChecker::createClauseList):
253         * tests/stress/es6-default-parameters.js: Added.
254         (assert):
255         (shouldThrow):
256         (shouldThrowSyntaxError):
257         (shouldThrowTDZ):
258         (basic):
259         (basicFunctionCaptureInDefault.basicFunctionCaptureInDefault.basicCaptured):
260         (basicCaptured.basicCaptured.tricky):
261         (strict):
262         (playground):
263         (scoping):
264         (augmentsArguments1):
265         (augmentsArguments2):
266         (augmentsArguments3):
267         (augmentsArguments4):
268         (augmentsArguments5):
269
270 2015-07-24  Xabier Rodriguez Calvar  <calvaris@igalia.com>
271
272         Remove JS Promise constructor unused piece of code
273         https://bugs.webkit.org/show_bug.cgi?id=147262
274
275         Reviewed by Geoffrey Garen.
276
277         * runtime/JSPromiseConstructor.cpp:
278         (JSC::constructPromise): Deleted.
279         * runtime/JSPromiseConstructor.h: Removed JSC::constructPromise.
280
281 2015-07-24  Mark Lam  <mark.lam@apple.com>
282
283         Add WASM files to vcxproj files.
284         https://bugs.webkit.org/show_bug.cgi?id=147264
285
286         Reviewed by Geoffrey Garen.
287
288         This is a follow up to http://trac.webkit.org/changeset/187254 where WASM files
289         were introduced but were not able to be added to the vcxproj files yet.
290
291         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
292         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
293
294 2015-07-23  Filip Pizlo  <fpizlo@apple.com>
295
296         DFG::safeToExecute() is wrong for MultiGetByOffset, doesn't consider the structures of the prototypes that get loaded from
297         https://bugs.webkit.org/show_bug.cgi?id=147250
298
299         Reviewed by Geoffrey Garen.
300         
301         This fixes a nasty - but currently benign - bug in DFG::safeToExecute(). That function
302         will tell you if hoisting a node to some point is safe in the sense that the node will
303         not crash the VM if it executes at that point. A node may be unsafe to execute if we
304         cannot prove that at that point, the memory it is loading is not garbage. This is a
305         necessarily loose notion - for example it's OK to hoist a load if we haven't proved
306         that the load makes semantic sense at that point, since anyway the place where the node
307         did get used will still be guarded by any such semantic checks. But because we may also
308         hoist uses of the load, we need to make sure that it doesn't produce a garbage value.
309         Also, we need to ensure that the load won't trap. Hence safeToExecute() returns true
310         anytime we can be sure that a node will not produce a garbage result (i.e. a malformed
311         JSValue or object pointer) and will not trap when executed at the point in question.
312         
313         The bug is that this verification isn't performed for the loads from prototypes inside
314         MultiGetByOffset. DFG::ByteCodeParser will guard MultiGetByOffset with CheckStructure's
315         on the prototypes. So, hypothetically, you might end up hoisting a MultiGetByOffset
316         above those structure checks, which would mean that we might load a value from a memory
317         location without knowing that the location is valid. It might then return the value
318         loaded.
319         
320         This never happens in practice. Those structure checks are more hoistable that the
321         MultiGetByOffset, since they read a strict subset of the MultiGetByOffset's abstract
322         heap reads. Also, we hoist in program order. So, those CheckStructure's will always be
323         hoisted before the MultiGetByOffset gets hoisted.
324         
325         But we should fix this anyway. DFG::safeToExecute() has a clear definition of what a
326         "true" return means for IR transformations, and it fails in satisfying that definition
327         for MultiGetByOffset.
328         
329         There are various approaches we can use for making this safe. I considered two:
330         
331         1) Have MultiGetByOffset refer to the prototypes it is loading from in IR, so that we
332            can check if it's safe to load from them.
333         
334         2) Turn off MultiGetByOffset hoisting when it will emit loads from prototypes, and the
335            prototype structure isn't being watched.
336         
337         I ended up using (2), because it will be the most natural solution once I finish
338         https://bugs.webkit.org/show_bug.cgi?id=146929. Already now, it's somewhat more natural
339         than (1) since that requires more extensive IR changes. Also, (2) will give us what we
340         want in *most* cases: we will usually watch the prototype structure, and we will
341         usually constant-fold loads from prototypes. Both of these usually-true things would
342         have to become false for MultiGetByOffset hoisting to be disabled by this change.
343         
344         This change also adds my attempt at a test, though it's not really a test of this bug.
345         This bug is currently benign. But, the test does at least trigger the logic to run,
346         which is better than nothing.
347
348         * dfg/DFGSafeToExecute.h:
349         (JSC::DFG::safeToExecute):
350         * tests/stress/multi-get-by-offset-hoist-around-structure-check.js: Added.
351         (foo):
352
353 2015-07-23  Sukolsak Sakshuwong  <sukolsak@gmail.com>
354
355         Implement WebAssembly modules
356         https://bugs.webkit.org/show_bug.cgi?id=147222
357
358         Reviewed by Filip Pizlo.
359
360         Make JSWASMModule inherit from JSDestructibleObject so that the destructor is called.
361
362         * wasm/JSWASMModule.h:
363
364 2015-07-23  Alex Christensen  <achristensen@webkit.org>
365
366         Remove compile and runtime flags for promises.
367         https://bugs.webkit.org/show_bug.cgi?id=147244
368
369         Reviewed by Yusuke Suzuki.
370
371         * API/JSCallbackObjectFunctions.h:
372         (JSC::JSCallbackObject<Parent>::JSCallbackObject):
373         * API/JSContextRef.cpp:
374         (JSGlobalContextCreateInGroup):
375         * Configurations/FeatureDefines.xcconfig:
376         * inspector/JSInjectedScriptHost.cpp:
377         (Inspector::JSInjectedScriptHost::getInternalProperties):
378         * runtime/JSGlobalObject.cpp:
379         (JSC::JSGlobalObject::init):
380         (JSC::JSGlobalObject::visitChildren):
381         * runtime/JSGlobalObject.h:
382         (JSC::JSGlobalObject::create):
383         (JSC::JSGlobalObject::syntaxErrorConstructor):
384         (JSC::JSGlobalObject::typeErrorConstructor):
385         (JSC::JSGlobalObject::URIErrorConstructor):
386         (JSC::JSGlobalObject::promiseConstructor):
387         (JSC::JSGlobalObject::nullGetterFunction):
388         (JSC::JSGlobalObject::nullSetterFunction):
389         (JSC::JSGlobalObject::applyFunction):
390         (JSC::JSGlobalObject::definePropertyFunction):
391         (JSC::JSGlobalObject::arrayProtoValuesFunction):
392         (JSC::JSGlobalObject::initializePromiseFunction):
393         (JSC::JSGlobalObject::newPromiseDeferredFunction):
394         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
395         (JSC::JSGlobalObject::regExpPrototype):
396         (JSC::JSGlobalObject::errorPrototype):
397         (JSC::JSGlobalObject::iteratorPrototype):
398         (JSC::JSGlobalObject::promisePrototype):
399         (JSC::JSGlobalObject::debuggerScopeStructure):
400         (JSC::JSGlobalObject::withScopeStructure):
401         (JSC::JSGlobalObject::iteratorResultStructure):
402         (JSC::JSGlobalObject::iteratorResultStructureOffset):
403         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
404         (JSC::JSGlobalObject::promiseStructure):
405         * runtime/JSPromise.cpp:
406         (JSC::JSPromise::result):
407         * runtime/JSPromise.h:
408         * runtime/JSPromiseConstructor.cpp:
409         (JSC::constructPromise):
410         * runtime/JSPromiseConstructor.h:
411         * runtime/JSPromiseDeferred.cpp:
412         (JSC::JSPromiseDeferred::visitChildren):
413         * runtime/JSPromiseDeferred.h:
414         * runtime/JSPromisePrototype.cpp:
415         (JSC::JSPromisePrototype::getOwnPropertySlot):
416         * runtime/JSPromisePrototype.h:
417         * runtime/RuntimeFlags.h:
418         * runtime/VM.cpp:
419         (JSC::VM::VM):
420         * runtime/VM.h:
421
422 2015-07-23  Sukolsak Sakshuwong  <sukolsak@gmail.com>
423
424         Implement WebAssembly modules
425         https://bugs.webkit.org/show_bug.cgi?id=147222
426
427         Reviewed by Mark Lam.
428
429         Introducing the boilerplate data structure for the WebAssembly module.
430         WebAssembly functionality will be added in a subsequent patch.
431
432         * CMakeLists.txt:
433         * JavaScriptCore.xcodeproj/project.pbxproj:
434         * wasm/JSWASMModule.cpp: Added.
435         (JSC::JSWASMModule::visitChildren):
436         * wasm/JSWASMModule.h: Added.
437         (JSC::JSWASMModule::create):
438         (JSC::JSWASMModule::createStructure):
439         (JSC::JSWASMModule::JSWASMModule):
440
441 2015-07-23  Devin Rousso  <drousso@apple.com>
442
443         Web Inspector: Add a function to CSSCompletions to get a list of supported system fonts
444         https://bugs.webkit.org/show_bug.cgi?id=147009
445
446         Reviewed by Joseph Pecoraro.
447
448         * inspector/protocol/CSS.json: Added getSupportedSystemFontFamilyNames function.
449
450 2015-07-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>
451
452         Add ENABLE_WEBASSEMBLY feature flag for WebAssembly
453         https://bugs.webkit.org/show_bug.cgi?id=147212
454
455         Reviewed by Filip Pizlo.
456
457         * Configurations/FeatureDefines.xcconfig:
458
459 2015-07-22  Filip Pizlo  <fpizlo@apple.com>
460
461         Simplify DFG::DesiredIdentifiers and make it possible to turn a UniquedStringImpl* into an identifierNumber at any time
462         https://bugs.webkit.org/show_bug.cgi?id=147218
463
464         Reviewed by Sam Weinig.
465         
466         I want to be able to take a UniquedStringImpl* and turn it into an identifierNumber at
467         various points in my work on https://bugs.webkit.org/show_bug.cgi?id=146929. Currently,
468         most Nodes that deal with identifiers use identifierNumbers and you can only create an
469         identifierNumber in BytecodeGenerator. DFG::ByteCodeParser does sort of have the
470         ability to create new identifierNumbers when inlining - it takes the inlined code's
471         identifiers and either gives them new numbers or reuses numbers from the enclosing
472         code.
473         
474         This patch takes that basic functionality and puts it in
475         DFG::DesiredIdentifiers::ensure(). Anyone can call this at any time to turn a
476         UniquedStringImpl* into an identifierNumber. This data structure is already used by
477         Plan to properly install any newly created identifier table entries into the CodeBlock.
478
479         * dfg/DFGByteCodeParser.cpp:
480         (JSC::DFG::ByteCodeParser::ByteCodeParser):
481         (JSC::DFG::ByteCodeParser::noticeArgumentsUse):
482         (JSC::DFG::ByteCodeParser::linkBlocks):
483         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
484         (JSC::DFG::ByteCodeParser::buildOperandMapsIfNecessary): Deleted.
485         * dfg/DFGDesiredIdentifiers.cpp:
486         (JSC::DFG::DesiredIdentifiers::DesiredIdentifiers):
487         (JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
488         (JSC::DFG::DesiredIdentifiers::ensure):
489         (JSC::DFG::DesiredIdentifiers::at):
490         (JSC::DFG::DesiredIdentifiers::addLazily): Deleted.
491         * dfg/DFGDesiredIdentifiers.h:
492
493 2015-07-22  Filip Pizlo  <fpizlo@apple.com>
494
495         Simplify things like CompareEq(@x,@x)
496         https://bugs.webkit.org/show_bug.cgi?id=145850
497
498         Reviewed by Sam Weinig.
499         
500         This simplifies x==x to true, except in cases where x might be a double (in which case this
501         might still be false if x is NaN).
502
503         * dfg/DFGAbstractInterpreterInlines.h:
504         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
505         * tests/stress/nan-equal-untyped.js: Added.
506         (foo):
507         (test):
508         * tests/stress/nan-equal.js: Added.
509         (foo):
510
511 2015-07-22  Joseph Pecoraro  <pecoraro@apple.com>
512
513         Web Inspector: Timeline should immediately start moving play head when starting a new recording
514         https://bugs.webkit.org/show_bug.cgi?id=147210
515
516         Reviewed by Timothy Hatcher.
517
518         * inspector/protocol/Timeline.json:
519         Add timestamps to recordingStarted and recordingStopped events.
520
521 2015-07-22  Yusuke Suzuki  <utatane.tea@gmail.com>
522
523         Introducing construct ability into JS executables
524         https://bugs.webkit.org/show_bug.cgi?id=147183
525
526         Reviewed by Geoffrey Garen.
527
528         Decouple the construct ability from the builtin functions.
529         Currently, all builtin functions are not constructors after r182995.
530         In that patch, when the given function is builtin JS function, we recognize it as the non-constructor function.
531
532         But, we need to relax it to implement some constructors in builtins JS.
533         By decoupling the construct ability from whether the function is builtin or not, we can provide
534
535         1. constructors written in builtin JS
536         2. non-constructors in normal JS functions
537
538         (1) is needed for Promise constructor.
539         And (2) is needed for method functions and arrow functions.
540
541         This patch introduces ConstructAbility into the unlinked function executables.
542         It holds whether the given JS function has the construct ability or not.
543         By leveraging this, this patch disables the construct ability of the method definitions, setters, getters and arrow functions.
544
545         And at the same time, this patch introduces the annotation for constructor in builtin JS.
546         We can define the function as follows,
547
548             constructor Promise(executor)
549             {
550                 ...
551             }
552
553         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
554         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
555         * JavaScriptCore.xcodeproj/project.pbxproj:
556         * builtins/BuiltinExecutables.cpp:
557         (JSC::BuiltinExecutables::createDefaultConstructor):
558         (JSC::BuiltinExecutables::createExecutableInternal):
559         * builtins/BuiltinExecutables.h:
560         * builtins/Iterator.prototype.js:
561         (symbolIterator):
562         (SymbolIterator): Deleted.
563         * bytecode/UnlinkedCodeBlock.cpp:
564         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
565         * bytecode/UnlinkedCodeBlock.h:
566         * bytecompiler/BytecodeGenerator.h:
567         (JSC::BytecodeGenerator::makeFunction):
568         * generate-js-builtins:
569         (getCopyright):
570         (Function):
571         (Function.__init__):
572         (Function.mangleName):
573         (getFunctions):
574         (mangleName): Deleted.
575         * jit/JITOperations.cpp:
576         * llint/LLIntSlowPaths.cpp:
577         (JSC::LLInt::setUpCall):
578         * parser/Parser.cpp:
579         (JSC::Parser<LexerType>::parseClass):
580         * runtime/CodeCache.cpp:
581         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
582         * runtime/CommonIdentifiers.h:
583         * runtime/ConstructAbility.h: Copied from Source/JavaScriptCore/builtins/Iterator.prototype.js.
584         * runtime/Executable.h:
585         * runtime/JSFunction.cpp:
586         (JSC::JSFunction::getConstructData):
587         * runtime/JSGlobalObject.cpp:
588         (JSC::JSGlobalObject::init):
589         * tests/stress/non-constructors.js: Added.
590         (shouldThrow):
591         (.prototype.method):
592         (.prototype.get getter):
593         (.prototype.set setter):
594         (.method):
595         (.get shouldThrow):
596         (.set shouldThrow):
597         (set var.test.get getter):
598         (set var.test.set setter):
599         (set var.test.normal):
600         (.set var):
601         (.set new):
602
603 2015-07-22  Csaba Osztrogonác  <ossy@webkit.org>
604
605         [JSC] Enable exception fuzzing for GCC too
606         https://bugs.webkit.org/show_bug.cgi?id=146831
607
608         Reviewed by Darin Adler.
609
610         * jit/JITOperations.cpp:
611
612 2015-07-22  Filip Pizlo  <fpizlo@apple.com>
613
614         Fixed pool allocation should always be aligned
615         https://bugs.webkit.org/show_bug.cgi?id=147201
616
617         Reviewed by Simon Fraser.
618         
619         Passing an unaligned size to the allocator can cause asserts or even worse things. The
620         Options reservation value isn't going to be aligned.
621
622         * jit/ExecutableAllocatorFixedVMPool.cpp:
623         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
624
625 2015-07-22  Csaba Osztrogonác  <ossy@webkit.org>
626
627         Enable STATIC_ASSERT_IS_TRIVIALLY_DESTRUCTIBLE for GCC
628         https://bugs.webkit.org/show_bug.cgi?id=146829
629
630         Reviewed by Brent Fulgham.
631
632         * heap/GCAssertions.h:
633
634 2015-07-22  Alex Christensen  <achristensen@webkit.org>
635
636         Fix quirks in CMake build on Mac and Windows
637         https://bugs.webkit.org/show_bug.cgi?id=147174
638
639         Reviewed by Gyuyoung Kim.
640
641         * PlatformMac.cmake:
642         Add JSRemoteInspector.cpp and remove semicolon from command to make it actually run.
643
644 2015-07-21  Yusuke Suzuki  <utatane.tea@gmail.com>
645
646         Add newTarget accessor to JS constructor written in C++
647         https://bugs.webkit.org/show_bug.cgi?id=147160
648
649         Reviewed by Geoffrey Garen.
650
651         This patch adds `ExecState#newTarget()` which returns `new.target` defined in ECMA262 6th.
652         It enables some C++ constructors (like Intl.XXX constructors) to leverage this to complete
653         its implementation.
654
655         When the constructor is called, |this| in the arguments is used for storing new.target instead.
656         So by adding the accessor for |this|, JS constructor written in C++ can access new.target.
657
658         And at the same time, this patch extends the existing `construct` to accept new.target value.
659         It is corresponding to the spec's Construct abstract operation.
660
661         * interpreter/CallFrame.h:
662         (JSC::ExecState::newTarget):
663         * interpreter/Interpreter.cpp:
664         (JSC::Interpreter::executeConstruct):
665         * interpreter/Interpreter.h:
666         * runtime/ConstructData.cpp:
667         (JSC::construct):
668         * runtime/ConstructData.h:
669         (JSC::construct):
670
671 2015-07-21  Filip Pizlo  <fpizlo@apple.com>
672
673         Unreviewed, fix a lot of tests. Need to initialize WTF threading sooner.
674
675         * jsc.cpp:
676         (main):
677
678 2015-07-21  Filip Pizlo  <fpizlo@apple.com>
679
680         Fixed VM pool allocation should have a reserve for allocations that cannot fail
681         https://bugs.webkit.org/show_bug.cgi?id=147154
682         rdar://problem/21847618
683
684         Reviewed by Geoffrey Garen.
685         
686         This adds the notion of a JIT pool reserve fraction. Some fraction, currently 1/4, of
687         the JIT pool is reserved for allocations that cannot fail. It makes sense to make this
688         a fraction rather than a constant because each allocation that can fail may cause some
689         number of allocations that cannot fail (for example, the OSR exit thunks that we
690         compile when we exit from some CodeBlock cannot fail).
691         
692         I've tested this by adding a test mode where we artificially limit the JIT pool size.
693         Prior to the fix, we had >20 failures. Now we have none.
694
695         * heap/GCLogging.cpp:
696         (WTF::printInternal): I needed a dump method on Options members when debugging this.
697         * heap/GCLogging.h:
698         * jit/ExecutableAllocator.h: Raise the ARM64 limit to 32MB because 16MB is cutting it too close.
699         * jit/ExecutableAllocatorFixedVMPool.cpp:
700         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Add the ability to artificially limit JIT pool size for testing.
701         (JSC::ExecutableAllocator::memoryPressureMultiplier): Implement the reserve when computing memory pressure for JIT tier-up heuristics.
702         (JSC::ExecutableAllocator::allocate): Implement the reserve when allocating can-fail things.
703         * jsc.cpp: Rewire some options parsing so that CommandLine happens before we create the JIT pool.
704         (main):
705         (CommandLine::parseArguments):
706         (jscmain):
707         * runtime/Options.cpp: 
708         (JSC::OptionRange::dump): I needed a dump method on Options members when debugging this.
709         (JSC::Options::initialize): This can now be called more than once.
710         * runtime/Options.h:
711
712 2015-07-21  Saam barati  <saambarati1@gmail.com>
713
714         ObjectPatternNode's entry should use "const Identifier&" instead of "Identifier"
715         https://bugs.webkit.org/show_bug.cgi?id=147156
716
717         Reviewed by Andreas Kling.
718
719         * parser/Nodes.h:
720
721 2015-07-21  Basile Clement  <basile_clement@apple.com>
722
723         Object allocation sinking phase is performing needless HashMap copies
724         https://bugs.webkit.org/show_bug.cgi?id=147159
725
726         Reviewed by Geoffrey Garen.
727
728         The points-to analyzer in the object allocation sinking phase is
729         currently performing copies of its allocation and pointers tables in
730         several places. While this is not a huge problem since those tables are
731         usually small and we are in the FTL path anyway, we still shouldn't be
732         doing such useless copying.
733
734         This patch also removes the DFGInsertOSRHintsForUpdate files that are
735         no longer needed with the new object sinking phase and should have been
736         removed in r186795.
737
738         * CMakeLists.txt:
739         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
740         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
741         * JavaScriptCore.xcodeproj/project.pbxproj:
742         * dfg/DFGInsertOSRHintsForUpdate.cpp: Removed.
743         (JSC::DFG::insertOSRHintsForUpdate): Deleted.
744         * dfg/DFGInsertOSRHintsForUpdate.h: Removed.
745         * dfg/DFGObjectAllocationSinkingPhase.cpp:
746
747 2015-07-21  Saam barati  <saambarati1@gmail.com>
748
749         DestructuringPatternNode and DestructuringAssignmentNode should be ParserArenaFreeable
750         https://bugs.webkit.org/show_bug.cgi?id=147140
751
752         Reviewed by Geoffrey Garen.
753
754         The descendants of DestructuringPatternNode that need destruction also
755         inherit from ParserArenaDeletable.
756
757         * parser/Nodes.h:
758         (JSC::DestructuringPatternNode::~DestructuringPatternNode):
759         (JSC::ObjectPatternNode::appendEntry):
760         (JSC::DestructuringAssignmentNode::bindings):
761
762 2015-07-21  Keith Miller  <keith_miller@apple.com>
763
764         Add support for the new.target syntax.
765         https://bugs.webkit.org/show_bug.cgi?id=147051
766
767         Reviewed by Yusuke Suzuki.
768
769         Add support for new.target. Essentially the implementation is, before constructor calls,
770         the target of a "new" is placed where "this" noramlly goes in the calling convention.
771         Then in the constructor before object is initialized we move the target of the "new"
772         into a local variable.
773
774         * bytecompiler/BytecodeGenerator.cpp:
775         (JSC::BytecodeGenerator::BytecodeGenerator):
776         * bytecompiler/NodesCodegen.cpp:
777         (JSC::NewTargetNode::emitBytecode):
778         * parser/ASTBuilder.h:
779         (JSC::ASTBuilder::newTargetExpr):
780         * parser/NodeConstructors.h:
781         (JSC::NewTargetNode::NewTargetNode):
782         * parser/Nodes.h:
783         * parser/Parser.cpp:
784         (JSC::Parser<LexerType>::parseMemberExpression):
785         * parser/SyntaxChecker.h:
786         (JSC::SyntaxChecker::newTargetExpr):
787         * runtime/CommonIdentifiers.h:
788         * tests/stress/new-target.js: Added.
789         (test):
790         (call):
791         (Constructor.subCall):
792         (Constructor.SubConstructor):
793         (Constructor):
794         (noAssign):
795         (doWeirdThings):
796         (SuperClass):
797         (SubClass):
798
799 2015-07-20  Saam barati  <saambarati1@gmail.com>
800
801         "let" scoping introduced incoherent story about symbol table cloning
802         https://bugs.webkit.org/show_bug.cgi?id=147046
803
804         Reviewed by Filip Pizlo.
805
806         This patch now establishes a clear set of rules for how SymbolTables
807         are owned by CodeBlock. Every SymbolTable that is used by a bytecode
808         instruction must live in CodeBlock's constant register pool. When CodeBlock
809         is being linked, it ensures that every SymbolTable in the constant pool is cloned. 
810         This leaves no room for an un-cloned symbol table to be used by a bytecode instruction. 
811         Some instructions may refer to SymbolTable's indirectly through a JSLexicalEnvironment. 
812         This is fine, all JSLexicalEnvironment's are allocated with references to cloned symbol tables.
813
814         Another goal of this patch is to remove the notion that a SymbolTable is 1 to 1 
815         with a CodeBlock. With lexical scoping, this view of the world is no longer
816         correct. This patch begins to remove this assumption by making CodeBlock's
817         symbolTable() getter method private. There is still one place where we need
818         to purge our codebase of this assumption and that is the type profiler. It 
819         has not been updated for lexical scoping. After it is updated in 
820         https://bugs.webkit.org/show_bug.cgi?id=145438
821         we will be able to remove CodeBlock's symbolTable() getter entirely.
822
823         * bytecode/CodeBlock.cpp:
824         (JSC::CodeBlock::CodeBlock):
825         (JSC::CodeBlock::nameForRegister):
826         * bytecode/CodeBlock.h:
827         (JSC::CodeBlock::addStringSwitchJumpTable):
828         (JSC::CodeBlock::stringSwitchJumpTable):
829         (JSC::CodeBlock::evalCodeCache):
830         (JSC::CodeBlock::symbolTable):
831         * bytecode/UnlinkedCodeBlock.cpp:
832         (JSC::UnlinkedFunctionExecutable::visitChildren):
833         (JSC::UnlinkedFunctionExecutable::link):
834         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
835         * bytecode/UnlinkedCodeBlock.h:
836         (JSC::UnlinkedCodeBlock::addExceptionHandler):
837         (JSC::UnlinkedCodeBlock::exceptionHandler):
838         (JSC::UnlinkedCodeBlock::setSymbolTableConstantIndex):
839         (JSC::UnlinkedCodeBlock::symbolTableConstantIndex):
840         (JSC::UnlinkedCodeBlock::symbolTable): Deleted.
841         (JSC::UnlinkedCodeBlock::setSymbolTable): Deleted.
842         * bytecompiler/BytecodeGenerator.cpp:
843         (JSC::BytecodeGenerator::generate):
844         (JSC::BytecodeGenerator::BytecodeGenerator):
845         (JSC::BytecodeGenerator::pushLexicalScope):
846         (JSC::BytecodeGenerator::variableForLocalEntry):
847         (JSC::BytecodeGenerator::createVariable):
848         (JSC::BytecodeGenerator::resolveType):
849         (JSC::BytecodeGenerator::emitResolveScope):
850         * bytecompiler/BytecodeGenerator.h:
851         (JSC::BytecodeGenerator::thisRegister):
852         (JSC::BytecodeGenerator::instructions):
853         (JSC::BytecodeGenerator::symbolTable): Deleted.
854         * dfg/DFGGraph.h:
855         (JSC::DFG::Graph::baselineCodeBlockFor):
856         (JSC::DFG::Graph::isStrictModeFor):
857         (JSC::DFG::Graph::symbolTableFor): Deleted.
858         * jit/AssemblyHelpers.h:
859         (JSC::AssemblyHelpers::baselineCodeBlock):
860         (JSC::AssemblyHelpers::argumentsStart):
861         (JSC::AssemblyHelpers::symbolTableFor): Deleted.
862         * runtime/CommonSlowPaths.cpp:
863         (JSC::SLOW_PATH_DECL):
864         * runtime/Executable.cpp:
865         (JSC::FunctionExecutable::visitChildren):
866         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation):
867         (JSC::FunctionExecutable::symbolTable): Deleted.
868         * runtime/Executable.h:
869
870 2015-07-18  Filip Pizlo  <fpizlo@apple.com>
871
872         REGRESSION(186691): OSR entry is broken on loop headers that have no live variables
873         https://bugs.webkit.org/show_bug.cgi?id=147074
874         rdar://problem/21869970
875
876         Reviewed by Michael Saboff.
877         
878         The OSR entry must-handle block/value widening introduced in r186691 would cause the
879         CFA to reexecute if it caused any live local variables to change value. But this fails
880         if the must-handle block has no live local variables, and the entry block otherwise
881         appears to be unreachable.
882         
883         This fixes the bug by having the change detection include whether the block hadn't been
884         visited in addition to whether any local variable values got widened.
885         
886         This is a ~4% speed-up on SunSpider in browser.
887
888         * dfg/DFGCFAPhase.cpp:
889         (JSC::DFG::CFAPhase::run):
890
891 2015-07-20  Mark Lam  <mark.lam@apple.com>
892
893         Rollout r187020 and r187021: breaks JSC API tests on debug builds.
894         https://bugs.webkit.org/show_bug.cgi?id=147110
895
896         * heap/MachineStackMarker.cpp:
897         (JSC::MachineThreads::addCurrentThread):
898         * runtime/JSLock.cpp:
899         (JSC::JSLockHolder::~JSLockHolder):
900         (JSC::JSLock::JSLock):
901         (JSC::JSLock::willDestroyVM):
902         (JSC::JSLock::setExclusiveThread):
903         (JSC::JSLock::lock):
904         (JSC::JSLock::unlock):
905         (JSC::JSLock::currentThreadIsHoldingLock):
906         (JSC::JSLock::dropAllLocks):
907         * runtime/JSLock.h:
908         (JSC::JSLock::vm):
909         (JSC::JSLock::hasExclusiveThread):
910         (JSC::JSLock::exclusiveThread):
911         * runtime/VM.h:
912         (JSC::VM::hasExclusiveThread):
913         (JSC::VM::exclusiveThread):
914         (JSC::VM::setExclusiveThread):
915
916 2015-07-20  Per Arne Vollan  <peavo@outlook.com>
917
918         Unreviewed debug build fix after r187020.
919
920         * heap/MachineStackMarker.cpp:
921         (JSC::MachineThreads::addCurrentThread):
922         VM::exclusiveThread() has changed return type to ThreadIdentifier.
923
924 2015-07-20  Per Arne Vollan  <peavo@outlook.com>
925
926         JavaScriptCore performance is very bad on Windows
927         https://bugs.webkit.org/show_bug.cgi?id=146448
928
929         Reviewed by Mark Lam.
930
931         Profiling shows that std::this_thread::get_id() is slow on Windows.
932         Use WTF::currentThread() instead, which calls GetCurrentThreadId().
933         This is faster on Windows. The issue has been reported to Microsoft,
934         https://connect.microsoft.com/VisualStudio/feedback/details/1558211.
935
936         * runtime/JSLock.cpp:
937         (JSC::JSLockHolder::~JSLockHolder):
938         (JSC::JSLock::JSLock):
939         (JSC::JSLock::willDestroyVM):
940         (JSC::JSLock::setExclusiveThread):
941         (JSC::JSLock::lock):
942         (JSC::JSLock::unlock):
943         (JSC::JSLock::currentThreadIsHoldingLock):
944         * runtime/JSLock.h:
945         (JSC::JSLock::vm):
946         (JSC::JSLock::hasExclusiveThread):
947         (JSC::JSLock::exclusiveThread):
948         * runtime/VM.h:
949         (JSC::VM::hasExclusiveThread):
950         (JSC::VM::exclusiveThread):
951         (JSC::VM::setExclusiveThread):
952
953 2015-07-19  Yusuke Suzuki  <utatane.tea@gmail.com>
954
955         In strict mode, `Object.keys(arguments)` includes "length"
956         https://bugs.webkit.org/show_bug.cgi?id=147071
957
958         Reviewed by Darin Adler.
959
960         ClonedAguments didn't set the "length" with DontEnum.
961
962         * runtime/ClonedArguments.cpp:
963         (JSC::ClonedArguments::createWithInlineFrame):
964         (JSC::ClonedArguments::createByCopyingFrom):
965         * tests/stress/arguments-length-always-dont-enum.js: Added.
966         (shouldBe):
967         (argsSloppy):
968         (argsStrict):
969
970 2015-07-19  Jordan Harband  <ljharb@gmail.com>
971
972         new Date(NaN).toJSON() must return null instead of throwing a TypeError
973         https://bugs.webkit.org/show_bug.cgi?id=141115
974
975         Reviewed by Yusuke Suzuki.
976
977         * runtime/DatePrototype.cpp:
978         (JSC::dateProtoFuncToJSON):
979
980 2015-07-19  Saam barati  <saambarati1@gmail.com>
981
982         Parser::parseFunctionInfo hits RELEASE_ASSERT for Arrow Functions
983         https://bugs.webkit.org/show_bug.cgi?id=147090
984
985         Reviewed by Yusuke Suzuki.
986
987         ArrowFunction's have there ParserFunctionInfo "name" field to 
988         be a non-null pointer. This is obviously allowed and valid except we 
989         had a RELEASE_ASSERT that claimed otherwise. This is a mistake. 
990
991         Note: ArrowFunction's will never actually have a function name;
992         there ParserFunctionInfo "name" field will be the empty string. 
993         This is not be mistaken with the name field being a null pointer.
994
995         * parser/Parser.cpp:
996         (JSC::Parser<LexerType>::parseFunctionInfo):
997
998 2015-07-18  Saam barati  <saambarati1@gmail.com>
999
1000         [ES6] Add support for block scope const
1001         https://bugs.webkit.org/show_bug.cgi?id=31813
1002
1003         Reviewed by Filip Pizlo.
1004
1005         'const' is now implemented in an ES6 spec compliant manner.
1006         'const' variables are always block scoped and always live
1007         either on the stack or in a JSLexicalEnvironment. 'const'
1008         variables never live on the global object.
1009
1010         Inside the BytecodeGenerator, when assigning to a stack
1011         'const' variable or a LocalClosureVar 'const' variable,
1012         we will emit code that just throws a type error.
1013         When assigning to a ClosureVar const variable, CodeBlock linking
1014         will ensure that we perform a dynamic lookup of that variable so
1015         that put_to_scope's slow path throws a type error.
1016
1017         The old 'const' implementation has been removed in this patch.
1018
1019         * bytecode/BytecodeList.json:
1020         * bytecode/BytecodeUseDef.h:
1021         (JSC::computeUsesForBytecodeOffset):
1022         (JSC::computeDefsForBytecodeOffset):
1023         * bytecode/CodeBlock.cpp:
1024         (JSC::CodeBlock::dumpBytecode):
1025         (JSC::CodeBlock::CodeBlock):
1026         * bytecompiler/BytecodeGenerator.cpp:
1027         (JSC::BytecodeGenerator::BytecodeGenerator):
1028         (JSC::BytecodeGenerator::pushLexicalScope):
1029         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
1030         (JSC::BytecodeGenerator::variable):
1031         (JSC::BytecodeGenerator::variableForLocalEntry):
1032         (JSC::BytecodeGenerator::createVariable):
1033         (JSC::BytecodeGenerator::emitResolveScope):
1034         (JSC::BytecodeGenerator::emitInstanceOf):
1035         (JSC::BytecodeGenerator::emitGetById):
1036         (JSC::BytecodeGenerator::isArgumentNumber):
1037         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
1038         (JSC::BytecodeGenerator::emitEnumeration):
1039         (JSC::BytecodeGenerator::variablePerSymbolTable): Deleted.
1040         (JSC::BytecodeGenerator::emitInitGlobalConst): Deleted.
1041         * bytecompiler/BytecodeGenerator.h:
1042         (JSC::Variable::Variable):
1043         (JSC::Variable::isReadOnly):
1044         (JSC::Variable::isSpecial):
1045         (JSC::Variable::isConst):
1046         (JSC::BytecodeGenerator::thisRegister):
1047         (JSC::BytecodeGenerator::emitTypeOf):
1048         (JSC::BytecodeGenerator::emitIn):
1049         * bytecompiler/NodesCodegen.cpp:
1050         (JSC::PostfixNode::emitResolve):
1051         (JSC::PrefixNode::emitResolve):
1052         (JSC::ReadModifyResolveNode::emitBytecode):
1053         (JSC::AssignResolveNode::emitBytecode):
1054         (JSC::CommaNode::emitBytecode):
1055         (JSC::BindingNode::bindValue):
1056         (JSC::ConstDeclNode::emitCodeSingle): Deleted.
1057         (JSC::ConstDeclNode::emitBytecode): Deleted.
1058         (JSC::ConstStatementNode::emitBytecode): Deleted.
1059         * dfg/DFGByteCodeParser.cpp:
1060         (JSC::DFG::ByteCodeParser::parseBlock):
1061         * dfg/DFGCapabilities.cpp:
1062         (JSC::DFG::capabilityLevel):
1063         * jit/JIT.cpp:
1064         (JSC::JIT::privateCompileMainPass):
1065         * jit/JIT.h:
1066         * jit/JITPropertyAccess.cpp:
1067         (JSC::JIT::emit_op_put_to_arguments):
1068         (JSC::JIT::emit_op_init_global_const): Deleted.
1069         * jit/JITPropertyAccess32_64.cpp:
1070         (JSC::JIT::emit_op_put_to_arguments):
1071         (JSC::JIT::emit_op_init_global_const): Deleted.
1072         * llint/LowLevelInterpreter.asm:
1073         * llint/LowLevelInterpreter32_64.asm:
1074         * llint/LowLevelInterpreter64.asm:
1075         * parser/ASTBuilder.h:
1076         (JSC::ASTBuilder::createDeclarationStatement):
1077         (JSC::ASTBuilder::createEmptyVarExpression):
1078         (JSC::ASTBuilder::createDebugger):
1079         (JSC::ASTBuilder::appendStatement):
1080         (JSC::ASTBuilder::createVarStatement): Deleted.
1081         (JSC::ASTBuilder::createLetStatement): Deleted.
1082         (JSC::ASTBuilder::createConstStatement): Deleted.
1083         (JSC::ASTBuilder::appendConstDecl): Deleted.
1084         * parser/NodeConstructors.h:
1085         (JSC::CommaNode::CommaNode):
1086         (JSC::SourceElements::SourceElements):
1087         (JSC::SwitchNode::SwitchNode):
1088         (JSC::BlockNode::BlockNode):
1089         (JSC::ConstStatementNode::ConstStatementNode): Deleted.
1090         (JSC::ConstDeclNode::ConstDeclNode): Deleted.
1091         * parser/Nodes.h:
1092         (JSC::ConstDeclNode::hasInitializer): Deleted.
1093         (JSC::ConstDeclNode::ident): Deleted.
1094         * parser/Parser.cpp:
1095         (JSC::Parser<LexerType>::parseStatementListItem):
1096         (JSC::Parser<LexerType>::parseVariableDeclaration):
1097         (JSC::Parser<LexerType>::parseWhileStatement):
1098         (JSC::Parser<LexerType>::parseVariableDeclarationList):
1099         (JSC::Parser<LexerType>::createBindingPattern):
1100         (JSC::Parser<LexerType>::parseDestructuringPattern):
1101         (JSC::Parser<LexerType>::parseDefaultValueForDestructuringPattern):
1102         (JSC::Parser<LexerType>::parseForStatement):
1103         (JSC::Parser<LexerType>::parseTryStatement):
1104         (JSC::Parser<LexerType>::parseFunctionInfo):
1105         (JSC::Parser<LexerType>::parseFunctionDeclaration):
1106         (JSC::Parser<LexerType>::parseClass):
1107         (JSC::Parser<LexerType>::parseConstDeclaration): Deleted.
1108         (JSC::Parser<LexerType>::parseConstDeclarationList): Deleted.
1109         * parser/Parser.h:
1110         (JSC::isEvalNode):
1111         (JSC::isEvalNode<EvalNode>):
1112         (JSC::isArguments):
1113         (JSC::isEval):
1114         (JSC::isEvalOrArgumentsIdentifier):
1115         (JSC::Scope::Scope):
1116         (JSC::Scope::declareCallee):
1117         (JSC::Scope::declareVariable):
1118         (JSC::Scope::declareLexicalVariable):
1119         (JSC::Scope::hasDeclaredVariable):
1120         (JSC::Scope::allowsVarDeclarations):
1121         (JSC::Scope::allowsLexicalDeclarations):
1122         (JSC::Scope::declareParameter):
1123         (JSC::Scope::declareBoundParameter):
1124         (JSC::Parser::destructuringKindFromDeclarationType):
1125         (JSC::Parser::assignmentContextFromDeclarationType):
1126         (JSC::Parser::isEvalOrArguments):
1127         (JSC::Parser::currentScope):
1128         (JSC::Parser::popScope):
1129         (JSC::Parser::declareVariable):
1130         (JSC::Parser::hasDeclaredVariable):
1131         (JSC::Parser::setStrictMode):
1132         (JSC::Parser::strictMode):
1133         (JSC::Parser::isValidStrictMode):
1134         (JSC::Parser::declareParameter):
1135         (JSC::Parser::declareBoundParameter):
1136         (JSC::Parser::breakIsValid):
1137         * parser/SyntaxChecker.h:
1138         (JSC::SyntaxChecker::createForInLoop):
1139         (JSC::SyntaxChecker::createForOfLoop):
1140         (JSC::SyntaxChecker::createEmptyStatement):
1141         (JSC::SyntaxChecker::createDeclarationStatement):
1142         (JSC::SyntaxChecker::createReturnStatement):
1143         (JSC::SyntaxChecker::createBreakStatement):
1144         (JSC::SyntaxChecker::createVarStatement): Deleted.
1145         (JSC::SyntaxChecker::createLetStatement): Deleted.
1146         * parser/VariableEnvironment.h:
1147         (JSC::VariableEnvironmentEntry::isCaptured):
1148         (JSC::VariableEnvironmentEntry::isConst):
1149         (JSC::VariableEnvironmentEntry::isVar):
1150         (JSC::VariableEnvironmentEntry::isLet):
1151         (JSC::VariableEnvironmentEntry::setIsCaptured):
1152         (JSC::VariableEnvironmentEntry::setIsConst):
1153         (JSC::VariableEnvironmentEntry::setIsVar):
1154         (JSC::VariableEnvironmentEntry::setIsLet):
1155         (JSC::VariableEnvironmentEntry::isConstant): Deleted.
1156         (JSC::VariableEnvironmentEntry::setIsConstant): Deleted.
1157         * runtime/Executable.cpp:
1158         (JSC::ProgramExecutable::initializeGlobalProperties):
1159         * runtime/JSGlobalObject.cpp:
1160         (JSC::JSGlobalObject::defineOwnProperty):
1161         (JSC::JSGlobalObject::addGlobalVar):
1162         (JSC::JSGlobalObject::addFunction):
1163         (JSC::lastInPrototypeChain):
1164         * runtime/JSGlobalObject.h:
1165         (JSC::JSGlobalObject::finishCreation):
1166         (JSC::JSGlobalObject::addVar):
1167         (JSC::JSGlobalObject::addConst): Deleted.
1168         * runtime/JSLexicalEnvironment.cpp:
1169         (JSC::JSLexicalEnvironment::symbolTablePut):
1170         * tests/stress/const-and-with-statement.js: Added.
1171         (truth):
1172         (assert):
1173         (shouldThrowInvalidConstAssignment):
1174         (.):
1175         * tests/stress/const-exception-handling.js: Added.
1176         (truth):
1177         (assert):
1178         (.):
1179         * tests/stress/const-loop-semantics.js: Added.
1180         (truth):
1181         (assert):
1182         (shouldThrowInvalidConstAssignment):
1183         (.):
1184         * tests/stress/const-not-strict-mode.js: Added.
1185         (truth):
1186         (assert):
1187         (shouldThrowTDZ):
1188         (.):
1189         * tests/stress/const-semantics.js: Added.
1190         (truth):
1191         (assert):
1192         (shouldThrowInvalidConstAssignment):
1193         (.):
1194         * tests/stress/const-tdz.js: Added.
1195         (truth):
1196         (assert):
1197         (shouldThrowTDZ):
1198         (.):
1199
1200 2015-07-18  Saam barati  <saambarati1@gmail.com>
1201
1202         lexical scoping is broken with respect to "break" and "continue"
1203         https://bugs.webkit.org/show_bug.cgi?id=147063
1204
1205         Reviewed by Filip Pizlo.
1206
1207         Bug #142944 which introduced "let" and lexical scoping
1208         didn't properly hook into the bytecode generator's machinery
1209         for calculating scope depth deltas for "break" and "continue". This
1210         resulted in the bytecode generator popping an incorrect number
1211         of scopes when lexical scopes were involved.
1212
1213         This patch fixes this problem and generalizes this machinery a bit.
1214         This patch also renames old functions in a sensible way that is more
1215         coherent in a world with lexical scoping.
1216
1217         * bytecompiler/BytecodeGenerator.cpp:
1218         (JSC::BytecodeGenerator::BytecodeGenerator):
1219         (JSC::BytecodeGenerator::newLabelScope):
1220         (JSC::BytecodeGenerator::emitProfileType):
1221         (JSC::BytecodeGenerator::pushLexicalScope):
1222         (JSC::BytecodeGenerator::popLexicalScope):
1223         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
1224         (JSC::BytecodeGenerator::resolveType):
1225         (JSC::BytecodeGenerator::emitResolveScope):
1226         (JSC::BytecodeGenerator::emitGetFromScope):
1227         (JSC::BytecodeGenerator::emitPutToScope):
1228         (JSC::BytecodeGenerator::emitPushWithScope):
1229         (JSC::BytecodeGenerator::emitGetParentScope):
1230         (JSC::BytecodeGenerator::emitPopScope):
1231         (JSC::BytecodeGenerator::emitPopWithOrCatchScope):
1232         (JSC::BytecodeGenerator::emitPopScopes):
1233         (JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
1234         (JSC::BytecodeGenerator::localScopeDepth):
1235         (JSC::BytecodeGenerator::labelScopeDepth):
1236         (JSC::BytecodeGenerator::emitThrowReferenceError):
1237         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
1238         (JSC::BytecodeGenerator::pushScopedControlFlowContext):
1239         (JSC::BytecodeGenerator::popScopedControlFlowContext):
1240         (JSC::BytecodeGenerator::emitPushCatchScope):
1241         (JSC::BytecodeGenerator::currentScopeDepth): Deleted.
1242         * bytecompiler/BytecodeGenerator.h:
1243         (JSC::BytecodeGenerator::hasFinaliser):
1244         (JSC::BytecodeGenerator::scopeDepth): Deleted.
1245         * bytecompiler/NodesCodegen.cpp:
1246         (JSC::ContinueNode::trivialTarget):
1247         (JSC::BreakNode::trivialTarget):
1248         (JSC::ReturnNode::emitBytecode):
1249         (JSC::WithNode::emitBytecode):
1250         (JSC::TryNode::emitBytecode):
1251         * tests/stress/lexical-scoping-break-continue.js: Added.
1252         (assert):
1253         (.):
1254
1255 2015-07-18  Commit Queue  <commit-queue@webkit.org>
1256
1257         Unreviewed, rolling out r186996.
1258         https://bugs.webkit.org/show_bug.cgi?id=147070
1259
1260         Broke JSC tests (Requested by smfr on #webkit).
1261
1262         Reverted changeset:
1263
1264         "lexical scoping is broken with respect to "break" and
1265         "continue""
1266         https://bugs.webkit.org/show_bug.cgi?id=147063
1267         http://trac.webkit.org/changeset/186996
1268
1269 2015-07-18  Saam barati  <saambarati1@gmail.com>
1270
1271         lexical scoping is broken with respect to "break" and "continue"
1272         https://bugs.webkit.org/show_bug.cgi?id=147063
1273
1274         Reviewed by Filip Pizlo.
1275
1276         Bug #142944 which introduced "let" and lexical scoping
1277         didn't properly hook into the bytecode generator's machinery
1278         for calculating scope depth deltas for "break" and "continue". This
1279         resulted in the bytecode generator popping an incorrect number
1280         of scopes when lexical scopes were involved.
1281
1282         This patch fixes this problem and generalizes this machinery a bit.
1283         This patch also renames old functions in a sensible way that is more
1284         coherent in a world with lexical scoping.
1285
1286         * bytecompiler/BytecodeGenerator.cpp:
1287         (JSC::BytecodeGenerator::BytecodeGenerator):
1288         (JSC::BytecodeGenerator::newLabelScope):
1289         (JSC::BytecodeGenerator::emitProfileType):
1290         (JSC::BytecodeGenerator::pushLexicalScope):
1291         (JSC::BytecodeGenerator::popLexicalScope):
1292         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
1293         (JSC::BytecodeGenerator::resolveType):
1294         (JSC::BytecodeGenerator::emitResolveScope):
1295         (JSC::BytecodeGenerator::emitGetFromScope):
1296         (JSC::BytecodeGenerator::emitPutToScope):
1297         (JSC::BytecodeGenerator::emitPushWithScope):
1298         (JSC::BytecodeGenerator::emitGetParentScope):
1299         (JSC::BytecodeGenerator::emitPopScope):
1300         (JSC::BytecodeGenerator::emitPopWithOrCatchScope):
1301         (JSC::BytecodeGenerator::emitPopScopes):
1302         (JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
1303         (JSC::BytecodeGenerator::localScopeDepth):
1304         (JSC::BytecodeGenerator::labelScopeDepth):
1305         (JSC::BytecodeGenerator::emitThrowReferenceError):
1306         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
1307         (JSC::BytecodeGenerator::pushScopedControlFlowContext):
1308         (JSC::BytecodeGenerator::popScopedControlFlowContext):
1309         (JSC::BytecodeGenerator::emitPushCatchScope):
1310         (JSC::BytecodeGenerator::currentScopeDepth): Deleted.
1311         * bytecompiler/BytecodeGenerator.h:
1312         (JSC::BytecodeGenerator::hasFinaliser):
1313         (JSC::BytecodeGenerator::scopeDepth): Deleted.
1314         * bytecompiler/NodesCodegen.cpp:
1315         (JSC::ContinueNode::trivialTarget):
1316         (JSC::BreakNode::trivialTarget):
1317         (JSC::ReturnNode::emitBytecode):
1318         (JSC::WithNode::emitBytecode):
1319         (JSC::TryNode::emitBytecode):
1320         * tests/stress/lexical-scoping-break-continue.js: Added.
1321         (assert):
1322         (.):
1323
1324 2015-07-17  Filip Pizlo  <fpizlo@apple.com>
1325
1326         DFG should have some obvious mitigations against watching structures that are unprofitable to watch
1327         https://bugs.webkit.org/show_bug.cgi?id=147034
1328
1329         Reviewed by Mark Lam and Michael Saboff.
1330         
1331         This implements two guards against the DFG watching structures that are likely to fire
1332         their watchpoints:
1333         
1334         - Don't watch dictionaries or any structure that had a dictionary in its past. Dictionaries
1335           can be flattened, and then they can transform back to dictionaries.
1336         
1337         - Don't watch structures whose past structures were transitioned-away from while their
1338           transition watchpoints were being watched. This property gives us monotonicity: if we
1339           recompile because we watched structure S1 of object O, then we won't make the same mistake
1340           again when object O has structure S2, S3, and so on.
1341         
1342         This is a 1.5% speed-up on Kraken. It does penalize some Octane tests, but it also seems to
1343         help some of them, so on Octane it's basically neutral.
1344
1345         * bytecode/Watchpoint.h:
1346         (JSC::WatchpointSet::invalidate):
1347         (JSC::WatchpointSet::isBeingWatched):
1348         (JSC::WatchpointSet::addressOfState):
1349         (JSC::WatchpointSet::addressOfSetIsNotEmpty):
1350         (JSC::InlineWatchpointSet::touch):
1351         (JSC::InlineWatchpointSet::isBeingWatched):
1352         * runtime/JSGlobalObject.h:
1353         (JSC::JSGlobalObject::createStructure):
1354         (JSC::JSGlobalObject::registerWeakMap):
1355         * runtime/Structure.cpp:
1356         (JSC::Structure::Structure):
1357         (JSC::Structure::toDictionaryTransition):
1358         (JSC::Structure::didTransitionFromThisStructure):
1359         * runtime/Structure.h:
1360
1361 2015-07-16  Filip Pizlo  <fpizlo@apple.com>
1362
1363         Remove DFG::DesiredWriteBarriers because it's just a very difficult way of saying "please barrier the machine code block owner"
1364         https://bugs.webkit.org/show_bug.cgi?id=147030
1365
1366         Reviewed by Andreas Kling.
1367         
1368         All of the users of DesiredWriteBarriers were just using it to request that Plan
1369         finalization executes a barrier on codeBlock->ownerExecutable. Indeed, that's the only
1370         owning cell in the heap that compilation affects. So, we might as well just have Plan
1371         unconditionally execute that barrier and then we don't need DesiredWriteBarriers at
1372         all.
1373
1374         * CMakeLists.txt:
1375         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1376         * JavaScriptCore.xcodeproj/project.pbxproj:
1377         * dfg/DFGByteCodeParser.cpp:
1378         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1379         * dfg/DFGDesiredWriteBarriers.cpp: Removed.
1380         * dfg/DFGDesiredWriteBarriers.h: Removed.
1381         * dfg/DFGGraph.cpp:
1382         (JSC::DFG::Graph::registerFrozenValues):
1383         * dfg/DFGPlan.cpp:
1384         (JSC::DFG::Plan::reallyAdd):
1385         (JSC::DFG::Plan::notifyCompiling):
1386         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
1387         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
1388         (JSC::DFG::Plan::cancel):
1389         * dfg/DFGPlan.h:
1390
1391 2015-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1392
1393         Integrate automatic microtask draining into JSC framework and re-enable Promise
1394         https://bugs.webkit.org/show_bug.cgi?id=146828
1395
1396         Reviewed by Sam Weinig.
1397
1398         Add automatic microtask draining system into JSC framework.
1399         When the depth of VM lock becomes 0, before this, we drain the queued microtasks.
1400         Enqueuing behavior can be injected by the JSGlobalObject's method table.
1401         It is utilized in WebCore to post the microtask to WebCore's event loop.
1402
1403         In the case of JSC interactive shell, VM depth is always greater than 0.
1404         So we manually drains the queued microtasks after evaluating the written line.
1405
1406         Since now JSC framework has the microtask queue, we can drain the queued microtasks.
1407         So re-enable the Promise in the JSC framework context.
1408
1409         * API/JSContextRef.cpp:
1410         (javaScriptRuntimeFlags): Deleted.
1411         * API/tests/testapi.c:
1412         (main):
1413         * API/tests/testapi.mm:
1414         (testObjectiveCAPIMain):
1415         * jsc.cpp:
1416         (runInteractive):
1417         * runtime/JSGlobalObject.cpp:
1418         (JSC::JSGlobalObject::queueMicrotask):
1419         * runtime/JSLock.cpp:
1420         (JSC::JSLock::willReleaseLock):
1421         * runtime/VM.cpp:
1422         (JSC::VM::queueMicrotask):
1423         (JSC::VM::drainMicrotasks):
1424         (JSC::QueuedTask::run):
1425         * runtime/VM.h:
1426         (JSC::QueuedTask::QueuedTask):
1427
1428 2015-07-17  Saam barati  <saambarati1@gmail.com>
1429
1430         Function parameters should be parsed in the same parser arena as the function body
1431         https://bugs.webkit.org/show_bug.cgi?id=145995
1432
1433         Reviewed by Yusuke Suzuki.
1434
1435         This patch changes how functions are parsed in JSC. A function's
1436         parameters are now parsed in the same arena as the function itself.
1437         This allows us to arena allocate all destructuring AST nodes and
1438         the FunctionParameters node. This will help make implementing ES6
1439         default parameter values sane.
1440
1441         A source code that represents a function now includes the text of the function's 
1442         parameters. The starting offset is at the opening parenthesis of the parameter
1443         list or at the starting character of the identifier for arrow functions that
1444         have single arguments and don't start with parenthesis.
1445
1446         For example:
1447
1448         "function (param1, param2) { ... }"
1449                                    ^
1450                                    | This offset used to be the starting offset of a function's SourceCode
1451                   ^
1452                   | This is the new starting offset for a function's SourceCode.
1453
1454         This requires us to change how some offsets are calculated
1455         and also requires us to report some different line numbers for internal
1456         metrics that use a SourceCode's starting line and column numbers.
1457
1458         This patch also does a bit of cleanup with regards to how
1459         functions are parsed in general (especially arrow functions).
1460         It removes some unnecessary #ifdefs and the likes for arrow
1461         to make things clearer and more deliberate.
1462
1463         * API/JSScriptRef.cpp:
1464         (parseScript):
1465         * builtins/BuiltinExecutables.cpp:
1466         (JSC::BuiltinExecutables::createExecutableInternal):
1467         * bytecode/UnlinkedCodeBlock.cpp:
1468         (JSC::generateFunctionCodeBlock):
1469         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1470         (JSC::UnlinkedFunctionExecutable::visitChildren):
1471         (JSC::UnlinkedFunctionExecutable::parameterCount): Deleted.
1472         * bytecode/UnlinkedCodeBlock.h:
1473         * bytecompiler/NodesCodegen.cpp:
1474         (JSC::DestructuringAssignmentNode::emitBytecode):
1475         (JSC::assignDefaultValueIfUndefined):
1476         (JSC::ArrayPatternNode::collectBoundIdentifiers):
1477         (JSC::DestructuringPatternNode::~DestructuringPatternNode): Deleted.
1478         * parser/ASTBuilder.h:
1479         (JSC::ASTBuilder::createClassExpr):
1480         (JSC::ASTBuilder::createFunctionExpr):
1481         (JSC::ASTBuilder::createFunctionBody):
1482         (JSC::ASTBuilder::createArrowFunctionExpr):
1483         (JSC::ASTBuilder::createGetterOrSetterProperty):
1484         (JSC::ASTBuilder::createElementList):
1485         (JSC::ASTBuilder::createFormalParameterList):
1486         (JSC::ASTBuilder::appendParameter):
1487         (JSC::ASTBuilder::createClause):
1488         (JSC::ASTBuilder::createClauseList):
1489         (JSC::ASTBuilder::createFuncDeclStatement):
1490         (JSC::ASTBuilder::createForInLoop):
1491         (JSC::ASTBuilder::createForOfLoop):
1492         (JSC::ASTBuilder::isResolve):
1493         (JSC::ASTBuilder::createDestructuringAssignment):
1494         (JSC::ASTBuilder::createArrayPattern):
1495         (JSC::ASTBuilder::appendArrayPatternSkipEntry):
1496         (JSC::ASTBuilder::appendArrayPatternEntry):
1497         (JSC::ASTBuilder::appendArrayPatternRestEntry):
1498         (JSC::ASTBuilder::finishArrayPattern):
1499         (JSC::ASTBuilder::createObjectPattern):
1500         (JSC::ASTBuilder::appendObjectPatternEntry):
1501         (JSC::ASTBuilder::createBindingLocation):
1502         (JSC::ASTBuilder::setEndOffset):
1503         * parser/Lexer.cpp:
1504         (JSC::Lexer<T>::Lexer):
1505         (JSC::Lexer<T>::nextTokenIsColon):
1506         (JSC::Lexer<T>::setTokenPosition):
1507         (JSC::Lexer<T>::lex):
1508         (JSC::Lexer<T>::clear):
1509         * parser/Lexer.h:
1510         (JSC::Lexer::setIsReparsingFunction):
1511         (JSC::Lexer::isReparsingFunction):
1512         (JSC::Lexer::lineNumber):
1513         (JSC::Lexer::setIsReparsing): Deleted.
1514         (JSC::Lexer::isReparsing): Deleted.
1515         * parser/NodeConstructors.h:
1516         (JSC::TryNode::TryNode):
1517         (JSC::FunctionParameters::FunctionParameters):
1518         (JSC::FuncExprNode::FuncExprNode):
1519         (JSC::FuncDeclNode::FuncDeclNode):
1520         (JSC::ArrayPatternNode::ArrayPatternNode):
1521         (JSC::ObjectPatternNode::ObjectPatternNode):
1522         (JSC::BindingNode::BindingNode):
1523         (JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
1524         (JSC::ParameterNode::ParameterNode): Deleted.
1525         (JSC::ArrayPatternNode::create): Deleted.
1526         (JSC::ObjectPatternNode::create): Deleted.
1527         (JSC::BindingNode::create): Deleted.
1528         * parser/Nodes.cpp:
1529         (JSC::ProgramNode::ProgramNode):
1530         (JSC::EvalNode::EvalNode):
1531         (JSC::FunctionBodyNode::FunctionBodyNode):
1532         (JSC::FunctionBodyNode::finishParsing):
1533         (JSC::FunctionNode::FunctionNode):
1534         (JSC::FunctionNode::finishParsing):
1535         (JSC::FunctionParameters::create): Deleted.
1536         (JSC::FunctionParameters::FunctionParameters): Deleted.
1537         (JSC::FunctionParameters::~FunctionParameters): Deleted.
1538         * parser/Nodes.h:
1539         (JSC::ProgramNode::startColumn):
1540         (JSC::ProgramNode::endColumn):
1541         (JSC::EvalNode::startColumn):
1542         (JSC::EvalNode::endColumn):
1543         (JSC::FunctionParameters::size):
1544         (JSC::FunctionParameters::at):
1545         (JSC::FunctionParameters::append):
1546         (JSC::FuncExprNode::body):
1547         (JSC::DestructuringPatternNode::~DestructuringPatternNode):
1548         (JSC::DestructuringPatternNode::isBindingNode):
1549         (JSC::DestructuringPatternNode::emitDirectBinding):
1550         (JSC::ArrayPatternNode::appendIndex):
1551         (JSC::ObjectPatternNode::appendEntry):
1552         (JSC::BindingNode::boundProperty):
1553         (JSC::BindingNode::divotStart):
1554         (JSC::BindingNode::divotEnd):
1555         (JSC::DestructuringAssignmentNode::bindings):
1556         (JSC::FuncDeclNode::body):
1557         (JSC::ParameterNode::pattern): Deleted.
1558         (JSC::ParameterNode::nextParam): Deleted.
1559         (JSC::FunctionParameters::patterns): Deleted.
1560         * parser/Parser.cpp:
1561         (JSC::Parser<LexerType>::Parser):
1562         (JSC::Parser<LexerType>::~Parser):
1563         (JSC::Parser<LexerType>::parseInner):
1564         (JSC::Parser<LexerType>::allowAutomaticSemicolon):
1565         (JSC::Parser<LexerType>::parseSourceElements):
1566         (JSC::Parser<LexerType>::createBindingPattern):
1567         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
1568         (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
1569         (JSC::Parser<LexerType>::parseSwitchClauses):
1570         (JSC::Parser<LexerType>::parseSwitchDefaultClause):
1571         (JSC::Parser<LexerType>::parseBlockStatement):
1572         (JSC::Parser<LexerType>::parseStatement):
1573         (JSC::Parser<LexerType>::parseFormalParameters):
1574         (JSC::Parser<LexerType>::parseFunctionBody):
1575         (JSC::stringForFunctionMode):
1576         (JSC::Parser<LexerType>::parseFunctionParameters):
1577         (JSC::Parser<LexerType>::parseFunctionInfo):
1578         (JSC::Parser<LexerType>::parseFunctionDeclaration):
1579         (JSC::Parser<LexerType>::parseClass):
1580         (JSC::Parser<LexerType>::parsePrimaryExpression):
1581         (JSC::Parser<LexerType>::parseMemberExpression):
1582         (JSC::Parser<LexerType>::parseArrowFunctionExpression):
1583         (JSC::operatorString):
1584         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBody): Deleted.
1585         * parser/Parser.h:
1586         (JSC::Parser::positionBeforeLastNewline):
1587         (JSC::Parser::locationBeforeLastToken):
1588         (JSC::Parser::findCachedFunctionInfo):
1589         (JSC::Parser::isofToken):
1590         (JSC::Parser::isEndOfArrowFunction):
1591         (JSC::Parser::isArrowFunctionParamters):
1592         (JSC::Parser::tokenStart):
1593         (JSC::Parser::isLETMaskedAsIDENT):
1594         (JSC::Parser::autoSemiColon):
1595         (JSC::Parser::setEndOfStatement):
1596         (JSC::Parser::canRecurse):
1597         (JSC::Parser<LexerType>::parse):
1598         (JSC::parse):
1599         * parser/ParserFunctionInfo.h:
1600         * parser/ParserModes.h:
1601         (JSC::functionNameIsInScope):
1602         * parser/SourceCode.h:
1603         (JSC::makeSource):
1604         (JSC::SourceCode::subExpression):
1605         (JSC::SourceCode::subArrowExpression): Deleted.
1606         * parser/SourceProviderCache.h:
1607         (JSC::SourceProviderCache::get):
1608         * parser/SourceProviderCacheItem.h:
1609         (JSC::SourceProviderCacheItem::endFunctionToken):
1610         (JSC::SourceProviderCacheItem::usedVariables):
1611         (JSC::SourceProviderCacheItem::writtenVariables):
1612         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
1613         * parser/SyntaxChecker.h:
1614         (JSC::SyntaxChecker::SyntaxChecker):
1615         (JSC::SyntaxChecker::createClassExpr):
1616         (JSC::SyntaxChecker::createFunctionExpr):
1617         (JSC::SyntaxChecker::createFunctionBody):
1618         (JSC::SyntaxChecker::createArrowFunctionExpr):
1619         (JSC::SyntaxChecker::setFunctionNameStart):
1620         (JSC::SyntaxChecker::createArguments):
1621         (JSC::SyntaxChecker::createPropertyList):
1622         (JSC::SyntaxChecker::createElementList):
1623         (JSC::SyntaxChecker::createFormalParameterList):
1624         (JSC::SyntaxChecker::appendParameter):
1625         (JSC::SyntaxChecker::createClause):
1626         (JSC::SyntaxChecker::createClauseList):
1627         * runtime/CodeCache.cpp:
1628         (JSC::CodeCache::getGlobalCodeBlock):
1629         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
1630         * runtime/Completion.cpp:
1631         (JSC::checkSyntax):
1632         * runtime/Executable.cpp:
1633         (JSC::ProgramExecutable::checkSyntax):
1634         * tests/controlFlowProfiler/conditional-expression.js:
1635         (testConditionalFunctionCall):
1636
1637 2015-07-16  Filip Pizlo  <fpizlo@apple.com>
1638
1639         Unreviewed, fix build for newer LLVMs.
1640
1641         * llvm/LLVMHeaders.h:
1642         * llvm/library/LLVMExports.cpp:
1643
1644 2015-07-16  Mark Lam  <mark.lam@apple.com>
1645
1646         RegExp::match() should set m_state to ByteCode if compilation fails.
1647         https://bugs.webkit.org/show_bug.cgi?id=147023
1648
1649         Reviewed by Michael Saboff.
1650
1651         A RegExp has a YarrCodeBlock that has 4 MacroAssemblerCodeRefs for compiled code.
1652         If one of these compilations succeeds, RegExp::m_state will be set to JITCode.
1653         Subsequently, if RegExp tries to compile another one of these but fails, m_state
1654         will be left untouched i.e. it still says JITCode.  As a result, when
1655         RegExp::match() later tries to execute the non-existant compiled code, it will
1656         crash.
1657
1658         The fix is to downgrade m_state to ByteCode if RegExp ever fails to compile.
1659         This failure should be rare.  We'll do the minimal work here to fix the issue and
1660         keep an eye on the perf bots.  If perf regresses, we can do some optimization work then.
1661
1662         This issue is difficult to test for since it either requires a low memory condition
1663         to trigger a failed RegExp compilation at the right moment, or for the RegExp to
1664         succeed compilation in the MatchedOnly mode but fail in IncludeSubpatterns mode.
1665         Instead, I manually tested it by instrumenting RegExp::compile() to fail once in every
1666         10 compilation attempts.
1667
1668         * runtime/RegExp.cpp:
1669         (JSC::RegExp::compile):
1670         (JSC::RegExp::compileMatchOnly):
1671
1672 2015-07-15  Brent Fulgham  <bfulgham@apple.com>
1673
1674         [Win] Fix armv7 build.
1675
1676         * jit/CCallHelpers.h:
1677         (JSC::CCallHelpers::setupArgumentsWithExecState): The 64-bit argument
1678         version of poke is not available on armv7 builds.
1679
1680 2015-07-15  Brent Fulgham  <bfulgham@apple.com>
1681
1682         [Win] 64-bit Build Failure
1683         https://bugs.webkit.org/show_bug.cgi?id=146989
1684
1685         Reviewed by Mark Lam.
1686
1687         * jit/CCallHelpers.h:
1688         (JSC::CCallHelpers::setupArgumentsWithExecState): Add missing
1689         declaration for 64-bit type on 4-argument register machines (like
1690         Windows).
1691
1692 2015-07-15  Saam barati  <saambarati1@gmail.com>
1693
1694         [ES6] implement block scoping to enable 'let'
1695         https://bugs.webkit.org/show_bug.cgi?id=142944
1696
1697         Reviewed by Filip Pizlo.
1698
1699         * CMakeLists.txt:
1700         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1701         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1702         * JavaScriptCore.xcodeproj/project.pbxproj:
1703         * builtins/BuiltinExecutables.cpp:
1704         (JSC::BuiltinExecutables::createExecutableInternal):
1705         * bytecode/BytecodeList.json:
1706         This patch adds a new opcode and removes op_pop_scope:
1707         1) op_get_parent_scope returns the parent scope but doesn't 
1708         implicitly write that scope into the scope register. op_pop_scope
1709         is now reduced to op_get_parent_scope followed by op_mov.
1710
1711         * bytecode/BytecodeUseDef.h:
1712         (JSC::computeUsesForBytecodeOffset):
1713         (JSC::computeDefsForBytecodeOffset):
1714         * bytecode/CodeBlock.cpp:
1715         (JSC::CodeBlock::dumpBytecode):
1716         (JSC::CodeBlock::CodeBlock):
1717         (JSC::CodeBlock::stronglyVisitStrongReferences):
1718         * bytecode/CodeBlock.h:
1719         (JSC::CodeBlock::addStringSwitchJumpTable):
1720         (JSC::CodeBlock::stringSwitchJumpTable):
1721         (JSC::CodeBlock::symbolTable):
1722         (JSC::CodeBlock::evalCodeCache):
1723         (JSC::CodeBlock::setConstantRegisters):
1724         (JSC::CodeBlock::replaceConstant):
1725         op_put_to_scope for LocalClosureVar now takes as an argument
1726         the constant index for the Symbol Table it will be putting into.
1727         This argument is only used to communicate from the BytecodeGenerator
1728         to CodeBlock linking time and it is not present in the linked bytecode.
1729
1730         op_put_to_scope for non LocalClosureVar takes, at the same index, an
1731         argument that represents the local scope depth which it uses for
1732         JSScope::abstractResolve to know how many scopes it needs to skip.
1733         Again, this is not in the linked code.
1734         op_get_from_scope and op_resolve_scope also take as an argument
1735         the local scope depth to use in JSScope::abstractResolve. Again,
1736         this is not used in the linked code.
1737
1738         * bytecode/EvalCodeCache.h:
1739         (JSC::EvalCodeCache::tryGet):
1740         (JSC::EvalCodeCache::getSlow):
1741         (JSC::EvalCodeCache::clear):
1742         (JSC::EvalCodeCache::isCacheable):
1743         When direct eval is called and passed a scope that 
1744         corresponds to a lexical scope, we can't safely cache 
1745         that code because we won't be able to guarantee
1746         that the cached code is always executed in the same scope.
1747         Consider this example:
1748         function foo() {
1749             let x = 20;
1750             eval("x;");
1751             if (b) {
1752                 let x = 30;
1753                 if (b) {
1754                     let y = 40;
1755                     eval("x;")
1756                 }
1757             }
1758         }
1759
1760         We can't reuse resolution depth when linking get_from_scope in evals.
1761
1762         * bytecode/UnlinkedCodeBlock.cpp:
1763         (JSC::generateFunctionCodeBlock):
1764         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1765         (JSC::UnlinkedFunctionExecutable::parameterCount):
1766         * bytecode/UnlinkedCodeBlock.h:
1767         Unlinked functions now know the variables that were under TDZ in their parent
1768         scope.
1769
1770         (JSC::UnlinkedCodeBlock::symbolTable):
1771         (JSC::UnlinkedCodeBlock::setSymbolTable):
1772         (JSC::UnlinkedCodeBlock::setSymbolTableConstantIndex):
1773         (JSC::UnlinkedCodeBlock::symbolTableConstantIndex):
1774         (JSC::UnlinkedCodeBlock::vm):
1775         * bytecompiler/BytecodeGenerator.cpp:
1776         (JSC::BytecodeGenerator::generate):
1777         (JSC::BytecodeGenerator::BytecodeGenerator):
1778         (JSC::BytecodeGenerator::~BytecodeGenerator):
1779         (JSC::BytecodeGenerator::newRegister):
1780         (JSC::BytecodeGenerator::reclaimFreeRegisters):
1781         (JSC::BytecodeGenerator::newBlockScopeVariable):
1782         (JSC::BytecodeGenerator::newTemporary):
1783         (JSC::BytecodeGenerator::emitProfileType):
1784         (JSC::BytecodeGenerator::emitLoadGlobalObject):
1785         (JSC::BytecodeGenerator::pushLexicalScope):
1786         (JSC::BytecodeGenerator::popLexicalScope):
1787         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
1788         (JSC::BytecodeGenerator::variable):
1789         (JSC::BytecodeGenerator::variablePerSymbolTable):
1790         (JSC::BytecodeGenerator::variableForLocalEntry):
1791         (JSC::BytecodeGenerator::createVariable):
1792         (JSC::BytecodeGenerator::emitResolveScope):
1793         (JSC::BytecodeGenerator::emitGetFromScope):
1794         (JSC::BytecodeGenerator::emitPutToScope):
1795         (JSC::BytecodeGenerator::initializeVariable):
1796         (JSC::BytecodeGenerator::emitTDZCheck):
1797         (JSC::BytecodeGenerator::needsTDZCheck):
1798         (JSC::BytecodeGenerator::emitTDZCheckIfNecessary):
1799         (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
1800         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
1801         (JSC::BytecodeGenerator::emitNewObject):
1802         (JSC::BytecodeGenerator::emitPushWithScope):
1803         (JSC::BytecodeGenerator::emitGetParentScope):
1804         (JSC::BytecodeGenerator::emitPopScope):
1805         (JSC::BytecodeGenerator::emitDebugHook):
1806         (JSC::BytecodeGenerator::pushFinallyContext):
1807         (JSC::BytecodeGenerator::pushIteratorCloseContext):
1808         (JSC::BytecodeGenerator::emitComplexPopScopes):
1809         (JSC::BytecodeGenerator::emitPopScopes):
1810         (JSC::BytecodeGenerator::popTryAndEmitCatch):
1811         (JSC::BytecodeGenerator::calculateTargetScopeDepthForExceptionHandler):
1812         (JSC::BytecodeGenerator::currentScopeDepth):
1813         (JSC::BytecodeGenerator::emitThrowReferenceError):
1814         (JSC::BytecodeGenerator::emitPushCatchScope):
1815         (JSC::BytecodeGenerator::beginSwitch):
1816         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
1817         (JSC::BytecodeGenerator::emitEnumeration):
1818         * bytecompiler/BytecodeGenerator.h:
1819         (JSC::Variable::Variable):
1820         (JSC::Variable::isResolved):
1821         (JSC::Variable::symbolTableConstantIndex):
1822         (JSC::Variable::ident):
1823         (JSC::BytecodeGenerator::ignoredResult):
1824         (JSC::BytecodeGenerator::tempDestination):
1825         (JSC::BytecodeGenerator::lastOpcodeID):
1826         (JSC::BytecodeGenerator::makeFunction):
1827         (JSC::BytecodeGenerator::symbolTable):
1828         (JSC::BytecodeGenerator::shouldOptimizeLocals): Deleted.
1829         (JSC::BytecodeGenerator::canOptimizeNonLocals): Deleted.
1830         The heart of the changes in this patch are in the bytecode generator.
1831         The bytecode generator now keeps a stack of tuples of 
1832         {symbol table, scope register, flag indicating catch or with scope, symbol table index in constant pool}
1833         that models the runtime scope stack. This symbol table stack is used
1834         in resolving local variables.
1835
1836         Also, the bytecode generator handles pushing and popping of lexical scopes. 
1837         This is relatively straight forward:
1838         Captured 'let' variables end up in the JSLexicalEnvironment scope and non-captured
1839         variables end up on the stack. Some trickiness is involved in generating
1840         code for 'for' loops that have captured variables (I'm talking about variables in the loop
1841         header, not the loop body). Each iteration of the for loop ends up with 
1842         its own JSLexicalEnvironment. Static code must be generated in such a way 
1843         to create this runtime behavior. This is done by emitting instructions to 
1844         push and pop a lexical scope at the end of each loop and copying values
1845         from the previous loop's scope into the new scope. This code must also
1846         ensure that each loop iteration's scope refers to the same underlying 
1847         SymbolTable so that no scope is accidentally mistaken as being a singleton scope.
1848
1849         When the debugger is enabled, all lexically defined variables will end up in the
1850         JSLexicalEnvironment.
1851
1852         * bytecompiler/NodesCodegen.cpp:
1853         (JSC::ResolveNode::emitBytecode):
1854         (JSC::FunctionCallResolveNode::emitBytecode):
1855         (JSC::PostfixNode::emitResolve):
1856         (JSC::DeleteResolveNode::emitBytecode):
1857         (JSC::TypeOfResolveNode::emitBytecode):
1858         (JSC::PrefixNode::emitResolve):
1859         (JSC::ReadModifyResolveNode::emitBytecode):
1860         (JSC::AssignResolveNode::emitBytecode):
1861         (JSC::BlockNode::emitBytecode):
1862         (JSC::ExprStatementNode::emitBytecode):
1863         (JSC::DeclarationStatement::emitBytecode):
1864         (JSC::EmptyVarExpression::emitBytecode):
1865         (JSC::EmptyLetExpression::emitBytecode):
1866         (JSC::ForNode::emitBytecode):
1867         (JSC::ForInNode::emitMultiLoopBytecode):
1868         (JSC::ForOfNode::emitBytecode):
1869         (JSC::SwitchNode::emitBytecode):
1870         (JSC::BindingNode::bindValue):
1871         (JSC::VarStatementNode::emitBytecode): Deleted.
1872         * debugger/DebuggerCallFrame.cpp:
1873         (JSC::DebuggerCallFrame::evaluate):
1874         * debugger/DebuggerScope.cpp:
1875         (JSC::DebuggerScope::getOwnPropertySlot):
1876         (JSC::DebuggerScope::put):
1877         * dfg/DFGByteCodeParser.cpp:
1878         (JSC::DFG::ByteCodeParser::parseBlock):
1879         * dfg/DFGCapabilities.cpp:
1880         (JSC::DFG::capabilityLevel):
1881         * dfg/DFGNode.h:
1882         (JSC::DFG::Node::castConstant):
1883         (JSC::DFG::Node::initializationValueForActivation):
1884         (JSC::DFG::Node::containsMovHint):
1885         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1886         CreateActivation nodes now have a second OpInfo that tracks the 
1887         initial value that needs to be placed in the activation. This initial value 
1888         is also used in allocation sinking to create proper bottom values for all 
1889         scope variables.
1890
1891         * dfg/DFGOperations.cpp:
1892         * dfg/DFGOperations.h:
1893         * dfg/DFGSpeculativeJIT.cpp:
1894         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
1895         * dfg/DFGSpeculativeJIT.h:
1896         (JSC::DFG::SpeculativeJIT::callOperation):
1897         * ftl/FTLIntrinsicRepository.h:
1898         * ftl/FTLLowerDFGToLLVM.cpp:
1899         (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
1900         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
1901         * ftl/FTLOperations.cpp:
1902         (JSC::FTL::operationMaterializeObjectInOSR):
1903         * interpreter/Interpreter.cpp:
1904         (JSC::Interpreter::execute):
1905         * jit/CCallHelpers.h:
1906         (JSC::CCallHelpers::setupArgumentsWithExecState):
1907         * jit/JIT.cpp:
1908         (JSC::JIT::privateCompileMainPass):
1909         * jit/JIT.h:
1910         * jit/JITInlines.h:
1911         (JSC::JIT::callOperation):
1912         * jit/JITOpcodes.cpp:
1913         (JSC::JIT::emit_op_push_with_scope):
1914         (JSC::JIT::compileOpStrictEq):
1915         (JSC::JIT::emit_op_catch):
1916         (JSC::JIT::emit_op_create_lexical_environment):
1917         (JSC::JIT::emit_op_get_parent_scope):
1918         (JSC::JIT::emit_op_switch_imm):
1919         (JSC::JIT::emit_op_enter):
1920         (JSC::JIT::emit_op_get_scope):
1921         (JSC::JIT::emit_op_pop_scope): Deleted.
1922         * jit/JITOpcodes32_64.cpp:
1923         (JSC::JIT::emit_op_push_with_scope):
1924         (JSC::JIT::emit_op_to_number):
1925         (JSC::JIT::emit_op_catch):
1926         (JSC::JIT::emit_op_create_lexical_environment):
1927         (JSC::JIT::emit_op_get_parent_scope):
1928         (JSC::JIT::emit_op_switch_imm):
1929         (JSC::JIT::emit_op_enter):
1930         (JSC::JIT::emit_op_get_scope):
1931         (JSC::JIT::emit_op_pop_scope): Deleted.
1932         * jit/JITOperations.cpp:
1933         (JSC::canAccessArgumentIndexQuickly):
1934         * jit/JITOperations.h:
1935         * llint/LLIntSlowPaths.cpp:
1936         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1937         * llint/LLIntSlowPaths.h:
1938         * llint/LowLevelInterpreter.asm:
1939         * llint/LowLevelInterpreter32_64.asm:
1940         * llint/LowLevelInterpreter64.asm:
1941         * parser/ASTBuilder.h:
1942         (JSC::ASTBuilder::createSourceElements):
1943         (JSC::ASTBuilder::funcDeclarations):
1944         (JSC::ASTBuilder::features):
1945         (JSC::ASTBuilder::numConstants):
1946         (JSC::ASTBuilder::createConditionalExpr):
1947         (JSC::ASTBuilder::createAssignResolve):
1948         (JSC::ASTBuilder::createClassDeclStatement):
1949         (JSC::ASTBuilder::createBlockStatement):
1950         (JSC::ASTBuilder::createIfStatement):
1951         (JSC::ASTBuilder::createForLoop):
1952         (JSC::ASTBuilder::createForInLoop):
1953         (JSC::ASTBuilder::createForOfLoop):
1954         (JSC::ASTBuilder::isBindingNode):
1955         (JSC::ASTBuilder::createEmptyStatement):
1956         (JSC::ASTBuilder::createDeclarationStatement):
1957         (JSC::ASTBuilder::createVarStatement):
1958         (JSC::ASTBuilder::createLetStatement):
1959         (JSC::ASTBuilder::createEmptyVarExpression):
1960         (JSC::ASTBuilder::createEmptyLetExpression):
1961         (JSC::ASTBuilder::createReturnStatement):
1962         (JSC::ASTBuilder::createTryStatement):
1963         (JSC::ASTBuilder::createSwitchStatement):
1964         (JSC::ASTBuilder::appendStatement):
1965         (JSC::ASTBuilder::createCommaExpr):
1966         (JSC::ASTBuilder::appendObjectPatternEntry):
1967         (JSC::ASTBuilder::createBindingLocation):
1968         (JSC::ASTBuilder::setEndOffset):
1969         (JSC::ASTBuilder::Scope::Scope):
1970         (JSC::ASTBuilder::makeAssignNode):
1971         (JSC::ASTBuilder::varDeclarations): Deleted.
1972         (JSC::ASTBuilder::addVar): Deleted.
1973         * parser/Keywords.table:
1974         * parser/NodeConstructors.h:
1975         (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
1976         (JSC::AssignResolveNode::AssignResolveNode):
1977         (JSC::ExprStatementNode::ExprStatementNode):
1978         (JSC::DeclarationStatement::DeclarationStatement):
1979         (JSC::EmptyVarExpression::EmptyVarExpression):
1980         (JSC::EmptyLetExpression::EmptyLetExpression):
1981         (JSC::IfElseNode::IfElseNode):
1982         (JSC::WhileNode::WhileNode):
1983         (JSC::ForNode::ForNode):
1984         (JSC::CaseBlockNode::CaseBlockNode):
1985         (JSC::SwitchNode::SwitchNode):
1986         (JSC::ConstDeclNode::ConstDeclNode):
1987         (JSC::BlockNode::BlockNode):
1988         (JSC::EnumerationNode::EnumerationNode):
1989         (JSC::ForInNode::ForInNode):
1990         (JSC::ForOfNode::ForOfNode):
1991         (JSC::ObjectPatternNode::create):
1992         (JSC::BindingNode::create):
1993         (JSC::BindingNode::BindingNode):
1994         (JSC::VarStatementNode::VarStatementNode): Deleted.
1995         * parser/Nodes.cpp:
1996         (JSC::ScopeNode::ScopeNode):
1997         (JSC::ScopeNode::singleStatement):
1998         (JSC::ProgramNode::ProgramNode):
1999         (JSC::EvalNode::EvalNode):
2000         (JSC::FunctionNode::FunctionNode):
2001         (JSC::FunctionNode::finishParsing):
2002         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
2003         * parser/Nodes.h:
2004         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
2005         (JSC::VariableEnvironmentNode::lexicalVariables):
2006         (JSC::ScopeNode::usesThis):
2007         (JSC::ScopeNode::needsActivationForMoreThanVariables):
2008         (JSC::ScopeNode::needsActivation):
2009         (JSC::ScopeNode::hasCapturedVariables):
2010         (JSC::ScopeNode::captures):
2011         (JSC::ScopeNode::varDeclarations):
2012         (JSC::ScopeNode::functionStack):
2013         (JSC::ScopeNode::neededConstants):
2014         (JSC::ProgramNode::startColumn):
2015         (JSC::ProgramNode::endColumn):
2016         (JSC::EvalNode::startColumn):
2017         (JSC::EvalNode::endColumn):
2018         (JSC::BindingNode::boundProperty):
2019         (JSC::BindingNode::divotStart):
2020         (JSC::BindingNode::divotEnd):
2021         (JSC::ScopeNode::capturedVariableCount): Deleted.
2022         (JSC::ScopeNode::capturedVariables): Deleted.
2023         (JSC::ScopeNode::varStack): Deleted.
2024         There is a new class called 'VariableEnvironmentNode' that has the
2025         necessary fields to model a lexical scope. Multiple AST nodes now 
2026         also inherit from VariableEnvironmentNode.
2027
2028         * parser/Parser.cpp:
2029         (JSC::Parser<LexerType>::parseInner):
2030         (JSC::Parser<LexerType>::didFinishParsing):
2031         (JSC::Parser<LexerType>::parseStatementListItem):
2032         (JSC::Parser<LexerType>::parseVariableDeclaration):
2033         (JSC::Parser<LexerType>::parseWhileStatement):
2034         (JSC::Parser<LexerType>::parseVariableDeclarationList):
2035         (JSC::Parser<LexerType>::createBindingPattern):
2036         (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
2037         (JSC::Parser<LexerType>::parseDestructuringPattern):
2038         (JSC::Parser<LexerType>::parseConstDeclarationList):
2039         (JSC::Parser<LexerType>::parseForStatement):
2040         (JSC::Parser<LexerType>::parseBreakStatement):
2041         (JSC::Parser<LexerType>::parseContinueStatement):
2042         (JSC::Parser<LexerType>::parseSwitchStatement):
2043         (JSC::Parser<LexerType>::parseTryStatement):
2044         (JSC::Parser<LexerType>::parseBlockStatement):
2045         (JSC::Parser<LexerType>::parseStatement):
2046         (JSC::Parser<LexerType>::parseFunctionInfo):
2047         (JSC::Parser<LexerType>::parseClassDeclaration):
2048         (JSC::Parser<LexerType>::parseClass):
2049         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
2050         (JSC::Parser<LexerType>::parseAssignmentExpression):
2051         (JSC::Parser<LexerType>::parseGetterSetter):
2052         (JSC::Parser<LexerType>::parsePrimaryExpression):
2053         (JSC::Parser<LexerType>::parseVarDeclaration): Deleted.
2054         (JSC::Parser<LexerType>::parseVarDeclarationList): Deleted.
2055         * parser/Parser.h:
2056         (JSC::Scope::Scope):
2057         (JSC::Scope::setIsFunction):
2058         (JSC::Scope::isFunction):
2059         (JSC::Scope::isFunctionBoundary):
2060         (JSC::Scope::setIsLexicalScope):
2061         (JSC::Scope::isLexicalScope):
2062         (JSC::Scope::declaredVariables):
2063         (JSC::Scope::finalizeLexicalEnvironment):
2064         (JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates):
2065         (JSC::Scope::declareCallee):
2066         (JSC::Scope::declareVariable):
2067         (JSC::Scope::declareLexicalVariable):
2068         (JSC::Scope::hasDeclaredVariable):
2069         (JSC::Scope::hasLexicallyDeclaredVariable):
2070         (JSC::Scope::hasDeclaredParameter):
2071         (JSC::Scope::declareWrite):
2072         (JSC::Scope::preventAllVariableDeclarations):
2073         (JSC::Scope::preventVarDeclarations):
2074         (JSC::Scope::allowsVarDeclarations):
2075         (JSC::Scope::allowsLexicalDeclarations):
2076         (JSC::Scope::declareParameter):
2077         (JSC::Scope::declareBoundParameter):
2078         (JSC::Scope::useVariable):
2079         (JSC::Scope::setNeedsFullActivation):
2080         (JSC::Scope::needsFullActivation):
2081         (JSC::Scope::hasDirectSuper):
2082         (JSC::Scope::setNeedsSuperBinding):
2083         (JSC::Scope::collectFreeVariables):
2084         (JSC::Scope::getCapturedVars):
2085         (JSC::Scope::copyCapturedVariablesToVector):
2086         (JSC::Parser::AutoCleanupLexicalScope::AutoCleanupLexicalScope):
2087         (JSC::Parser::AutoCleanupLexicalScope::~AutoCleanupLexicalScope):
2088         (JSC::Parser::AutoCleanupLexicalScope::setIsValid):
2089         (JSC::Parser::AutoCleanupLexicalScope::isValid):
2090         (JSC::Parser::AutoCleanupLexicalScope::setPopped):
2091         (JSC::Parser::AutoCleanupLexicalScope::scope):
2092         (JSC::Parser::currentScope):
2093         (JSC::Parser::pushScope):
2094         (JSC::Parser::popScopeInternal):
2095         (JSC::Parser::popScope):
2096         (JSC::Parser::declareVariable):
2097         (JSC::Parser::hasDeclaredVariable):
2098         (JSC::Parser::hasDeclaredParameter):
2099         (JSC::Parser::declareWrite):
2100         (JSC::Parser::findCachedFunctionInfo):
2101         (JSC::Parser::isFunctionBodyNode):
2102         (JSC::Parser::continueIsValid):
2103         (JSC::Parser::pushLabel):
2104         (JSC::Parser::popLabel):
2105         (JSC::Parser::getLabel):
2106         (JSC::Parser::isLETMaskedAsIDENT):
2107         (JSC::Parser<LexerType>::parse):
2108         (JSC::Scope::preventNewDecls): Deleted.
2109         (JSC::Scope::allowsNewDecls): Deleted.
2110         (JSC::Scope::getCapturedVariables): Deleted.
2111         There are basic parser changes that now allow for the 'let'
2112         keyword. The trickiest change is how we will still treat 'let' 
2113         as an identifier for sloppy-mode code sometimes. For example,
2114         "var let = ..." is allowed but "let let" or "const let" is not.
2115
2116         The most significant change to the parser made for this patch
2117         is appropriating the Scope struct to also also model a lexical 
2118         scope. Changes were made in how we track captured variables to 
2119         account for this. In general, I think some of this code could 
2120         benefit from a slight refactoring to make things cleaner.
2121
2122         * parser/ParserTokens.h:
2123         * parser/SyntaxChecker.h:
2124         (JSC::SyntaxChecker::createNewExpr):
2125         (JSC::SyntaxChecker::createConditionalExpr):
2126         (JSC::SyntaxChecker::createAssignResolve):
2127         (JSC::SyntaxChecker::createEmptyVarExpression):
2128         (JSC::SyntaxChecker::createEmptyLetExpression):
2129         (JSC::SyntaxChecker::createClassExpr):
2130         (JSC::SyntaxChecker::createClassDeclStatement):
2131         (JSC::SyntaxChecker::createBlockStatement):
2132         (JSC::SyntaxChecker::createExprStatement):
2133         (JSC::SyntaxChecker::createIfStatement):
2134         (JSC::SyntaxChecker::createForLoop):
2135         (JSC::SyntaxChecker::createForInLoop):
2136         (JSC::SyntaxChecker::createForOfLoop):
2137         (JSC::SyntaxChecker::createEmptyStatement):
2138         (JSC::SyntaxChecker::createVarStatement):
2139         (JSC::SyntaxChecker::createLetStatement):
2140         (JSC::SyntaxChecker::createReturnStatement):
2141         (JSC::SyntaxChecker::createBreakStatement):
2142         (JSC::SyntaxChecker::createContinueStatement):
2143         (JSC::SyntaxChecker::createTryStatement):
2144         (JSC::SyntaxChecker::createSwitchStatement):
2145         (JSC::SyntaxChecker::createWhileStatement):
2146         (JSC::SyntaxChecker::createWithStatement):
2147         (JSC::SyntaxChecker::createDoWhileStatement):
2148         (JSC::SyntaxChecker::createGetterOrSetterProperty):
2149         (JSC::SyntaxChecker::appendStatement):
2150         (JSC::SyntaxChecker::combineCommaNodes):
2151         (JSC::SyntaxChecker::evalCount):
2152         (JSC::SyntaxChecker::appendBinaryExpressionInfo):
2153         (JSC::SyntaxChecker::operatorStackPop):
2154         (JSC::SyntaxChecker::addVar): Deleted.
2155         * parser/VariableEnvironment.cpp: Added.
2156         (JSC::VariableEnvironment::markVariableAsCapturedIfDefined):
2157         (JSC::VariableEnvironment::markVariableAsCaptured):
2158         (JSC::VariableEnvironment::markAllVariablesAsCaptured):
2159         (JSC::VariableEnvironment::hasCapturedVariables):
2160         (JSC::VariableEnvironment::captures):
2161         (JSC::VariableEnvironment::swap):
2162         * parser/VariableEnvironment.h: Added.
2163         (JSC::VariableEnvironmentEntry::isCaptured):
2164         (JSC::VariableEnvironmentEntry::isConstant):
2165         (JSC::VariableEnvironmentEntry::isVar):
2166         (JSC::VariableEnvironmentEntry::isLet):
2167         (JSC::VariableEnvironmentEntry::setIsCaptured):
2168         (JSC::VariableEnvironmentEntry::setIsConstant):
2169         (JSC::VariableEnvironmentEntry::setIsVar):
2170         (JSC::VariableEnvironmentEntry::setIsLet):
2171         (JSC::VariableEnvironmentEntry::clearIsVar):
2172         (JSC::VariableEnvironment::begin):
2173         (JSC::VariableEnvironment::end):
2174         (JSC::VariableEnvironment::add):
2175         (JSC::VariableEnvironment::size):
2176         (JSC::VariableEnvironment::contains):
2177         (JSC::VariableEnvironment::remove):
2178         VariableEnvironment is a new class that keeps track
2179         of the static environment in the parser and the bytecode generator.
2180         VariableEnvironment behaves like SymbolTable but for the bytecode generator.
2181         It keeps track of variable types, i.e, if a variable is a "var", "let", "const" 
2182         and whether or not its captured.
2183
2184         * runtime/CodeCache.cpp:
2185         (JSC::CodeCache::getGlobalCodeBlock):
2186         (JSC::CodeCache::getProgramCodeBlock):
2187         (JSC::CodeCache::getEvalCodeBlock):
2188         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
2189         * runtime/CodeCache.h:
2190         (JSC::CodeCache::clear):
2191         * runtime/CommonSlowPaths.cpp:
2192         (JSC::SLOW_PATH_DECL):
2193         * runtime/CommonSlowPaths.h:
2194         * runtime/ExceptionHelpers.cpp:
2195         (JSC::createErrorForInvalidGlobalAssignment):
2196         (JSC::createTDZError):
2197         (JSC::throwOutOfMemoryError):
2198         * runtime/ExceptionHelpers.h:
2199         * runtime/Executable.cpp:
2200         (JSC::EvalExecutable::create):
2201         (JSC::ProgramExecutable::initializeGlobalProperties):
2202         * runtime/Executable.h:
2203         * runtime/JSCJSValue.h:
2204         (JSC::jsUndefined):
2205         (JSC::jsTDZValue):
2206         (JSC::jsBoolean):
2207         * runtime/JSEnvironmentRecord.h:
2208         (JSC::JSEnvironmentRecord::finishCreationUninitialized):
2209         (JSC::JSEnvironmentRecord::finishCreation):
2210         * runtime/JSGlobalObject.cpp:
2211         (JSC::JSGlobalObject::createProgramCodeBlock):
2212         (JSC::JSGlobalObject::createEvalCodeBlock):
2213         * runtime/JSGlobalObject.h:
2214         (JSC::JSGlobalObject::weakRandomInteger):
2215         * runtime/JSGlobalObjectFunctions.cpp:
2216         (JSC::globalFuncEval):
2217         * runtime/JSLexicalEnvironment.cpp:
2218         (JSC::JSLexicalEnvironment::symbolTableGet):
2219         * runtime/JSLexicalEnvironment.h:
2220         (JSC::JSLexicalEnvironment::create):
2221         * runtime/JSScope.cpp:
2222         (JSC::JSScope::resolve):
2223         (JSC::JSScope::abstractResolve):
2224         (JSC::JSScope::collectVariablesUnderTDZ):
2225         (JSC::JSScope::isLexicalScope):
2226         (JSC::resolveModeName):
2227         * runtime/JSScope.h:
2228         * runtime/PropertySlot.h:
2229         (JSC::PropertySlot::setValue):
2230         * runtime/SymbolTable.cpp:
2231         (JSC::SymbolTable::SymbolTable):
2232         (JSC::SymbolTable::cloneScopePart):
2233         * runtime/SymbolTable.h:
2234         SymbolTable now uses an extra bit to know if it corresponds
2235         to a "let"-like environment or not.
2236
2237         * runtime/WriteBarrier.h:
2238         (JSC::WriteBarrierBase<Unknown>::get):
2239         (JSC::WriteBarrierBase<Unknown>::clear):
2240         (JSC::WriteBarrierBase<Unknown>::setUndefined):
2241         (JSC::WriteBarrierBase<Unknown>::setStartingValue):
2242         (JSC::WriteBarrierBase<Unknown>::isNumber):
2243         (JSC::WriteBarrierBase<Unknown>::isObject):
2244         (JSC::WriteBarrierBase<Unknown>::isNull):
2245         * tests/stress/activation-sink-default-value-tdz-error.js: Added.
2246         (shouldThrowTDZ):
2247         (bar):
2248         (foo.cap):
2249         * tests/stress/activation-sink-osrexit-default-value-tdz-error.js: Added.
2250         (shouldThrowTDZ):
2251         (bar):
2252         * tests/stress/lexical-let-and-with-statement.js: Added.
2253         (truth):
2254         (assert):
2255         (.):
2256         * tests/stress/lexical-let-exception-handling.js: Added.
2257         (truth):
2258         (assert):
2259         (.):
2260         * tests/stress/lexical-let-global-not-captured-variables.js: Added.
2261         (truth):
2262         (assert):
2263         (foo):
2264         (.let.capY):
2265         * tests/stress/lexical-let-loop-semantics.js: Added.
2266         (truth):
2267         (assert):
2268         (shouldThrowTDZ):
2269         (.):
2270         * tests/stress/lexical-let-not-strict-mode.js: Added.
2271         (truth):
2272         (assert):
2273         (shouldThrowTDZ):
2274         (.):
2275         * tests/stress/lexical-let-semantics.js: Added.
2276         (truth):
2277         (assert):
2278         (let.globalFunction):
2279         (let.retGlobalNumberCaptured):
2280         (let.setGlobalNumberCaptured):
2281         (.):
2282         * tests/stress/lexical-let-tdz.js: Added.
2283         (truth):
2284         (assert):
2285         (shouldThrowTDZ):
2286         (.):
2287
2288 2015-07-15  Anders Carlsson  <andersca@apple.com>
2289
2290         Make JavaScriptCore SPI headers used by WebCore SPI headers self-contained
2291         https://bugs.webkit.org/show_bug.cgi?id=146978
2292
2293         Reviewed by Dan Bernstein.
2294
2295         * debugger/DebuggerPrimitives.h:
2296         * disassembler/Disassembler.h:
2297         * heap/Weak.h:
2298         * inspector/InspectorValues.h:
2299         * runtime/JSCJSValue.h:
2300
2301 2015-07-14  Anders Carlsson  <andersca@apple.com>
2302
2303         Assertions.h should include ExportMacros.h
2304         https://bugs.webkit.org/show_bug.cgi?id=146948
2305
2306         Reviewed by Tim Horton.
2307
2308         Remove now unneeded WTF_EXPORT_PRIVATE define.
2309
2310         * API/JSBase.h:
2311
2312 2015-07-14  Matthew Mirman  <mmirman@apple.com>
2313
2314         Repatch. Makes compileArithSub in the DFG ensure that the constant is an int32.
2315         https://bugs.webkit.org/show_bug.cgi?id=146910
2316         rdar://problem/21729083
2317
2318         Reviewed by Filip Pizlo.
2319         
2320         Also fixes the debug build problem where all edges are assumed to 
2321         have UntypedUse before the fixup phase.
2322
2323         * dfg/DFGSpeculativeJIT.cpp:
2324         (JSC::DFG::SpeculativeJIT::compileArithSub):
2325         * dfg/DFGValidate.cpp:
2326         (JSC::DFG::Validate::validateEdgeWithDoubleResultIfNecessary):
2327         * tests/stress/arith-add-with-constants.js: Added some tests for this case.
2328         (arithAdd42WrittenAsInteger):
2329         (testArithAdd42WrittenAsInteger):
2330         (arithSub42WrittenAsDouble):
2331         (testArithSub42WrittenAsDouble):
2332         (doubleConstant):
2333         (testDoubleConstant): Added test for the case of +0.0 and Math.min(0.0)
2334         (arithAdd42WrittenAsDouble): Deleted.
2335         (testArithAdd42WrittenAsDouble): Deleted.
2336
2337 2015-07-14  Matthew Mirman  <mmirman@apple.com>
2338
2339         Unreviewed, rolling out r186805.
2340
2341         Made raytracer on octane 80% slower
2342
2343         Reverted changeset:
2344
2345         "Makes compileArithSub in the DFG ensure that the constant is
2346         an int32."
2347         https://bugs.webkit.org/show_bug.cgi?id=146910
2348         http://trac.webkit.org/changeset/186805
2349
2350 2015-07-13  Matthew Mirman  <mmirman@apple.com>
2351
2352         Makes compileArithSub in the DFG ensure that the constant is an int32.
2353         https://bugs.webkit.org/show_bug.cgi?id=146910
2354         rdar://problem/21729083
2355
2356         Reviewed by Filip Pizlo.
2357         
2358         Also fixes the debug build problem where all edges are assumed to 
2359         have UntypedUse before the fixup phase.
2360
2361         * dfg/DFGSpeculativeJIT.cpp:
2362         (JSC::DFG::SpeculativeJIT::compileArithSub):
2363         * dfg/DFGValidate.cpp:
2364         (JSC::DFG::Validate::validateEdgeWithDoubleResultIfNecessary):
2365         * tests/stress/arith-add-with-constants.js: Added some tests for this case.
2366         (arithAdd42WrittenAsInteger):
2367         (testArithAdd42WrittenAsInteger):
2368         (arithSub42WrittenAsDouble):
2369         (testArithSub42WrittenAsDouble):
2370         (doubleConstant):
2371         (testDoubleConstant): Added test for the case of +0.0 and Math.min(0.0)
2372         (arithAdd42WrittenAsDouble): Deleted.
2373         (testArithAdd42WrittenAsDouble): Deleted.
2374
2375 2015-07-13  Basile Clement  <basile_clement@apple.com>
2376
2377         Object cycles should not prevent allocation elimination/sinking
2378         https://bugs.webkit.org/show_bug.cgi?id=143073
2379
2380         Reviewed by Filip Pizlo.
2381
2382         This patch introduces a new allocation sinking phase that is able to
2383         sink cycles, in DFGAllocationCycleSinkingPhase.cpp. This phase
2384         supersedes the old allocation sinking phase in
2385         DFGObjectAllocationSinkingPhase.cpp, as that previous phase was never
2386         able to sink allocation cycles while the new phase sometimes can; see
2387         DFGAllocationCycleSinkingPhase.cpp for details.
2388
2389         For now, the new sinking phase is kept behind a
2390         JSC_enableAllocationCycleSinking flag that reverts to the old sinking
2391         phase when false (i.e., by default). This also removes the old
2392         JSC_enableObjectAllocationSinking flag. run-javascriptcore-tests
2393         defaults to using the new sinking phase.
2394
2395         * dfg/DFGGraph.h:
2396         (JSC::DFG::Graph::addStructureSet): Allow empty structure sets
2397         * dfg/DFGLazyNode.cpp:
2398         (JSC::DFG::LazyNode::dump): Prettier dump
2399         * dfg/DFGNode.h:
2400         (JSC::DFG::Node::cellOperand): Move to opInfo for MaterializeCreateActivation
2401         (JSC::DFG::Node::hasStructureSet): Add MaterializeNewObject
2402         (JSC::DFG::Node::objectMaterializationData): Move to opInfo2
2403         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: Remove unused header
2404         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2405         (JSC::DFG::ObjectAllocationSinkingPhase::ObjectAllocationSinkingPhase): Deleted.
2406         (JSC::DFG::ObjectAllocationSinkingPhase::run): Deleted.
2407         (JSC::DFG::ObjectAllocationSinkingPhase::performSinking): Deleted.
2408         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints): Deleted.
2409         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints): Deleted.
2410         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations): Deleted.
2411         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields): Deleted.
2412         (JSC::DFG::ObjectAllocationSinkingPhase::resolve): Deleted.
2413         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode): Deleted.
2414         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize): Deleted.
2415         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize): Deleted.
2416         * dfg/DFGObjectAllocationSinkingPhase.h:
2417         * dfg/DFGPromotedHeapLocation.h: Add a hash and a helper function to PromotedLocationDescriptor
2418         (JSC::DFG::PromotedLocationDescriptor::PromotedLocationDescriptor):
2419         (JSC::DFG::PromotedLocationDescriptor::operator bool):
2420         (JSC::DFG::PromotedLocationDescriptor::neededForMaterialization):
2421         (JSC::DFG::PromotedLocationDescriptorHash::hash):
2422         (JSC::DFG::PromotedLocationDescriptorHash::equal):
2423         * dfg/DFGValidate.cpp:
2424         (JSC::DFG::Validate::validateSSA): Assert that most nodes never see a phantom allocation
2425         * ftl/FTLLowerDFGToLLVM.cpp:
2426         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeNewObject): Use the new structureSet() operand
2427         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation): Node has a new child
2428         * ftl/FTLOSRExitCompiler.cpp: Handle materialization cycles
2429         (JSC::FTL::compileStub):
2430         * ftl/FTLOperations.cpp: Handle materialization cycles
2431         (JSC::FTL::operationPopulateObjectInOSR):
2432         (JSC::FTL::operationMaterializeObjectInOSR):
2433         * ftl/FTLOperations.h: Handle materialization cycles
2434         * tests/stress/correctly-sink-object-even-though-it-dies.js: Added.
2435         (clobber):
2436         (foo):
2437         * tests/stress/eliminate-object-read-over-call.js: Added.
2438         (clobber):
2439         (foo):
2440         * tests/stress/materialize-object-on-edge.js: Added.
2441         (call):
2442         (foo):
2443         * tests/stress/object-sinking-stress.js: Added.
2444         (foo):
2445         * tests/stress/sink-object-cycle.js: Added.
2446         (clobber):
2447         (foo):
2448         * tests/stress/sink-object-past-put.js: Added.
2449         (clobber):
2450         (foo):
2451         * tests/stress/sinkable-new-object-in-loop.js: Added.
2452         (foo):
2453
2454 2015-07-13  Daniel Bates  <dabates@apple.com>
2455
2456         Cleanup: Avoid extraneous increment and decrement of reference count of ScriptArguments in ConsoleClient
2457         https://bugs.webkit.org/show_bug.cgi?id=146920
2458
2459         Reviewed by Brian Burg.
2460
2461         Remove local variable RefPtr<ScriptArguments> and copy constructor call with an argument that
2462         was initialized with an rvalue reference. The argument itself is an lvalue reference.
2463
2464         * runtime/ConsoleClient.cpp:
2465         (JSC::ConsoleClient::printConsoleMessageWithArguments):
2466         (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
2467
2468 2015-07-13  Anders Carlsson  <andersca@apple.com>
2469
2470         Apps linked with a deployment target of iOS 7.x or earlier crash when using modern WebKit API
2471         https://bugs.webkit.org/show_bug.cgi?id=146913
2472         rdar://problem/21789252
2473
2474         Reviewed by Dan Bernstein.
2475
2476         Make a top-level symlink from /System/Library/PrivateFrameworks/JavaScriptCore.framework to
2477         /System/Library/Frameworks/JavaScriptCore.framework.
2478     
2479         * JavaScriptCore.xcodeproj/project.pbxproj:
2480
2481 2015-07-12  Filip Pizlo  <fpizlo@apple.com>
2482
2483         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
2484         https://bugs.webkit.org/show_bug.cgi?id=146897
2485
2486         Reviewed by Mark Lam.
2487         
2488         The idea is to eventually support adaptive watchpoints. An adaptive watchpoint will be
2489         able to watch for a condition that is more fine-grained than any one watchpoint set. For
2490         example, we might watch a singleton object to see if it ever acquires a property called
2491         "foo". So long as it doesn't have such a property, we don't want to invalidate any code.
2492         But if it gets that property, then we should deoptimize. Current watchpoints will
2493         invalidate code as soon as any property is added (or deleted), because they will use the
2494         transition watchpoint set of the singleton object's structure, and that fires anytime
2495         there is any transition.
2496         
2497         An adaptive watchpoint would remember the singleton object, and when it got fired, it
2498         would check if the object's new structure has the property "foo". If not, it would check
2499         if the object's new structure is watchable (i.e. has a valid transition watchpoint set).
2500         If the property is missing and the structure is watchable, it would add itself to the
2501         watchpoint set of the new structure. Otherwise, it would deoptimize.
2502         
2503         There are two problems with this idea, and this patch fixes these problems. First, we
2504         usually fire the transition watchpoint before we do the structure transition. This means
2505         that if the fire() method looked at the singleton object's structure, it would see the old
2506         structure, not the new one. It would have no way of knowing what the new structure is.
2507         Second, inside the fire() method, the watchpoint set being invalidated still appears
2508         valid, since we change the state after we fire all watchpoints.
2509         
2510         This patch addresses both issues. Now, in the most important case (addPropertyTransition),
2511         we fire the watchpoint set after we have modified the object. This is accomplished using
2512         a deferral scope called DeferredStructureTransitionWatchpointFire. In cases where there is
2513         no deferral, the adaptive watchpoint will conservatively resort to deoptimization because
2514         it would find that the singleton object's structure is no longer watchable. This is
2515         because in the absence of deferral, the singleton object would still have the original
2516         structure, but that structure's watchpoint set would now report itself as having been
2517         invalidated.
2518
2519         * bytecode/Watchpoint.cpp:
2520         (JSC::WatchpointSet::fireAllSlow): Change the state of the set before firing all watchpoints.
2521         (JSC::WatchpointSet::fireAllWatchpoints):
2522         * runtime/JSObject.h:
2523         (JSC::JSObject::putDirectInternal): Use the deferral scope.
2524         * runtime/Structure.cpp:
2525         (JSC::Structure::Structure): Pass the deferral scope to didTransitionFromThisStructure.
2526         (JSC::Structure::addPropertyTransition): Pass the deferral scope to create().
2527         (JSC::StructureFireDetail::dump): This is no longer anonymous.
2528         (JSC::DeferredStructureTransitionWatchpointFire::DeferredStructureTransitionWatchpointFire): Start with a null structure.
2529         (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire): Fire the watchpoint if there is a structure.
2530         (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).
2531         (JSC::Structure::didTransitionFromThisStructure): Defer the watchpoint firing if there is a deferral scope.
2532         * runtime/Structure.h:
2533         (JSC::StructureFireDetail::StructureFireDetail): Move this to the header.
2534         * runtime/StructureInlines.h:
2535         (JSC::Structure::create): Pass the deferral scope to the constructor.
2536
2537 2015-07-12  Filip Pizlo  <fpizlo@apple.com>
2538
2539         Watchpoints should be removed from their owning WatchpointSet before they are fired
2540         https://bugs.webkit.org/show_bug.cgi?id=146895
2541
2542         Reviewed by Sam Weinig.
2543         
2544         This simplifies the WatchpointSet API by making it so that when Watchpoint::fire() is
2545         called, the Watchpoint is no longer in the set. This means that you don't have to remember
2546         to remove it from the set's list (currently we do that implicitly as part of whatever
2547         any particular Watchpoint::fireInternal() does), and you can now write adaptive
2548         watchpoints that re-add themselves to a different set if they determine that the thing
2549         they are actually watching is still intact but now needs to be watched in a different way
2550         (like watching for whether some singleton object has a property of some name).
2551
2552         * bytecode/Watchpoint.cpp:
2553         (JSC::Watchpoint::~Watchpoint): Add a comment about why this is necessary.
2554         (JSC::Watchpoint::fire): Make this out-of-line, private, and make it assert that we're no longer on the list.
2555         (JSC::WatchpointSet::fireAllWatchpoints): Make this remove the watchpoint from the list before firing it.
2556         * bytecode/Watchpoint.h:
2557         (JSC::Watchpoint::fire): Deleted. I moved this to Watchpoint.cpp.
2558
2559 2015-07-10  Filip Pizlo  <fpizlo@apple.com>
2560
2561         DFG::DesiredWatchpoints should accept WatchpointSetType's that aren't necessarily pointers
2562         https://bugs.webkit.org/show_bug.cgi?id=146875
2563
2564         Reviewed by Dan Bernstein.
2565         
2566         In the future we'll want to add a desired watchpoint set that's something like "please
2567         watch property 'Foo' for 'deletion' on structure 'S1'", so that the "set type" is struct
2568         like "struct MySet { StringImpl* property; Mode mode; Structure* structure };".
2569         
2570         This is a very mechanical change for now - all of the current users happen to use sets
2571         that are pointer typed, so it's just a matter of moving some "*"'s around.
2572
2573         * dfg/DFGDesiredWatchpoints.h:
2574         (JSC::DFG::GenericSetAdaptor::add):
2575         (JSC::DFG::GenericSetAdaptor::hasBeenInvalidated):
2576         (JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints):
2577         (JSC::DFG::GenericDesiredWatchpoints::addLazily):
2578         (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
2579         (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
2580         (JSC::DFG::GenericDesiredWatchpoints::isWatched):
2581         (JSC::DFG::DesiredWatchpoints::isWatched):
2582
2583 2015-07-10  Filip Pizlo  <fpizlo@apple.com>
2584
2585         Watchpoints should be allocated with FastMalloc
2586         https://bugs.webkit.org/show_bug.cgi?id=146874
2587
2588         Reviewed by Dan Bernstein.
2589         
2590         This is in preparation for adding new subclasses of Watchpoint. While starting to do this
2591         I realized that the way Watchpoints allocated themselves was unusual.
2592
2593         * bytecode/CodeBlockJettisoningWatchpoint.h:
2594         (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): No need for the default constructor.
2595         * bytecode/Watchpoint.h:
2596         (JSC::Watchpoint::Watchpoint): This should be noncopyable and fast-allocated.
2597         * 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.
2598         * dfg/DFGDesiredWatchpoints.h:
2599         (JSC::DFG::GenericDesiredWatchpoints::reallyAdd): Use the Bag<> API rather than the very awkward SegmentedVector<> API.
2600
2601 2015-07-10  Filip Pizlo  <fpizlo@apple.com>
2602
2603         AI folding of IsObjectOrNull is broken for non-object types that may be null
2604         https://bugs.webkit.org/show_bug.cgi?id=146867
2605
2606         Reviewed by Ryosuke Niwa.
2607
2608         * dfg/DFGAbstractInterpreterInlines.h:
2609         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Fix the bug and add some text describing what is going on.
2610         * tests/stress/misc-is-object-or-null.js: Added. Test for the bug.
2611         (foo):
2612         * tests/stress/other-is-object-or-null.js: Added. Test for a bug I almost introduced.
2613         (foo):
2614
2615 2015-07-10  Filip Pizlo  <fpizlo@apple.com>
2616
2617         It should be easy to measure total compile times.
2618         https://bugs.webkit.org/show_bug.cgi?id=146857
2619
2620         Reviewed by Sam Weinig.
2621         
2622         This gives DFG::Plan the ability to track total compile times, and return them in a map
2623         of stats that jsc.cpp can display.
2624         
2625         I want to do some work to bring down DFG compile times. This will help me measure whether
2626         I'm making a difference or not.
2627
2628         * dfg/DFGPlan.cpp:
2629         (JSC::DFG::Plan::Plan):
2630         (JSC::DFG::Plan::~Plan):
2631         (JSC::DFG::Plan::computeCompileTimes):
2632         (JSC::DFG::Plan::reportCompileTimes):
2633         (JSC::DFG::Plan::compileInThread):
2634         (JSC::DFG::Plan::compileInThreadImpl):
2635         (JSC::DFG::Plan::cancel):
2636         (JSC::DFG::Plan::compileTimeStats):
2637         (JSC::DFG::dumpAndVerifyGraph): Deleted.
2638         (JSC::DFG::profilerCompilationKindForMode): Deleted.
2639         * dfg/DFGPlan.h:
2640         (JSC::DFG::Plan::compileTimeStats):
2641         * jsc.cpp:
2642         (jscmain):
2643         * runtime/Options.h:
2644
2645 2015-07-04  Filip Pizlo  <fpizlo@apple.com>
2646
2647         DFG fragile frozen values are fundamentally broken
2648         https://bugs.webkit.org/show_bug.cgi?id=146602
2649
2650         Reviewed by Mark Lam.
2651         
2652         This change gets rid of the FragileValue value strength, because it was fundamentally
2653         broken.
2654         
2655         FragileValue was a value known to the compiler but not tracked by the GC in any way -
2656         it wasn't marked and it wasn't weak. This was used to support AI bootstrap for OSR
2657         must-handle values. The philosophy was that if the compiler did use the value for
2658         optimization, it would have been strengthened to a weak value (or maybe even a strong
2659         value, though we probably won't do that). But this was too much of a pipe dream. I've
2660         found at least one case where the compiler did use the value, but never strengthened
2661         it: it would happen if the value ended up in an OSR entry data expected value. Then if
2662         we GCed, we might have killed the value, but OSR entry would still try to use it for
2663         validation. That might have sort of just worked, but it's clearly shady.
2664
2665         The reason why we made must-handle values fragile and not weak is that most of the time
2666         the values disappear from the abstract state: they are LUBed to a non-constant. If we
2667         kept them around as weak, we'd have too many cases of the GC killing the code because
2668         it thought that the value was somehow meaningful to the code when it was only used as a
2669         temporary artifact of optimization.
2670
2671         So, it's true that it's very important for must-handle values not to automatically be
2672         weak or strong. It's also true that the values are necessary for AI bootstrap because
2673         we need to know what values OSR entry will require. But we shouldn't accomplish these
2674         goals by having the compiler hold onto what are essentially dangling pointers.
2675         
2676         This implements a better solution: instead of having InPlaceAbstractState bootstrap the
2677         AI with must-handle values at the beginning, we now widen the valuesAtHead of the
2678         must-handle block after AI converges. This widening is done in CFAPhase. This allows us
2679         to see if the must-handle values are necessary at all. In most cases, the widening
2680         takes a non-constant abstract value and simply amends something to its type based on
2681         the type of the must-handle value, and so the must-handle value never actually shows up
2682         in either the IR or any abstract value. In the unlikely event that the value at head is
2683         bottom, we freeze the must-handle value. This change removes FragileValue, and this
2684         freezing uses WeakValue as the strength. That makes sense: since the abstract value was
2685         bottom, the must-handle value becomes integral to the IR and so it makes no sense for
2686         the GC to keep the resulting CodeBlock alive if that must-handle value dies. This will
2687         sometimes happen for example if you have a very long-running loop whose pre-header
2688         allocates some object, but that pre-header appears to always exit to the optimizing JIT
2689         because it was only profiled once in the LLInt and that profiling appears insufficient
2690         to the DFG. In that case, we'll effectively constant-fold the references to the object
2691         inside the loop, which is both efficient (yay constant folding!) and necessary
2692         (otherwise we wouldn't know what the type of the variable should have been).
2693         
2694         Testing and debugging this is complicated. So, this adds some new capabilities:
2695         
2696         - DFG IR dumps also dump all of the FrozenValues that point to the heap along with
2697           their strengths, so that it's easy to see what GC objects the DFG feels are necessary
2698           for the compilation.
2699         
2700         - DFG OSR entry preparation prints out the OSR entry data structures, so that it's easy
2701           to see what GC pointers (and other things) are used for OSR entry validation. The
2702           printouts are quite detailed, and should also help other kinds of OSR entry
2703           debugging.
2704         
2705         - DFG::Plan now validates whether all of the GC pointers planted in the various JITCode
2706           data structures are also properly registered as either weak or strong pointers in the
2707           CodeBlock. This validation check previously failed due to fragile values ending up in
2708           the OSR entry data structures, both in the newly added test (dead-osr-entry-value.js)
2709           and in some pre-existing tests (like earley-boyer and 3d-raytrace).
2710
2711         * CMakeLists.txt:
2712         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2713         * JavaScriptCore.xcodeproj/project.pbxproj:
2714         * bytecode/CodeBlock.cpp:
2715         (JSC::CodeBlock::stronglyVisitStrongReferences):
2716         * bytecode/CodeOrigin.cpp:
2717         (JSC::InlineCallFrame::visitAggregate):
2718         * bytecode/Operands.h:
2719         (JSC::Operands::operand):
2720         (JSC::Operands::hasOperand):
2721         * bytecode/StructureSet.cpp:
2722         (JSC::StructureSet::dump):
2723         (JSC::StructureSet::validateReferences):
2724         * bytecode/StructureSet.h:
2725         * bytecode/TrackedReferences.cpp: Added.
2726         (JSC::TrackedReferences::TrackedReferences):
2727         (JSC::TrackedReferences::~TrackedReferences):
2728         (JSC::TrackedReferences::add):
2729         (JSC::TrackedReferences::check):
2730         (JSC::TrackedReferences::dump):
2731         * bytecode/TrackedReferences.h: Added.
2732         * dfg/DFGAbstractValue.cpp:
2733         (JSC::DFG::AbstractValue::observeTransitions):
2734         (JSC::DFG::AbstractValue::set):
2735         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
2736         (JSC::DFG::AbstractValue::mergeOSREntryValue):
2737         (JSC::DFG::AbstractValue::filter):
2738         (JSC::DFG::AbstractValue::dumpInContext):
2739         (JSC::DFG::AbstractValue::validateReferences):
2740         (JSC::DFG::AbstractValue::setOSREntryValue): Deleted.
2741         * dfg/DFGAbstractValue.h:
2742         (JSC::DFG::AbstractValue::fullTop):
2743         (JSC::DFG::AbstractValue::merge):
2744         * dfg/DFGByteCodeParser.cpp:
2745         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2746         * dfg/DFGCFAPhase.cpp:
2747         (JSC::DFG::CFAPhase::run):
2748         * dfg/DFGCommonData.cpp:
2749         (JSC::DFG::CommonData::invalidate):
2750         (JSC::DFG::CommonData::validateReferences):
2751         * dfg/DFGCommonData.h:
2752         (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit):
2753         * dfg/DFGFrozenValue.h:
2754         (JSC::DFG::FrozenValue::FrozenValue):
2755         (JSC::DFG::FrozenValue::strengthenTo):
2756         (JSC::DFG::FrozenValue::pointsToHeap):
2757         (JSC::DFG::FrozenValue::strength):
2758         (JSC::DFG::FrozenValue::freeze):
2759         * dfg/DFGGraph.cpp:
2760         (JSC::DFG::Graph::Graph):
2761         (JSC::DFG::Graph::dump):
2762         (JSC::DFG::Graph::registerFrozenValues):
2763         (JSC::DFG::Graph::visitChildren):
2764         (JSC::DFG::Graph::freeze):
2765         (JSC::DFG::Graph::freezeStrong):
2766         (JSC::DFG::Graph::freezeFragile): Deleted.
2767         * dfg/DFGGraph.h:
2768         * dfg/DFGInPlaceAbstractState.cpp:
2769         (JSC::DFG::InPlaceAbstractState::initialize):
2770         * dfg/DFGJITCode.cpp:
2771         (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
2772         (JSC::DFG::JITCode::validateReferences):
2773         * dfg/DFGJITCode.h:
2774         * dfg/DFGJITCompiler.cpp:
2775         (JSC::DFG::JITCompiler::addressOfDoubleConstant):
2776         (JSC::DFG::JITCompiler::noticeOSREntry):
2777         * dfg/DFGJITCompiler.h:
2778         (JSC::DFG::JITCompiler::branchStructurePtr):
2779         (JSC::DFG::JITCompiler::jitCode):
2780         (JSC::DFG::JITCompiler::noticeOSREntry): Deleted.
2781         * dfg/DFGMinifiedGraph.cpp: Added.
2782         (JSC::DFG::MinifiedGraph::prepareAndShrink):
2783         (JSC::DFG::MinifiedGraph::validateReferences):
2784         * dfg/DFGMinifiedGraph.h:
2785         (JSC::DFG::MinifiedGraph::append):
2786         (JSC::DFG::MinifiedGraph::prepareAndShrink): Deleted.
2787         * dfg/DFGOSREntry.cpp:
2788         (JSC::DFG::OSREntryData::dumpInContext):
2789         (JSC::DFG::OSREntryData::dump):
2790         (JSC::DFG::prepareOSREntry):
2791         * dfg/DFGOSREntry.h:
2792         (JSC::DFG::getOSREntryDataBytecodeIndex):
2793         * dfg/DFGPlan.cpp:
2794         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
2795         * dfg/DFGSpeculativeJIT.cpp:
2796         (JSC::DFG::SpeculativeJIT::linkOSREntries):
2797         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
2798         * dfg/DFGStructureAbstractValue.cpp:
2799         (JSC::DFG::StructureAbstractValue::dump):
2800         (JSC::DFG::StructureAbstractValue::validateReferences):
2801         * dfg/DFGStructureAbstractValue.h:
2802         * dfg/DFGValidate.cpp:
2803         (JSC::DFG::Validate::validate):
2804         * dfg/DFGValueStrength.cpp:
2805         (WTF::printInternal):
2806         * dfg/DFGValueStrength.h:
2807         (JSC::DFG::merge):
2808         * ftl/FTLExitPropertyValue.cpp:
2809         (JSC::FTL::ExitPropertyValue::dump):
2810         (JSC::FTL::ExitPropertyValue::validateReferences):
2811         * ftl/FTLExitPropertyValue.h:
2812         * ftl/FTLExitTimeObjectMaterialization.cpp:
2813         (JSC::FTL::ExitTimeObjectMaterialization::dump):
2814         (JSC::FTL::ExitTimeObjectMaterialization::validateReferences):
2815         * ftl/FTLExitTimeObjectMaterialization.h:
2816         * ftl/FTLExitValue.cpp:
2817         (JSC::FTL::ExitValue::dump):
2818         (JSC::FTL::ExitValue::validateReferences):
2819         * ftl/FTLExitValue.h:
2820         * ftl/FTLJITCode.cpp:
2821         (JSC::FTL::JITCode::dfgCommon):
2822         (JSC::FTL::JITCode::validateReferences):
2823         * ftl/FTLJITCode.h:
2824         (JSC::FTL::JITCode::handles):
2825         (JSC::FTL::JITCode::dataSections):
2826         * ftl/FTLOSRExit.cpp:
2827         (JSC::FTL::OSRExit::codeLocationForRepatch):
2828         (JSC::FTL::OSRExit::validateReferences):
2829         * ftl/FTLOSRExit.h:
2830         (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
2831         * jit/JITCode.cpp:
2832         (JSC::JITCode::typeName):
2833         (JSC::JITCode::validateReferences):
2834         (JSC::JITCode::execute):
2835         * jit/JITCode.h:
2836         (JSC::JITCode::start):
2837         * tests/stress/dead-osr-entry-value.js: Added.
2838         (foo):
2839
2840 2015-07-09  Filip Pizlo  <fpizlo@apple.com>
2841
2842         It should be possible to run the OSR exit fuzzer
2843         https://bugs.webkit.org/show_bug.cgi?id=146814
2844
2845         Reviewed by Mark Lam.
2846         
2847         Fix a silly bug: the option matching was accidentally allowing a prefix match, which
2848         always did the wrong thing for --fireOSRExitFuzzAt and --fireOSRExitFuzzAtStatic. Make
2849         this an exact match instead.
2850
2851         * runtime/Options.cpp:
2852         (JSC::Options::setOption):
2853
2854 2015-07-09  Mark Lam  <mark.lam@apple.com>
2855
2856         SymbolTable::entryFor() should do a bounds check before indexing into the localToEntry vector.
2857         https://bugs.webkit.org/show_bug.cgi?id=146807
2858
2859         Reviewed by Filip Pizlo.
2860
2861         When we capture an argument by name and we use "arguments", we put all of the
2862         arguments into the scope.  But destructured arguments are put into the scope
2863         anonymously i.e. the SymbolTable knows that the scope offset is in use via
2864         SymbolTable::m_maxScopeOffset, but that ScopeOffset won't appear in
2865         SymbolTable::m_map.
2866
2867         The SymbolTable's m_localToEntry vector is synthesized from its m_map, and will
2868         have a size which is based on the largest ScopeOffset in the m_map.  If we have a
2869         scenario where the anonymous argument is at a higher ScopeOffset than all the
2870         named arguments, then the m_localsToEntry vector will not have an entry for it
2871         i.e. the m_localsToEntry vector will have a size that is <= the ScopeOffset of
2872         the anonymous argument.
2873
2874         Hence, SymbolTable::entryFor() should ensure that the requested ScopeOffset is
2875         within the bounds of the m_localToEntry vector before indexing into it.
2876
2877         * runtime/SymbolTable.cpp:
2878         (JSC::SymbolTable::entryFor):
2879
2880 2015-07-09  Michael Saboff  <msaboff@apple.com>
2881
2882         REGRESSION (r180248): Repro Crash: com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::createRangeError + 20
2883         https://bugs.webkit.org/show_bug.cgi?id=146767
2884
2885         Reviewed by Geoffrey Garen.
2886
2887         If the stack check fails at the top most frame, we must use that frame to
2888         generate the exception.  Reverted the code to always use the current frame to
2889         throw an out of stack exception.
2890
2891         * llint/LLIntSlowPaths.cpp:
2892         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2893
2894 2015-07-03  Filip Pizlo  <fpizlo@apple.com>
2895
2896         OSR exit fuzzing should allow us to select a static exit site
2897         https://bugs.webkit.org/show_bug.cgi?id=146601
2898
2899         Reviewed by Geoffrey Garen.
2900         
2901         The original implementation of the fuzzer allows us to trigger an exit based on its index
2902         in the dynamic sequence of exit sites encountered. But there are usually millions of
2903         dynamically encountered exit sites, even if the program only has thousands of static exit
2904         sites. That means that we would at best be able to do a random sampling of exits, and
2905         those would be biased to the hottest exit sites.
2906         
2907         This change allows us to also select exit sites based on their index in the static
2908         sequence of exit sites that the compiler compiled. Then, once that static exit site is
2909         selected, we can select which dynamic exit at that exit site we should trigger. Since the
2910         number of static exit sites is usually smallish (it's bounded by program size), we can do
2911         an exhaustive search over all exit sites in most programs.
2912
2913         * dfg/DFGOSRExitFuzz.cpp:
2914         (JSC::numberOfStaticOSRExitFuzzChecks):
2915         (JSC::numberOfOSRExitFuzzChecks):
2916         * dfg/DFGOSRExitFuzz.h:
2917         (JSC::DFG::doOSRExitFuzzing):
2918         * dfg/DFGSpeculativeJIT.cpp:
2919         (JSC::DFG::SpeculativeJIT::emitOSRExitFuzzCheck):
2920         * ftl/FTLLowerDFGToLLVM.cpp:
2921         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
2922         * jsc.cpp:
2923         (jscmain):
2924         * runtime/Options.h:
2925         * runtime/TestRunnerUtils.h:
2926
2927 2015-07-08  Joseph Pecoraro  <pecoraro@apple.com>
2928
2929         Fix grammar issue in TypeError attempting to change an unconfigurable property
2930         https://bugs.webkit.org/show_bug.cgi?id=146774
2931
2932         Reviewed by Brent Fulgham.
2933
2934         * runtime/JSFunction.cpp:
2935         (JSC::JSFunction::defineOwnProperty):
2936         * runtime/JSObject.cpp:
2937         (JSC::JSObject::defineOwnNonIndexProperty):
2938         * runtime/StringObject.cpp:
2939         (JSC::StringObject::defineOwnProperty):
2940
2941 2015-07-06  Csaba Osztrogonác  <ossy@webkit.org>
2942
2943         Remove the unused HeapBlock.h
2944         https://bugs.webkit.org/show_bug.cgi?id=146580
2945
2946         Reviewed by Andreas Kling.
2947
2948         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2949         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2950         * JavaScriptCore.xcodeproj/project.pbxproj:
2951         * heap/CopiedBlock.h:
2952         * heap/CopiedSpace.h:
2953         * heap/CopiedSpaceInlines.h:
2954         * heap/HandleBlock.h:
2955         * heap/HeapBlock.h: Removed.
2956         * heap/MarkedBlock.h:
2957
2958 2015-07-06  Saam barati  <saambarati1@gmail.com>
2959
2960         JSC's parser should follow the ES6 spec with respect to parsing Declarations
2961         https://bugs.webkit.org/show_bug.cgi?id=146621
2962
2963         Reviewed by Mark Lam.
2964
2965         There were a few locations where JSC would allow declaration statements
2966         in incorrect ways. JSC didn't distinguish between 'Statement' and
2967         'StatementListItem' grammar productions. The relevant grammar is here:
2968         http://www.ecma-international.org/ecma-262/6.0/index.html#sec-statements
2969
2970         From the ECMA Script 6.0 spec:
2971         1. Section 13.6 The if Statement (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-if-statement) 
2972          says that IfStatements only takes Statements for the "then-else" clauses, not StatementListItems.
2973          (Same with 'while/for/do-while' loop bodies).
2974         2. Section 13 ECMAScript Language: Statements and Declarations 
2975          (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-statements-and-declarations)
2976          defines the syntax of Statements, and they do not include ClassDeclarations and LexicalDeclarations 
2977          (const, let, see 13.3.1 Let and Const Declarations).
2978          Declarations can only be in the “then-else” clauses when embedded in a StatementListItem in a BlockStatement (see 13.2).
2979
2980         Hence, the following style of declarations are no longer allowed:
2981             'if/for/while (condition) const x = 40;'
2982             'if/for/while (condition) class C { }'
2983
2984         Instead, we mandate such declaration constructs are within a StatementList 
2985        (which is the production that JSC's Parser::parseSourceElements function parses):
2986            'if/for/while (condition) { const x = 40; }'
2987            'if/for/while (condition) { class C { } }'
2988
2989         * parser/Parser.cpp:
2990         (JSC::Parser<LexerType>::parseSourceElements):
2991         (JSC::Parser<LexerType>::parseStatementListItem):
2992         (JSC::Parser<LexerType>::parseVarDeclaration):
2993         (JSC::Parser<LexerType>::parseStatement):
2994         (JSC::Parser<LexerType>::parseExpressionStatement):
2995         * parser/Parser.h:
2996         (JSC::Parser::getLabel):
2997
2998 2015-07-06  Alex Christensen  <achristensen@webkit.org>
2999
3000         Unreviewed debug build fix after r186358.
3001
3002         * runtime/JSArray.cpp:
3003         (JSC::JSArray::fastConcatWith):
3004         Pass vm parameter to fastConcatType.
3005
3006 2015-07-06  Ryosuke Niwa  <rniwa@webkit.org>
3007
3008         Array.concat should be fast for integer or double arrays
3009         https://bugs.webkit.org/show_bug.cgi?id=146260
3010
3011         Reviewed by Darin Adler.
3012
3013         Added a fast path to Array.prototype.concat. When concatenating two Int32, Double, or Contiguous
3014         arrays, simply memcopy the arrays into a new uninitialized buffer.
3015
3016         This improves huffman encoding in CompressionBench by 3.7x on a Mid 2014 MacBookPro.
3017
3018         * runtime/ArrayPrototype.cpp:
3019         (JSC::arrayProtoFuncConcat):
3020         * runtime/JSArray.cpp:
3021         (JSC::JSArray::fastConcatWith): Added.
3022         * runtime/JSArray.h:
3023         (JSC::JSArray::fastConcatType): Added. Returns the resultant array's indexing type if we can use
3024         the fact path. Returns NonArray otherwise.
3025
3026 2015-07-06  Youenn Fablet  <youenn.fablet@crf.canon.fr>
3027
3028         [Streams API] Remove ReadableStream custom constructor
3029         https://bugs.webkit.org/show_bug.cgi?id=146547
3030
3031         Reviewed by Darin Adler.
3032
3033         Adding helper function to throw range errors.
3034
3035         * runtime/Error.h:
3036         (JSC::throwRangeError):
3037         (JSC::throwVMRangeError):
3038
3039 2015-07-05  Yusuke Suzuki  <utatane.tea@gmail.com>
3040
3041         [ES6] Implement the latest Promise spec in JS
3042         https://bugs.webkit.org/show_bug.cgi?id=146229
3043
3044         Reviewed by Sam Weinig.
3045
3046         Updated the Promise implementation to meet to the ES6 spec.
3047         This patch
3048         1. Implement ES6 Promise and related abstract operations in builtins JS
3049         2. Expose @enqueueJob private function to JS world to post the microtask
3050
3051         Updated implementation has one-on-one correspondence to the ES6 spec description.
3052         And keep the JSPromiseDeferred because it is the interface used from the WebCore.
3053
3054         * CMakeLists.txt:
3055         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3056         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3057         * JavaScriptCore.xcodeproj/project.pbxproj:
3058         * builtins/Array.prototype.js:
3059         (reduce):
3060         (reduceRight):
3061         (every):
3062         (forEach):
3063         (filter):
3064         (map):
3065         (some):
3066         (fill):
3067         (find):
3068         (findIndex):
3069         (includes):
3070         (copyWithin):
3071         ToInteger / ToLength are renamed to toInteger and toLength.
3072         * builtins/ArrayConstructor.js:
3073         (from):
3074         ToInteger / ToLength are renamed to toInteger and toLength.
3075         * builtins/GlobalObject.js:
3076         (toInteger):
3077         (toLength):
3078         (isObject):
3079         (ToInteger): Deleted.
3080         (ToLength): Deleted.
3081         ToInteger / ToLength are renamed to toInteger and toLength.
3082         Add new abstract operation, isObject.
3083         * builtins/Operations.Promise.js: Added.
3084         (isPromise):
3085         (newPromiseReaction):
3086         (newPromiseDeferred):
3087         (newPromiseCapability.executor):
3088         (newPromiseCapability):
3089         (triggerPromiseReactions):
3090         (rejectPromise):
3091         (fulfillPromise):
3092         (createResolvingFunctions.resolve):
3093         (createResolvingFunctions.reject):
3094         (createResolvingFunctions):
3095         (promiseReactionJob):
3096         (promiseResolveThenableJob):
3097         (initializePromise):
3098         Added Promise related abstract operations.
3099         * builtins/Promise.prototype.js:
3100         (catch):
3101         (.onFulfilled):
3102         (.onRejected):
3103         (then):
3104         Promise#then implementation in JS.
3105         * builtins/PromiseConstructor.js: Added.
3106         (all.newResolveElement):
3107         (all):
3108         (race):
3109         (reject):
3110         (resolve):
3111         Promise static functions implementations in JS.
3112         * builtins/StringConstructor.js:
3113         (raw):
3114         ToInteger / ToLength are renamed to toInteger and toLength.
3115         * inspector/JSInjectedScriptHost.cpp:
3116         (Inspector::JSInjectedScriptHost::getInternalProperties):
3117         * runtime/CommonIdentifiers.h:
3118         * runtime/JSGlobalObject.cpp:
3119         (JSC::enqueueJob):
3120         (JSC::JSGlobalObject::init):
3121         (JSC::JSGlobalObject::visitChildren):
3122         * runtime/JSGlobalObject.h:
3123         (JSC::JSGlobalObject::initializePromiseFunction):
3124         (JSC::JSGlobalObject::newPromiseDeferredFunction):
3125         * runtime/JSJob.cpp: Renamed from Source/JavaScriptCore/runtime/JSPromiseReaction.h.
3126         (JSC::createJSJob):
3127         (JSC::JSJobMicrotask::run):
3128         * runtime/JSJob.h: Renamed from Source/JavaScriptCore/runtime/JSPromiseFunctions.h.
3129         * runtime/JSPromise.cpp:
3130         (JSC::JSPromise::create):
3131         (JSC::JSPromise::JSPromise):
3132         (JSC::JSPromise::finishCreation):
3133         (JSC::JSPromise::result):
3134         (JSC::JSPromise::destroy): Deleted.
3135         (JSC::JSPromise::visitChildren): Deleted.
3136         (JSC::JSPromise::reject): Deleted.
3137         (JSC::JSPromise::resolve): Deleted.
3138         (JSC::JSPromise::appendResolveReaction): Deleted.
3139         (JSC::JSPromise::appendRejectReaction): Deleted.
3140         (JSC::triggerPromiseReactions): Deleted.
3141         * runtime/JSPromise.h:
3142         (JSC::JSPromise::status): Deleted.
3143         (JSC::JSPromise::result): Deleted.
3144         (JSC::JSPromise::constructor): Deleted.
3145         * runtime/JSPromiseConstructor.cpp:
3146         (JSC::constructPromise):
3147         (JSC::JSPromiseConstructorFuncResolve): Deleted.
3148         (JSC::JSPromiseConstructorFuncReject): Deleted.
3149         (JSC::performPromiseRaceLoop): Deleted.
3150         (JSC::JSPromiseConstructorFuncRace): Deleted.
3151         (JSC::performPromiseAll): Deleted.
3152         (JSC::JSPromiseConstructorFuncAll): Deleted.
3153         * runtime/JSPromiseDeferred.cpp:
3154         (JSC::JSPromiseDeferred::create):
3155         (JSC::createJSPromiseDeferredFromConstructor): Deleted.
3156         (JSC::updateDeferredFromPotentialThenable): Deleted.
3157         (JSC::performDeferredResolve): Deleted.
3158         (JSC::performDeferredReject): Deleted.
3159         (JSC::abruptRejection): Deleted.
3160         * runtime/JSPromiseDeferred.h:
3161         * runtime/JSPromiseFunctions.cpp: Removed.
3162         (JSC::deferredConstructionFunction): Deleted.
3163         (JSC::createDeferredConstructionFunction): Deleted.
3164         (JSC::identifyFunction): Deleted.
3165         (JSC::createIdentifyFunction): Deleted.
3166         (JSC::promiseAllCountdownFunction): Deleted.
3167         (JSC::createPromiseAllCountdownFunction): Deleted.
3168         (JSC::promiseResolutionHandlerFunction): Deleted.
3169         (JSC::createPromiseResolutionHandlerFunction): Deleted.
3170         (JSC::rejectPromiseFunction): Deleted.
3171         (JSC::createRejectPromiseFunction): Deleted.
3172         (JSC::resolvePromiseFunction): Deleted.
3173         (JSC::createResolvePromiseFunction): Deleted.
3174         (JSC::throwerFunction): Deleted.
3175         (JSC::createThrowerFunction): Deleted.
3176         * runtime/JSPromisePrototype.cpp:
3177         (JSC::JSPromisePrototypeFuncThen): Deleted.
3178         * runtime/JSPromiseReaction.cpp: Removed.
3179         (JSC::createExecutePromiseReactionMicrotask): Deleted.
3180         (JSC::ExecutePromiseReactionMicrotask::run): Deleted.
3181         (JSC::JSPromiseReaction::create): Deleted.
3182         (JSC::JSPromiseReaction::JSPromiseReaction): Deleted.
3183         (JSC::JSPromiseReaction::finishCreation): Deleted.
3184         (JSC::JSPromiseReaction::visitChildren): Deleted.
3185         * runtime/VM.cpp:
3186         (JSC::VM::VM): Deleted.
3187         * runtime/VM.h:
3188
3189 2015-07-04  Chris Dumez  <cdumez@apple.com>
3190
3191         Drop RefPtr::clear() method
3192         https://bugs.webkit.org/show_bug.cgi?id=146556
3193
3194         Reviewed by Brady Eidson.
3195
3196         Drop RefPtr::clear() method in favor of "= nullptr;" pattern.
3197
3198 2015-07-03  Dan Bernstein  <mitz@apple.com>
3199
3200         Just give up on -Wunreachable-code in JavaScriptCore.
3201
3202         * Configurations/Base.xcconfig:
3203         * llint/LowLevelInterpreter.cpp:
3204         (JSC::CLoop::execute):
3205
3206 2015-07-03  Dan Bernstein  <mitz@apple.com>
3207
3208         Fixed the LLINT CLoop build.
3209
3210         * llint/LowLevelInterpreter.cpp:
3211         (JSC::CLoop::execute):
3212
3213 2015-07-03  Dan Bernstein  <mitz@apple.com>
3214
3215         [Xcode] Update some build settings as recommended by Xcode 7
3216         https://bugs.webkit.org/show_bug.cgi?id=146597
3217
3218         Reviewed by Sam Weinig.
3219
3220         * Configurations/Base.xcconfig: Enabled CLANG_WARN_UNREACHABLE_CODE and
3221         GCC_NO_COMMON_BLOCKS. Removed GCC_MODEL_TUNING.
3222
3223         * JavaScriptCore.xcodeproj/project.pbxproj: Updated LastUpgradeCheck.
3224
3225         * dfg/DFGGraph.h: Tweaked the definition of DFG_CRASH to suppress unreachable code warnings.
3226
3227 2015-07-03  Yusuke Suzuki  <utatane.tea@gmail.com>
3228
3229         Relax builtin JS restriction about try-catch
3230         https://bugs.webkit.org/show_bug.cgi?id=146555
3231
3232         Reviewed by Sam Weinig.
3233
3234         When retrieving the captured variables from the full activated scope,
3235         it swapped the given vector with the stored declared variables vector.
3236         This is because retrieving the captured variables are executed in the
3237         last sequence of the parser, so declared variables are no longer used.
3238         However, in builtins functions case, after retrieving the captured
3239         variables, we check the variables by using declared variables vector.
3240         So at that time, the declared variables vector becomes empty and it
3241         raises assertion failures when the builtins function contains the full
3242         activated scope. try-catch's catch scope requires the upper scope full
3243         activated, so JS code in the builtins cannot use the try-catch.
3244
3245         This patch relaxes this restriction. When retrieving the captured
3246         variables from the scope, just copy to the given vector.
3247
3248         * parser/Parser.h:
3249         (JSC::Scope::getCapturedVariables):
3250
3251 2015-07-02  Filip Pizlo  <fpizlo@apple.com>
3252
3253         DFG and FTL should have an OSR exit fuzzer
3254         https://bugs.webkit.org/show_bug.cgi?id=146562
3255
3256         Reviewed by Benjamin Poulain.
3257         
3258         Adds a basic OSR exit fuzzer to JSC. This isn't hooked into any test harnesses yet, but I
3259         spot-checked it on v8-earley-boyer.js and so far found no bugs. I'd like to figure out how
3260         to harness this after I land it.
3261         
3262         Since it's turned off by default, it should have no effect on behavior.
3263
3264         * CMakeLists.txt:
3265         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3266         * JavaScriptCore.xcodeproj/project.pbxproj:
3267         * dfg/DFGOSRExitFuzz.cpp: Added.
3268         (JSC::numberOfOSRExitFuzzChecks):
3269         * dfg/DFGOSRExitFuzz.h: Added.
3270         * dfg/DFGSpeculativeJIT.cpp:
3271         (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
3272         (JSC::DFG::SpeculativeJIT::emitOSRExitFuzzCheck):
3273         (JSC::DFG::SpeculativeJIT::speculationCheck):
3274         * dfg/DFGSpeculativeJIT.h:
3275         * ftl/FTLLowerDFGToLLVM.cpp:
3276         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
3277         * jsc.cpp:
3278         (jscmain):
3279         * runtime/Options.h:
3280         * runtime/TestRunnerUtils.h:
3281
3282 2015-07-02  Saam barati  <saambarati1@gmail.com>
3283
3284         Rename "Deconstruction" to "Destructuring" throughout JSC
3285         https://bugs.webkit.org/show_bug.cgi?id=146100
3286
3287         Reviewed by Mark Lam.
3288
3289         It is good to use the same naming conventions as the ES6 
3290         spec because it is the de facto way of speaking about these 
3291         language features. This also has the benefit of improving JSC's
3292         hackability because it improves code readability for newcomers 
3293         to JSC or newcomers to this part of the code base.
3294
3295         * bytecompiler/BytecodeGenerator.cpp:
3296         (JSC::BytecodeGenerator::generate):
3297         (JSC::BytecodeGenerator::BytecodeGenerator):
3298         (JSC::BytecodeGenerator::initializeNextParameter):
3299         (JSC::BytecodeGenerator::visibleNameForParameter):
3300         * bytecompiler/BytecodeGenerator.h:
3301         (JSC::BytecodeGenerator::registerFor):
3302         * bytecompiler/NodesCodegen.cpp:
3303         (JSC::ForInNode::tryGetBoundLocal):
3304         (JSC::ForInNode::emitLoopHeader):
3305         (JSC::ForOfNode::emitBytecode):
3306         (JSC::ClassExprNode::emitBytecode):
3307         (JSC::DestructuringAssignmentNode::emitBytecode):
3308         (JSC::DestructuringPatternNode::~DestructuringPatternNode):
3309         (JSC::ArrayPatternNode::collectBoundIdentifiers):
3310         (JSC::DeconstructingAssignmentNode::emitBytecode): Deleted.
3311         (JSC::DeconstructionPatternNode::~DeconstructionPatternNode): Deleted.
3312         * parser/ASTBuilder.h:
3313         (JSC::ASTBuilder::createElementList):
3314         (JSC::ASTBuilder::createFormalParameterList):
3315         (JSC::ASTBuilder::createClause):
3316         (JSC::ASTBuilder::createClauseList):
3317         (JSC::ASTBuilder::createForInLoop):
3318         (JSC::ASTBuilder::createForOfLoop):