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