[JSC] Don't reference the properties of @Reflect directly
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-03-14  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [JSC] Don't reference the properties of @Reflect directly
4         https://bugs.webkit.org/show_bug.cgi?id=155436
5
6         Reviewed by Geoffrey Garen.
7
8         Reflect.ownKeys and Reflect.getOwnPropertyDescriptor can be altered with the user-crafted values.
9         Instead of referencing them directly, let's reference them through private names.
10
11         * builtins/ObjectConstructor.js:
12         (assign):
13         * runtime/CommonIdentifiers.h:
14         * runtime/ObjectConstructor.cpp:
15         (JSC::ObjectConstructor::finishCreation): Deleted.
16         * runtime/ReflectObject.cpp:
17         (JSC::ReflectObject::finishCreation):
18         * tests/stress/object-assign-correctness.js:
19         (runTests.):
20         (runTests.get let):
21         (Reflect.ownKeys):
22         (Reflect.getOwnPropertyDescriptor):
23         (test.let.handler.switch.case.string_appeared_here.return.get enumerable): Deleted.
24         (test.let.handler.getOwnPropertyDescriptor): Deleted.
25         (test.let.handler.ownKeys): Deleted.
26         (test.let.handler.get getProps): Deleted.
27         (test.let.handler): Deleted.
28         (test): Deleted.
29
30 2016-03-14  Daniel Bates  <dabates@apple.com>
31
32         Web Inspector: Display Content Security Policy hash in details sidebar for script and style elements
33         https://bugs.webkit.org/show_bug.cgi?id=155466
34         <rdar://problem/25152480>
35
36         Reviewed by Joseph Pecoraro and Timothy Hatcher.
37
38         Add property contentSecurityPolicyHash to store the CSP hash for an HTML style element or an
39         applicable HTML script element.
40
41         * inspector/protocol/DOM.json:
42
43 2016-03-14  Joonghun Park  <jh718.park@samsung.com>
44
45         Purge PassRefPtr from ArrayBuffer, ArchiveResource, Pasteboard, LegacyWebArchive and DataObjectGtk
46         https://bugs.webkit.org/show_bug.cgi?id=150497
47
48         Reviewed by Darin Adler.
49
50         * runtime/ArrayBuffer.h:
51         (JSC::ArrayBuffer::create):
52         (JSC::ArrayBuffer::createAdopted):
53         (JSC::ArrayBuffer::createFromBytes):
54         (JSC::ArrayBuffer::createUninitialized):
55         (JSC::ArrayBuffer::slice):
56         (JSC::ArrayBuffer::sliceImpl):
57
58 2016-03-14  Benjamin Poulain  <bpoulain@apple.com>
59
60         Andy VanWagoner no longer has time to own Intl
61
62         * features.json:
63         Andy is busy with other things.
64
65         Andy, thanks for your amazing work on Intl and your dedication
66         to making things right.
67
68 2016-03-14  Julien Brianceau  <jbriance@cisco.com>
69
70         [mips] Fix unaligned access in LLINT.
71         https://bugs.webkit.org/show_bug.cgi?id=153228
72
73         Address loads used with btbxx opcodes were wrongly converted to lw
74         instruction instead of lbu, leading to unaligned access on mips
75         platforms. This is not a bug as it's silently fixed up by kernel,
76         but it's more efficient to avoid unaligned accesses for mips.
77
78         Reviewed by Geoffrey Garen.
79
80         * offlineasm/mips.rb:
81
82 2016-03-14  Filip Pizlo  <fpizlo@apple.com>
83
84         REGRESSION(r194394): >2x slow-down on CDjs
85         https://bugs.webkit.org/show_bug.cgi?id=155471
86
87         Unreviewed (rollout).
88
89         This revision changes localeCompare() so that it's *much* slower than before. It's
90         understandable that sometimes things will get a tiny bit slower when implementing new
91         language features, but more than 2x regression on a major benchmark is not OK.
92
93         This rolls out that change. We can reland it once we think about how to do it in a
94         performant way.
95
96         * builtins/StringPrototype.js:
97         (search):
98         (localeCompare): Deleted.
99         * runtime/StringPrototype.cpp:
100         (JSC::StringPrototype::finishCreation):
101
102 2016-03-14  Mark Lam  <mark.lam@apple.com>
103
104         Need to distinguish between Symbol() and Symbol("").
105         https://bugs.webkit.org/show_bug.cgi?id=155438
106
107         Reviewed by Saam Barati.
108
109         * runtime/PrivateName.h:
110         (JSC::PrivateName::PrivateName):
111
112 2016-03-14  Oliver Hunt  <oliver@apple.com>
113
114         Temporarily disable the separated heap.
115         https://bugs.webkit.org/show_bug.cgi?id=155472
116
117         Reviewed by Geoffrey Garen.
118
119         Temporarily disable this.
120
121         * Configurations/FeatureDefines.xcconfig:
122
123 2016-03-14  Joseph Pecoraro  <pecoraro@apple.com>
124
125         Reduce generated JSON HeapSnapshot size
126         https://bugs.webkit.org/show_bug.cgi?id=155460
127
128         Reviewed by Geoffrey Garen.
129
130         Adjust the HeapSnapshot JSON to better reduce its size.
131         Changes include:
132
133           - avoid inner array groups and instead just have a large array for
134             nodes/edges. This removes lots of small array allocations.
135           - eliminate duplicate edges
136           - avoid duplicating edge names by including them in their own table;
137           - now both the nodes and edges lists hold only integers
138
139         * heap/HeapSnapshotBuilder.cpp:
140         (JSC::HeapSnapshotBuilder::json):
141         Add some more documentation for the slightly modified format.
142         While generating, clear data structures as early as possible.
143
144         * heap/HeapSnapshotBuilder.h:
145         (JSC::HeapSnapshotEdge::HeapSnapshotEdge):
146         During JSON building, the edge's cell pointers are converted to the
147         identifier they point to. This avoids having to re-lookup the identifier.
148
149         * tests/heapProfiler/driver/driver.js:
150         (CheapHeapSnapshotEdge):
151         (CheapHeapSnapshot):
152         (CheapHeapSnapshot.prototype.edgeNameFromTableIndex):
153         (HeapSnapshot):
154         Update test driver for slightly different snapshot format.
155
156 2016-03-14  Keith Miller  <keith_miller@apple.com>
157
158         We should be able to eliminate cloned arguments objects that use the length property
159         https://bugs.webkit.org/show_bug.cgi?id=155391
160
161         Reviewed by Geoffrey Garen.
162
163         Previously if a programmer tried to use arguments.length in a strict function we would not eliminate the
164         arguments object. We were unable to eliminate the arguments object because the user would get a cloned arguments
165         object, which does not special case the length property. Thus, in order to get arguments elimination for cloned
166         we need to add a special case. There are two things that need to happen for the elimination to succeed.
167
168         First, we need to eliminate the CheckStructure blocking the GetByOffset for the length property. In order to
169         eliminate the check structure we need to prove to the Abstract Interpreter that this structure check is
170         unnesssary. This didn't occur before for two reasons: 1) CreateClonedArguments did not set the structure it
171         produced. 2) Even if CreateClonedArguments provided the global object's cloned arguments structure we would
172         transition the new argements object when we added the length property during construction. To fix the second
173         problem we now pre-assign a slot on clonedArgumentsStructure for the length property. Additionally, in order to
174         prevent future transitions of the structure we need to choose an indexing type for the structure. Since, not
175         eliminating the arguments object is so expensive we choose to have all cloned arguments start with continuous
176         indexing type, this avoids transitioning when otherwise we would not have to. In the future we should be smarter
177         about choosing the indexing type but since its relatively rare to have a arguments object escape we don't worry
178         about this for now.
179
180         Additionally, this patch renames all former references of outOfBandArguments to clonedArguments and adds
181         extra instrumentation to DFGArgumentsEliminationPhase.
182
183         * bytecode/BytecodeList.json:
184         * bytecode/BytecodeUseDef.h:
185         (JSC::computeUsesForBytecodeOffset):
186         (JSC::computeDefsForBytecodeOffset):
187         * bytecode/CodeBlock.cpp:
188         (JSC::CodeBlock::dumpBytecode):
189         * bytecode/ValueRecovery.h:
190         (JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
191         (JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated): Deleted.
192         * bytecompiler/BytecodeGenerator.cpp:
193         (JSC::BytecodeGenerator::BytecodeGenerator):
194         * dfg/DFGAbstractInterpreterInlines.h:
195         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
196         * dfg/DFGArgumentsEliminationPhase.cpp:
197         * dfg/DFGByteCodeParser.cpp:
198         (JSC::DFG::ByteCodeParser::parseBlock):
199         * dfg/DFGCapabilities.cpp:
200         (JSC::DFG::capabilityLevel):
201         * dfg/DFGOperations.cpp:
202         * dfg/DFGSpeculativeJIT.cpp:
203         (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
204         * dfg/DFGStructureRegistrationPhase.cpp:
205         (JSC::DFG::StructureRegistrationPhase::run):
206         * dfg/DFGVariableEventStream.cpp:
207         (JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
208         * ftl/FTLLowerDFGToB3.cpp:
209         (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
210         * ftl/FTLOperations.cpp:
211         (JSC::FTL::operationMaterializeObjectInOSR):
212         * jit/JIT.cpp:
213         (JSC::JIT::privateCompileMainPass):
214         * jit/JIT.h:
215         * jit/JITOpcodes.cpp:
216         (JSC::JIT::emit_op_create_cloned_arguments):
217         (JSC::JIT::emit_op_create_out_of_band_arguments): Deleted.
218         * llint/LowLevelInterpreter.asm:
219         * runtime/ClonedArguments.cpp:
220         (JSC::ClonedArguments::ClonedArguments):
221         (JSC::ClonedArguments::createEmpty):
222         (JSC::ClonedArguments::createWithInlineFrame):
223         (JSC::ClonedArguments::createByCopyingFrom):
224         (JSC::ClonedArguments::createStructure):
225         * runtime/ClonedArguments.h:
226         * runtime/JSGlobalObject.cpp:
227         (JSC::JSGlobalObject::init):
228         (JSC::JSGlobalObject::visitChildren):
229         * runtime/JSGlobalObject.h:
230         (JSC::JSGlobalObject::clonedArgumentsStructure):
231         (JSC::JSGlobalObject::outOfBandArgumentsStructure): Deleted.
232
233 2016-03-14  Saam barati  <sbarati@apple.com>
234
235         [ES6] Make JSON.stringify ES6 compatible
236         https://bugs.webkit.org/show_bug.cgi?id=155448
237
238         Reviewed by Sam Weinig and Mark Lam.
239
240         We weren't following the spec with respect to the "toJSON" property
241         of the thing being stringified. We were perform hasProperty(.)
242         on "toJSON" instead of get(.). This patch changes it our
243         implementation to perform get(value, "toJSON").
244
245         * runtime/JSCJSValue.h:
246         * runtime/JSCJSValueInlines.h:
247         (JSC::JSValue::isFunction):
248         (JSC::JSValue::isCallable):
249         * runtime/JSONObject.cpp:
250         (JSC::Stringifier::toJSON):
251         (JSC::Stringifier::toJSONImpl):
252         (JSC::Stringifier::appendStringifiedValue):
253         * tests/es6.yaml:
254         * tests/stress/proxy-json.js:
255         (test):
256         (test.let.handler.get assert):
257         (test.let.handler):
258
259 2016-03-14  Saam barati  <sbarati@apple.com>
260
261         [ES6] Disallow var assignments in for-in loops
262         https://bugs.webkit.org/show_bug.cgi?id=155451
263
264         Reviewed by Mark Lam.
265
266         We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384
267         because last time we made this change it broke some websites. Lets try making
268         it again because it's what the ES6 mandates. If it still breaks things we will
269         roll it out.
270
271         * parser/Parser.cpp:
272         (JSC::Parser<LexerType>::parseForStatement):
273
274 2016-03-14  Saam barati  <sbarati@apple.com>
275
276         assignments in for-in/for-of header not allowed
277         https://bugs.webkit.org/show_bug.cgi?id=155384
278
279         Reviewed by Darin Adler.
280
281         This patch prevents assignments to the loop variable
282         in for in/of loops in all but one situation. The following
283         syntax is still allowed even though the spec prevents it:
284         ```
285         for (var i = X in blah) ;
286         ```
287         If the loop contains let/const, destructuring, or is a for-of
288         loop, we always throw a syntax error if there is an assignment.
289         We can do this with full backwards compatibility.
290         We only allow the above type of for-in loops because Oliver told
291         me that when he tried to make such programs illegal he ran
292         into real websites breaking.
293
294         This patch also removed the !::CreatesAST compile-time branch when checking
295         assignments to new.target. This was a dangerous thing for me
296         to introduce into our parser. There are times where ::CreatesAST
297         is true but we also want to check for syntax errors. For example,
298         when parsing the top-level AST of a program. Though this check
299         was technically correct, it's dangerous to have. It was correct
300         because we would always be reparsing the new.target assignment
301         because new.target is only allowed inside a function. That made it
302         so that (!::CreatesAST <=> we care about new.target assignment syntax errors).
303         But, (!::CreatesAST <=> we care about syntax error X) is not true in general.
304         I think it's safer to remove such code.
305
306         * parser/ASTBuilder.h:
307         (JSC::ASTBuilder::createNewTargetExpr):
308         (JSC::ASTBuilder::isNewTarget):
309         (JSC::ASTBuilder::createResolve):
310         * parser/Nodes.h:
311         (JSC::ExpressionNode::isBoolean):
312         (JSC::ExpressionNode::isSpreadExpression):
313         (JSC::ExpressionNode::isSuperNode):
314         (JSC::ExpressionNode::isNewTarget):
315         (JSC::ExpressionNode::isBytecodeIntrinsicNode):
316         * parser/Parser.cpp:
317         (JSC::Parser<LexerType>::parseForStatement):
318         (JSC::Parser<LexerType>::parseAssignmentExpression):
319         (JSC::Parser<LexerType>::parseUnaryExpression):
320
321 2016-03-13  Joseph Pecoraro  <pecoraro@apple.com>
322
323         Remove ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) guards
324         https://bugs.webkit.org/show_bug.cgi?id=155417
325
326         Reviewed by Yusuke Suzuki.
327
328         * Configurations/FeatureDefines.xcconfig:
329         * parser/Parser.cpp:
330         (JSC::Parser<LexerType>::parsePrimaryExpression): Deleted.
331         (JSC::Parser<LexerType>::parseMemberExpression): Deleted.
332
333 2016-03-13  Konstantin Tokarev  <annulen@yandex.ru>
334
335         Added new port JSCOnly.
336         https://bugs.webkit.org/show_bug.cgi?id=154512
337
338         Reviewed by Michael Catanzaro.
339
340         This port allows to build JavaScriptCore engine with minimal
341         dependencies.
342
343         * PlatformJSCOnly.cmake: Added.
344
345 2016-03-12  Mark Lam  <mark.lam@apple.com>
346
347         http://kangax.github.io/compat-table/esnext/ crashes reliably.
348         https://bugs.webkit.org/show_bug.cgi?id=155404
349
350         Reviewed by Yusuke Suzuki.
351
352         constructObjectFromPropertyDescriptor() was incorrectly assuming that either
353         both getter and setter will be set or unset.  It did not consider that only one
354         of the getter or setter may be set.  This patch fixes that.
355
356         * runtime/ObjectConstructor.h:
357         (JSC::constructObjectFromPropertyDescriptor):
358         * tests/stress/proxy-with-unbalanced-getter-setter.js: Added.
359         (assert):
360         (let.handler.defineProperty):
361         (i.):
362         (i.assert):
363         (i.get assert):
364         (set assert):
365
366 2016-03-12  Brian Burg  <bburg@apple.com>
367
368         When generating Objective-C protocol types, getters for objects need to synthesize a new object instance
369         https://bugs.webkit.org/show_bug.cgi?id=155389
370         <rdar://problem/25125821>
371
372         Reviewed by Timothy Hatcher.
373
374         Currently, in object property getters for Objective-C protocol types, we use
375         a C-style cast of the member's RWIProtocolJSONObject * to the type of the property.
376         However, at runtime the class of `self` is going to be RWIProtocolJSONObject *,
377         not MemberType *, so any subsequent calls to MemberType properties on the return value
378         will fail as the selectors will not be recognized.
379
380         Instead of doing a C-style pointer cast, we need to create a new MemberType object
381         that's backed by the InspectorObject retrieved from the parent object by key.
382         This requires a new initWithJSONObject initializer for each object protocol type.
383
384         * inspector/scripts/codegen/generate_objc_header.py:
385         (ObjCHeaderGenerator._generate_type_interface): Add new declaration.
386
387         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
388         (ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
389         (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_json_object): Added.
390         Forward through to the super class initializer who assigns the underlying InspectorObject.
391
392         (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
393         Drive-by cleanup to use the more compact [super init] form.
394
395         * inspector/scripts/codegen/objc_generator.py:
396         (ObjCGenerator.protocol_to_objc_expression_for_member):
397         For property getters of objects, use initWithJSONObject: rather than a C-style cast.
398
399         Rebaseline relevant test results.
400
401         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
402         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
403         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
404         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
405         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
406         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
407         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
408
409 2016-03-12  Konstantin Tokarev  <annulen@yandex.ru>
410
411         Removed variable names from default constructor declarations.
412         https://bugs.webkit.org/show_bug.cgi?id=155397
413
414         Reviewed by Mark Lam.
415
416         They carry no information and generate unused variable warning with GCC
417         4.8 in a lot of source files.
418
419         * parser/VariableEnvironment.h:
420
421 2016-03-12  Myles C. Maxfield  <mmaxfield@apple.com>
422
423         Delete dead SVG Font code
424         https://bugs.webkit.org/show_bug.cgi?id=154718
425
426         Reviewed by Antti Koivisto.
427
428         * Configurations/FeatureDefines.xcconfig:
429
430 2016-03-11  Benjamin Poulain  <bpoulain@apple.com>
431
432         [JSC] Remove a few jumps from DFG
433         https://bugs.webkit.org/show_bug.cgi?id=155347
434
435         Reviewed by Mark Lam.
436
437         Usually, setting ValueTrue or ValueFalse is set
438         by Compare+Or. There are 3 places in DFG with branches instead.
439
440         This patch changes them to the usual pattern.
441
442         * dfg/DFGSpeculativeJIT64.cpp:
443         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
444         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
445
446 2016-03-11  Saam barati  <sbarati@apple.com>
447
448         [ES6] Make Object.assign spec compliant
449         https://bugs.webkit.org/show_bug.cgi?id=155375
450
451         Reviewed by Michael Saboff.
452
453         This is a straight forward implementation of Object.assign
454         in the spec.
455         https://tc39.github.io/ecma262/#sec-object.assign
456         Before, weren't performing all of the specified operations.
457         Now, we are.
458
459         * builtins/ObjectConstructor.js:
460         (assign):
461         * runtime/CommonIdentifiers.h:
462         * runtime/JSGlobalObject.cpp:
463         (JSC::JSGlobalObject::init):
464         * tests/es6.yaml:
465
466 2016-03-11  Mark Lam  <mark.lam@apple.com>
467
468         Implement Function.name and Function#toString for ES6 class.
469         https://bugs.webkit.org/show_bug.cgi?id=155336
470
471         Reviewed by Geoffrey Garen.
472
473         The only thing that the ES6 spec says about toString with regards to class
474         objects is:
475
476         "The string representation must have the syntax of a FunctionDeclaration,
477         FunctionExpression, GeneratorDeclaration, GeneratorExpression, ClassDeclaration,
478         ClassExpression, ArrowFunction, MethodDefinition, or GeneratorMethod depending
479         upon the actual characteristics of the object."
480
481         Previously, invoking toString() on a class object will return the function
482         source string of the class' constructor function.  This does not conform to the
483         spec in that the toString string for a class does not have the syntax of a
484         ClassDeclaration or ClassExpression.
485
486         This is now fixed by doing the following:
487
488         1. Added "m_classSource" to FunctionExecutable (and correspondingly to
489            UnlinkedFunctionExecutable, FunctionMetadataNode, and ClassExprNode).
490            m_classSource is the SourceCode for the code range "class ... { ... }".
491
492            Since the class constructor function is the in memory representation of the
493            class object, only class constructor functions will have its m_classSource
494            set.  m_classSource will be "null" (by default) for all other functions.
495            This is how we know if a FunctionExecutable is for a class.
496
497            Note: FunctionExecutable does not have its own m_classSource.  It always gets
498            it from its UnlinkedFunctionExecutable.  This is ok to do because our CodeCache
499            currently does not cache UnlinkedFunctionExecutables for class constructors.
500
501         2. The ClassExprNode now tracks the SourceCode range for the class expression.
502            This is used to set m_classSource in the UnlinkedFunctionExecutable at
503            bytecode generation time, and the FunctionExecutable later at bytecode
504            linking time.
505
506         3. Function.prototype.toString() now checks if the function is for a class.
507            If so, it returns the string for the class source instead of just the
508            function source for the class constructor.
509
510            Note: the class source is static from the time the class was parsed.  This
511            can introduces some weirdness at runtime.  Consider the following:
512
513                var v1 = class {}
514                v1.toString(); // yields "class {}".
515
516                class c2 extends v1 {}
517
518                c2.__proto__ === v1; // yields true i.e. c2 extends v1.
519                c2.toString(); // yields "class c2 extends v1 {}" which is fine.
520
521                v1 = {}; // point v1 to something else now.
522
523                c2.__proto__ === v1; // now yields false i.e. c2 no longer extends v1.
524                                     // c2 actually extends the class that v1 used to
525                                     // point to, but ...
526                c2.toString(); // still yields "class c2 extends v1 {}" which is no longer true.
527
528            It is unclear how we can best implement toString() to avoid this issue.
529            The above behavior is how Chrome (Version 51.0.2671.0 canary (64-bit))
530            currently implements toString() of a class, and we do the same in this patch.
531            In Firefox (45.0), toString() of a class will yield the function source of it
532            constructor function, which is not better.
533
534         In this patch, we also added ES6 compliance for Function.name on class objects:
535
536         4. The ClassExprNode now has a m_ecmaName string for tracking the inferred
537            name of a class according to the ES6 spec.  The ASTBuilder now mirrors its
538            handling of FuncExprNodes to ClassExprNodes in setting the nodes' m_ecmaName
539            where relevant.
540
541            The m_ecmaName is later used to set the m_ecmaName of the FunctionExecutable
542            of the class constructor, which in turn is used to populate the initial value
543            of the Function.name property.
544
545         5. Also renamed some variable names (/m_metadata/metadata/) to be consistent with
546            webkit naming convention.
547
548         * bytecode/UnlinkedFunctionExecutable.cpp:
549         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
550         * bytecode/UnlinkedFunctionExecutable.h:
551         * bytecompiler/BytecodeGenerator.cpp:
552         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
553         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
554         * bytecompiler/BytecodeGenerator.h:
555         * bytecompiler/NodesCodegen.cpp:
556         (JSC::ClassExprNode::emitBytecode):
557         * parser/ASTBuilder.h:
558         (JSC::ASTBuilder::createAssignResolve):
559         (JSC::ASTBuilder::createYield):
560         (JSC::ASTBuilder::createClassExpr):
561         (JSC::ASTBuilder::createFunctionExpr):
562         (JSC::ASTBuilder::createProperty):
563         (JSC::ASTBuilder::makeAssignNode):
564         * parser/NodeConstructors.h:
565         (JSC::FunctionParameters::FunctionParameters):
566         (JSC::BaseFuncExprNode::BaseFuncExprNode):
567         (JSC::FuncExprNode::FuncExprNode):
568         (JSC::FuncDeclNode::FuncDeclNode):
569         (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
570         (JSC::ClassDeclNode::ClassDeclNode):
571         (JSC::ClassExprNode::ClassExprNode):
572         * parser/Nodes.h:
573         (JSC::ExpressionNode::isDestructuringNode):
574         (JSC::ExpressionNode::isFuncExprNode):
575         (JSC::ExpressionNode::isArrowFuncExprNode):
576         (JSC::ExpressionNode::isClassExprNode):
577         (JSC::ExpressionNode::isCommaNode):
578         (JSC::ExpressionNode::isSimpleArray):
579         (JSC::ExpressionNode::isAdd):
580         * parser/Parser.cpp:
581         (JSC::stringForFunctionMode):
582         (JSC::Parser<LexerType>::parseFunctionInfo):
583         (JSC::Parser<LexerType>::parseClass):
584         * parser/ParserFunctionInfo.h:
585         * parser/SyntaxChecker.h:
586         (JSC::SyntaxChecker::createEmptyLetExpression):
587         (JSC::SyntaxChecker::createYield):
588         (JSC::SyntaxChecker::createClassExpr):
589         (JSC::SyntaxChecker::createFunctionExpr):
590         (JSC::SyntaxChecker::createFunctionMetadata):
591         (JSC::SyntaxChecker::createArrowFunctionExpr):
592         * runtime/Executable.cpp:
593         (JSC::FunctionExecutable::FunctionExecutable):
594         (JSC::FunctionExecutable::finishCreation):
595         * runtime/Executable.h:
596         * runtime/FunctionPrototype.cpp:
597         (JSC::functionProtoFuncToString):
598         * tests/es6.yaml:
599
600 2016-03-11  Commit Queue  <commit-queue@webkit.org>
601
602         Unreviewed, rolling out r197994.
603         https://bugs.webkit.org/show_bug.cgi?id=155368
604
605         Broke several ARM tests (Requested by msaboff on #webkit).
606
607         Reverted changeset:
608
609         "[JSC] Add register reuse for ArithAdd of an Int32 and
610         constant in DFG"
611         https://bugs.webkit.org/show_bug.cgi?id=155164
612         http://trac.webkit.org/changeset/197994
613
614 2016-03-11  Yusuke Suzuki  <utatane.tea@gmail.com>
615
616         [ES6] Implement Reflect.set without receiver support
617         https://bugs.webkit.org/show_bug.cgi?id=155024
618
619         Reviewed by Geoffrey Garen.
620
621         This patch implements Reflect.set.
622         The challenge in this patch is Reflect.set requires boolean result of [[Set]],
623         this is not propagated in the previous JSC put implementation.
624
625         This patch changes the put and putByIndex signature from `void put(...)` and `void putByIndex(...)` to `bool put(...)` and `bool putByIndex(...)`,
626         more consistent style to the ECMA262 spec's [[Set]].
627
628         This patch modifies so many part of WebKit. But almost all the changes are mechanical ones.
629
630         Currently, this patch does not support receiver modification support.
631         This will be supported in the subsequent patch[1].
632
633         [1]: https://bugs.webkit.org/show_bug.cgi?id=155294
634
635         * API/JSCallbackObject.h:
636         * API/JSCallbackObjectFunctions.h:
637         (JSC::JSCallbackObject<Parent>::put):
638         (JSC::JSCallbackObject<Parent>::putByIndex):
639         * debugger/DebuggerScope.cpp:
640         (JSC::DebuggerScope::put):
641         * debugger/DebuggerScope.h:
642         * jsc.cpp:
643         (WTF::RuntimeArray::put):
644         * runtime/ClassInfo.h:
645         * runtime/ClonedArguments.cpp:
646         (JSC::ClonedArguments::put):
647         * runtime/ClonedArguments.h:
648         * runtime/CustomGetterSetter.cpp:
649         (JSC::callCustomSetter):
650         * runtime/CustomGetterSetter.h:
651         * runtime/GenericArguments.h:
652         * runtime/GenericArgumentsInlines.h:
653         (JSC::GenericArguments<Type>::put):
654         (JSC::GenericArguments<Type>::putByIndex):
655         * runtime/GetterSetter.cpp:
656         (JSC::callSetter):
657         * runtime/GetterSetter.h:
658         * runtime/JSArray.cpp:
659         (JSC::JSArray::defineOwnProperty):
660         (JSC::JSArray::put):
661         (JSC::JSArray::push):
662         * runtime/JSArray.h:
663         * runtime/JSArrayBuffer.cpp:
664         (JSC::JSArrayBuffer::put):
665         * runtime/JSArrayBuffer.h:
666         * runtime/JSArrayBufferView.cpp:
667         (JSC::JSArrayBufferView::put):
668         * runtime/JSArrayBufferView.h:
669         * runtime/JSCJSValue.cpp:
670         (JSC::JSValue::putToPrimitive):
671         (JSC::JSValue::putToPrimitiveByIndex):
672         * runtime/JSCJSValue.h:
673         * runtime/JSCJSValueInlines.h:
674         (JSC::JSValue::put):
675         (JSC::JSValue::putInline):
676         (JSC::JSValue::putByIndex):
677         * runtime/JSCell.cpp:
678         (JSC::JSCell::put):
679         (JSC::JSCell::putByIndex):
680         * runtime/JSCell.h:
681         * runtime/JSDataView.cpp:
682         (JSC::JSDataView::put):
683         * runtime/JSDataView.h:
684         * runtime/JSFunction.cpp:
685         (JSC::JSFunction::put):
686         (JSC::JSFunction::defineOwnProperty):
687         * runtime/JSFunction.h:
688         * runtime/JSGenericTypedArrayView.h:
689         * runtime/JSGenericTypedArrayViewInlines.h:
690         (JSC::JSGenericTypedArrayView<Adaptor>::put):
691         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
692         * runtime/JSGlobalLexicalEnvironment.cpp:
693         (JSC::JSGlobalLexicalEnvironment::put):
694         * runtime/JSGlobalLexicalEnvironment.h:
695         * runtime/JSGlobalObject.cpp:
696         (JSC::JSGlobalObject::put):
697         * runtime/JSGlobalObject.h:
698         * runtime/JSLexicalEnvironment.cpp:
699         (JSC::JSLexicalEnvironment::put):
700         * runtime/JSLexicalEnvironment.h:
701         * runtime/JSModuleEnvironment.cpp:
702         (JSC::JSModuleEnvironment::put):
703         * runtime/JSModuleEnvironment.h:
704         * runtime/JSModuleNamespaceObject.cpp:
705         (JSC::JSModuleNamespaceObject::put):
706         (JSC::JSModuleNamespaceObject::putByIndex):
707         * runtime/JSModuleNamespaceObject.h:
708         * runtime/JSModuleRecord.cpp:
709         (JSC::JSModuleRecord::instantiateDeclarations):
710         * runtime/JSObject.cpp:
711         (JSC::JSObject::put):
712         (JSC::JSObject::putInlineSlow):
713         (JSC::JSObject::putByIndex):
714         (JSC::JSObject::putGetter):
715         (JSC::JSObject::putSetter):
716         (JSC::JSObject::putDirectAccessor):
717         (JSC::JSObject::putDirectCustomAccessor):
718         (JSC::JSObject::putDirectNonIndexAccessor):
719         (JSC::JSObject::putIndexedDescriptor):
720         (JSC::JSObject::defineOwnIndexedProperty):
721         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
722         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
723         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
724         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
725         (JSC::JSObject::putByIndexBeyondVectorLength):
726         (JSC::JSObject::putDirectNativeIntrinsicGetter):
727         (JSC::JSObject::putDirectNativeFunction):
728         (JSC::JSObject::putDirectMayBeIndex):
729         (JSC::validateAndApplyPropertyDescriptor):
730         * runtime/JSObject.h:
731         (JSC::JSObject::putByIndexInline):
732         (JSC::JSObject::putDirect):
733         * runtime/JSObjectInlines.h:
734         (JSC::JSObject::putInline):
735         * runtime/JSProxy.cpp:
736         (JSC::JSProxy::put):
737         (JSC::JSProxy::putByIndex):
738         * runtime/JSProxy.h:
739         * runtime/JSSymbolTableObject.h:
740         (JSC::symbolTablePut):
741         (JSC::symbolTablePutTouchWatchpointSet):
742         (JSC::symbolTablePutInvalidateWatchpointSet):
743         (JSC::symbolTablePutWithAttributesTouchWatchpointSet):
744         * runtime/Lookup.h:
745         (JSC::putEntry):
746         (JSC::lookupPut):
747         * runtime/ProxyObject.cpp:
748         (JSC::ProxyObject::performPut):
749         (JSC::ProxyObject::put):
750         (JSC::ProxyObject::putByIndexCommon):
751         (JSC::ProxyObject::putByIndex):
752         * runtime/ProxyObject.h:
753         * runtime/PutPropertySlot.h:
754         * runtime/ReflectObject.cpp:
755         (JSC::reflectObjectSet):
756         * runtime/RegExpConstructor.cpp:
757         (JSC::setRegExpConstructorInput):
758         (JSC::setRegExpConstructorMultiline):
759         * runtime/RegExpObject.cpp:
760         (JSC::RegExpObject::defineOwnProperty):
761         (JSC::regExpObjectSetLastIndexStrict):
762         (JSC::regExpObjectSetLastIndexNonStrict):
763         (JSC::RegExpObject::put):
764         * runtime/RegExpObject.h:
765         * runtime/SparseArrayValueMap.cpp:
766         (JSC::SparseArrayValueMap::putEntry):
767         (JSC::SparseArrayEntry::put):
768         * runtime/SparseArrayValueMap.h:
769         * runtime/StringObject.cpp:
770         (JSC::StringObject::put):
771         (JSC::StringObject::putByIndex):
772         * runtime/StringObject.h:
773         * tests/es6.yaml:
774         * tests/modules/namespace.js:
775         * tests/stress/reflect-set.js: Added.
776         (shouldBe):
777         (shouldThrow):
778         (receiverCase.object2.set Cocoa):
779         (receiverCase):
780         (proxyCase):
781         (objectCase.set get shouldBe):
782         (objectCase.get shouldBe):
783         (arrayCase.set get shouldBe):
784         (arrayCase.get shouldBe):
785         (arrayBufferCase.set get shouldBe):
786         (arrayBufferCase.get shouldBe):
787         (set get shouldBe):
788         (get shouldBe):
789         (argumentCase.test1):
790         (argumentCase.test2):
791         (argumentCase.test3):
792         (argumentCase.test4.set get shouldBe):
793         (argumentCase.test5.get shouldBe):
794         (argumentStrictCase.test1):
795         (argumentStrictCase.test2):
796         (argumentStrictCase.test3):
797         (argumentStrictCase.test4.set get shouldBe):
798         (argumentStrictCase.test5.get shouldBe):
799         (stringObjectCase.set get shouldBe):
800         (stringObjectCase.get shouldBe):
801         (customSetter.test1):
802         (customSetter.test2):
803         (customSetter.test3):
804         (customSetter):
805         (regExpLastIndex):
806         (functionCase.func):
807
808 2016-03-10  Brian Burg  <bburg@apple.com>
809
810         Web Inspector: generated initWithPayload: protocol object initializers should recursively decode array and object members
811         https://bugs.webkit.org/show_bug.cgi?id=155337
812         <rdar://problem/25098357>
813
814         Reviewed by Timothy Hatcher.
815
816         In cases where an object member is itself an object or array, we were
817         not calling initWithPayload: on the object member itself. So, this caused
818         a runtime error when constructing the outer object because the generated
819         code casted the NSDictionary/NSArray into the member's protocol object type.
820
821         * inspector/scripts/codegen/objc_generator.py:
822         (ObjCGenerator.payload_to_objc_expression_for_member):
823         Do a straightforward call to initWithPayload: for objects. For arrays,
824         call a templated helper function which does the same thing. The helper
825         is used to make this array decoding fit into a single generated expression.
826
827         Rebaseline relevant test results.
828
829         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
830         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
831         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
832
833 2016-03-10  Keith Miller  <keith_miller@apple.com>
834
835         Unreviewed, fix Changelog. git merged poorly.
836
837 2016-03-10  Keith Miller  <keith_miller@apple.com>
838
839         Unreviewed, fix testapi.
840
841         * API/tests/TypedArrayCTest.cpp:
842         (testAccess):
843         (testConstructors):
844         (forEachTypedArrayType):
845         (testTypedArrayCAPI):
846
847 2016-03-10  Saam barati  <sbarati@apple.com>
848
849         [ES6] Make RegExp.prototype.toString spec compliant
850         https://bugs.webkit.org/show_bug.cgi?id=155341
851
852         Reviewed by Filip Pizlo.
853
854         Before we were directly calling into the flagsString
855         function. Instead, we must get the "flags" property
856         of the thisObject. This will usually call into the flags
857         getter, but not always. Specifically, you can you a Proxy
858         to observe this behavior.
859
860         * runtime/RegExpPrototype.cpp:
861         (JSC::regExpProtoFuncToString):
862         (JSC::regExpProtoGetterGlobal):
863         * tests/es6.yaml:
864         * tests/es6/Proxy_internal_get_calls_RegExp.prototype.toString.js: Added.
865         (test.get var):
866         (test.):
867         * tests/stress/regexp-prototype-tostring.js: Added.
868         (assert):
869         (test):
870         (test.get var):
871         (test.):
872         (let.handler.get switch):
873         (let.handler):
874         (get test):
875         (test.get RegExp):
876
877 2016-03-10  Benjamin Poulain  <bpoulain@apple.com>
878
879         [JSC] Add register reuse for ArithAdd of an Int32 and constant in DFG
880         https://bugs.webkit.org/show_bug.cgi?id=155164
881
882         Reviewed by Geoffrey Garen.
883
884         Every "inc" in loop was looking like this:
885             move rX, rY
886             inc rY
887             jo 0x230f4a200580
888
889         This patch add register Reuse to that case to remove
890         the extra "move".
891
892         * dfg/DFGOSRExit.h:
893         (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
894         (JSC::DFG::SpeculationRecovery::immediate):
895         * dfg/DFGOSRExitCompiler32_64.cpp:
896         (JSC::DFG::OSRExitCompiler::compileExit):
897         * dfg/DFGOSRExitCompiler64.cpp:
898         (JSC::DFG::OSRExitCompiler::compileExit):
899         * dfg/DFGSpeculativeJIT.cpp:
900         (JSC::DFG::SpeculativeJIT::compileArithAdd):
901         * tests/stress/arith-add-with-constant-overflow.js: Added.
902         (opaqueAdd):
903
904 2016-03-10  Keith Miller  <keith_miller@apple.com>
905
906         Unreviewed, build fix for r197983, hopefully.
907
908         * API/WebKitAvailability.h:
909
910 2016-03-10  Keith Miller  <keith_miller@apple.com>
911
912         Typed Arrays have no public facing API
913         https://bugs.webkit.org/show_bug.cgi?id=120112
914
915         Reviewed by Geoffrey Garen.
916
917         This patch adds a new C-API (an Obj-C API will follow in the future) for Typed Arrays. The API has two sets of
918         functions. One for Typed Arrays and another for Array Buffers. This API is intended to reflect the use of Typed
919         Array objects in JS code. There is a method for each of the core TypedArray and Array Buffer methods.
920         Originally, we were planning on using a separate non-JS object as the backing store instead of a JS Array Buffer
921         but we decide to defer that idea since there was no good CF/NS API that met all the constraints we needed
922         (Discussed further below). We also wanted to want until Shared Array Buffers had reached a more finished state
923         to see what impact they might have on an API.
924
925         The API has the following Typed Array construction methods:
926         1) Create with length (the backing buffer is zero initialized). -- JSObjectMakeTypedArray
927         2) Create with an existing pointer and a destructor. -- JSObjectMakeTypedArrayFromBytesNoCopy
928         3) Create with an Array Buffer object. -- JSObjectMakeTypedArrayFromArrayBuffer
929         4) Create with an Array Buffer object with a given offset and length. -- JSObjectMakeTypedArrayFromArrayBufferWithOffset
930
931         The API has the following functions on Typed Array JSObjectRefs:
932         5) Get access to a temporary void* of the backing store's data. -- JSObjectGetTypedArrayBytesPtr
933         6) Get the length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayLength
934         7) Get the byte length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteLength
935         8) Get the byte offset of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteOffset
936         9) Get a Typed Array object's Array Buffer  backing store. -- JSObjectGetTypedArrayBuffer
937
938         The API has the following Array Buffer construction method:
939         10) Create with an existing pointer and a destructor. -- JSObjectMakeArrayBufferWithBytesNoCopy
940
941         The API has the following functions on Array Buffer JSObjectRefs:
942         11) Get access to a temporary void* of the backing store's data. -- JSObjectGetArrayBufferBytesPtr
943         12) Get the byte length of an Array Buffer object (returns 0 if it is not an Array Buffer object). -- JSObjectGetArrayBufferByteLength
944
945         The API adds the following new typedefs and enumerations:
946         13) A typedef representing the function pointer type used to deallocate byte pointers provided to constructors. -- JSTypedArrayByesDeallocator
947         14) An enumeration indicating the Typed Array API type of a JSValueRef. -- JSTypedArrayType
948
949         Finally, The API has the following function to get Typed Array Types:
950         15)  Get the Typed Array type of a JS value. -- JSValueGetTypedArrayType
951
952         There are a couple of things to note about these functions. Calling JSObjectGetTypedArrayBytesPtr (5) or
953         JSObjectGetArrayBufferBytesPtr (12) will pin and lock the ArrayBuffer's data for the remaining lifetime of that
954         ArrayBuffer. This is because, currently, we do not have finalizers for our Array Buffers or Typed Arrays with a
955         backing ArrayBuffer and adding one would likely incur a non-trivial cost to GC. Also, we do not have a direct
956         way to make a Typed Array from a pointer with an offset as we do not expect using offsets to be a common use
957         case of the API.
958
959         While it would have been nice to integrate our backing store with CFData or one of its subclasses, it is not
960         possible to force a CFData/CFMutableData to be both writable and have a fixed size/backing store pointer.
961         NSData is not writable and CFMutableData can have a fixed pointer if it is allocated with a non-zero capacity
962         but there is no way for us to force an existing CFMutableData into this state.
963
964         * API/APIUtils.h: Copied from Source/JavaScriptCore/runtime/ArrayBuffer.cpp.
965         (handleExceptionIfNeeded):
966         (setException):
967         * API/JSBase.h:
968         * API/JSObjectRef.cpp:
969         (handleExceptionIfNeeded): Deleted.
970         * API/JSTypedArray.cpp: Added.
971         (toJSTypedArrayType):
972         (toTypedArrayType):
973         (createTypedArray):
974         (JSValueGetTypedArrayType):
975         (JSObjectMakeTypedArray):
976         (JSObjectMakeTypedArrayWithBytesNoCopy):
977         (JSObjectMakeTypedArrayWithArrayBuffer):
978         (JSObjectMakeTypedArrayWithArrayBufferAndOffset):
979         (JSObjectGetTypedArrayBytesPtr):
980         (JSObjectGetTypedArrayLength):
981         (JSObjectGetTypedArrayByteLength):
982         (JSObjectGetTypedArrayByteOffset):
983         (JSObjectGetTypedArrayBuffer):
984         (JSObjectMakeArrayBufferWithBytesNoCopy):
985         (JSObjectGetArrayBufferBytesPtr):
986         (JSObjectGetArrayBufferByteLength):
987         * API/JSTypedArray.h: Added.
988         * API/JSValueRef.cpp:
989         (handleExceptionIfNeeded): Deleted.
990         * API/JSValueRef.h:
991         * API/JavaScript.h:
992         * API/WebKitAvailability.h:
993         * API/tests/TypedArrayCTest.cpp: Added.
994         (id):
995         (freePtr):
996         (assertEqualsAsNumber):
997         (testAccess):
998         (testConstructors):
999         (forEachTypedArrayType):
1000         (testTypedArrayCAPI):
1001         * API/tests/TypedArrayCTest.h: Added.
1002         * API/tests/testapi.c:
1003         (main):
1004         * CMakeLists.txt:
1005         * ForwardingHeaders/JavaScriptCore/JSTypedArray.h: Added.
1006         * JavaScriptCore.xcodeproj/project.pbxproj:
1007         * PlatformEfl.cmake:
1008         * PlatformGTK.cmake:
1009         * runtime/ArrayBuffer.cpp:
1010         (JSC::ArrayBuffer::transfer):
1011         * runtime/ArrayBuffer.h:
1012         (JSC::arrayBufferDestructorNull):
1013         (JSC::arrayBufferDestructorDefault):
1014         (JSC::ArrayBufferContents::ArrayBufferContents):
1015         (JSC::ArrayBufferContents::transfer):
1016         (JSC::ArrayBuffer::createAdopted):
1017         (JSC::ArrayBuffer::createFromBytes):
1018         (JSC::ArrayBuffer::ArrayBuffer):
1019         (JSC::ArrayBuffer::pinAndLock):
1020         (JSC::ArrayBufferContents::tryAllocate):
1021         (JSC::ArrayBufferContents::~ArrayBufferContents):
1022         * shell/PlatformWin.cmake:
1023
1024 2016-03-10  Saam barati  <sbarati@apple.com>
1025
1026         [ES6] Instanceof isn't spec compliant when the RHS is a Proxy with a target that is a function
1027         https://bugs.webkit.org/show_bug.cgi?id=155329
1028
1029         Reviewed by Mark Lam.
1030
1031         We use type info flags on the structure to dictate whether or not 
1032         the RHS of an instanceof is a valid RHS (i.e, a function). The solution
1033         to make Proxy a valid RHS when the Proxy's target is callable is to have
1034         two different structures for ProxyObject: one for a non-callable target 
1035         and one for a callable target.
1036
1037         * runtime/JSGlobalObject.cpp:
1038         (JSC::JSGlobalObject::init):
1039         (JSC::JSGlobalObject::visitChildren):
1040         * runtime/JSGlobalObject.h:
1041         (JSC::JSGlobalObject::moduleRecordStructure):
1042         (JSC::JSGlobalObject::moduleNamespaceObjectStructure):
1043         (JSC::JSGlobalObject::proxyObjectStructure):
1044         (JSC::JSGlobalObject::callableProxyObjectStructure):
1045         (JSC::JSGlobalObject::proxyRevokeStructure):
1046         (JSC::JSGlobalObject::wasmModuleStructure):
1047         * runtime/ProxyConstructor.cpp:
1048         (JSC::makeRevocableProxy):
1049         (JSC::constructProxyObject):
1050         (JSC::ProxyConstructor::getConstructData):
1051         * runtime/ProxyObject.cpp:
1052         (JSC::ProxyObject::ProxyObject):
1053         (JSC::ProxyObject::structureForTarget):
1054         (JSC::ProxyObject::finishCreation):
1055         * runtime/ProxyObject.h:
1056         (JSC::ProxyObject::create):
1057         (JSC::ProxyObject::createStructure):
1058         * tests/es6.yaml:
1059         * tests/stress/proxy-instanceof.js: Added.
1060         (assert):
1061         (test):
1062         (C):
1063         (test.let.handler.get if):
1064         (test.let.handler):
1065
1066 2016-03-10  Michael Saboff  <msaboff@apple.com>
1067
1068         [ES6] RegExp sticky flag should be ignored in String.match when global flag is given
1069         https://bugs.webkit.org/show_bug.cgi?id=155332
1070
1071         Reviewed by Saam Barati.
1072
1073         Removed logic from stringProtoFuncMatch that handles the case where both global and sticky flags are set.
1074
1075         * runtime/StringPrototype.cpp:
1076         (JSC::stringProtoFuncMatch):
1077
1078 2016-03-10  Michael Saboff  <msaboff@apple.com>
1079
1080         [ES6] Allow RegExp constructor to take pattern from an existing RegExp with new flags
1081         https://bugs.webkit.org/show_bug.cgi?id=155315
1082
1083         Reviewed by Saam Barati.
1084
1085         Changed to comply with section 21.2.3.1, step 5.  Eliminated syntax error.
1086
1087         In the process, change to get the VM at the top of the function.
1088
1089         Updated tests accordingly.
1090
1091         * runtime/RegExpConstructor.cpp:
1092         (JSC::constructRegExp):
1093         * tests/es6.yaml: Changed miscellaneous_RegExp_constructor_can_alter_flags.js to normal.
1094         * tests/mozilla/mozilla-tests.yaml: Disabled ecma_3/RegExp/15.10.4.1-5-n.js as it checks
1095         for the old behavior of throwing a syntax error.
1096
1097 2016-03-10  Saam barati  <sbarati@apple.com>
1098
1099         [ES6] Make ToPropertyDescriptor spec compliant
1100         https://bugs.webkit.org/show_bug.cgi?id=155313
1101
1102         Reviewed by Mark Lam.
1103
1104         We were performing HasProperty(.) and Get(.) in the same operation.
1105         This isn't valid according to the spec and it's user observable
1106         behavior with Proxy. This patch fixes ToPropertyDescriptor to use
1107         two distinct operations for HasProperty(.) and Get(.).
1108
1109         * runtime/ObjectConstructor.cpp:
1110         (JSC::ownEnumerablePropertyKeys):
1111         (JSC::toPropertyDescriptor):
1112         * tests/es6.yaml:
1113         * tests/stress/to-property-key-correctness.js: Added.
1114         (assert):
1115         (test):
1116         (test.let.handler.has):
1117         (arrayEq):
1118         (let.handler.has):
1119         (let.target):
1120         (set get let):
1121
1122 2016-03-10  Brian Burg  <bburg@apple.com>
1123
1124         Web Inspector: report the underlying parser error message when JSON parsing fails
1125         https://bugs.webkit.org/show_bug.cgi?id=155303
1126         <rdar://problem/25088939>
1127
1128         Reviewed by Timothy Hatcher.
1129
1130         * inspector/scripts/generate-inspector-protocol-bindings.py:
1131         (generate_from_specification.load_specification):
1132         Stringize the underlying error so we can see what it says.
1133
1134 2016-03-09  Joseph Pecoraro  <pecoraro@apple.com>
1135
1136         Web Inspector: JavaScript Heap Allocations Timeline
1137         https://bugs.webkit.org/show_bug.cgi?id=155287
1138         <rdar://problem/25078088>
1139
1140         Reviewed by Timothy Hatcher.
1141
1142         * inspector/InjectedScriptSource.js:
1143         (InjectedScript.prototype._describe):
1144         (InjectedScript.prototype._nodeDescription):
1145         Provide the nicer node preview more often.
1146
1147 2016-03-10  Saam barati  <sbarati@apple.com>
1148
1149         Assignment to new.target should be an early error
1150         https://bugs.webkit.org/show_bug.cgi?id=151148
1151
1152         Reviewed by Mark Lam.
1153
1154         This patch makes it so that any form of assignment to new.target
1155         is an early syntax error.
1156
1157         * parser/ASTBuilder.h:
1158         (JSC::ASTBuilder::createNewTargetExpr):
1159         (JSC::ASTBuilder::isNewTarget):
1160         (JSC::ASTBuilder::createResolve):
1161         * parser/Parser.cpp:
1162         (JSC::Parser<LexerType>::parseAssignmentExpression):
1163         (JSC::Parser<LexerType>::parseUnaryExpression):
1164         * parser/SyntaxChecker.h:
1165         (JSC::SyntaxChecker::createThisExpr):
1166         (JSC::SyntaxChecker::createSuperExpr):
1167         (JSC::SyntaxChecker::createNewTargetExpr):
1168         (JSC::SyntaxChecker::isNewTarget):
1169         (JSC::SyntaxChecker::createResolve):
1170         (JSC::SyntaxChecker::createObjectLiteral):
1171         * tests/es6.yaml:
1172         * tests/stress/new-target-syntax-errors.js: Added.
1173         (shouldBeSyntaxError):
1174         (shouldNotBeSyntaxError):
1175         * tests/stress/new-target.js:
1176         (Constructor):
1177         (doWeirdThings):
1178         (noAssign): Deleted.
1179         (catch): Deleted.
1180
1181 2016-03-08  Skachkov Oleksandr  <gskachkov@gmail.com>
1182
1183         How we load new.target in arrow functions is broken
1184         https://bugs.webkit.org/show_bug.cgi?id=155153
1185
1186         Reviewed by Saam Barati.
1187
1188         Fixed not correct approach of caching new.target. In current patch was added code feature
1189         flag that shows that current function is using new.target, when generating byte code an arrow 
1190         function we are loading new.target value to its register from arrow function lexical environment. 
1191
1192         * bytecompiler/BytecodeGenerator.cpp:
1193         (JSC::BytecodeGenerator::BytecodeGenerator):
1194         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
1195         * bytecompiler/BytecodeGenerator.h:
1196         (JSC::BytecodeGenerator::newTarget):
1197         * parser/ASTBuilder.h:
1198         (JSC::ASTBuilder::createNewTargetExpr):
1199         (JSC::ASTBuilder::usesNewTarget):
1200         * parser/Nodes.h:
1201         (JSC::ScopeNode::usesNewTarget):
1202         * parser/ParserModes.h:
1203         * tests/stress/arrowfunction-lexical-bind-newtarget.js:
1204
1205 2016-03-09  Joseph Pecoraro  <pecoraro@apple.com>
1206
1207         Web Inspector: Get a RemoteObject or ObjectPreview from HeapSnapshot Object Identifier
1208         https://bugs.webkit.org/show_bug.cgi?id=155264
1209         <rdar://problem/25070716>
1210
1211         Reviewed by Timothy Hatcher.
1212
1213         * inspector/InjectedScript.h:
1214         * inspector/InjectedScript.cpp:
1215         (Inspector::InjectedScript::functionDetails):
1216         (Inspector::InjectedScript::previewValue):
1217         New InjectedScript methods for building Debugger.FunctionDetails
1218         or Runtime.ObjectPreview protocol objects from a JSValue.
1219
1220         * inspector/InjectedScriptSource.js:
1221         (InjectedScript.prototype.previewValue):
1222         (InjectedScript.prototype.functionDetails):
1223         (InjectedScript.prototype.getFunctionDetails):
1224         (InjectedScript.RemoteObject.prototype._isPreviewableObjectInternal):
1225         (InjectedScript.RemoteObject.prototype._createObjectPreviewForValue): Deleted.
1226         (InjectedScript.RemoteObject.prototype._appendEntryPreviews): Deleted.
1227         Share code around creating function details or object preview objects.
1228
1229         * inspector/agents/InspectorHeapAgent.cpp:
1230         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
1231         (Inspector::InspectorHeapAgent::nodeForHeapObjectIdentifier):
1232         (Inspector::InspectorHeapAgent::getPreview):
1233         (Inspector::InspectorHeapAgent::getRemoteObject):
1234         * inspector/agents/InspectorHeapAgent.h:
1235         * inspector/protocol/Heap.json:
1236         New protocol methods that go from heap object identifier to a
1237         remote object or some kind of preview.
1238
1239         * inspector/scripts/codegen/generator.py:
1240         Allow runtime casts for ObjectPreview.
1241
1242 2016-03-09  Andy VanWagoner  <thetalecrafter@gmail.com>
1243
1244         [INTL] Intl Constructors not web compatible with Object.create usage
1245         https://bugs.webkit.org/show_bug.cgi?id=153679
1246
1247         Reviewed by Darin Adler.
1248
1249         Add workaround for initializing NumberFormat and DateTimeFormat objects
1250         using Object.create followed by constructor.call. This is necessary for
1251         backwards compatibility with libraries relying on v1 behavior of Intl
1252         constructors.
1253
1254         Collator does not get the workaround, since polyfills do not include it,
1255         and there are not any known instances of v2 incompatible libraries.
1256
1257         The workaround involves checking for an object that inherits from the
1258         *Format constructor, but was not actually initialized with that type. A
1259         substitute instance is created and attached to the object using a private
1260         name. The prototype functions then check for the private property to use
1261         in place of the original object.
1262
1263         Since this behavior is not part of the v2 spec, it should be removed as
1264         soon as the incompatible behavior is no longer in common use.
1265
1266         * runtime/CommonIdentifiers.h:
1267         * runtime/IntlDateTimeFormatConstructor.cpp:
1268         (JSC::callIntlDateTimeFormat):
1269         * runtime/IntlDateTimeFormatPrototype.cpp:
1270         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
1271         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
1272         * runtime/IntlNumberFormatConstructor.cpp:
1273         (JSC::callIntlNumberFormat):
1274         * runtime/IntlNumberFormatPrototype.cpp:
1275         (JSC::IntlNumberFormatPrototypeGetterFormat):
1276         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
1277
1278 2016-03-09  Saam barati  <sbarati@apple.com>
1279
1280         Add proper JSON.stringify support for Proxy when the target is an array
1281         https://bugs.webkit.org/show_bug.cgi?id=155180
1282
1283         Reviewed by Darin Adler.
1284
1285         This patch makes the following type of program true:
1286         `JSON.stringify(new Proxy([25], {})) === "[25]"`
1287
1288         We need to change the JSON stringifier to use the IsArray test
1289         in section 7.2.2 of ES6 spec instead of the JSC inherits(JSArray::info())
1290         test.
1291
1292         This patch also adds tests for general JSON.stringify support
1293         of Proxy.
1294
1295         * runtime/ArrayConstructor.cpp:
1296         (JSC::arrayConstructorIsArray):
1297         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
1298         * runtime/ArrayConstructor.h:
1299         (JSC::isArray):
1300         * runtime/JSONObject.cpp:
1301         (JSC::Stringifier::Holder::object):
1302         (JSC::Stringifier::appendStringifiedValue):
1303         (JSC::Stringifier::startNewLine):
1304         (JSC::Stringifier::Holder::Holder):
1305         * tests/es6.yaml:
1306         * tests/stress/proxy-json.js: Added.
1307         (assert):
1308         (test):
1309
1310 2016-03-09  Saam Barati  <sbarati@apple.com>
1311
1312         ES6: Implement lexical scoping for function definitions in strict mode
1313         https://bugs.webkit.org/show_bug.cgi?id=152844
1314
1315         Reviewed by Geoffrey Garen.
1316
1317         This patch implements block scoping for function definitions
1318         in strict mode. The implementation works as follows:
1319         
1320         - If we're in sloppy mode, function declarations work exactly
1321           as they did before this patch. I.e, function declarations are hoisted
1322           and declared like "var" variables.
1323         
1324         - If you're in strict mode and at the top of a function scope or program
1325           scope, function declarations still work like they used to. They are defined
1326           like "var" variables. This is necessary for backwards compatibility
1327           because ES5 strict mode allowed duplicate function declarations at the
1328           top-most scope of a program/function.
1329         
1330         - If you're in strict mode and inside a block statement or a switch statement,
1331           function declarations are now block scoped. All function declarations within
1332           a block are hoisted to the beginning of the block. They are not hoisted out of the 
1333           block like they are in sloppy mode. This allows for the following types of
1334           programs:
1335           ```
1336           function foo() {
1337               function bar() { return 20; }
1338               {
1339                   function bar() { return 30; }
1340                   bar(); // 30
1341               }
1342               bar(); // 20
1343           }
1344           ```
1345
1346         * bytecompiler/BytecodeGenerator.cpp:
1347         (JSC::BytecodeGenerator::BytecodeGenerator):
1348         (JSC::BytecodeGenerator::instantiateLexicalVariables):
1349         (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
1350         (JSC::BytecodeGenerator::pushLexicalScope):
1351         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1352         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
1353         (JSC::BytecodeGenerator::popLexicalScope):
1354         (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
1355         (JSC::BytecodeGenerator::pushTDZVariables):
1356         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
1357         (JSC::BytecodeGenerator::emitNewRegExp):
1358         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
1359         (JSC::BytecodeGenerator::emitNewFunctionExpression):
1360         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
1361         * bytecompiler/BytecodeGenerator.h:
1362         * parser/ASTBuilder.h:
1363         (JSC::ASTBuilder::createSourceElements):
1364         (JSC::ASTBuilder::features):
1365         (JSC::ASTBuilder::numConstants):
1366         (JSC::ASTBuilder::createFuncDeclStatement):
1367         (JSC::ASTBuilder::createClassDeclStatement):
1368         (JSC::ASTBuilder::createBlockStatement):
1369         (JSC::ASTBuilder::createTryStatement):
1370         (JSC::ASTBuilder::createSwitchStatement):
1371         (JSC::ASTBuilder::Scope::Scope):
1372         (JSC::ASTBuilder::funcDeclarations): Deleted.
1373         * parser/NodeConstructors.h:
1374         (JSC::CaseBlockNode::CaseBlockNode):
1375         (JSC::SwitchNode::SwitchNode):
1376         (JSC::BlockNode::BlockNode):
1377         * parser/Nodes.cpp:
1378         (JSC::ScopeNode::ScopeNode):
1379         (JSC::ScopeNode::singleStatement):
1380         (JSC::ProgramNode::ProgramNode):
1381         (JSC::ModuleProgramNode::ModuleProgramNode):
1382         (JSC::EvalNode::EvalNode):
1383         (JSC::FunctionNode::FunctionNode):
1384         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
1385         * parser/Nodes.h:
1386         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
1387         (JSC::VariableEnvironmentNode::lexicalVariables):
1388         (JSC::VariableEnvironmentNode::functionStack):
1389         (JSC::ScopeNode::captures):
1390         (JSC::ScopeNode::varDeclarations):
1391         (JSC::ScopeNode::neededConstants):
1392         (JSC::ProgramNode::startColumn):
1393         (JSC::ProgramNode::endColumn):
1394         (JSC::EvalNode::startColumn):
1395         (JSC::EvalNode::endColumn):
1396         (JSC::ModuleProgramNode::startColumn):
1397         (JSC::ModuleProgramNode::endColumn):
1398         (JSC::ScopeNode::functionStack): Deleted.
1399         * parser/Parser.cpp:
1400         (JSC::Parser<LexerType>::parseInner):
1401         (JSC::Parser<LexerType>::didFinishParsing):
1402         (JSC::Parser<LexerType>::parseStatementListItem):
1403         (JSC::Parser<LexerType>::parseSwitchStatement):
1404         (JSC::Parser<LexerType>::parseBlockStatement):
1405         (JSC::Parser<LexerType>::parseStatement):
1406         (JSC::Parser<LexerType>::parseFunctionInfo):
1407         (JSC::getMetadata):
1408         (JSC::Parser<LexerType>::parseFunctionDeclaration):
1409         (JSC::Parser<LexerType>::parseExportDeclaration):
1410         * parser/Parser.h:
1411         (JSC::Scope::declareVariable):
1412         (JSC::Scope::declareFunction):
1413         (JSC::Scope::appendFunction):
1414         (JSC::Scope::takeFunctionDeclarations):
1415         (JSC::Scope::declareLexicalVariable):
1416         (JSC::Parser::currentVariableScope):
1417         (JSC::Parser::currentLexicalDeclarationScope):
1418         (JSC::Parser::currentFunctionScope):
1419         (JSC::Parser::pushScope):
1420         (JSC::Parser::popScopeInternal):
1421         (JSC::Parser::declareVariable):
1422         (JSC::Parser::declareFunction):
1423         (JSC::Parser::hasDeclaredVariable):
1424         (JSC::Parser::isFunctionMetadataNode):
1425         (JSC::Parser<LexerType>::parse):
1426         * parser/SyntaxChecker.h:
1427         (JSC::SyntaxChecker::createFuncDeclStatement):
1428         (JSC::SyntaxChecker::createClassDeclStatement):
1429         (JSC::SyntaxChecker::createBlockStatement):
1430         (JSC::SyntaxChecker::createExprStatement):
1431         (JSC::SyntaxChecker::createIfStatement):
1432         (JSC::SyntaxChecker::createContinueStatement):
1433         (JSC::SyntaxChecker::createTryStatement):
1434         (JSC::SyntaxChecker::createSwitchStatement):
1435         (JSC::SyntaxChecker::createWhileStatement):
1436         (JSC::SyntaxChecker::createWithStatement):
1437         (JSC::SyntaxChecker::createDoWhileStatement):
1438         * parser/VariableEnvironment.h:
1439         (JSC::VariableEnvironmentEntry::isExported):
1440         (JSC::VariableEnvironmentEntry::isImported):
1441         (JSC::VariableEnvironmentEntry::isImportedNamespace):
1442         (JSC::VariableEnvironmentEntry::isFunction):
1443         (JSC::VariableEnvironmentEntry::setIsCaptured):
1444         (JSC::VariableEnvironmentEntry::setIsConst):
1445         (JSC::VariableEnvironmentEntry::setIsExported):
1446         (JSC::VariableEnvironmentEntry::setIsImported):
1447         (JSC::VariableEnvironmentEntry::setIsImportedNamespace):
1448         (JSC::VariableEnvironmentEntry::setIsFunction):
1449         (JSC::VariableEnvironmentEntry::clearIsVar):
1450         (JSC::VariableEnvironment::VariableEnvironment):
1451         (JSC::VariableEnvironment::begin):
1452         (JSC::VariableEnvironment::end):
1453         * tests/es6.yaml:
1454         * tests/stress/block-scoped-function-declarations.js: Added.
1455         (assert):
1456         (test):
1457         (f.foo.bar):
1458         (f.foo.):
1459         (f.foo):
1460         (f):
1461         (assert.foo.):
1462         (assert.foo):
1463         (assert.foo.foo):
1464         (assert.foo.bar):
1465         (assert.foo.switch.case.1):
1466         (assert.foo.switch.case.2):
1467         (assert.foo.switch.foo):
1468         (assert.foo.switch.bar):
1469
1470 2016-03-09  Saam barati  <sbarati@apple.com>
1471
1472         Array.isArray support for Proxy
1473         https://bugs.webkit.org/show_bug.cgi?id=155179
1474
1475         Reviewed by Mark Lam.
1476
1477         This patch implements Array.isArray to be compliant
1478         with the ES6 spec. Specifically, it needs to interface
1479         properly with Proxy arguments.
1480         https://tc39.github.io/ecma262/#sec-isarray
1481
1482         * runtime/ArrayConstructor.cpp:
1483         (JSC::ArrayConstructor::getCallData):
1484         (JSC::arrayConstructorIsArray):
1485         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
1486         * runtime/ArrayPrototype.cpp:
1487         (JSC::speciesConstructArray):
1488         * runtime/ProxyObject.cpp:
1489         (JSC::ProxyObject::revoke):
1490         (JSC::ProxyObject::isRevoked):
1491         (JSC::ProxyObject::visitChildren):
1492         * runtime/ProxyObject.h:
1493         (JSC::ProxyObject::target):
1494         (JSC::ProxyObject::handler):
1495         * tests/es6.yaml:
1496         * tests/stress/proxy-is-array.js: Added.
1497         (assert):
1498         (test):
1499
1500 2016-03-09  Benjamin Poulain  <bpoulain@apple.com>
1501
1502         [JSC] Fix the ARM64 MacroAssembler after r197816
1503         https://bugs.webkit.org/show_bug.cgi?id=155268
1504
1505         Reviewed by Mark Lam.
1506
1507         The patch tries to generate instructions that do not exist,
1508         causing quite fun stuff at runtime.
1509
1510         * assembler/MacroAssemblerARM64.h:
1511         (JSC::MacroAssemblerARM64::load8):
1512         (JSC::MacroAssemblerARM64::store16):
1513         (JSC::MacroAssemblerARM64::store8):
1514
1515 2016-03-09  Commit Queue  <commit-queue@webkit.org>
1516
1517         Unreviewed, rolling out r197873.
1518         https://bugs.webkit.org/show_bug.cgi?id=155262
1519
1520         "Crashes some JSC tests" (Requested by mlam on #webkit).
1521
1522         Reverted changeset:
1523
1524         "Add dumping of function expression names in CodeBlock
1525         bytecode dump."
1526         https://bugs.webkit.org/show_bug.cgi?id=155248
1527         http://trac.webkit.org/changeset/197873
1528
1529 2016-03-09  Oliver Hunt  <oliver@apple.com>
1530
1531         Fix old iOS
1532
1533         * jit/ExecutableAllocatorFixedVMPool.cpp:
1534         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
1535
1536 2016-03-09  Oliver Hunt  <oliver@apple.com>
1537
1538         Wincairo buildfix
1539         https://bugs.webkit.org/show_bug.cgi?id=155245
1540
1541         Reviewed by Mark Lam.
1542
1543         Fix up exports for a few symbols
1544
1545         * jit/ExecutableAllocator.h:
1546         * jit/ExecutableAllocatorFixedVMPool.cpp:
1547
1548 2016-03-09  Mark Lam  <mark.lam@apple.com>
1549
1550         Add dumping of function expression names in CodeBlock bytecode dump.
1551         https://bugs.webkit.org/show_bug.cgi?id=155248
1552
1553         Reviewed by Filip Pizlo.
1554
1555         Because ...
1556         [  19] new_func_exp      loc5, loc3, f0:foo
1557
1558         ... is more informative than
1559         [  19] new_func_exp      loc5, loc3, f0
1560
1561         Anonymous functions will be dumped as <anon>.
1562
1563         * bytecode/CodeBlock.cpp:
1564         (JSC::CodeBlock::dumpFunctionExpr):
1565         (JSC::CodeBlock::dumpBytecode):
1566         * bytecode/CodeBlock.h:
1567
1568 2016-03-09  Michael Saboff  <msaboff@apple.com>
1569
1570         [ES6] Implement RegExp sticky flag and related functionality
1571         https://bugs.webkit.org/show_bug.cgi?id=155177
1572
1573         Reviewed by Saam Barati.
1574
1575         Implemented the ES6 RegExp sticky functionality.
1576
1577         There are two main behavior changes when the sticky flag is specified.
1578         1) Matching starts at lastIndex and lastIndex is updated after the match.
1579         2) The regular expression is only matched from the start position in the string.
1580         See ES6 section 21.2.5.2.2 for details.
1581
1582         Changed both the Yarr interpreter and jit to not loop to the next character for sticky RegExp's.
1583         Updated RegExp exec and match, and stringProtoFuncMatch to handle lastIndex changes.
1584
1585         Restructured the way flags are passed to and through YarrPatterns to use RegExpFlags instead of
1586         individual bools.
1587
1588         Updated tests for 'y' flag and new behavior.
1589
1590         * bytecode/CodeBlock.cpp:
1591         (JSC::regexpToSourceString):
1592         * inspector/ContentSearchUtilities.cpp:
1593         (Inspector::ContentSearchUtilities::findMagicComment):
1594         * runtime/CommonIdentifiers.h:
1595         * runtime/RegExp.cpp:
1596         (JSC::regExpFlags):
1597         (JSC::RegExpFunctionalTestCollector::outputOneTest):
1598         (JSC::RegExp::finishCreation):
1599         (JSC::RegExp::compile):
1600         (JSC::RegExp::compileMatchOnly):
1601         * runtime/RegExp.h:
1602         * runtime/RegExpKey.h:
1603         * runtime/RegExpObjectInlines.h:
1604         (JSC::RegExpObject::execInline):
1605         (JSC::RegExpObject::matchInline):
1606         * runtime/RegExpPrototype.cpp:
1607         (JSC::regExpProtoFuncCompile):
1608         (JSC::flagsString):
1609         (JSC::regExpProtoGetterMultiline):
1610         (JSC::regExpProtoGetterSticky):
1611         (JSC::regExpProtoGetterUnicode):
1612         * runtime/StringPrototype.cpp:
1613         (JSC::stringProtoFuncMatch):
1614         * tests/es6.yaml:
1615         * tests/stress/static-getter-in-names.js:
1616         (shouldBe):
1617         * yarr/RegularExpression.cpp:
1618         (JSC::Yarr::RegularExpression::Private::compile):
1619         * yarr/YarrInterpreter.cpp:
1620         (JSC::Yarr::Interpreter::tryConsumeBackReference):
1621         (JSC::Yarr::Interpreter::matchAssertionBOL):
1622         (JSC::Yarr::Interpreter::matchAssertionEOL):
1623         (JSC::Yarr::Interpreter::matchAssertionWordBoundary):
1624         (JSC::Yarr::Interpreter::matchDotStarEnclosure):
1625         (JSC::Yarr::Interpreter::matchDisjunction):
1626         (JSC::Yarr::Interpreter::Interpreter):
1627         (JSC::Yarr::ByteCompiler::atomPatternCharacter):
1628         * yarr/YarrInterpreter.h:
1629         (JSC::Yarr::BytecodePattern::BytecodePattern):
1630         (JSC::Yarr::BytecodePattern::estimatedSizeInBytes):
1631         (JSC::Yarr::BytecodePattern::ignoreCase):
1632         (JSC::Yarr::BytecodePattern::multiline):
1633         (JSC::Yarr::BytecodePattern::sticky):
1634         (JSC::Yarr::BytecodePattern::unicode):
1635         * yarr/YarrJIT.cpp:
1636         (JSC::Yarr::YarrGenerator::matchCharacterClass):
1637         (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
1638         (JSC::Yarr::YarrGenerator::generateAssertionBOL):
1639         (JSC::Yarr::YarrGenerator::generateAssertionEOL):
1640         (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
1641         (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
1642         (JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
1643         (JSC::Yarr::YarrGenerator::backtrack):
1644         * yarr/YarrPattern.cpp:
1645         (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
1646         (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
1647         (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
1648         (JSC::Yarr::YarrPatternConstructor::optimizeBOL):
1649         (JSC::Yarr::YarrPattern::compile):
1650         (JSC::Yarr::YarrPattern::YarrPattern):
1651         * yarr/YarrPattern.h:
1652         (JSC::Yarr::YarrPattern::reset):
1653         (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
1654         (JSC::Yarr::YarrPattern::ignoreCase):
1655         (JSC::Yarr::YarrPattern::multiline):
1656         (JSC::Yarr::YarrPattern::sticky):
1657         (JSC::Yarr::YarrPattern::unicode):
1658
1659 2016-03-09  Mark Lam  <mark.lam@apple.com>
1660
1661         FunctionExecutable::ecmaName() should not be based on inferredName().
1662         https://bugs.webkit.org/show_bug.cgi?id=155203
1663
1664         Reviewed by Michael Saboff.
1665
1666         The ES6 rules for how a function name should be inferred closely matches JSC's
1667         implementation with one exception:
1668             var o = {}
1669             o.foo = function() {}
1670
1671         JSC's inferredName for o.foo would be "foo".
1672         ES6 specifies that o.foo.name is "".
1673
1674         The fix is to add a distinct FunctionExecutable::ecmaName() which applies the ES6
1675         rules for inferring the initial value of Function.name.
1676
1677         * bytecode/UnlinkedFunctionExecutable.cpp:
1678         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1679         * bytecode/UnlinkedFunctionExecutable.h:
1680         * parser/ASTBuilder.h:
1681         (JSC::ASTBuilder::createAssignResolve):
1682         (JSC::ASTBuilder::createGetterOrSetterProperty):
1683         (JSC::ASTBuilder::createProperty):
1684         (JSC::ASTBuilder::makeAssignNode):
1685         * parser/Nodes.h:
1686         * runtime/Executable.h:
1687         * runtime/JSFunction.cpp:
1688         (JSC::JSFunction::reifyName):
1689         * tests/es6.yaml:
1690
1691 2016-03-09  Michael Saboff  <msaboff@apple.com>
1692
1693         Harden JSC Root element functions from bad values
1694         https://bugs.webkit.org/show_bug.cgi?id=155234
1695
1696         Reviewed by Saam Barati.
1697
1698         Changed jsCast() to jsDynamicCast() in Root related function to protect against being
1699         called with non-Root arguments.
1700
1701         * jsc.cpp:
1702         (functionCreateElement):
1703         (functionGetElement):
1704         (functionSetElementRoot):
1705
1706 2016-03-09  Benjamin Poulain  <benjamin@webkit.org>
1707
1708         [JSC] Pick how to OSR Enter to FTL at runtime instead of compile time
1709         https://bugs.webkit.org/show_bug.cgi?id=155217
1710
1711         Reviewed by Filip Pizlo.
1712
1713         This patch addresses 2 types of problems with tiering up to FTL
1714         with OSR Entry in a loop:
1715         -When there are nested loops, it is generally valuable to enter
1716          an outer loop rather than an inner loop.
1717         -When tiering up at a point that cannot OSR Enter, we are at
1718          the mercy of the outer loop frequency to compile the right
1719          entry point.
1720
1721         The first case is significant in the test "gaussian-blur".
1722         That test has 4 nested loops. When we have an OSR Entry,
1723         the analysis phases have to be pesimistic where we enter:
1724         we do not really know what constraint can be proven from
1725         the DFG code that was running.
1726
1727         In "gaussian-blur", integer-range analysis removes pretty
1728         much all overflow checks in the inner loops of where we entered.
1729         The more outside we enter, the better code we generate.
1730
1731         Since we spend the most iterations in the inner loop, we naturally
1732         tend to OSR Enter into the 2 most inner loops, making the most
1733         pessimistic assumptions.
1734
1735         To avoid such problems, I changed how we decide where to OSR Enter.
1736         Previously, the last CheckTierUpAndOSREnter to cross the threshold
1737         was where we take the entry point for FTL.
1738
1739         What happens now is that the entry point is not decied when
1740         compiling the CheckTierUp variants. Instead, all the information
1741         we need is gathered during compilation and keept on the JITCode
1742         to be used at runtime.
1743
1744         When we try to tier up and decide to OSR Enter, we use the information
1745         we have to pick a good outer loop for OSR Entry.
1746
1747         Now the problem is outer loop do not CheckTierUpAndOSREnter often,
1748         wasting several miliseconds before entering the newly compiled FTL code.
1749
1750         To solve that, every CheckTierUpAndOSREnter has its own trigger that
1751         bypass the counter. When the FTL Code is compiled, the trigger is set
1752         and we enter through the right CheckTierUpAndOSREnter immediately.
1753
1754         ---
1755
1756         This new mechanism also solves a problem of ai-astar.
1757         When we try to tier up in ai-astar, we had nothing to compile until
1758         the outer loop is reached.
1759
1760         To make sure we reached the CheckTierUpAndOSREnter in a reasonable time,
1761         we had CheckTierUpWithNestedTriggerAndOSREnter with a special trigger.
1762
1763         With the new mechanism, we can do much better:
1764         -When we keep hitting CheckTierUpInLoop, we now have all the information
1765          we need to already start compiling the outer loop.
1766          Instead of waiting for the outer loop to be reached a few times, we compile
1767          it as soon as the inner loop is hammering CheckTierUpInLoop.
1768         -With the new triggers, the very next time we hit the outer loop, we OSR Enter.
1769
1770         This allow us to compile what we need sooner and enter sooner.
1771
1772         * dfg/DFGAbstractInterpreterInlines.h:
1773         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
1774         * dfg/DFGClobberize.h:
1775         (JSC::DFG::clobberize): Deleted.
1776         * dfg/DFGDoesGC.cpp:
1777         (JSC::DFG::doesGC): Deleted.
1778         * dfg/DFGFixupPhase.cpp:
1779         (JSC::DFG::FixupPhase::fixupNode): Deleted.
1780         * dfg/DFGJITCode.h:
1781         * dfg/DFGJITCompiler.cpp:
1782         (JSC::DFG::JITCompiler::JITCompiler):
1783         (JSC::DFG::JITCompiler::compileEntryExecutionFlag):
1784         * dfg/DFGNodeType.h:
1785         * dfg/DFGOperations.cpp:
1786         * dfg/DFGOperations.h:
1787         * dfg/DFGPlan.h:
1788         (JSC::DFG::Plan::canTierUpAndOSREnter):
1789         * dfg/DFGPredictionPropagationPhase.cpp:
1790         (JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
1791         * dfg/DFGSafeToExecute.h:
1792         (JSC::DFG::safeToExecute): Deleted.
1793         * dfg/DFGSpeculativeJIT32_64.cpp:
1794         (JSC::DFG::SpeculativeJIT::compile): Deleted.
1795         * dfg/DFGSpeculativeJIT64.cpp:
1796         (JSC::DFG::SpeculativeJIT::compile):
1797         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1798         (JSC::DFG::TierUpCheckInjectionPhase::run):
1799         (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
1800         (JSC::DFG::TierUpCheckInjectionPhase::findLoopsContainingLoopHintWithoutOSREnter): Deleted.
1801         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
1802         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
1803         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
1804         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1805         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
1806         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
1807
1808 2016-03-08  Filip Pizlo  <fpizlo@apple.com>
1809
1810         DFG should be able to constant-fold strings
1811         https://bugs.webkit.org/show_bug.cgi?id=155200
1812
1813         Reviewed by Geoffrey Garen.
1814
1815         This adds constant-folding of string1 + string2 and string.length. The actual folding
1816         rule is easy, but there are some gotchas.
1817
1818         The problem is that the DFG cannot allocate new JSString objects until we are on the
1819         main thread. So, DFG IR must have a node for a JSValue string constant that hasn't been
1820         created yet - i.e. it doesn't have any concrete JSValue bits yet.
1821
1822         We have the ability to speak of such things, using LazyJSValue. But that's a class, not
1823         a node type. This patch now adds a node type, LazyJSConstant, which is a Node that holds
1824         a LazyJSValue.
1825
1826         This puts us in a weird situation: AI uses JSValue to represent constants. It would take
1827         a lot of work to change it to use LazyJSValue. So, this implements the constant folding
1828         in StrengthReductionPhase. I created a bug and put a FIXME about moving these rules into
1829         AI.
1830
1831         OTOH, our experience in B3 shows that constant folding in strength reduction is quite
1832         nice. It would totally make sense to have strength reduction have constant folding rules
1833         that mirror the rules in AI, or to factor out the AI constant folding rules, the same
1834         way that B3 factors out those rules into Value methods.
1835
1836         Another issue is how to represent the cumulative result of possibly many foldings. I
1837         initially considered adding LazyJSValue kinds that represented concatenation. Folding
1838         the concatenation to a constant meand that this constant was actually a LazyJSValue that
1839         represented the concatenation of two other things. But this would get super messy if we
1840         wanted to fold an operation that uses the results of another folded operation.
1841
1842         So, the JIT thread folds string operations by creating a WTF::String that contains the
1843         result. The DFG::Graph holds a +1 on the underlying StringImpl, so we can pass the
1844         StringImpl* around without reference counting. The LazyJSValue now has a special kind
1845         that means: we created this StringImpl* on the JIT thread, and once the JIT is done, we
1846         will relinquish ownership of it. LazyJSValue has some magic to emit code for these
1847         to-be-created-JSStrings while also transferring ownership of the StringImpl from the JIT
1848         thread to the main thread and registering the JSString with the GC.
1849
1850         This just implements folding for concatenation and GetArrayLength. It's just a proof of
1851         concept for evil things I want to do later.
1852
1853         This change is a 2.5x speed-up on the string concatenation microbenchmarks I added in
1854         this patch.
1855
1856         * dfg/DFGAbstractInterpreterInlines.h:
1857         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1858         * dfg/DFGClobberize.h:
1859         (JSC::DFG::clobberize):
1860         * dfg/DFGDoesGC.cpp:
1861         (JSC::DFG::doesGC):
1862         * dfg/DFGFixupPhase.cpp:
1863         (JSC::DFG::FixupPhase::fixupNode):
1864         * dfg/DFGFrozenValue.cpp:
1865         (JSC::DFG::FrozenValue::emptySingleton):
1866         (JSC::DFG::FrozenValue::tryGetString):
1867         (JSC::DFG::FrozenValue::dumpInContext):
1868         * dfg/DFGFrozenValue.h:
1869         (JSC::DFG::FrozenValue::strength):
1870         * dfg/DFGGraph.h:
1871         * dfg/DFGLazyJSValue.cpp:
1872         (JSC::DFG::LazyJSValue::newString):
1873         (JSC::DFG::LazyJSValue::getValue):
1874         (JSC::DFG::equalToStringImpl):
1875         (JSC::DFG::LazyJSValue::tryGetStringImpl):
1876         (JSC::DFG::LazyJSValue::tryGetString):
1877         (JSC::DFG::LazyJSValue::strictEqual):
1878         (JSC::DFG::LazyJSValue::switchLookupValue):
1879         (JSC::DFG::LazyJSValue::emit):
1880         (JSC::DFG::LazyJSValue::dumpInContext):
1881         * dfg/DFGLazyJSValue.h:
1882         (JSC::DFG::LazyJSValue::LazyJSValue):
1883         (JSC::DFG::LazyJSValue::knownStringImpl):
1884         (JSC::DFG::LazyJSValue::kind):
1885         (JSC::DFG::LazyJSValue::tryGetValue):
1886         (JSC::DFG::LazyJSValue::character):
1887         (JSC::DFG::LazyJSValue::stringImpl):
1888         * dfg/DFGMayExit.cpp:
1889         (JSC::DFG::mayExit):
1890         * dfg/DFGNode.cpp:
1891         (JSC::DFG::Node::convertToIdentityOn):
1892         (JSC::DFG::Node::convertToLazyJSConstant):
1893         (JSC::DFG::Node::convertToPutHint):
1894         (JSC::DFG::Node::convertToPutClosureVarHint):
1895         (JSC::DFG::Node::tryGetString):
1896         (JSC::DFG::Node::promotedLocationDescriptor):
1897         * dfg/DFGNode.h:
1898         (JSC::DFG::Node::convertToConstant):
1899         (JSC::DFG::Node::convertToConstantStoragePointer):
1900         (JSC::DFG::Node::castConstant):
1901         (JSC::DFG::Node::hasLazyJSValue):
1902         (JSC::DFG::Node::lazyJSValue):
1903         (JSC::DFG::Node::initializationValueForActivation):
1904         * dfg/DFGNodeType.h:
1905         * dfg/DFGPredictionPropagationPhase.cpp:
1906         (JSC::DFG::PredictionPropagationPhase::propagate):
1907         * dfg/DFGSafeToExecute.h:
1908         (JSC::DFG::safeToExecute):
1909         * dfg/DFGSpeculativeJIT.cpp:
1910         (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
1911         (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
1912         * dfg/DFGSpeculativeJIT.h:
1913         * dfg/DFGSpeculativeJIT32_64.cpp:
1914         (JSC::DFG::SpeculativeJIT::compile):
1915         * dfg/DFGSpeculativeJIT64.cpp:
1916         (JSC::DFG::SpeculativeJIT::compile):
1917         * dfg/DFGStrengthReductionPhase.cpp:
1918         (JSC::DFG::StrengthReductionPhase::handleNode):
1919         * ftl/FTLCapabilities.cpp:
1920         (JSC::FTL::canCompile):
1921         * ftl/FTLLowerDFGToB3.cpp:
1922         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1923         (JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant):
1924         (JSC::FTL::DFG::LowerDFGToB3::compileLazyJSConstant):
1925         (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
1926
1927 2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>
1928
1929         Web Inspector: Memory Timeline should show MemoryPressure events
1930         https://bugs.webkit.org/show_bug.cgi?id=155158
1931         <rdar://problem/25026610>
1932
1933         Reviewed by Brian Burg.
1934
1935         * inspector/protocol/Memory.json:
1936
1937 2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>
1938
1939         Web Inspector: Add Heap domain start/stop tracking commands
1940         https://bugs.webkit.org/show_bug.cgi?id=155190
1941
1942         Reviewed by Brian Burg.
1943
1944         * inspector/agents/InspectorHeapAgent.cpp:
1945         (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
1946         (Inspector::InspectorHeapAgent::startTracking):
1947         (Inspector::InspectorHeapAgent::stopTracking):
1948         * inspector/agents/InspectorHeapAgent.h:
1949         * inspector/protocol/Heap.json:
1950
1951 2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>
1952
1953         Web Inspector: Add a way to create a Heap Snapshot
1954         https://bugs.webkit.org/show_bug.cgi?id=155188
1955
1956         Reviewed by Brian Burg.
1957
1958         * inspector/agents/InspectorHeapAgent.h:
1959         * inspector/protocol/Heap.json:
1960         * inspector/agents/InspectorHeapAgent.cpp:
1961         (Inspector::InspectorHeapAgent::snapshot):
1962         Take a heap snapshot and return the JSON string result.
1963
1964         * inspector/protocol/Debugger.json:
1965         Remove unused optional inferredName. Our displayName would be inferred.
1966
1967 2016-03-08  Oliver Hunt  <oliver@apple.com>
1968
1969         Fix ios bot build.
1970
1971         * jit/ExecutableAllocatorFixedVMPool.cpp:
1972         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
1973
1974 2016-03-08  Mark Lam  <mark.lam@apple.com>
1975
1976         Implement Function.name support for getters/setters and inferring name of function properties.
1977         https://bugs.webkit.org/show_bug.cgi?id=154865
1978
1979         Rubber-stamped by Joseph Pecoraro.
1980
1981         Follow up to the fix for this bug: adding a few small clean-ups for issues Joe
1982         pointed out in the bug.
1983
1984         * runtime/JSBoundSlotBaseFunction.cpp:
1985         (JSC::JSBoundSlotBaseFunction::create):
1986         * runtime/JSCJSValue.cpp:
1987         (JSC::JSValue::putToPrimitiveByIndex):
1988
1989 2016-03-08  Oliver Hunt  <oliver@apple.com>
1990
1991         Start moving to separated writable and executable mappings in the JIT
1992         https://bugs.webkit.org/show_bug.cgi?id=155178
1993
1994         Reviewed by Fil Pizlo.
1995
1996         Start moving to a separate writable and executable heap for the various
1997         JITs.
1998
1999         As part of our work to harden the JIT against various attacks, we're
2000         moving away from our current RWX heap and on to using separate RW and X
2001         mappings. This means that simply leaking the location of the executable
2002         mapping is not sufficient to compromise JSC, so we can continue to
2003         use direct executable pointers in our GC objects (which we need for
2004         performance), but keep the writable pointer in only a single location
2005         so that we are less likely to leak the address. To further obscure the
2006         address of the writable region we place it in an execute only region
2007         of memory so that it is not possible to read the location from 
2008         anywhere. That means an attacker must have at least partial control
2009         of PC (to call jitMemCopy) before they can start to attack the JIT.
2010
2011         This work is initially ARM64 only, as we use as the jitMemCopy is
2012         currently specific to that platform's calling conventions and layout.
2013         We're just landing it in the current form so that we can at least
2014         ensure it doesn't regress.
2015
2016         * Configurations/FeatureDefines.xcconfig:
2017         * assembler/ARM64Assembler.h:
2018         (JSC::ARM64Assembler::ldp):
2019         (JSC::ARM64Assembler::ldnp):
2020         (JSC::ARM64Assembler::fillNops):
2021         (JSC::ARM64Assembler::stp):
2022         (JSC::ARM64Assembler::stnp):
2023         (JSC::ARM64Assembler::replaceWithJump):
2024         (JSC::ARM64Assembler::replaceWithLoad):
2025         (JSC::ARM64Assembler::replaceWithAddressComputation):
2026         (JSC::ARM64Assembler::setPointer):
2027         (JSC::ARM64Assembler::repatchInt32):
2028         (JSC::ARM64Assembler::repatchCompact):
2029         (JSC::ARM64Assembler::linkJumpOrCall):
2030         (JSC::ARM64Assembler::linkCompareAndBranch):
2031         (JSC::ARM64Assembler::linkConditionalBranch):
2032         (JSC::ARM64Assembler::linkTestAndBranch):
2033         (JSC::ARM64Assembler::loadStoreRegisterPairOffset):
2034         (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
2035         * assembler/LinkBuffer.cpp:
2036         (JSC::LinkBuffer::copyCompactAndLinkCode):
2037         (JSC::LinkBuffer::allocate):
2038         * assembler/LinkBuffer.h:
2039         (JSC::LinkBuffer::LinkBuffer):
2040         * assembler/MacroAssemblerARM64.h:
2041         (JSC::MacroAssemblerARM64::sub64):
2042         (JSC::MacroAssemblerARM64::load64):
2043         (JSC::MacroAssemblerARM64::loadPair64):
2044         (JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess):
2045         (JSC::MacroAssemblerARM64::load8):
2046         (JSC::MacroAssemblerARM64::store64):
2047         (JSC::MacroAssemblerARM64::storePair64):
2048         (JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess):
2049         (JSC::MacroAssemblerARM64::store8):
2050         (JSC::MacroAssemblerARM64::branchAdd64):
2051         (JSC::MacroAssemblerARM64::branchSub64):
2052         * jit/ExecutableAllocator.h:
2053         (JSC::performJITMemcpy):
2054         * jit/ExecutableAllocatorFixedVMPool.cpp:
2055         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
2056         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
2057         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
2058         * runtime/Options.cpp:
2059         (JSC::recomputeDependentOptions):
2060         * runtime/Options.h:
2061
2062 2016-03-08  Mark Lam  <mark.lam@apple.com>
2063
2064         Implement Function.name support for getters/setters and inferring name of function properties.
2065         https://bugs.webkit.org/show_bug.cgi?id=154865
2066
2067         Reviewed by Geoffrey Garen.
2068
2069         1. toString() no longer uses the value of Function.name as the name of the
2070            function in the returned string, because ...
2071
2072             i. Function.name is supposed to be configurable.  Hence, it can be made
2073                writable and can be set to any JSValue, or deleted.
2074            ii. Function.prototype.toString() is supposed to produce a string that can be
2075                eval'ed.  Hence, for JS functions, the function name in the produced
2076                string must be a legal function name (and not some arbitrary value set in
2077                Function.name).  For example, while a number is a legal value for
2078                Function.name, it is not legal as the function name in the toString()
2079                string.
2080
2081            Instead, we'll always use the original name from the JS source that the
2082            function was parsed from.
2083
2084         2. JSFunction::name() now always return the original name, not the value of
2085            the Function.name property.  As a result, it also no longer needs an
2086            ExecState* arg.
2087
2088            If the original name is an empty string, JSFunction::name() will use the
2089            inferred name.
2090
2091         3. For JS functions, the original name can be attained from their
2092            FunctionExecutable object.
2093
2094            For host/native functions (which do not have a FunctionExecutable), we get the
2095            "original" name from its NativeExecutable.
2096
2097         4. The m_hostFunctionStubMap now keys its NativeExecutable pointers using the
2098            original name, in addition to the native function and constructor pointers.
2099
2100            This is needed because we want a different NativeExecutable for functions with
2101            a different name (to satisfy (3) above).
2102
2103         5. Changed JSBoundFunction to store the name of its bound function in its
2104            NativeExecutable.  This will later be used to generate the toString() string.
2105            It's Function.name value is eagerly initialized at construction time.
2106
2107         6. Function.name for getters/setters are now prefixed with "get"/"set".
2108            This was done both for the JSBoundSlotBaseFunctions and JS definable get/set
2109            functions.
2110
2111         7. Added InternalFunction::m_originalName so that we can use it to generate the
2112            toString() string.  We're storing it as a JSString instead of a WTF::String
2113            only because we want InternalFunction to be continue to be trivially
2114            destructible.
2115
2116         * inspector/JSInjectedScriptHost.cpp:
2117         (Inspector::JSInjectedScriptHost::functionDetails):
2118         * jit/JITThunks.cpp:
2119         (JSC::JITThunks::finalize):
2120         (JSC::JITThunks::hostFunctionStub):
2121         * jit/JITThunks.h:
2122         * runtime/Executable.h:
2123         * runtime/FunctionPrototype.cpp:
2124         (JSC::functionProtoFuncToString):
2125         * runtime/InternalFunction.cpp:
2126         (JSC::InternalFunction::finishCreation):
2127         (JSC::InternalFunction::visitChildren):
2128         (JSC::InternalFunction::name):
2129         (JSC::InternalFunction::displayName):
2130         * runtime/InternalFunction.h:
2131         * runtime/JSBoundFunction.cpp:
2132         (JSC::JSBoundFunction::create):
2133         (JSC::JSBoundFunction::visitChildren):
2134         (JSC::JSBoundFunction::toStringName): Deleted.
2135         * runtime/JSBoundFunction.h:
2136         (JSC::JSBoundFunction::boundThis):
2137         (JSC::JSBoundFunction::boundArgs):
2138         (JSC::JSBoundFunction::createStructure):
2139         * runtime/JSBoundSlotBaseFunction.cpp:
2140         (JSC::boundSlotBaseFunctionCall):
2141         (JSC::JSBoundSlotBaseFunction::create):
2142         * runtime/JSFunction.cpp:
2143         (JSC::JSFunction::initializeRareData):
2144         (JSC::JSFunction::name):
2145         (JSC::JSFunction::displayName):
2146         (JSC::JSFunction::calculatedDisplayName):
2147         (JSC::JSFunction::reifyName):
2148         * runtime/JSFunction.h:
2149         * tests/es6.yaml:
2150
2151 2016-03-08  Commit Queue  <commit-queue@webkit.org>
2152
2153         Unreviewed, rolling out r197793 and r197799.
2154         https://bugs.webkit.org/show_bug.cgi?id=155195
2155
2156         something weird happened while landing this and everything
2157         broke (Requested by olliej on #webkit).
2158
2159         Reverted changesets:
2160
2161         "Start moving to separated writable and executable mappings in
2162         the JIT"
2163         https://bugs.webkit.org/show_bug.cgi?id=155178
2164         http://trac.webkit.org/changeset/197793
2165
2166         "arm64 build fix after r197793."
2167         http://trac.webkit.org/changeset/197799
2168
2169 2016-03-08  Alex Christensen  <achristensen@webkit.org>
2170
2171         arm64 build fix after r197793.
2172
2173         * jit/ExecutableAllocatorFixedVMPool.cpp:
2174         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
2175         (JSC::FixedVMPoolExecutableAllocator::initializeBulletproofJIT):
2176         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
2177         Use consistent ENABLE macro.  It looks like it was partially renamed.
2178
2179 2016-03-08  Filip Pizlo  <fpizlo@apple.com>
2180
2181         Regexp matching should incur less call overhead
2182         https://bugs.webkit.org/show_bug.cgi?id=155181
2183
2184         Reviewed by Geoffrey Garen.
2185
2186         Previously we had DFG/FTL code call into the DFGOperation, which then called in to
2187         RegExpObject, which then called into createRegExpMatchesArray, which then called into
2188         RegExp, which then called the code generated by Yarr.
2189
2190         Now we have DFG/FTL code call into the DFGOperation, which does all of the things and calls
2191         into code generated by Yarr.
2192
2193         This is another tiny Octane/regexp speed-up.
2194
2195         * JavaScriptCore.xcodeproj/project.pbxproj:
2196         * dfg/DFGOperations.cpp:
2197         * runtime/RegExp.cpp:
2198         (JSC::regExpFlags):
2199         (JSC::RegExp::compile):
2200         (JSC::RegExp::match):
2201         (JSC::RegExp::compileMatchOnly):
2202         (JSC::RegExp::deleteCode):
2203         (JSC::RegExpFunctionalTestCollector::clearRegExp): Deleted.
2204         (JSC::RegExp::compileIfNecessary): Deleted.
2205         (JSC::RegExp::compileIfNecessaryMatchOnly): Deleted.
2206         * runtime/RegExp.h:
2207         * runtime/RegExpInlines.h: Added.
2208         (JSC::RegExpFunctionalTestCollector::clearRegExp):
2209         (JSC::RegExp::compileIfNecessary):
2210         (JSC::RegExp::matchInline):
2211         (JSC::RegExp::compileIfNecessaryMatchOnly):
2212         * runtime/RegExpMatchesArray.cpp:
2213         (JSC::createEmptyRegExpMatchesArray):
2214         (JSC::createStructureImpl):
2215         (JSC::tryCreateUninitializedRegExpMatchesArray): Deleted.
2216         (JSC::createRegExpMatchesArray): Deleted.
2217         * runtime/RegExpMatchesArray.h:
2218         (JSC::tryCreateUninitializedRegExpMatchesArray):
2219         (JSC::createRegExpMatchesArray):
2220         * runtime/RegExpObject.cpp:
2221         (JSC::RegExpObject::put):
2222         (JSC::RegExpObject::exec):
2223         (JSC::RegExpObject::match):
2224         (JSC::getLastIndexAsUnsigned): Deleted.
2225         * runtime/RegExpObject.h:
2226         (JSC::RegExpObject::getLastIndex):
2227         (JSC::RegExpObject::test):
2228         (JSC::RegExpObject::testInline):
2229         * runtime/RegExpObjectInlines.h: Added.
2230         (JSC::getRegExpObjectLastIndexAsUnsigned):
2231         (JSC::RegExpObject::execInline):
2232         (JSC::RegExpObject::matchInline):
2233
2234 2016-03-08  Mark Lam  <mark.lam@apple.com>
2235
2236         synthesizePrototype() and friends need to be followed by exception checks (or equivalent).
2237         https://bugs.webkit.org/show_bug.cgi?id=155169
2238
2239         Reviewed by Geoffrey Garen.
2240
2241         With the exception checks, we may end up throwing new exceptions over an existing
2242         one that has been thrown but not handled yet, thereby obscuring it.  It may also
2243         mean that the VM will continue running on potentially unstable state, which may
2244         have undesirable consequences.
2245
2246         I first observed this in some failed assertion while running tests on a patch for
2247         https://bugs.webkit.org/show_bug.cgi?id=154865.
2248
2249         Performance is neutral with this patch (tested on x86_64).
2250
2251         1. Deleted JSNotAnObject, and removed all uses of it.
2252
2253         2. Added exception checks, when needed, following calls to synthesizePrototype()
2254            and JSValue::toObject().
2255
2256            The cases that do not need an exception check are the ones that already ensures
2257            that JSValue::toObject() is only called on a value that is convertible to an
2258            object.  In those cases, I added an assertion that no exception was thrown
2259            after the call.
2260
2261         * CMakeLists.txt:
2262         * JavaScriptCore.xcodeproj/project.pbxproj:
2263         * inspector/ScriptCallStackFactory.cpp:
2264         (Inspector::createScriptCallStackFromException):
2265         * interpreter/Interpreter.cpp:
2266         * jit/JITOperations.cpp:
2267         * llint/LLIntSlowPaths.cpp:
2268         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2269         * runtime/ArrayPrototype.cpp:
2270         (JSC::arrayProtoFuncJoin):
2271         (JSC::arrayProtoFuncConcat):
2272         (JSC::arrayProtoFuncPop):
2273         (JSC::arrayProtoFuncPush):
2274         (JSC::arrayProtoFuncReverse):
2275         (JSC::arrayProtoFuncShift):
2276         (JSC::arrayProtoFuncSlice):
2277         (JSC::arrayProtoFuncSplice):
2278         (JSC::arrayProtoFuncUnShift):
2279         (JSC::arrayProtoFuncIndexOf):
2280         (JSC::arrayProtoFuncLastIndexOf):
2281         (JSC::arrayProtoFuncValues):
2282         (JSC::arrayProtoFuncEntries):
2283         (JSC::arrayProtoFuncKeys):
2284         * runtime/CommonSlowPaths.cpp:
2285         (JSC::SLOW_PATH_DECL):
2286         * runtime/ExceptionHelpers.cpp:
2287         * runtime/JSCJSValue.cpp:
2288         (JSC::JSValue::toObjectSlowCase):
2289         (JSC::JSValue::toThisSlowCase):
2290         (JSC::JSValue::synthesizePrototype):
2291         (JSC::JSValue::putToPrimitive):
2292         (JSC::JSValue::putToPrimitiveByIndex):
2293         * runtime/JSCJSValueInlines.h:
2294         (JSC::JSValue::getPropertySlot):
2295         (JSC::JSValue::get):
2296         * runtime/JSFunction.cpp:
2297         * runtime/JSGlobalObjectFunctions.cpp:
2298         (JSC::globalFuncProtoGetter):
2299         * runtime/JSNotAnObject.cpp: Removed.
2300         * runtime/JSNotAnObject.h: Removed.
2301         * runtime/ObjectConstructor.cpp:
2302         (JSC::objectConstructorDefineProperties):
2303         (JSC::objectConstructorCreate):
2304         * runtime/ObjectPrototype.cpp:
2305         (JSC::objectProtoFuncValueOf):
2306         (JSC::objectProtoFuncHasOwnProperty):
2307         (JSC::objectProtoFuncIsPrototypeOf):
2308         (JSC::objectProtoFuncToString):
2309         * runtime/VM.cpp:
2310         (JSC::VM::VM):
2311         * runtime/VM.h:
2312
2313 2016-03-08  Oliver Hunt  <oliver@apple.com>
2314
2315         Start moving to separated writable and executable mappings in the JIT
2316         https://bugs.webkit.org/show_bug.cgi?id=155178
2317
2318         Reviewed by Filip Pizlo.
2319
2320         Start moving to a separate writable and executable heap for the various
2321         JITs.
2322
2323         As part of our work to harden the JIT against various attacks, we're
2324         moving away from our current RWX heap and on to using separate RW and X
2325         mappings. This means that simply leaking the location of the executable
2326         mapping is not sufficient to compromise JSC, so we can continue to
2327         use direct executable pointers in our GC objects (which we need for
2328         performance), but keep the writable pointer in only a single location
2329         so that we are less likely to leak the address. To further obscure the
2330         address of the writable region we place it in an execute only region
2331         of memory so that it is not possible to read the location from 
2332         anywhere. That means an attacker must have at least partial control
2333         of PC (to call jitMemCopy) before they can start to attack the JIT.
2334
2335         This work is initially ARM64 only, as we use as the jitMemCopy is
2336         currently specific to that platform's calling conventions and layout.
2337         We're just landing it in the current form so that we can at least
2338         ensure it doesn't regress.
2339
2340         * Configurations/FeatureDefines.xcconfig:
2341         * assembler/ARM64Assembler.h:
2342         (JSC::ARM64Assembler::ldp):
2343         (JSC::ARM64Assembler::ldnp):
2344         (JSC::ARM64Assembler::fillNops):
2345         (JSC::ARM64Assembler::stp):
2346         (JSC::ARM64Assembler::stnp):
2347         (JSC::ARM64Assembler::replaceWithJump):
2348         (JSC::ARM64Assembler::replaceWithLoad):
2349         (JSC::ARM64Assembler::replaceWithAddressComputation):
2350         (JSC::ARM64Assembler::setPointer):
2351         (JSC::ARM64Assembler::repatchInt32):
2352         (JSC::ARM64Assembler::repatchCompact):
2353         (JSC::ARM64Assembler::linkJumpOrCall):
2354         (JSC::ARM64Assembler::linkCompareAndBranch):
2355         (JSC::ARM64Assembler::linkConditionalBranch):
2356         (JSC::ARM64Assembler::linkTestAndBranch):
2357         (JSC::ARM64Assembler::loadStoreRegisterPairOffset):
2358         (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):
2359         * assembler/LinkBuffer.cpp:
2360         (JSC::LinkBuffer::copyCompactAndLinkCode):
2361         (JSC::LinkBuffer::allocate):
2362         * assembler/LinkBuffer.h:
2363         (JSC::LinkBuffer::LinkBuffer):
2364         * assembler/MacroAssemblerARM64.h:
2365         (JSC::MacroAssemblerARM64::sub64):
2366         (JSC::MacroAssemblerARM64::load64):
2367         (JSC::MacroAssemblerARM64::loadPair64):
2368         (JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess):
2369         (JSC::MacroAssemblerARM64::load8):
2370         (JSC::MacroAssemblerARM64::store64):
2371         (JSC::MacroAssemblerARM64::storePair64):
2372         (JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess):
2373         (JSC::MacroAssemblerARM64::store8):
2374         (JSC::MacroAssemblerARM64::branchAdd64):
2375         (JSC::MacroAssemblerARM64::branchSub64):
2376         * jit/ExecutableAllocator.h:
2377         (JSC::performJITMemcpy):
2378         * jit/ExecutableAllocatorFixedVMPool.cpp:
2379         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
2380         (JSC::FixedVMPoolExecutableAllocator::initializeBulletproofJIT):
2381         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
2382         * runtime/Options.cpp:
2383         (JSC::recomputeDependentOptions):
2384         * runtime/Options.h:
2385
2386 2016-03-08  Michael Saboff  <msaboff@apple.com>
2387
2388         [ES6] Regular Expression canonicalization tables for Unicode need to be updated to use Unicode CaseFolding.txt
2389         https://bugs.webkit.org/show_bug.cgi?id=155114
2390
2391         Reviewed by Darin Adler.
2392
2393         Extracted out the Unicode canonicalization table creation from
2394         YarrCanonicalizeUnicode.js into a new Python script, generateYarrCanonicalizeUnicode.
2395         That script generates the Unicode tables as the file YarrCanonicalizeUnicode.cpp in
2396         DerivedSources/JavaScriptCore.
2397
2398         Updated the processing of ignore case to make the ASCII short cuts dependent on whether
2399         or not we are a Unicode pattern.
2400
2401         Renamed yarr/YarrCanonicalizeUnicode.{cpp,js} back to their prior names,
2402         YarrCanonicalizeUCS2.{cpp,js}.
2403         Renamed yarr/YarrCanonicalizeUnicode.h to YarrCanonicalize.h as it declares both the
2404         legacy UCS2 and Unicode tables.
2405
2406         * CMakeLists.txt:
2407         * DerivedSources.make:
2408         * JavaScriptCore.xcodeproj/project.pbxproj:
2409         * generateYarrCanonicalizeUnicode: Added.
2410         * ucd: Added.
2411         * ucd/CaseFolding.txt: Added.  The current verion, 8.0, of the Unicode CaseFolding table.
2412         * yarr/YarrCanonicalizeUCS2.cpp: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.cpp.
2413         * yarr/YarrCanonicalize.h: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.h.
2414         * yarr/YarrCanonicalizeUCS2.js: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.js.
2415         (printHeader):
2416         * yarr/YarrCanonicalizeUnicode.cpp: Removed.
2417         * yarr/YarrCanonicalizeUnicode.h: Removed.
2418         * yarr/YarrCanonicalizeUnicode.js: Removed.
2419         * yarr/YarrInterpreter.cpp:
2420         (JSC::Yarr::Interpreter::tryConsumeBackReference):
2421         * yarr/YarrJIT.cpp:
2422         * yarr/YarrPattern.cpp:
2423         (JSC::Yarr::CharacterClassConstructor::putChar):
2424
2425 2016-03-08  Andreas Kling  <akling@apple.com>
2426
2427         WeakBlock::visit() should check for a WeakHandleOwner before consulting mark bits.
2428         <https://webkit.org/b/155154>
2429
2430         Reviewed by Darin Adler.
2431
2432         Reorder the checks in WeakBlock::visit() so we don't look at the mark bits in MarkedBlock
2433         unless the current WeakImpl has a WeakHandleOwner we need to consult.
2434
2435         I was originally hoping to make an optimization that could skip over entire WeakBlocks
2436         if they didn't have a single WeakHandleOwner, but it turns out that scenario is not as
2437         common as I suspected.
2438
2439         * heap/WeakBlock.cpp:
2440         (JSC::WeakBlock::visit):
2441
2442 2016-03-07  Saam barati  <sbarati@apple.com>
2443
2444         [ES6] Implement revocable proxies
2445         https://bugs.webkit.org/show_bug.cgi?id=154321
2446
2447         Reviewed by Mark Lam.
2448
2449         This patch is a straight forward implementation of Proxy.revocable
2450         with respect to section 26.2.2.1 of the ECMAScript spec.
2451         https://tc39.github.io/ecma262/#sec-proxy.revocable
2452
2453         This patch also fixes a bug in Proxy where we
2454         were incorrectly caching "in", i.e, `"x" in proxy`.
2455         We should never blatantly cache this because caching is observable
2456         behavior by users of the language. We could come up with
2457         a smarter caching scheme that caches only if the Proxy's
2458         handler doesn't have a "has" property, i.e, we don't have
2459         to call out to JS code. But for now, it's easiest to disable
2460         caching.
2461
2462         * CMakeLists.txt:
2463         * JavaScriptCore.xcodeproj/project.pbxproj:
2464         * runtime/JSGlobalObject.cpp:
2465         (JSC::JSGlobalObject::init):
2466         (JSC::JSGlobalObject::visitChildren):
2467         * runtime/JSGlobalObject.h:
2468         (JSC::JSGlobalObject::moduleRecordStructure):
2469         (JSC::JSGlobalObject::moduleNamespaceObjectStructure):
2470         (JSC::JSGlobalObject::proxyObjectStructure):
2471         (JSC::JSGlobalObject::proxyRevokeStructure):
2472         (JSC::JSGlobalObject::wasmModuleStructure):
2473         * runtime/ProxyConstructor.cpp:
2474         (JSC::ProxyConstructor::create):
2475         (JSC::ProxyConstructor::ProxyConstructor):
2476         (JSC::makeRevocableProxy):
2477         (JSC::proxyRevocableConstructorThrowError):
2478         (JSC::ProxyConstructor::finishCreation):
2479         (JSC::constructProxyObject):
2480         * runtime/ProxyConstructor.h:
2481         (JSC::ProxyConstructor::createStructure):
2482         * runtime/ProxyObject.cpp:
2483         (JSC::ProxyObject::finishCreation):
2484         (JSC::performProxyGet):
2485         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
2486         (JSC::ProxyObject::performHasProperty):
2487         (JSC::ProxyObject::performPut):
2488         (JSC::performProxyCall):
2489         (JSC::performProxyConstruct):
2490         (JSC::ProxyObject::performDelete):
2491         (JSC::ProxyObject::performPreventExtensions):
2492         (JSC::ProxyObject::performIsExtensible):
2493         (JSC::ProxyObject::performDefineOwnProperty):
2494         (JSC::ProxyObject::performGetOwnPropertyNames):
2495         (JSC::ProxyObject::performSetPrototype):
2496         (JSC::ProxyObject::performGetPrototype):
2497         (JSC::ProxyObject::getPrototype):
2498         (JSC::ProxyObject::revoke):
2499         (JSC::ProxyObject::visitChildren):
2500         * runtime/ProxyObject.h:
2501         (JSC::ProxyObject::create):
2502         * runtime/ProxyRevoke.cpp: Added.
2503         (JSC::ProxyRevoke::create):
2504         (JSC::ProxyRevoke::ProxyRevoke):
2505         (JSC::ProxyRevoke::finishCreation):
2506         (JSC::performProxyRevoke):
2507         (JSC::ProxyRevoke::getCallData):
2508         (JSC::ProxyRevoke::visitChildren):
2509         * runtime/ProxyRevoke.h: Added.
2510         (JSC::ProxyRevoke::createStructure):
2511         (JSC::ProxyRevoke::proxy):
2512         (JSC::ProxyRevoke::setProxyToNull):
2513         * tests/stress/proxy-has-property.js:
2514         (assert):
2515         (assert.let.handler.has):
2516         (assert.let.foo):
2517         * tests/stress/proxy-revoke.js: Added.
2518         (assert):
2519         (throw.new.Error.):
2520         (throw.new.Error):
2521         (callAllHandlers):
2522         (shouldThrowNullHandler):
2523         (allHandlersShouldThrow):
2524         (i.let.trap.of.traps.trap.string_appeared_here.func):
2525         (i.let.trap.of.traps.else.func):
2526         (i.Proxy.revocable):
2527
2528 2016-03-07  Csaba Osztrogon√°c  <ossy@webkit.org>
2529
2530         Fix the ARM build after r197687
2531         https://bugs.webkit.org/show_bug.cgi?id=155128
2532
2533         Reviewed by Saam Barati.
2534
2535         * assembler/MacroAssemblerARM.h:
2536         (JSC::MacroAssemblerARM::moveZeroToDouble):
2537
2538 2016-03-07  Filip Pizlo  <fpizlo@apple.com>
2539
2540         Reduce the number of instructions needed to record the last regexp result
2541         https://bugs.webkit.org/show_bug.cgi?id=155161
2542
2543         Reviewed by Sam Weinig.
2544
2545         This tightens up RegExpCachedResult::record(). My profiling shows that we spend just
2546         over 1% of the time in Octane/regexp in this function. This function had two obvious
2547         redundancies:
2548
2549         1) It executed the write barrier on owner twice. It only needs to execute it once. Since
2550            the same RegExpConstructor is likely to be used many times, it makes sense to do the
2551            barrier without looking at the 'to' objects at all. In steady state, this means that
2552            the RegExpConstructor will simply be OldGrey so this one barrier will always skip the
2553            slow path.
2554
2555         2) It cleared some fields that didn't need to be cleared, since we can just use
2556            m_reified to indicate that the fields are not meaningful anymore.
2557
2558         This is meant to be a microscopic regexp speed-up.
2559
2560         * runtime/RegExpCachedResult.cpp:
2561         (JSC::RegExpCachedResult::visitChildren):
2562         (JSC::RegExpCachedResult::lastResult):
2563         * runtime/RegExpCachedResult.h:
2564         (JSC::RegExpCachedResult::record):
2565
2566 2016-03-07  Filip Pizlo  <fpizlo@apple.com>
2567
2568         createRegExpMatchesArray should allocate substrings more quickly
2569         https://bugs.webkit.org/show_bug.cgi?id=155160
2570
2571         Reviewed by Sam Weinig.
2572
2573         This was calling a version of jsSubstring() that isn't inlineable because it was doing a lot
2574         of checks in finishCreation(). In particular, it was checking that the base string is not
2575         itself a substring and that it's been resolved. We don't need those checks here, since the
2576         string must have been resolved prior to regexp processing.
2577
2578         This patch is also smart about whether to do checks for the empty and full substrings. In
2579         the matches array loop, these checks are super unlikely to be profitable, so we just
2580         unconditionally allocate the substring.
2581
2582         This removes those checks and makes the allocation inlineable. It looks like a 1% speed-up
2583         on Octane/regexp.
2584
2585         * runtime/JSString.h:
2586         (JSC::jsSubstring):
2587         (JSC::jsSubstringOfResolved):
2588         * runtime/RegExpMatchesArray.cpp:
2589         (JSC::createRegExpMatchesArray):
2590
2591 2016-03-07  Benjamin Poulain  <bpoulain@apple.com>
2592
2593         [JSC] Small clean up of how we use SSA's valuesAtHead
2594         https://bugs.webkit.org/show_bug.cgi?id=155152
2595
2596         Reviewed by Filip Pizlo.
2597
2598         liveAtHead and valuesAtHead contain the same nodes,
2599         we do not need the extra look up.
2600
2601         This also opens the way to use the same kind of liveness
2602         analysis as Air (where live values at head do not use a set).
2603
2604         * dfg/DFGInPlaceAbstractState.cpp:
2605         (JSC::DFG::InPlaceAbstractState::beginBasicBlock):
2606         (JSC::DFG::InPlaceAbstractState::merge):
2607
2608 2016-03-07  Brian Burg  <bburg@apple.com>
2609
2610         Web Inspector: the protocol generator should generate factory method stubs for protocol types
2611         https://bugs.webkit.org/show_bug.cgi?id=155103
2612         <rdar://problem/25002772>
2613
2614         Reviewed by Timothy Hatcher.
2615
2616         Generate stubs with unique names so that parsing methods can be used
2617         reflectively at runtime, based on the protocol version that's loaded.
2618
2619         * JavaScriptCore.xcodeproj/project.pbxproj:
2620         * inspector/scripts/codegen/__init__.py:
2621         * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
2622         Added. For each type in a domain, add a method of the form
2623         -[ProtocolTypeConversions _parseXXX:fromPayload]. This is in a category
2624         method, and the selector is only ever looked up at runtime.
2625
2626         (ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
2627         * inspector/scripts/generate-inspector-protocol-bindings.py:
2628         (generate_from_specification):
2629
2630         Rebaseline test results with new generator output.
2631
2632         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2633         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2634         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2635         * inspector/scripts/tests/expected/enum-values.json-result:
2636         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2637         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2638         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2639         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2640         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2641         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2642         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2643         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2644         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2645
2646 2016-03-07  Filip Pizlo  <fpizlo@apple.com>
2647
2648         RegExp.prototype.exec() should call into Yarr at most once
2649         https://bugs.webkit.org/show_bug.cgi?id=155139
2650
2651         Reviewed by Saam Barati.
2652
2653         For apparently no good reason, RegExp.prototype.match() was calling into Yarr twice, almost
2654         as if it was hoping that the non-matching case was so common that it was best to have the
2655         matching case do the work all over again.
2656
2657         This is a 4% speed-up on Octane/regexp. It's also a matter of common sense: we should not be
2658         in the business of presuming whether someone's match will succeed or fail. The increased
2659         cost of running Yarr twice is so much larger than whatever savings we were getting from
2660         running a match-only regexp that this is just not a good overall deal for the engine.
2661
2662         Also, it's interesting that we are seeing a 4% speed-up on regexp despite the fact that a
2663         majority (almost a supermajority, I think) of calls into RegExp.prototype.match() are failed
2664         matches. So, this change is a 4% speed-up despite being a slow down on the common case. That
2665         tells you just how bad the old behavior was on the uncommon case.
2666
2667         * runtime/MatchResult.h:
2668         (MatchResult::MatchResult):
2669         (MatchResult::failed):
2670         (MatchResult::operator bool):
2671         * runtime/RegExpCachedResult.cpp:
2672         (JSC::RegExpCachedResult::lastResult):
2673         * runtime/RegExpConstructor.h:
2674         (JSC::RegExpConstructor::setMultiline):
2675         (JSC::RegExpConstructor::multiline):
2676         (JSC::RegExpConstructor::performMatch):
2677         (JSC::RegExpConstructor::recordMatch):
2678         * runtime/RegExpMatchesArray.cpp:
2679         (JSC::createRegExpMatchesArray):
2680         (JSC::createEmptyRegExpMatchesArray):
2681         (JSC::createStructureImpl):
2682         * runtime/RegExpMatchesArray.h:
2683         (JSC::createRegExpMatchesArray):
2684         * runtime/RegExpObject.cpp:
2685         (JSC::RegExpObject::put):
2686         (JSC::getLastIndexAsUnsigned):
2687         (JSC::RegExpObject::exec):
2688         (JSC::RegExpObject::match):
2689         * runtime/RegExpObject.h:
2690         (JSC::RegExpObject::getLastIndex):
2691         (JSC::RegExpObject::test):
2692         * runtime/StringPrototype.cpp:
2693         (JSC::stringProtoFuncMatch):
2694
2695 2016-03-07  Joseph Pecoraro  <pecoraro@apple.com>
2696
2697         Heap Snapshot should include different Edge types and data (Property, Index, Variable)
2698         https://bugs.webkit.org/show_bug.cgi?id=154937
2699
2700         Reviewed by Geoffrey Garen.
2701
2702         * heap/SlotVisitor.cpp:
2703         (JSC::SlotVisitor::appendHidden):
2704         * heap/SlotVisitor.h:
2705         * heap/SlotVisitorInlines.h:
2706         (JSC::SlotVisitor::appendHidden):
2707         (JSC::SlotVisitor::appendValuesHidden):
2708         Add new visit methods to visit a reference without snapshotting the edge.
2709
2710         * heap/Heap.cpp:
2711         (JSC::AddExtraHeapSnapshotEdges::AddExtraHeapSnapshotEdges):
2712         (JSC::AddExtraHeapSnapshotEdges::operator()):
2713         (JSC::Heap::addHeapSnapshotEdges):
2714         (JSC::Heap::removeDeadHeapSnapshotNodes):
2715         (JSC::Heap::collectImpl):
2716         * heap/Heap.h:
2717         After marking, visit the live cells for a chance to record extra
2718         heap snapshotting information about the cell.
2719
2720         * heap/HeapSnapshotBuilder.cpp:
2721         (JSC::HeapSnapshotBuilder::appendNode):
2722         (JSC::HeapSnapshotBuilder::appendEdge):
2723         (JSC::HeapSnapshotBuilder::appendPropertyNameEdge):
2724         (JSC::HeapSnapshotBuilder::appendVariableNameEdge):
2725         (JSC::HeapSnapshotBuilder::appendIndexEdge):
2726         (JSC::HeapSnapshotBuilder::json):
2727         * heap/HeapSnapshotBuilder.h:
2728         (JSC::HeapSnapshotEdge::HeapSnapshotEdge):
2729         Construct edges with extra data.
2730
2731         * runtime/ClassInfo.h:
2732         * runtime/JSCell.cpp:
2733         (JSC::JSCell::heapSnapshot):
2734         * runtime/JSCell.h:
2735         Add a new method to provide cells with an opportunity to provide
2736         extra heap snapshotting information.
2737
2738         * runtime/JSObject.cpp:
2739         (JSC::JSObject::visitButterfly):
2740         (JSC::JSObject::visitChildren):
2741         (JSC::JSObject::heapSnapshot):
2742         (JSC::JSFinalObject::visitChildren):
2743         * runtime/JSObject.h:
2744         Capture object property names and index names when heap snapshotting.
2745         Do not include them as internal edges in normal visitChildren.
2746
2747         * runtime/JSEnvironmentRecord.cpp:
2748         (JSC::JSEnvironmentRecord::visitChildren):
2749         (JSC::JSEnvironmentRecord::heapSnapshot):
2750         * runtime/JSEnvironmentRecord.h:
2751         * runtime/JSSegmentedVariableObject.cpp:
2752         (JSC::JSSegmentedVariableObject::visitChildren):
2753         (JSC::JSSegmentedVariableObject::heapSnapshot):
2754         * runtime/JSSegmentedVariableObject.h:
2755         Capture scope variable names when heap snapshotting.
2756
2757         * runtime/Structure.cpp:
2758         (JSC::Structure::visitChildren):
2759         * runtime/Structure.h:
2760         * runtime/StructureInlines.h:
2761         (JSC::Structure::propertyTable):
2762         When performing a heap snapshotting collection, don't clear the
2763         property table so that accessing the table during this GC is okay.
2764
2765         * tests/heapProfiler/driver/driver.js:
2766         * tests/heapProfiler/property-edge-types.js: Added.
2767         * tests/heapProfiler/variable-edge-types.js: Added.
2768         Tests covering the different edge types and data we capture.
2769
2770 2016-03-07  Saam barati  <sbarati@apple.com>
2771
2772         [ES6] Implement Proxy.[[GetPrototypeOf]]
2773         https://bugs.webkit.org/show_bug.cgi?id=155099
2774
2775         Reviewed by Mark Lam.
2776
2777         This patch is a straight forward implementation of Proxy.[[GetPrototypeOf]]
2778         with respect to section 9.5.1 of the ECMAScript spec.
2779         https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-getprototypeof
2780
2781         * runtime/ProxyObject.cpp:
2782         (JSC::performProxyGet):
2783         (JSC::ProxyObject::setPrototype):
2784         (JSC::ProxyObject::performGetPrototype):
2785         (JSC::ProxyObject::getPrototype):
2786         (JSC::ProxyObject::visitChildren):
2787         * runtime/ProxyObject.h:
2788         * tests/es6.yaml:
2789         * tests/stress/proxy-get-prototype-of.js: Added.
2790         (assert):
2791         (throw.new.Error.let.handler.get getPrototypeOf):
2792         (throw.new.Error.get let):
2793         (throw.new.Error.get catch):
2794         (throw.new.Error):
2795         (assert.let.handler.getPrototypeOf):
2796         (assert.get let):
2797         (assert.get catch):
2798         (assert.):
2799         (let.handler.getPrototypeOf):
2800         (get let):
2801         (let.handler.has):
2802
2803 2016-03-07  Brian Burg  <bburg@apple.com>
2804
2805         Web Inspector: rename generated *EnumConversionHelpers.h to *TypeConversions.h
2806         https://bugs.webkit.org/show_bug.cgi?id=155121
2807         <rdar://problem/25010391>
2808
2809         Reviewed by Timothy Hatcher.
2810
2811         Split out this renaming from the work to generate factory method stubs for types.
2812
2813         * JavaScriptCore.xcodeproj/project.pbxproj:
2814         * inspector/scripts/codegen/__init__.py:
2815         * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
2816         (ObjCConfigurationImplementationGenerator.generate_output):
2817         * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
2818         (ObjCFrontendDispatcherImplementationGenerator.generate_output):
2819         * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objc_conversion_helpers.py.
2820         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
2821         (ObjCProtocolTypesImplementationGenerator.generate_output):
2822         * inspector/scripts/codegen/objc_generator_templates.py:
2823         * inspector/scripts/generate-inspector-protocol-bindings.py:
2824         (generate_from_specification):
2825
2826         Rebaseline tests after changing generator order.
2827
2828         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2829         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2830         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2831         * inspector/scripts/tests/expected/enum-values.json-result:
2832         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2833         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2834         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2835         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2836         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2837         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2838         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2839         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2840         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2841
2842 2016-03-07  Benjamin Poulain  <benjamin@webkit.org>
2843
2844         [JSC] Improve and64() and or64() with immediate on x86
2845         https://bugs.webkit.org/show_bug.cgi?id=155104
2846
2847         Reviewed by Geoffrey Garen.
2848
2849         GetButterflyReadOnly was doing:
2850             movq 0x8(%rbx), %r9
2851             movq $0xfffffffffffffffc, %r11
2852             andq %r11, %r9
2853         There is no need for the move to load the immediate,
2854         andq sign extend its immediate.
2855
2856         With this patch, we have:
2857             movq 0x8(%rbx), %r9
2858             andq $0xfffffffffffffffc, %r9
2859
2860         * assembler/MacroAssemblerX86_64.h:
2861         (JSC::MacroAssemblerX86_64::and64):
2862         (JSC::MacroAssemblerX86_64::or64):
2863
2864 2016-03-07  Brian Burg  <bburg@apple.com>
2865
2866         Web Inspector: It should be possible to initialize generated ObjC protocol types from an NSDictionary payload
2867         https://bugs.webkit.org/show_bug.cgi?id=155102
2868         <rdar://problem/25002015>
2869
2870         Reviewed by Timothy Hatcher.
2871
2872         In Objective-C code, we sometimes prefer to parse JSON using Cocoa rather
2873         than the InspectorValue classes. Support initializing protocol objects
2874         directly from an NSDictionary payload. This delegates validation of values to
2875         the setter methods that already exist on the protocol object classes.
2876
2877         * inspector/scripts/codegen/generate_objc_header.py:
2878         (ObjCHeaderGenerator._generate_type_interface):
2879         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
2880         (ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
2881         (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
2882         * inspector/scripts/codegen/objc_generator.py:
2883         (ObjCGenerator.payload_to_objc_expression_for_member):
2884         Add a new helper method to generate an expression to unpack the value
2885         from an NSDictionary. If it's not a primitive, the setter performs
2886         validation of the value's kind using -[NSObject isKindOfClass:].
2887
2888         Rebaseline relevant tests.
2889
2890         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2891         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2892         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2893         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2894         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2895         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2896         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2897
2898 2016-03-07  Benjamin Poulain  <benjamin@webkit.org>
2899
2900         [JSC] Simplify the overflow check of ArithAbs
2901         https://bugs.webkit.org/show_bug.cgi?id=155063
2902
2903         Reviewed by Geoffrey Garen.
2904
2905         The only integer that overflow abs(int32) is INT_MIN.
2906         For some reason, our code testing for that case
2907         was checking the top bit of the result specifically.
2908
2909         The code required a large immediate on x86 and an extra
2910         register on ARM64.
2911
2912         This patch turns the overflow check into a branch on
2913         the sign of the result.
2914
2915         * dfg/DFGSpeculativeJIT32_64.cpp:
2916         (JSC::DFG::SpeculativeJIT::compile):
2917         * dfg/DFGSpeculativeJIT64.cpp:
2918         (JSC::DFG::SpeculativeJIT::compile):
2919         * ftl/FTLLowerDFGToB3.cpp:
2920         (JSC::FTL::DFG::LowerDFGToB3::compileArithAbs):
2921         * jit/ThunkGenerators.cpp:
2922         (JSC::absThunkGenerator):
2923         * tests/stress/arith-abs-overflow.js: Added.
2924         (opaqueAbs):
2925
2926 2016-03-07  Benjamin Poulain  <bpoulain@apple.com>
2927
2928         [JSC] Improve how DFG zero Floating Point registers
2929         https://bugs.webkit.org/show_bug.cgi?id=155096
2930
2931         Reviewed by Geoffrey Garen.
2932
2933         DFG had a weird way of zeroing a FPR:
2934             -zero a GP.
2935             -move that to a FP.
2936
2937         Filip added moveZeroToDouble() for B3. This patch
2938         uses that in the lower tiers.
2939
2940         * assembler/MacroAssemblerARMv7.h:
2941         (JSC::MacroAssemblerARMv7::moveZeroToDouble):
2942         * dfg/DFGSpeculativeJIT64.cpp:
2943         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
2944         * jit/ThunkGenerators.cpp:
2945         (JSC::floorThunkGenerator):
2946         (JSC::roundThunkGenerator):
2947
2948 2016-03-07  Andreas Kling  <akling@apple.com>
2949
2950         REGRESSION (r197303): Web Inspector crashes web process when inspecting an element on TOT
2951         <https://webkit.org/b/154812>
2952
2953         Reviewed by Geoffrey Garen.
2954
2955         Guard against null pointer dereference for UnlinkedCodeBlocks that don't have any control flow
2956         profiling data.
2957
2958         * bytecode/CodeBlock.cpp:
2959         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
2960         * bytecode/UnlinkedCodeBlock.h:
2961         (JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets):
2962
2963 2016-03-07  Benjamin Poulain  <benjamin@webkit.org>
2964
2965         [JSC] Remove a useless "Move" from baseline-JIT op_mul's fast path
2966         https://bugs.webkit.org/show_bug.cgi?id=155071
2967
2968         Reviewed by Geoffrey Garen.
2969
2970         We do not need to multiply to a scratch and then move the result
2971         to the destination. We can just multiply to the destination.
2972
2973         * jit/JITArithmetic.cpp:
2974         (JSC::JIT::emit_op_mul):
2975         * jit/JITMulGenerator.cpp:
2976         (JSC::JITMulGenerator::generateFastPath):
2977
2978 2016-03-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2979
2980         [JSC] StringObject.{put, defineOwnProperty} should realize indexed properties
2981         https://bugs.webkit.org/show_bug.cgi?id=155089
2982
2983         Reviewed by Geoffrey Garen.
2984
2985         Through implementing Reflect.set[1], we found StringObject does not obey the spec.
2986         StringObject::put should call putByIndex if the given propertyName is index.
2987         And StringObject::defineOwnProperty should recognize indexed properties since
2988         JSObject::defineOwnIndexedProperty is specialized to JSObject layout.
2989         Before calling JSObject::defineOwnProperty,
2990         StringObject should handle its special indexed own properties.
2991         It is responsibility of StringObject::defineOwnProperty.
2992
2993         And the logic is cleaned up by using validateAndApplyPropertyDescriptor.
2994
2995         [1]: https://bugs.webkit.org/show_bug.cgi?id=155024
2996
2997         * runtime/StringObject.cpp:
2998         (JSC::StringObject::put):
2999         (JSC::StringObject::putByIndex):
3000         (JSC::isStringOwnProperty):
3001         (JSC::StringObject::defineOwnProperty):
3002         (JSC::StringObject::deleteProperty):
3003         * tests/stress/string-object-define-own-property.js: Added.
3004         (shouldBe):
3005         (shouldThrow):
3006         * tests/stress/string-object-put-by-index.js: Added.
3007         (shouldBe):
3008         (shouldThrow):
3009         (testSloppy):
3010         (testStrict):
3011
3012 2016-03-06  Brian Burg  <bburg@apple.com>
3013
3014         Web Inspector: the protocol generator should have separate prefix options for Objective-C classes and filenames
3015         https://bugs.webkit.org/show_bug.cgi?id=155101
3016         <rdar://problem/25000053>
3017
3018         Reviewed by Timothy Hatcher.
3019
3020         It should be possible to generate Objective-C protocol types without prefixing all class names.
3021         The prefixes are only necessary when the generated files are part of a framework, but this isn't
3022         how the generated Objective-C frontend files are used.
3023
3024         Add a separate framework setting and switch over code to use the 'protocol_group' in filenames,
3025         and the 'objc_prefix' for Objective-C enum and class prefixes.
3026
3027         No tests need to be rebaselined because tests always set the protocol_group and objc_prefix
3028         to the same value.
3029
3030         * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
3031         (ObjCBackendDispatcherHeaderGenerator.output_filename):
3032         * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
3033         (ObjCConfigurationImplementationGenerator.output_filename):
3034         (ObjCConfigurationImplementationGenerator.generate_output):
3035         * inspector/scripts/codegen/generate_objc_configuration_header.py:
3036         (ObjCConfigurationHeaderGenerator.output_filename):
3037         (ObjCConfigurationHeaderGenerator.generate_output):
3038         (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
3039         * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
3040         (ObjCBackendDispatcherImplementationGenerator.output_filename):
3041         (ObjCBackendDispatcherImplementationGenerator.generate_output):
3042         (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
3043         * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
3044         (ObjCConversionHelpersGenerator.output_filename):
3045         * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
3046         (ObjCFrontendDispatcherImplementationGenerator.output_filename):
3047         (ObjCFrontendDispatcherImplementationGenerator.generate_output):
3048         * inspector/scripts/codegen/generate_objc_header.py:
3049         (ObjCHeaderGenerator.output_filename):
3050         * inspector/scripts/codegen/generate_objc_internal_header.py:
3051         (ObjCInternalHeaderGenerator.output_filename):
3052         (ObjCInternalHeaderGenerator.generate_output):
3053         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
3054         (ObjCProtocolTypesImplementationGenerator.output_filename):
3055         (ObjCProtocolTypesImplementationGenerator.generate_output):
3056         * inspector/scripts/codegen/models.py:
3057         * inspector/scripts/codegen/objc_generator.py:
3058         (ObjCGenerator):
3059         (ObjCGenerator.protocol_name):
3060         (ObjCGenerator.objc_prefix):
3061
3062 2016-03-06  Brian Burg  <bburg@apple.com>
3063
3064         Unreviewed, rebaseline inspector protocol generator tests after r197563.
3065
3066         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
3067         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
3068         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
3069         * inspector/scripts/tests/expected/enum-values.json-result:
3070         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
3071
3072 2016-03-06  Benjamin Poulain  <benjamin@webkit.org>
3073
3074         [JSC] Improve DFG's Int32 ArithMul if one operand is a constant
3075         https://bugs.webkit.org/show_bug.cgi?id=155066
3076
3077         Reviewed by Filip Pizlo.
3078
3079         When multiplying an integer by a constant, DFG was doing quite
3080         a bit worse than baseline JIT.
3081         We were loading the constant into a register, doing the multiply,
3082         the checking the result and both operands for negative zero.
3083
3084         This patch changes:
3085         -Use the multiply-by-immediate form on x86.
3086         -Do as few checks as possible to detect negative-zero.
3087
3088         In most cases, this reduce the negative-zero checks
3089         to zero or one TEST+JUMP.
3090
3091         * assembler/MacroAssembler.h:
3092         (JSC::MacroAssembler::mul32):
3093         * dfg/DFGSpeculativeJIT.cpp:
3094         (JSC::DFG::SpeculativeJIT::compileArithMul):
3095
3096 2016-03-06  Benjamin Poulain  <benjamin@webkit.org>
3097
3098         [JSC] Remove a superfluous Move in front of every double unboxing
3099         https://bugs.webkit.org/show_bug.cgi?id=155064
3100
3101         Reviewed by Saam Barati.
3102
3103         Double unboxing was always doing:
3104             Move source, scratch
3105             Add64 tag, scratch
3106             IntToDouble scratch, fp
3107
3108         We do not need to "Move" to copy the source.
3109         Both x86 and ARM64 have an efficient 3 operands Add instruction.
3110
3111         * dfg/DFGSpeculativeJIT.cpp:
3112         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3113         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
3114         (JSC::DFG::SpeculativeJIT::speculateRealNumber):
3115         * dfg/DFGSpeculativeJIT.h:
3116         (JSC::DFG::SpeculativeJIT::unboxDouble):
3117         * jit/AssemblyHelpers.h:
3118         (JSC::AssemblyHelpers::unboxDoubleWithoutAssertions):
3119         (JSC::AssemblyHelpers::unboxDouble):
3120         (JSC::AssemblyHelpers::unboxDoubleNonDestructive):
3121
3122 2016-03-06  Benjamin Poulain  <benjamin@webkit.org>
3123
3124         [JSC] Use 3 operands Add in more places
3125         https://bugs.webkit.org/show_bug.cgi?id=155082
3126
3127         Reviewed by Filip Pizlo.
3128
3129         * assembler/MacroAssembler.h:
3130         (JSC::MacroAssembler::addPtr):
3131         (JSC::MacroAssembler::add32):
3132         * assembler/MacroAssemblerARMv7.h:
3133         (JSC::MacroAssemblerARMv7::add32):
3134         * dfg/DFGSpeculativeJIT.cpp:
3135         (JSC::DFG::SpeculativeJIT::compileArithAdd):
3136         The case with child1 constant is useless.
3137         The canonical form will have the constant as child2.
3138
3139         Also add register reuse for the fast-add.
3140         Registers are a scarce resource on x86.
3141
3142         * jit/CCallHelpers.h:
3143         (JSC::CCallHelpers::prepareForTailCallSlow):
3144         * yarr/YarrJIT.cpp:
3145         (JSC::Yarr::YarrGenerator::generate):
3146
3147 2016-03-06  Benjamin Poulain  <bpoulain@apple.com>
3148
3149         [JSC] Improve codegen of Compare and Test
3150         https://bugs.webkit.org/show_bug.cgi?id=155055
3151
3152         Reviewed by Filip Pizlo.
3153
3154         This patch introduces a few improvements on how we lower
3155         Compare and Test with immediates:
3156             -Add certain Immediate forms of ARM64.
3157             -Use CBZ/CBNZ when possible on ARM64.
3158             -When possible, convert a CMP into a TST
3159              On some hardware, we can issue more TST simultaneously.
3160
3161              On x86, any TST+Jump is candidate for macro-fusion.
3162              They are also smaller.
3163              (sections 3.4.2.2 and 3.5.1.9)
3164             -Do not load the mask immediate of a TST
3165              if it only contains ones (mostly useful for ARM64
3166              since that would not have been a valid immediate).
3167
3168         * assembler/MacroAssembler.h:
3169         (JSC::MacroAssembler::compare32):
3170         * assembler/MacroAssemblerARM64.h:
3171         (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare):
3172         (JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare):
3173         This is somewhat unrelated but I found that out while working
3174         on moveDoubleConditionallyTest32:
3175             If "thenCase" and "dest" are assigned the same register
3176             by the allocator, then the first (f)fcsel would override
3177             the "thenCase" and the second fcsel would always be "elseCase".
3178
3179         This is covered by testb3 but was only uncovered
3180         after recent "Move" removals in lowering.
3181
3182         (JSC::MacroAssemblerARM64::moveConditionally32):
3183         (JSC::MacroAssemblerARM64::moveConditionally64):
3184         (JSC::MacroAssemblerARM64::moveConditionallyTest32):
3185         (JSC::MacroAssemblerARM64::moveDoubleConditionally32):
3186         (JSC::MacroAssemblerARM64::moveDoubleConditionally64):
3187         (JSC::MacroAssemblerARM64::moveDoubleConditionallyTest32):
3188         (JSC::MacroAssemblerARM64::branch32):
3189         (JSC::MacroAssemblerARM64::branch64):
3190         (JSC::MacroAssemblerARM64::branchTest32):
3191         (JSC::MacroAssemblerARM64::test32):
3192         The version taking an immediate was guarded by
3193         (cond == Zero) || (cond == NonZero). That is overzealous,
3194         and only needed for CBZ/CBNZ.
3195
3196         (JSC::MacroAssemblerARM64::branchTest64):
3197         (JSC::MacroAssemblerARM64::compare32):
3198         (JSC::MacroAssemblerARM64::compare64):
3199         (JSC::MacroAssemblerARM64::commuteCompareToZeroIntoTest):
3200         * assembler/MacroAssemblerX86Common.h:
3201         (JSC::MacroAssemblerX86Common::moveConditionally32):
3202         (JSC::MacroAssemblerX86Common::moveConditionallyTest32):
3203         (JSC::MacroAssemblerX86Common::branch32):
3204         (JSC::MacroAssemblerX86Common::test32):
3205         (JSC::MacroAssemblerX86Common::branchTest32):
3206         (JSC::MacroAssemblerX86Common::compare32):
3207         (JSC::MacroAssemblerX86Common::commuteCompareToZeroIntoTest):
3208         * assembler/MacroAssemblerX86_64.h:
3209         (JSC::MacroAssemblerX86_64::compare64):
3210         (JSC::MacroAssemblerX86_64::branch64):
3211         (JSC::MacroAssemblerX86_64::moveConditionally64):
3212         * b3/B3LowerToAir.cpp:
3213         (JSC::B3::Air::LowerToAir::createGenericCompare):
3214         Unfortunately this cannot be abstracted by the MacroAssembler.
3215         Those immediates are not valid, we have to pick the better
3216         for right away.
3217
3218         * b3/air/AirOpcode.opcodes:
3219         * b3/testb3.cpp:
3220         (JSC::B3::int64Operands):
3221         (JSC::B3::modelCompare):
3222         (JSC::B3::testCompareImpl):
3223         (JSC::B3::testCompare):
3224         (JSC::B3::b3Pow):
3225         (JSC::B3::testPowDoubleByIntegerLoop):
3226         Some versions of pow(double, int) do not return
3227         the exact same bits as our integer loop.
3228         Added a new version to have the same behavior
3229         as the B3 loop.
3230
3231         (JSC::B3::run):
3232         * dfg/DFGSpeculativeJIT.cpp:
3233         (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
3234         * dfg/DFGSpeculativeJIT64.cpp:
3235         (JSC::DFG::SpeculativeJIT::compileInt32Compare):
3236         Comparing to an immediate is super common. Do not waste
3237         a register for that!
3238
3239 2016-03-06  Filip Pizlo  <fpizlo@apple.com>
3240
3241         Unreviewed, fix build. This was a messed up merge.
3242
3243         * ftl/FTLLowerDFGToB3.cpp:
3244         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
3245
3246 2016-03-06  Filip Pizlo  <fpizlo@apple.com>
3247
3248         DFG should know how to speculate StringOrOther
3249         https://bugs.webkit.org/show_bug.cgi?id=155094
3250
3251         Reviewed by Saam Barati.
3252
3253         Any code that processes the regexp matches array was previously doing a relatively expensive
3254         Branch(Untyped:). This introduces a new use kind called StringOrOther, which is perfect for
3255         code that loops over the matches array and branches on the entries being non-empty.
3256
3257         To do this, I needed to introduce code into the FTL that creates new blocks. We still had that
3258         awful FTL_NEW_BLOCK idiom since the only way to debug LLVM IR was to ascribe names to basic
3259         blocks. B3 IR is inherently more debuggable since unlike LLVM, B3 knows how to always respect
3260         code origin, and it knows how to print the code origin nicely in the dumps. So, rather than
3261         continue using FTL_NEW_BLOCK(m_out, ("things")), I replaced all of that stuff with
3262         m_out.newBlock(). It's much nicer that way.
3263
3264         This is a tiny speed-up on Octane/regexp at best. I was hoping for more. Oh well.
3265
3266         * bytecode/SpeculatedType.h:
3267         (JSC::isStringSpeculation):
3268         (JSC::isStringOrOtherSpeculation):
3269         (JSC::isSymbolSpeculation):
3270         * dfg/DFGFixupPhase.cpp:
3271         (JSC::DFG::FixupPhase::fixupNode):
3272         * dfg/DFGNode.h:
3273         (JSC::DFG::Node::shouldSpeculateString):
3274         (JSC::DFG::Node::shouldSpeculateStringOrOther):
3275         (JSC::DFG::Node::shouldSpeculateStringObject):
3276         * dfg/DFGSafeToExecute.h:
3277         (JSC::DFG::SafeToExecuteEdge::operator()):
3278         * dfg/DFGSpeculativeJIT.cpp:
3279         (JSC::DFG::SpeculativeJIT::compileStringZeroLength):
3280         (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
3281         (JSC::DFG::SpeculativeJIT::emitStringBranch):
3282         (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
3283         (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer):
3284         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
3285         (JSC::DFG::SpeculativeJIT::speculateString):
3286         (JSC::DFG::SpeculativeJIT::speculateStringOrOther):
3287         (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
3288         (JSC::DFG::SpeculativeJIT::speculate):
3289         * dfg/DFGSpeculativeJIT.h:
3290         * dfg/DFGSpeculativeJIT32_64.cpp:
3291         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
3292         (JSC::DFG::SpeculativeJIT::emitBranch):
3293         * dfg/DFGSpeculativeJIT64.cpp:
3294         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
3295         (JSC::DFG::SpeculativeJIT::emitBranch):
3296         * dfg/DFGUseKind.cpp:
3297         (WTF::printInternal):
3298         * dfg/DFGUseKind.h:
3299         (JSC::DFG::typeFilterFor):
3300         * ftl/FTLCapabilities.cpp:
3301         (JSC::FTL::canCompile):
3302         * ftl/FTLLowerDFGToB3.cpp:
3303         (JSC::FTL::DFG::LowerDFGToB3::lower):
3304         (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
3305         (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber):
3306         (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
3307         (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
3308         (JSC::FTL::DFG::LowerDFGToB3::compileArithDiv):
3309         (JSC::FTL::DFG::LowerDFGToB3::compileArithMod):
3310         (JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax):
3311         (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
3312         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
3313         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructure):
3314         (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure):
3315         (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
3316         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
3317         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
3318         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
3319         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
3320         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
3321         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
3322         (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
3323         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
3324         (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
3325         (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest):
3326         (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
3327         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
3328         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
3329         (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
3330         (JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive):
3331         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
3332         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
3333         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
3334         (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
3335         (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
3336         (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
3337         (JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite):
3338         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
3339         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
3340         (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
3341         (JSC::FTL::DFG::LowerDFGToB3::compileIsString):
3342         (JSC::FTL::DFG::LowerDFGToB3::compileIsObject):
3343         (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
3344         (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
3345         (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
3346         (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
3347         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
3348         (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
3349         (JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty):
3350         (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
3351         (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname):