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