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