Static property hashtable should only lookup with non-symbol key
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         Static property hashtable should only lookup with non-symbol key
4         https://bugs.webkit.org/show_bug.cgi?id=144438
5
6         Reviewed by Darin Adler.
7
8         Static property hashtable compares the Identifier's uid
9         with the normal C string without interning it.
10         So this comparison is performed in their contents.
11         As the result, in this comparison, symbol-ness is not considered.
12
13         So if accidentally the hash collision occur with the symbol and the string
14         and they have the same contents, the hash table entry is looked up incorrectly.
15
16         * runtime/Lookup.h:
17         (JSC::HashTable::entry):
18
19 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
20
21         Class syntax should allow string and numeric identifiers for method names
22         https://bugs.webkit.org/show_bug.cgi?id=144254
23
24         Reviewed by Darin Adler.
25
26         Added the support for string and numeric identifiers in class syntax.
27
28         * parser/Parser.cpp:
29         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
30         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
31         outside a class constructor as it should be.
32         (JSC::Parser<LexerType>::parseFunctionDeclaration):
33         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
34         element to allow numeric and string method names. For both of those method names, parse it here instead
35         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
36         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
37         this function is never used to parse a class method.
38         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
39         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
40         * parser/Parser.h:
41         * parser/SyntaxChecker.h:
42         (JSC::SyntaxChecker::createProperty):
43
44 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
45
46         FTL should use AI more
47         https://bugs.webkit.org/show_bug.cgi?id=144500
48
49         Reviewed by Oliver Hunt.
50         
51         This makes our type check folding even more comprehensive by ensuring that even if the FTL
52         decides to emit some checks, it will still do another query to the abstract interpreter to
53         see if the check is necessary. This helps with cases where we decided early on to speculate
54         one way, but later proved a more specific type of the value in question, and the constant
55         folder didn't catch it.
56         
57         This also makes it more natural to query the abstract interpreter. For example, if you just
58         want the proven type, you can now say provenType(node) or provenType(edge).
59
60         * dfg/DFGArrayMode.cpp:
61         (JSC::DFG::ArrayMode::alreadyChecked):
62         * dfg/DFGArrayMode.h:
63         * ftl/FTLLowerDFGToLLVM.cpp:
64         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
65         (JSC::FTL::LowerDFGToLLVM::compileToThis):
66         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
67         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
68         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
69         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
70         (JSC::FTL::LowerDFGToLLVM::compileGetById):
71         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
72         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
73         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
74         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
75         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
76         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
77         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
78         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
79         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
80         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
81         (JSC::FTL::LowerDFGToLLVM::compileIsString):
82         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
83         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
84         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
85         (JSC::FTL::LowerDFGToLLVM::baseIndex):
86         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
87         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
88         (JSC::FTL::LowerDFGToLLVM::boolify):
89         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
90         (JSC::FTL::LowerDFGToLLVM::lowInt32):
91         (JSC::FTL::LowerDFGToLLVM::lowInt52):
92         (JSC::FTL::LowerDFGToLLVM::lowCell):
93         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
94         (JSC::FTL::LowerDFGToLLVM::lowDouble):
95         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
96         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
97         (JSC::FTL::LowerDFGToLLVM::isNumber):
98         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
99         (JSC::FTL::LowerDFGToLLVM::isNotCell):
100         (JSC::FTL::LowerDFGToLLVM::isCell):
101         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
102         (JSC::FTL::LowerDFGToLLVM::isMisc):
103         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
104         (JSC::FTL::LowerDFGToLLVM::isBoolean):
105         (JSC::FTL::LowerDFGToLLVM::isNotOther):
106         (JSC::FTL::LowerDFGToLLVM::isOther):
107         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
108         (JSC::FTL::LowerDFGToLLVM::isObject):
109         (JSC::FTL::LowerDFGToLLVM::isNotObject):
110         (JSC::FTL::LowerDFGToLLVM::isNotString):
111         (JSC::FTL::LowerDFGToLLVM::isString):
112         (JSC::FTL::LowerDFGToLLVM::isFunction):
113         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
114         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
115         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
116         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
117         (JSC::FTL::LowerDFGToLLVM::abstractValue):
118         (JSC::FTL::LowerDFGToLLVM::provenType):
119         (JSC::FTL::LowerDFGToLLVM::provenValue):
120         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
121
122 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
123
124         USE(...) macro should expect unprefixed variables
125         https://bugs.webkit.org/show_bug.cgi?id=144454
126
127         Reviewed by Daniel Bates.
128
129         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
130
131 2015-05-01  Jordan Harband  <ljharb@gmail.com>
132
133         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
134         https://bugs.webkit.org/show_bug.cgi?id=144314
135
136         Reviewed by Darin Adler.
137
138         Fixing handling of Infinity position args, per
139         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
140         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
141         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
142
143         * runtime/StringPrototype.cpp:
144         (JSC::clampInt32):
145         (JSC::stringProtoFuncStartsWith):
146         (JSC::stringProtoFuncEndsWith):
147         (JSC::stringProtoFuncIncludes):
148
149 2015-05-01  Basile Clement  <basile_clement@apple.com>
150
151         Math.abs() returns negative
152         https://bugs.webkit.org/show_bug.cgi?id=137827
153
154         Reviewed by Michael Saboff.
155
156         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
157         identity function.
158
159         * dfg/DFGAbstractInterpreterInlines.h:
160         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
161         * tests/stress/math-abs-positive.js: Added, was previously failing.
162         (foo):
163
164 2015-05-01  Basile Clement  <basile_clement@apple.com>
165
166         Function allocation sinking shouldn't be performed on singleton functions
167         https://bugs.webkit.org/show_bug.cgi?id=144166
168
169         Reviewed by Geoffrey Garen.
170
171         Function allocations usually are free of any other side effects, but
172         this is not the case for allocations performed while the underlying
173         FunctionExecutable is still a singleton (as this allogation will fire
174         watchpoints invalidating code that depends on it being a singleton).
175         As the object allocation sinking phase assumes object allocation is
176         free of side-effects, sinking these allocations is not correct.
177
178         This also means that when materializing a function allocation on OSR
179         exit, that function's executable will never be a singleton, and we don't have
180         to worry about its watchpoint, allowing us to use
181         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
182         JSFunction::create.
183
184         * dfg/DFGObjectAllocationSinkingPhase.cpp:
185         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
186         * ftl/FTLOperations.cpp:
187         (JSC::FTL::operationMaterializeObjectInOSR):
188
189 2015-04-30  Jon Davis  <jond@apple.com>
190
191         Web Inspector: console should show an icon for console.info() messages
192         https://bugs.webkit.org/show_bug.cgi?id=18530
193
194         Reviewed by Timothy Hatcher.
195
196         * inspector/ConsoleMessage.cpp:
197         (Inspector::messageLevelValue):
198         * inspector/protocol/Console.json:
199         * runtime/ConsoleClient.cpp:
200         (JSC::appendMessagePrefix):
201         * runtime/ConsolePrototype.cpp:
202         (JSC::ConsolePrototype::finishCreation):
203         (JSC::consoleProtoFuncInfo):
204         * runtime/ConsoleTypes.h:
205
206 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
207
208         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
209         https://bugs.webkit.org/show_bug.cgi?id=144462
210
211         Reviewed by Geoffrey Garen and Mark Lam.
212         
213         At some point we started adding representation-agnostic helpers for doing common type tests.
214         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
215         they had overlapping powers, though SpeculativeJIT was a bit better.
216         
217         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
218         better because now all of these helpers can be used in all of the assembly-based JITs, not
219         just the DFG. It also settles on what I find to be a slightly better naming convention.
220         For example where we previously would have said branchIsString, now we say
221         branchIfString. Similarly, branchNotString becomes branchIfNotString.
222
223         * dfg/DFGSpeculativeJIT.cpp:
224         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
225         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
226         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
227         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
228         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
229         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
230         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
231         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
232         (JSC::DFG::SpeculativeJIT::speculateObject):
233         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
234         (JSC::DFG::SpeculativeJIT::speculateString):
235         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
236         (JSC::DFG::SpeculativeJIT::speculateNotCell):
237         (JSC::DFG::SpeculativeJIT::speculateOther):
238         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
239         (JSC::DFG::SpeculativeJIT::emitSwitchString):
240         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
241         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
242         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
243         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
244         * dfg/DFGSpeculativeJIT.h:
245         * dfg/DFGSpeculativeJIT32_64.cpp:
246         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
247         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
248         (JSC::DFG::SpeculativeJIT::emitCall):
249         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
250         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
251         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
252         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
253         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
254         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
255         (JSC::DFG::SpeculativeJIT::compile):
256         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
257         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
258         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
259         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
260         * dfg/DFGSpeculativeJIT64.cpp:
261         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
262         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
263         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
264         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
265         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
266         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
267         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
268         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
269         (JSC::DFG::SpeculativeJIT::compile):
270         (JSC::DFG::SpeculativeJIT::writeBarrier):
271         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
272         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
273         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
274         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
275         * jit/AssemblyHelpers.h:
276         (JSC::AssemblyHelpers::branchIfCell):
277         (JSC::AssemblyHelpers::branchIfOther):
278         (JSC::AssemblyHelpers::branchIfNotOther):
279         (JSC::AssemblyHelpers::branchIfObject):
280         (JSC::AssemblyHelpers::branchIfNotObject):
281         (JSC::AssemblyHelpers::branchIfType):
282         (JSC::AssemblyHelpers::branchIfNotType):
283         (JSC::AssemblyHelpers::branchIfString):
284         (JSC::AssemblyHelpers::branchIfNotString):
285         (JSC::AssemblyHelpers::branchIfSymbol):
286         (JSC::AssemblyHelpers::branchIfNotSymbol):
287         (JSC::AssemblyHelpers::branchIfFunction):
288         (JSC::AssemblyHelpers::branchIfNotFunction):
289         (JSC::AssemblyHelpers::branchIfEmpty):
290         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
291         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
292         * jit/JITPropertyAccess.cpp:
293         (JSC::JIT::emitScopedArgumentsGetByVal):
294
295 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
296
297         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
298         https://bugs.webkit.org/show_bug.cgi?id=144463
299
300         Reviewed by Benjamin Poulain.
301         
302         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
303         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
304         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
305         converting the boolean into an integer. But as part of doing that, it would try to
306         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
307         and it would try to figure out if the addition might overflow. Part of that logic
308         involved checking if the immediate is either a boolean or a sufficiently small integer.
309         But: it would check if it's a sufficiently small integer before checking if it was a
310         boolean, so it would try to call asNumber() on the boolean.
311         
312         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
313         case was previously never hit until I wrote these tests, and so we never knew that
314         calling asNumber() on a boolean was wrong.
315         
316         The fix is super simple: the expression should just check for boolean first.
317         
318         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
319         garbage, and that's OK, since we'd take the boolean case anyway.
320
321         * dfg/DFGGraph.h:
322         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
323
324 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
325
326         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
327
328         * jit/JITOperations.cpp:
329
330 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
331
332         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
333         particular that they cannot change their minds and may be called from compiler threads.
334
335         Rubber stamped by Geoffrey Garen.
336
337         * runtime/JSCell.h:
338
339 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
340
341         DFG Is<Blah> versions of TypeOf should fold based on proven input type
342         https://bugs.webkit.org/show_bug.cgi?id=144409
343
344         Reviewed by Geoffrey Garen.
345         
346         We were missing some obvious folding opportunities here. I don't know how this affects real
347         code, but in general, we like to ensure that our constant folding is comprehensive. So this
348         is more about placating my static analysis OCD than anything else.
349         
350         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
351
352         * dfg/DFGAbstractInterpreterInlines.h:
353         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
354
355 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
356
357         Use the default hash value for Symbolized StringImpl
358         https://bugs.webkit.org/show_bug.cgi?id=144347
359
360         Reviewed by Darin Adler.
361
362         Before this patch, symbolized StringImpl* has a special hash value
363         to avoid the hash collision with the other normal StringImpl*.
364         I guess that it is introduced when private symbols are introduced.
365         However, it prevents using symbolized StringImpl* in the other place
366         For example, using it as WTFString cause a problem because of its special hash value.
367
368         When only using private symbols, they are not exposed to the outside of JSC,
369         so we can handle it carefully. But now, it's extended to symbols.
370         So I think storing a special hash value in StringImpl* causes an error.
371
372         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
373         And to provide significantly different hash value when using it as symbol,
374         store the additional hash value in symbolized StringImpl*. It is used when
375         the hash value is required by IdentifierRepHash.
376
377         * runtime/Identifier.h:
378         (JSC::IdentifierRepHash::hash):
379         * runtime/Lookup.h:
380         (JSC::HashTable::entry):
381         * runtime/PropertyMapHashTable.h:
382         (JSC::PropertyTable::find):
383         (JSC::PropertyTable::get):
384         * runtime/Structure.cpp:
385         (JSC::PropertyTable::checkConsistency):
386
387 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
388
389         [JSC] Remove RageConvert array conversion
390         https://bugs.webkit.org/show_bug.cgi?id=144433
391
392         Reviewed by Filip Pizlo.
393
394         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
395         pretty hard:
396         -The indexing types shows that the array access varies between Int32 and DoubleArray.
397         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
398          An Arrayify node would convert the Int32 to that type.
399         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
400          node would use RageConvert instead of Convert.
401         -The Arrayify for that GetByVal with RageConvert would not convert the array to
402          Contiguous.
403         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
404          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
405          fail systematically and we never get to run the later code.
406
407         Getting rid of RageConvert fixes the problem and does not seems to have any
408         negative side effect on other benchmarks.
409
410         The improvments on Kraken are:
411             -stanford-crypto-aes: definitely 1.0915x faster.
412             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
413             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
414
415         * dfg/DFGAbstractInterpreterInlines.h:
416         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
417         * dfg/DFGArrayMode.cpp:
418         (JSC::DFG::ArrayMode::refine):
419         (JSC::DFG::arrayConversionToString):
420         * dfg/DFGArrayMode.h:
421         * dfg/DFGArrayifySlowPathGenerator.h:
422         * dfg/DFGFixupPhase.cpp:
423         (JSC::DFG::FixupPhase::fixupNode):
424         * dfg/DFGOperations.cpp:
425         * dfg/DFGOperations.h:
426         * dfg/DFGPredictionPropagationPhase.cpp:
427         (JSC::DFG::PredictionPropagationPhase::propagate):
428         * dfg/DFGTypeCheckHoistingPhase.cpp:
429         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
430         * ftl/FTLLowerDFGToLLVM.cpp:
431         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
432         * runtime/JSObject.cpp:
433         (JSC::JSObject::convertDoubleToContiguous):
434         (JSC::JSObject::ensureContiguousSlow):
435         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
436         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
437         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
438         * runtime/JSObject.h:
439         (JSC::JSObject::rageEnsureContiguous): Deleted.
440
441 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
442
443         Gracefully handle missing auto pause key on remote inspector setup
444         https://bugs.webkit.org/show_bug.cgi?id=144411
445
446         Reviewed by Timothy Hatcher.
447
448         * inspector/remote/RemoteInspector.mm:
449         (Inspector::RemoteInspector::receivedSetupMessage):
450
451 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
452
453         NodeList has issues with Symbol and empty string
454         https://bugs.webkit.org/show_bug.cgi?id=144310
455
456         Reviewed by Darin Adler.
457
458         * runtime/PropertyName.h:
459         (JSC::PropertyName::isSymbol):
460         Helper to check if the PropertyName is a string or symbol property.
461
462 2015-04-29  Alex Christensen  <achristensen@webkit.org>
463
464         Fix non-cygwin incremental builds on Windows.
465         https://bugs.webkit.org/show_bug.cgi?id=143264
466
467         Reviewed by Brent Fulgham.
468
469         * generate-js-builtins:
470         Remove stale headers before calling os.rename to replace them.
471
472 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
473
474         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
475         https://bugs.webkit.org/show_bug.cgi?id=144397
476
477         Reviewed by Andreas Kling.
478         
479         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
480         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
481         making a getCallData() call if it isn't necessary.
482
483         * API/JSCallbackObject.h:
484         * runtime/InternalFunction.h:
485         * runtime/JSTypeInfo.h:
486         (JSC::TypeInfo::typeOfShouldCallGetCallData):
487         * runtime/Operations.cpp:
488         (JSC::jsTypeStringForValue):
489         * tests/stress/type-of-functions-and-objects.js: Added.
490         (foo):
491         (bar):
492         (baz):
493         (fuzz):
494         (expect):
495         (test):
496
497 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
498
499         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
500         https://bugs.webkit.org/show_bug.cgi?id=144013
501
502         Reviewed by Mark Lam.
503
504         This patch implements Array.prototype.sort in JavaScript, removing the
505         C++ implementations. It is simpler and less error-prone to express our
506         operations in JavaScript, which provides memory safety, exception safety,
507         and recursion safety.
508
509         The performance result is mixed, but net positive in my opinion. It's
510         difficult to enumerate all the results, since we used to have so many
511         different sorting modes, and there are lots of different data patterns
512         across which you might want to measure sorting. Suffice it to say:
513
514             (*) The benchmarks we track are faster or unchanged.
515
516             (*) Sorting random input using a comparator -- which we think is
517             common -- is 3X faster.
518
519             (*) Sorting random input in a non-array object -- which jQuery does
520             -- is 4X faster.
521
522             (*) Sorting random input in a compact array of integers using a
523             trivial pattern-matchable comparator is 2X *slower*.
524
525         * builtins/Array.prototype.js:
526         (sort.min):
527         (sort.stringComparator):
528         (sort.compactSparse): Special case compaction for sparse arrays because
529         we don't want to hang when sorting new Array(BIG).
530
531         (sort.compact):
532         (sort.merge):
533         (sort.mergeSort): Use merge sort because it's a reasonably efficient
534         stable sort. We have evidence that some sites depend on stable sort,
535         even though the ES6 spec does not mandate it. (See
536         <http://trac.webkit.org/changeset/33967>.)
537
538         This is a textbook implementation of merge sort with three optimizations:
539
540             (1) Use iteration instead of recursion;
541
542             (2) Use array subscripting instead of array copying in order to
543             create logical sub-lists without creating physical sub-lists;
544
545             (3) Swap src and dst at each iteration instead of copying src into
546             dst, and only copy src into the subject array at the end if src is
547             not the subject array.
548
549         (sort.inflate):
550         (sort.comparatorSort):
551         (sort): Sort in JavaScript for the win.
552
553         * builtins/BuiltinExecutables.cpp:
554         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
555         names so we can use helper functions.
556
557         * bytecode/CodeBlock.h:
558         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
559         * bytecode/UnlinkedCodeBlock.cpp:
560         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
561         * bytecode/UnlinkedCodeBlock.h:
562         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
563         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
564         * bytecompiler/BytecodeGenerator.cpp:
565         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
566         * bytecompiler/BytecodeGenerator.h:
567         * bytecompiler/NodesCodegen.cpp:
568         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
569         on pattern matching anymore. This was mainly an optimization to avoid 
570         the overhead of calling from C++ to JS, which we now avoid by
571         sorting in JS.
572
573         * heap/Heap.cpp:
574         (JSC::Heap::markRoots):
575         (JSC::Heap::pushTempSortVector): Deleted.
576         (JSC::Heap::popTempSortVector): Deleted.
577         (JSC::Heap::visitTempSortVectors): Deleted.
578         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
579         in JavaScript using a normal JavaScript array for our temporary storage.
580
581         * parser/Parser.cpp:
582         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
583         helper functions.
584
585         * runtime/ArrayPrototype.cpp:
586         (JSC::isNumericCompareFunction): Deleted.
587         (JSC::attemptFastSort): Deleted.
588         (JSC::performSlowSort): Deleted.
589         (JSC::arrayProtoFuncSort): Deleted.
590
591         * runtime/CommonIdentifiers.h: New strings used by sort.
592
593         * runtime/JSArray.cpp:
594         (JSC::compareNumbersForQSortWithInt32): Deleted.
595         (JSC::compareNumbersForQSortWithDouble): Deleted.
596         (JSC::compareNumbersForQSort): Deleted.
597         (JSC::compareByStringPairForQSort): Deleted.
598         (JSC::JSArray::sortNumericVector): Deleted.
599         (JSC::JSArray::sortNumeric): Deleted.
600         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
601         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
602         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
603         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
604         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
605         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
606         (JSC::JSArray::sortCompactedVector): Deleted.
607         (JSC::JSArray::sort): Deleted.
608         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
609         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
610         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
611         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
612         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
613         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
614         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
615         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
616         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
617         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
618         (JSC::JSArray::sortVector): Deleted.
619         (JSC::JSArray::compactForSorting): Deleted.
620         * runtime/JSArray.h:
621
622         * runtime/JSGlobalObject.cpp:
623         (JSC::JSGlobalObject::init):
624         * runtime/ObjectConstructor.cpp:
625         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
626         by sort.
627
628 2015-04-29  Mark Lam  <mark.lam@apple.com>
629
630         Safari WebKit crash when loading Google Spreadsheet.
631         https://bugs.webkit.org/show_bug.cgi?id=144020
632
633         Reviewed by Filip Pizlo.
634
635         The bug is that the object allocation sinking phase did not account for a case
636         where a property of a sunken object is only initialized on one path and not
637         another.  As a result, on the path where the property is not initialized, we'll
638         encounter an Upsilon with a BottomValue (which is not allowed by definition).
639
640         The fix is to use a JSConstant(undefined) as the bottom value instead (of
641         BottomValue).  If the property is uninitialized, it should still be accessible
642         and have the value undefined.
643
644         * dfg/DFGObjectAllocationSinkingPhase.cpp:
645         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
646         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
647         (foo):
648         (foo2):
649
650 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
651
652         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
653         https://bugs.webkit.org/show_bug.cgi?id=144257
654
655         Reviewed by Darin Adler.
656
657         SHA1 is used to calculate CodeBlockHash.
658         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
659         However, the source code can contain null character.
660         So when performing `strlen` on the source code's CString, it returns the incorrect length.
661         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
662
663         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
664         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
665
666         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
667         is not correct. Because
668
669         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
670         2. If CString can contain a null character, this assertion becomes incorrect.
671
672         So this patch just drops the assertion.
673
674         In the current implementation, we once convert the entire source code to the newly allocated
675         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
676         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
677         We'll implement it in the separate patch[2].
678
679         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
680         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
681
682         * tests/stress/eval-script-contains-null-character.js: Added.
683         (shouldBe):
684         (test):
685         * tests/stress/template-literal-line-terminators.js:
686         * tests/stress/template-literal-syntax.js:
687         * tests/stress/template-literal.js:
688
689 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
690
691         Evict IsEnvironmentRecord from inline type flags
692         https://bugs.webkit.org/show_bug.cgi?id=144398
693
694         Reviewed by Mark Lam and Michael Saboff.
695         
696         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
697         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
698         and evicts it into the out-of-line type flags. This change has no performance implications
699         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
700         where we access it at all is in String.prototype.repeat, and there we already load the
701         structure anyway.
702
703         * runtime/JSTypeInfo.h:
704         (JSC::TypeInfo::implementsHasInstance):
705         (JSC::TypeInfo::structureIsImmortal):
706         (JSC::TypeInfo::isEnvironmentRecord):
707
708 2015-04-29  Darin Adler  <darin@apple.com>
709
710         [ES6] Implement Unicode code point escapes
711         https://bugs.webkit.org/show_bug.cgi?id=144377
712
713         Reviewed by Antti Koivisto.
714
715         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
716         the header. Made it a non-member class so it doesn't need to be part
717         of a template. Made it use UChar32 instead of int for the value to
718         make it clearer what goes into this class.
719         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
720         old type() function.
721         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
722         parseFourDigitUnicodeHex and added support for code point escapes.
723         (JSC::isLatin1): Added an overload for UChar32.
724         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
725         to call it with a UChar, so no need to overload for that type for now.
726         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
727         Also added FIXME about a subtle ES6 change that we might want to make later.
728         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
729         to call it with a UChar, so no need to overload for that type for now.
730         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
731         don't need to repeat the code twice. Added code to handle code point escapes.
732         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
733         code in line.
734         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
735         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
736         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
737         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
738         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
739         the code that handles the escapes, since the code point escape code now
740         consumes characters while parsing rather than peeking ahead. Test case
741         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
742         giving a syntax error.
743
744         * parser/Lexer.h: Updated for above changes.
745
746         * runtime/StringConstructor.cpp:
747         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
748         out 0x10FFFF; clearer this way.
749
750 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
751
752         [CMake] [GTK] Organize and clean up unused CMake variables
753         https://bugs.webkit.org/show_bug.cgi?id=144364
754
755         Reviewed by Gyuyoung Kim.
756
757         * PlatformGTK.cmake: Add variables specific to this project.
758
759 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
760
761         TypeOf should return SpecStringIdent and the DFG should know this
762         https://bugs.webkit.org/show_bug.cgi?id=144376
763
764         Reviewed by Andreas Kling.
765         
766         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
767         
768         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
769         bad.
770
771         * dfg/DFGAbstractInterpreterInlines.h:
772         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
773         * dfg/DFGAbstractValue.cpp:
774         (JSC::DFG::AbstractValue::setType):
775         * dfg/DFGAbstractValue.h:
776         (JSC::DFG::AbstractValue::setType):
777         * dfg/DFGInPlaceAbstractState.cpp:
778         (JSC::DFG::InPlaceAbstractState::initialize):
779         * dfg/DFGPredictionPropagationPhase.cpp:
780         (JSC::DFG::PredictionPropagationPhase::propagate):
781         * runtime/SmallStrings.cpp:
782         (JSC::SmallStrings::initialize):
783         * tests/stress/switch-typeof-indirect.js: Added.
784         (bar):
785         (foo):
786         (test):
787         * tests/stress/switch-typeof-slightly-indirect.js: Added.
788         (foo):
789         (test):
790         * tests/stress/switch-typeof.js: Added.
791         (foo):
792         (test):
793
794 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
795
796         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
797         https://bugs.webkit.org/show_bug.cgi?id=144373
798
799         Reviewed by Darin Adler.
800
801         Revert r181868 as it caused a failure on live.com. We can try
802         re-enabling this exception after we make idl attributes configurable,
803         which may have prevented this particular failure.
804
805         * runtime/ObjectPrototype.cpp:
806         (JSC::objectProtoFuncDefineGetter):
807         (JSC::objectProtoFuncDefineSetter):
808
809 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
810
811         Deadlock on applications using JSContext on non-main thread
812         https://bugs.webkit.org/show_bug.cgi?id=144370
813
814         Reviewed by Timothy Hatcher.
815
816         * inspector/remote/RemoteInspector.mm:
817         (Inspector::RemoteInspector::singleton):
818         Prevent a possible deadlock by assuming we can synchronously
819         run something on the main queue at this time.
820
821 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
822
823         FTL should fully support Switch (it currently lacks the SwitchString variant)
824         https://bugs.webkit.org/show_bug.cgi?id=144348
825
826         Reviewed by Benjamin Poulain.
827         
828         This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
829         in LayoutTests/js/regress.
830
831         * dfg/DFGCommon.cpp:
832         (JSC::DFG::stringLessThan):
833         * dfg/DFGCommon.h:
834         * dfg/DFGOperations.cpp:
835         * dfg/DFGOperations.h:
836         * dfg/DFGSpeculativeJIT.cpp:
837         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
838         * dfg/DFGSpeculativeJIT.h:
839         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
840         * ftl/FTLCapabilities.cpp:
841         (JSC::FTL::canCompile):
842         * ftl/FTLIntrinsicRepository.h:
843         * ftl/FTLLowerDFGToLLVM.cpp:
844         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
845         (JSC::FTL::LowerDFGToLLVM::switchString):
846         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
847         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
848         (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
849         (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
850         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
851         (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
852         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
853         * ftl/FTLOutput.cpp:
854         (JSC::FTL::Output::check):
855         * ftl/FTLOutput.h:
856         * ftl/FTLWeight.h:
857         (JSC::FTL::Weight::inverse):
858         * jit/JITOperations.h:
859
860 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
861
862         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
863         https://bugs.webkit.org/show_bug.cgi?id=144304
864
865         Reviewed by Geoffrey Garen.
866
867         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
868         ENABLE_LLINT_C_LOOP, disabled by default.
869         * llint/LLIntSlowPaths.cpp:
870         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
871
872 2015-04-28  Commit Queue  <commit-queue@webkit.org>
873
874         Unreviewed, rolling out r183514.
875         https://bugs.webkit.org/show_bug.cgi?id=144359
876
877         It broke cloop test bots (Requested by mcatanzaro on #webkit).
878
879         Reverted changeset:
880
881         "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
882         https://bugs.webkit.org/show_bug.cgi?id=144304
883         http://trac.webkit.org/changeset/183514
884
885 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
886
887         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
888         https://bugs.webkit.org/show_bug.cgi?id=144304
889
890         Reviewed by Geoffrey Garen.
891
892         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
893         ENABLE_LLINT_C_LOOP, disabled by default.
894         * llint/LLIntSlowPaths.cpp:
895         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
896
897 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
898
899         Fix common typo "targetting" => "targeting"
900         https://bugs.webkit.org/show_bug.cgi?id=144349
901
902         Reviewed by Daniel Bates.
903
904         * bytecode/ExecutionCounter.h:
905
906 2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>
907
908         Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
909         https://bugs.webkit.org/show_bug.cgi?id=144328
910
911         Reviewed by Andreas Kling.
912
913         Update the status of ES6 features.
914
915         * features.json:
916
917 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
918
919         DFG should not use or preserve Phantoms during transformations
920         https://bugs.webkit.org/show_bug.cgi?id=143736
921
922         Reviewed by Geoffrey Garen.
923         
924         Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
925         no longer necessary to preserve Phantoms during transformations. They are still useful just
926         before FixupPhase to support backwards propagation analyses. They are still inserted late in the
927         game in the DFG backend. But transformations don't need to worry about them. Inside a basic
928         block, we can be sure that so long as the IR pinpoints the place where the value becomes
929         available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
930         other block would need the value (either for OSR or for DFG execution), then we don't need any
931         liveness markers.
932         
933         So, this removes any places where we inserted Phantoms just for liveness during transformation
934         and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
935         Check node only keeps its children so long as those children have checks.
936         
937         The fact that we no longer convertToPhantom() means that we have to be more careful when
938         constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
939         Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
940         a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
941         Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
942         GetLocals.
943         
944         The only Phantom-like cruft left over after this patch is:
945         
946         - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
947           backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
948           the users of the original local's live range in bytecode. This is essential for supporting our
949           BackwardsPropagationPhase, which is an important optimization for things like asm.js.
950         
951         - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
952           https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
953           alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
954           the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
955           treat GetLocal/SetLocal conservatively, this should all be sound.
956         
957         This change should be perf-neutral although it does reduce the total work that the compiler
958         does.
959
960         * CMakeLists.txt:
961         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
962         * JavaScriptCore.xcodeproj/project.pbxproj:
963         * dfg/DFGAdjacencyList.h:
964         (JSC::DFG::AdjacencyList::justChecks):
965         * dfg/DFGArgumentsEliminationPhase.cpp:
966         * dfg/DFGBasicBlock.cpp:
967         (JSC::DFG::BasicBlock::replaceTerminal):
968         * dfg/DFGBasicBlock.h:
969         (JSC::DFG::BasicBlock::findTerminal):
970         * dfg/DFGCFGSimplificationPhase.cpp:
971         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
972         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
973         * dfg/DFGCPSRethreadingPhase.cpp:
974         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
975         (JSC::DFG::CPSRethreadingPhase::clearVariables):
976         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
977         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
978         * dfg/DFGCSEPhase.cpp:
979         * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
980         (JSC::DFG::CleanUpPhase::CleanUpPhase):
981         (JSC::DFG::CleanUpPhase::run):
982         (JSC::DFG::performCleanUp):
983         (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
984         (JSC::DFG::PhantomRemovalPhase::run): Deleted.
985         (JSC::DFG::performPhantomRemoval): Deleted.
986         * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
987         * dfg/DFGConstantFoldingPhase.cpp:
988         (JSC::DFG::ConstantFoldingPhase::foldConstants):
989         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
990         (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
991         * dfg/DFGDCEPhase.cpp:
992         (JSC::DFG::DCEPhase::run):
993         (JSC::DFG::DCEPhase::fixupBlock):
994         (JSC::DFG::DCEPhase::cleanVariables):
995         * dfg/DFGFixupPhase.cpp:
996         (JSC::DFG::FixupPhase::fixupBlock):
997         (JSC::DFG::FixupPhase::fixupNode):
998         (JSC::DFG::FixupPhase::convertStringAddUse):
999         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1000         (JSC::DFG::FixupPhase::checkArray):
1001         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
1002         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
1003         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
1004         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
1005         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1006         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1007         (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
1008         (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
1009         * dfg/DFGGraph.cpp:
1010         (JSC::DFG::Graph::convertToConstant):
1011         (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
1012         * dfg/DFGGraph.h:
1013         * dfg/DFGInsertionSet.h:
1014         (JSC::DFG::InsertionSet::insertCheck):
1015         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1016         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1017         * dfg/DFGLICMPhase.cpp:
1018         (JSC::DFG::LICMPhase::attemptHoist):
1019         * dfg/DFGNode.cpp:
1020         (JSC::DFG::Node::remove):
1021         * dfg/DFGNode.h:
1022         (JSC::DFG::Node::replaceWith):
1023         (JSC::DFG::Node::convertToPhantom): Deleted.
1024         (JSC::DFG::Node::convertToCheck): Deleted.
1025         (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
1026         * dfg/DFGNodeFlags.h:
1027         * dfg/DFGNodeType.h:
1028         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1029         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1030         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1031         * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
1032         * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
1033         * dfg/DFGPhantomRemovalPhase.cpp: Removed.
1034         * dfg/DFGPhantomRemovalPhase.h: Removed.
1035         * dfg/DFGPlan.cpp:
1036         (JSC::DFG::Plan::compileInThreadImpl):
1037         * dfg/DFGPutStackSinkingPhase.cpp:
1038         * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
1039         * dfg/DFGResurrectionForValidationPhase.h: Removed.
1040         * dfg/DFGSSAConversionPhase.cpp:
1041         (JSC::DFG::SSAConversionPhase::run):
1042         * dfg/DFGSpeculativeJIT64.cpp:
1043         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
1044         * dfg/DFGStoreBarrierElisionPhase.cpp:
1045         (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
1046         * dfg/DFGStrengthReductionPhase.cpp:
1047         (JSC::DFG::StrengthReductionPhase::handleNode):
1048         (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
1049         * dfg/DFGValidate.cpp:
1050         (JSC::DFG::Validate::validate):
1051         (JSC::DFG::Validate::validateCPS):
1052         (JSC::DFG::Validate::validateSSA):
1053         * dfg/DFGVarargsForwardingPhase.cpp:
1054         * ftl/FTLLink.cpp:
1055         (JSC::FTL::link):
1056         * ftl/FTLLowerDFGToLLVM.cpp:
1057         (JSC::FTL::LowerDFGToLLVM::compileNode):
1058         (JSC::FTL::LowerDFGToLLVM::compileNoOp):
1059         (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
1060
1061 2015-04-28  Andreas Kling  <akling@apple.com>
1062
1063         DFG+FTL should generate efficient code for branching on a string's boolean value.
1064         <https://webkit.org/b/144317>
1065
1066         Reviewed by Geoff Garen & Filip Pizlo
1067
1068         Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
1069         instead of dropping out to C++ whenever we branch on a string.
1070
1071         The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
1072         the DFG JIT gets some new codegen logic in this patch.
1073
1074         Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
1075
1076         * dfg/DFGFixupPhase.cpp:
1077         (JSC::DFG::FixupPhase::fixupNode):
1078         * dfg/DFGSpeculativeJIT.cpp:
1079         (JSC::DFG::SpeculativeJIT::emitStringBranch):
1080         * dfg/DFGSpeculativeJIT.h:
1081         * dfg/DFGSpeculativeJIT32_64.cpp:
1082         (JSC::DFG::SpeculativeJIT::emitBranch):
1083         * dfg/DFGSpeculativeJIT64.cpp:
1084         (JSC::DFG::SpeculativeJIT::emitBranch):
1085
1086 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1087
1088         VarargsForwardingPhase should only consider MovHints that have the candidate as a child
1089         https://bugs.webkit.org/show_bug.cgi?id=144340
1090
1091         Reviewed by Michael Saboff and Mark Lam.
1092         
1093         Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
1094         CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
1095         Basically, we'd keep it alive until the end of the block. This maximized the chances of
1096         there being an interfering operation, which would prevent elimination.
1097         
1098         The fix is to only consider MovHints that have the arguments candidate as a child. We only
1099         care to track the liveness of those bytecode locals that would need an arguments object
1100         recovery on OSR exit.
1101         
1102         This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
1103         introduced in http://trac.webkit.org/changeset/183406.
1104
1105         * dfg/DFGVarargsForwardingPhase.cpp:
1106
1107 2015-04-28  Csaba Osztrogon√°c  <ossy@webkit.org>
1108
1109         Remove WinCE cruft from cmake build system
1110         https://bugs.webkit.org/show_bug.cgi?id=144325
1111
1112         Reviewed by Gyuyoung Kim.
1113
1114         * CMakeLists.txt:
1115         * create_jit_stubs: Removed.
1116
1117 2015-04-27  Andreas Kling  <akling@apple.com>
1118
1119         RegExp matches arrays should use contiguous indexing.
1120         <https://webkit.org/b/144286>
1121
1122         Reviewed by Geoffrey Garen.
1123
1124         We had a custom Structure being used for RegExp matches arrays that would
1125         put the arrays into SlowPutArrayStorageShape mode. This was just left
1126         from when matches arrays were custom, lazily initialized objects.
1127
1128         This change removes that Structure and switches the matches arrays to
1129         using the default ContiguousShape Structure. This allows the FTL JIT
1130         to compile the inner loop of the Octane/regexp benchmark.
1131
1132         Also made a version of initializeIndex() [inline] that takes the indexing
1133         type in an argument, allowing createRegExpMatchesArray() to initialize
1134         the entire array without branching on the indexing type for each entry.
1135
1136         ~3% progression on Octane/regexp.
1137
1138         * runtime/JSGlobalObject.cpp:
1139         (JSC::JSGlobalObject::init):
1140         (JSC::JSGlobalObject::visitChildren):
1141         * runtime/JSGlobalObject.h:
1142         (JSC::JSGlobalObject::mapStructure):
1143         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1144         * runtime/JSObject.h:
1145         (JSC::JSObject::initializeIndex):
1146         * runtime/RegExpMatchesArray.cpp:
1147         (JSC::createRegExpMatchesArray):
1148
1149 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1150
1151         FTL failed to initialize arguments.callee on the slow path as well as the fast path
1152         https://bugs.webkit.org/show_bug.cgi?id=144293
1153
1154         Reviewed by Mark Lam.
1155         
1156         The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
1157         to initialize the callee on the common path after the fast and slow path.
1158
1159         * ftl/FTLLowerDFGToLLVM.cpp:
1160         (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
1161         * tests/stress/arguments-callee-uninitialized.js: Added.
1162         (foo):
1163
1164 2015-04-27  Benjamin Poulain  <bpoulain@apple.com>
1165
1166         [JSC] Add support for typed arrays to the Array profiling
1167         https://bugs.webkit.org/show_bug.cgi?id=143913
1168
1169         Reviewed by Filip Pizlo.
1170
1171         This patch adds ArrayModes for every typed arrays. Having that information
1172         let us generate better GetByVal and PutByVal when the type speculation
1173         are not good enough.
1174
1175         A typical case where this is useful is any basic block for which the type
1176         of the object is always more restrictive than the speculation (for example, 
1177         a basic block gated by a branch only taken for on type).
1178
1179         * bytecode/ArrayProfile.cpp:
1180         (JSC::dumpArrayModes):
1181         * bytecode/ArrayProfile.h:
1182         (JSC::arrayModeFromStructure):
1183         * dfg/DFGArrayMode.cpp:
1184         (JSC::DFG::ArrayMode::fromObserved):
1185         (JSC::DFG::ArrayMode::refine):
1186         Maintain the refine() semantic. We do not support OutOfBounds access
1187         for GetByVal on typed array.
1188
1189         * runtime/IndexingType.h:
1190         * tests/stress/typed-array-get-by-val-profiling.js: Added.
1191         (testArray.testCode):
1192         (testArray):
1193         * tests/stress/typed-array-put-by-val-profiling.js: Added.
1194         (testArray.testCode):
1195         (testArray):
1196
1197 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1198
1199         Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
1200         causes many debug test failures.
1201
1202         * runtime/JSGlobalObject.cpp:
1203         (JSC::JSGlobalObject::init):
1204         (JSC::JSGlobalObject::visitChildren):
1205         * runtime/JSGlobalObject.h:
1206         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
1207         * runtime/JSObject.h:
1208         (JSC::JSObject::initializeIndex):
1209         * runtime/RegExpMatchesArray.cpp:
1210         (JSC::createRegExpMatchesArray):
1211
1212 2015-04-27  Andreas Kling  <akling@apple.com>
1213
1214         RegExp matches arrays should use contiguous indexing.
1215         <https://webkit.org/b/144286>
1216
1217         Reviewed by Geoffrey Garen.
1218
1219         We had a custom Structure being used for RegExp matches arrays that would
1220         put the arrays into SlowPutArrayStorageShape mode. This was just left
1221         from when matches arrays were custom, lazily initialized objects.
1222
1223         This change removes that Structure and switches the matches arrays to
1224         using the default ContiguousShape Structure. This allows the FTL JIT
1225         to compile the inner loop of the Octane/regexp benchmark.
1226
1227         Also made a version of initializeIndex() [inline] that takes the indexing
1228         type in an argument, allowing createRegExpMatchesArray() to initialize
1229         the entire array without branching on the indexing type for each entry.
1230
1231         ~3% progression on Octane/regexp.
1232
1233         * runtime/JSGlobalObject.cpp:
1234         (JSC::JSGlobalObject::init):
1235         (JSC::JSGlobalObject::visitChildren):
1236         * runtime/JSGlobalObject.h:
1237         (JSC::JSGlobalObject::mapStructure):
1238         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1239         * runtime/JSObject.h:
1240         (JSC::JSObject::initializeIndex):
1241         * runtime/RegExpMatchesArray.cpp:
1242         (JSC::createRegExpMatchesArray):
1243
1244 2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>
1245
1246         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
1247         https://bugs.webkit.org/show_bug.cgi?id=144257
1248
1249         Temporarily disable skip these tests.
1250
1251         * tests/stress/template-literal-line-terminators.js:
1252         * tests/stress/template-literal-syntax.js:
1253         * tests/stress/template-literal.js:
1254
1255 2015-04-27  Basile Clement  <basile_clement@apple.com>
1256
1257         Function allocations shouldn't sink through Put operations
1258         https://bugs.webkit.org/show_bug.cgi?id=144176
1259
1260         Reviewed by Filip Pizlo.
1261
1262         By design, we don't support function allocation sinking through any
1263         related operation ; however object allocation can sink through PutByOffset et
1264         al.
1265
1266         Currently, the checks to prevent function allocation to sink through
1267         these are misguided and do not prevent anything ; function allocation sinking
1268         through these operations is prevented as a side effect of requiring an
1269         AllocatePropertyStorage through which the function allocation is seen as
1270         escaping.
1271
1272         This changes it so that ObjectAllocationSinkingPhase::handleNode()
1273         checks properly that only object allocations sink through related write
1274         operations.
1275
1276         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1277         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1278         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1279
1280 2015-04-25  Filip Pizlo  <fpizlo@apple.com>
1281
1282         VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
1283         https://bugs.webkit.org/show_bug.cgi?id=143843
1284
1285         Reviewed by Geoffrey Garen.
1286         
1287         It will soon come to pass that Phantom isn't available at the time that
1288         VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
1289         a value dies for OSR.
1290         
1291         This is simplified by two things:
1292         
1293         1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
1294            before by polishing the API.
1295         
1296         2) This phase already operates on one node at a time and allows itself to do a full search
1297            of the enclosing basic block for that node. This is fine because CreateDirectArguments
1298            and friends is a rarely occurring node. The fact that it operates on one node at a time
1299            makes it even easier to reason about OSR liveness - we just track the list of locals in
1300            which it is live.
1301         
1302         This change has no effect right now but it is a necessary prerequisite to implementing
1303         https://bugs.webkit.org/show_bug.cgi?id=143736.
1304
1305         * dfg/DFGBasicBlock.h:
1306         (JSC::DFG::BasicBlock::tryAt):
1307         * dfg/DFGForAllKills.h:
1308         (JSC::DFG::forAllKilledOperands):
1309         * dfg/DFGPhantomInsertionPhase.cpp:
1310         * dfg/DFGVarargsForwardingPhase.cpp:
1311
1312 2015-04-27  Jordan Harband  <ljharb@gmail.com>
1313
1314         Map#entries and Map#keys error for non-Maps is swapped
1315         https://bugs.webkit.org/show_bug.cgi?id=144253
1316
1317         Reviewed by Simon Fraser.
1318
1319         Correcting error messages on Set/Map methods when called on
1320         incompatible objects.
1321
1322         * runtime/MapPrototype.cpp:
1323         (JSC::mapProtoFuncEntries):
1324         (JSC::mapProtoFuncKeys):
1325         * runtime/SetPrototype.cpp:
1326         (JSC::setProtoFuncEntries):
1327
1328 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
1329
1330         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
1331         https://bugs.webkit.org/show_bug.cgi?id=144186
1332
1333         Reviewed by Geoffrey Garen.
1334         
1335         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
1336         Int32. We may later perform code simplifications based on the proof that this is Int32, and
1337         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
1338         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
1339         except that we still need the overflow check!
1340
1341         Previously we mishandled this:
1342
1343         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
1344           to keep it alive. That's dirty and it's just indicative of a deeper issue.
1345
1346         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
1347           powerless. This was sort of hiding the bug.
1348
1349         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
1350           something that you are relying on for subsequent simplifications.
1351         
1352         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
1353         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
1354         we no longer need the weird MustGenerate node.
1355
1356         * dfg/DFGAbstractInterpreterInlines.h:
1357         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1358         * dfg/DFGArgumentsEliminationPhase.cpp:
1359         * dfg/DFGClobberize.h:
1360         (JSC::DFG::clobberize):
1361         * dfg/DFGDCEPhase.cpp:
1362         (JSC::DFG::DCEPhase::run):
1363         * dfg/DFGDoesGC.cpp:
1364         (JSC::DFG::doesGC):
1365         * dfg/DFGFixupPhase.cpp:
1366         (JSC::DFG::FixupPhase::fixupNode):
1367         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1368         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1369         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1370         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
1371         * dfg/DFGMayExit.cpp:
1372         (JSC::DFG::mayExit):
1373         * dfg/DFGNode.h:
1374         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1375         * dfg/DFGNodeType.h:
1376         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1377         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1378         * dfg/DFGPhantomCanonicalizationPhase.cpp:
1379         (JSC::DFG::PhantomCanonicalizationPhase::run):
1380         * dfg/DFGPhantomRemovalPhase.cpp:
1381         (JSC::DFG::PhantomRemovalPhase::run):
1382         * dfg/DFGPlan.cpp:
1383         (JSC::DFG::Plan::compileInThreadImpl):
1384         * dfg/DFGPredictionPropagationPhase.cpp:
1385         (JSC::DFG::PredictionPropagationPhase::propagate):
1386         * dfg/DFGSafeToExecute.h:
1387         (JSC::DFG::safeToExecute):
1388         * dfg/DFGSpeculativeJIT32_64.cpp:
1389         (JSC::DFG::SpeculativeJIT::compile):
1390         * dfg/DFGSpeculativeJIT64.cpp:
1391         (JSC::DFG::SpeculativeJIT::compile):
1392         * dfg/DFGTypeCheckHoistingPhase.cpp:
1393         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1394         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1395         * dfg/DFGVarargsForwardingPhase.cpp:
1396         * ftl/FTLCapabilities.cpp:
1397         (JSC::FTL::canCompile):
1398         * ftl/FTLLowerDFGToLLVM.cpp:
1399         (JSC::FTL::LowerDFGToLLVM::compileNode):
1400         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
1401         (foo):
1402         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
1403         (foo):
1404         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
1405         (foo):
1406         * tests/stress/fold-based-on-int32-proof.js: Added.
1407         (foo):
1408
1409 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1410
1411         Class body ending with a semicolon throws a SyntaxError
1412         https://bugs.webkit.org/show_bug.cgi?id=144244
1413
1414         Reviewed by Darin Adler.
1415
1416         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
1417         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
1418         it by continue'ing when it encounters a semicolon.
1419
1420         * parser/Parser.cpp:
1421         (JSC::Parser<LexerType>::parseClass):
1422
1423 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1424
1425         Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
1426         https://bugs.webkit.org/show_bug.cgi?id=144243
1427
1428         Reviewed by Darin Adler.
1429
1430         Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
1431
1432         * parser/Parser.cpp:
1433         (JSC::Parser<LexerType>::parseGetterSetter):
1434
1435 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1436
1437         Map#forEach does not pass "map" argument to callback.
1438         https://bugs.webkit.org/show_bug.cgi?id=144187
1439
1440         Reviewed by Darin Adler.
1441
1442         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
1443         step 7.a.i., the callback should be called with three arguments.
1444
1445         * runtime/MapPrototype.cpp:
1446         (JSC::mapProtoFuncForEach):
1447
1448 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1449
1450         [ES6] Implement ES6 template literals
1451         https://bugs.webkit.org/show_bug.cgi?id=142691
1452
1453         Reviewed by Darin Adler.
1454
1455         This patch implements TemplateLiteral.
1456         Since TaggedTemplate requires some global states and
1457         primitive operations like GetTemplateObject,
1458         we separate the patch. It will be implemented in a subsequent patch.
1459
1460         Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
1461         By disabling it, we can disable Template Literal support.
1462
1463         To implement template literals, in this patch,
1464         we newly introduces bytecode op_to_string.
1465         In template literals, we alternately evaluate the expression and
1466         perform ToString onto the result of evaluation.
1467         For example,
1468
1469         `${f1()} ${f2()}`
1470
1471         In this template literal, execution order is the following,
1472         1. calling f1()
1473         2. ToString(the result of f1())
1474         3. calling f2()
1475         4. ToString(the result of f2())
1476
1477         op_strcat also performs ToString. However, performing ToString
1478         onto expressions are batched in op_strcat, it's not the same to the
1479         template literal spec. In the above example,
1480         ToString(f1()) should be called before calling f2().
1481
1482         * Configurations/FeatureDefines.xcconfig:
1483         * bytecode/BytecodeList.json:
1484         * bytecode/BytecodeUseDef.h:
1485         (JSC::computeUsesForBytecodeOffset):
1486         (JSC::computeDefsForBytecodeOffset):
1487         * bytecode/CodeBlock.cpp:
1488         (JSC::CodeBlock::dumpBytecode):
1489         * bytecompiler/BytecodeGenerator.h:
1490         (JSC::BytecodeGenerator::emitToString):
1491         (JSC::BytecodeGenerator::emitToNumber): Deleted.
1492         * bytecompiler/NodesCodegen.cpp:
1493         (JSC::TemplateStringNode::emitBytecode):
1494         (JSC::TemplateLiteralNode::emitBytecode):
1495         * dfg/DFGByteCodeParser.cpp:
1496         (JSC::DFG::ByteCodeParser::parseBlock):
1497         * dfg/DFGCapabilities.cpp:
1498         (JSC::DFG::capabilityLevel):
1499         * jit/JIT.cpp:
1500         (JSC::JIT::privateCompileMainPass):
1501         (JSC::JIT::privateCompileSlowCases):
1502         * jit/JIT.h:
1503         * jit/JITOpcodes.cpp:
1504         (JSC::JIT::emit_op_to_string):
1505         (JSC::JIT::emitSlow_op_to_string):
1506         * jit/JITOpcodes32_64.cpp:
1507         (JSC::JIT::emit_op_to_string):
1508         (JSC::JIT::emitSlow_op_to_string):
1509         * llint/LowLevelInterpreter32_64.asm:
1510         * llint/LowLevelInterpreter64.asm:
1511         * parser/ASTBuilder.h:
1512         (JSC::ASTBuilder::createTemplateString):
1513         (JSC::ASTBuilder::createTemplateStringList):
1514         (JSC::ASTBuilder::createTemplateExpressionList):
1515         (JSC::ASTBuilder::createTemplateLiteral):
1516         * parser/Lexer.cpp:
1517         (JSC::Lexer<T>::Lexer):
1518         (JSC::Lexer<T>::parseIdentifierSlowCase):
1519         (JSC::Lexer<T>::parseString):
1520         (JSC::LineNumberAdder::LineNumberAdder):
1521         (JSC::LineNumberAdder::clear):
1522         (JSC::LineNumberAdder::add):
1523         (JSC::Lexer<T>::parseTemplateLiteral):
1524         (JSC::Lexer<T>::lex):
1525         (JSC::Lexer<T>::scanRegExp):
1526         (JSC::Lexer<T>::scanTrailingTemplateString):
1527         (JSC::Lexer<T>::parseStringSlowCase): Deleted.
1528         * parser/Lexer.h:
1529         * parser/NodeConstructors.h:
1530         (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
1531         (JSC::TemplateStringNode::TemplateStringNode):
1532         (JSC::TemplateStringListNode::TemplateStringListNode):
1533         (JSC::TemplateLiteralNode::TemplateLiteralNode):
1534         * parser/Nodes.h:
1535         (JSC::TemplateExpressionListNode::value):
1536         (JSC::TemplateExpressionListNode::next):
1537         (JSC::TemplateStringNode::cooked):
1538         (JSC::TemplateStringNode::raw):
1539         (JSC::TemplateStringListNode::value):
1540         (JSC::TemplateStringListNode::next):
1541         * parser/Parser.cpp:
1542         (JSC::Parser<LexerType>::parseTemplateString):
1543         (JSC::Parser<LexerType>::parseTemplateLiteral):
1544         (JSC::Parser<LexerType>::parsePrimaryExpression):
1545         * parser/Parser.h:
1546         * parser/ParserTokens.h:
1547         * parser/SyntaxChecker.h:
1548         (JSC::SyntaxChecker::createTemplateString):
1549         (JSC::SyntaxChecker::createTemplateStringList):
1550         (JSC::SyntaxChecker::createTemplateExpressionList):
1551         (JSC::SyntaxChecker::createTemplateLiteral):
1552         (JSC::SyntaxChecker::createSpreadExpression): Deleted.
1553         * runtime/CommonSlowPaths.cpp:
1554         (JSC::SLOW_PATH_DECL):
1555         * runtime/CommonSlowPaths.h:
1556         * tests/stress/template-literal-line-terminators.js: Added.
1557         (test):
1558         (testEval):
1559         (testEvalLineNumber):
1560         * tests/stress/template-literal-syntax.js: Added.
1561         (testSyntax):
1562         (testSyntaxError):
1563         * tests/stress/template-literal.js: Added.
1564         (test):
1565         (testEval):
1566         (testEmbedded):
1567
1568 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1569
1570         Set#forEach does not pass "key" or "set" arguments to callback.
1571         https://bugs.webkit.org/show_bug.cgi?id=144188
1572
1573         Reviewed by Darin Adler.
1574
1575         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
1576         Set#forEach should pass 3 arguments to the callback.
1577
1578         * runtime/SetPrototype.cpp:
1579         (JSC::setProtoFuncForEach):
1580
1581 2015-04-26  Benjamin Poulain  <benjamin@webkit.org>
1582
1583         [JSC] Implement Math.clz32(), remove Number.clz()
1584         https://bugs.webkit.org/show_bug.cgi?id=144205
1585
1586         Reviewed by Michael Saboff.
1587
1588         This patch adds the ES6 function Math.clz32(), and remove the non-standard
1589         Number.clz(). Number.clz() probably came from an older draft.
1590
1591         The new function has a corresponding instrinsic: Clz32Intrinsic,
1592         and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
1593
1594         * assembler/MacroAssemblerX86Common.h:
1595         (JSC::MacroAssemblerX86Common::countLeadingZeros32):
1596         * assembler/X86Assembler.h:
1597         (JSC::X86Assembler::bsr_rr):
1598         The x86 assembler did not have countLeadingZeros32() because there is
1599         no native CLZ instruction on that architecture.
1600
1601         I have added the version with bsr + branches for the case of zero.
1602         An other popular version uses cmov to handle the case of zero. I kept
1603         it simple since the Assembler has no support for cmov.
1604
1605         It is unlikely to matter much. If the code is hot enough, LLVM picks
1606         something good based on the surrounding code.
1607
1608         * dfg/DFGAbstractInterpreterInlines.h:
1609         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1610         Constant handling + effect propagation. The node only produces integer (between 0 and 32).
1611
1612         * dfg/DFGBackwardsPropagationPhase.cpp:
1613         (JSC::DFG::BackwardsPropagationPhase::propagate):
1614         Thanks to the definition of toUint32(), we can ignore plenty of details
1615         from doubles.
1616
1617         * dfg/DFGByteCodeParser.cpp:
1618         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1619         * dfg/DFGClobberize.h:
1620         (JSC::DFG::clobberize):
1621         * dfg/DFGDoesGC.cpp:
1622         (JSC::DFG::doesGC):
1623         * dfg/DFGFixupPhase.cpp:
1624         (JSC::DFG::FixupPhase::fixupNode):
1625         * dfg/DFGNodeType.h:
1626         * dfg/DFGPredictionPropagationPhase.cpp:
1627         (JSC::DFG::PredictionPropagationPhase::propagate):
1628         * dfg/DFGSafeToExecute.h:
1629         (JSC::DFG::safeToExecute):
1630         * dfg/DFGSpeculativeJIT.cpp:
1631         (JSC::DFG::SpeculativeJIT::compileArithClz32):
1632         * dfg/DFGSpeculativeJIT.h:
1633         * dfg/DFGSpeculativeJIT32_64.cpp:
1634         (JSC::DFG::SpeculativeJIT::compile):
1635         * dfg/DFGSpeculativeJIT64.cpp:
1636         (JSC::DFG::SpeculativeJIT::compile):
1637         * ftl/FTLCapabilities.cpp:
1638         (JSC::FTL::canCompile):
1639         * ftl/FTLIntrinsicRepository.h:
1640         * ftl/FTLLowerDFGToLLVM.cpp:
1641         (JSC::FTL::LowerDFGToLLVM::compileNode):
1642         (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
1643         * ftl/FTLOutput.h:
1644         (JSC::FTL::Output::ctlz32):
1645         * jit/ThunkGenerators.cpp:
1646         (JSC::clz32ThunkGenerator):
1647         * jit/ThunkGenerators.h:
1648         * runtime/Intrinsic.h:
1649         * runtime/MathCommon.h:
1650         (JSC::clz32):
1651         Fun fact: InstCombine does not recognize this pattern to eliminate
1652         the branch which makes our FTL version better than the C version.
1653
1654         * runtime/MathObject.cpp:
1655         (JSC::MathObject::finishCreation):
1656         (JSC::mathProtoFuncClz32):
1657         * runtime/NumberPrototype.cpp:
1658         (JSC::clz): Deleted.
1659         (JSC::numberProtoFuncClz): Deleted.
1660         * runtime/VM.cpp:
1661         (JSC::thunkGeneratorForIntrinsic):
1662         * tests/stress/math-clz32-basics.js: Added.
1663         (mathClz32OnInteger):
1664         (testMathClz32OnIntegers):
1665         (verifyMathClz32OnIntegerWithOtherTypes):
1666         (mathClz32OnDouble):
1667         (testMathClz32OnDoubles):
1668         (verifyMathClz32OnDoublesWithOtherTypes):
1669         (mathClz32NoArguments):
1670         (mathClz32TooManyArguments):
1671         (testMathClz32OnConstants):
1672         (mathClz32StructTransition):
1673         (Math.clz32):
1674
1675 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1676
1677         [ES6] Array.from need to accept iterables
1678         https://bugs.webkit.org/show_bug.cgi?id=141055
1679
1680         Reviewed by Darin Adler.
1681
1682         ES6 spec requires that Array.from accepts iterable objects.
1683         This patch introduces this functionality, Array.from accepting iterable objects.
1684
1685         Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
1686         However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
1687         `typeof thisObj === "function"` queries the given object has `[[Call]]`.
1688         This will be fixed in the subsequent patch[1].
1689
1690         [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
1691
1692         * builtins/ArrayConstructor.js:
1693         (from):
1694         * parser/Parser.cpp:
1695         (JSC::Parser<LexerType>::parseInner):
1696         * runtime/CommonIdentifiers.h:
1697         * runtime/JSGlobalObject.cpp:
1698         (JSC::JSGlobalObject::init):
1699         * tests/stress/array-from-with-iterable.js: Added.
1700         (shouldBe):
1701         (.set for):
1702         (.set var):
1703         (.get var):
1704         (argumentsGenerators):
1705         (.set shouldBe):
1706         (.set new):
1707         * tests/stress/array-from-with-iterator.js: Added.
1708         (shouldBe):
1709         (shouldThrow):
1710         (createIterator.iterator.return):
1711         (createIterator):
1712         (.):
1713
1714 2015-04-25  Jordan Harband  <ljharb@gmail.com>
1715
1716         Set#keys !== Set#values
1717         https://bugs.webkit.org/show_bug.cgi?id=144190
1718
1719         Reviewed by Darin Adler.
1720
1721         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
1722         Set#keys should === Set#values
1723
1724         * runtime/SetPrototype.cpp:
1725         (JSC::SetPrototype::finishCreation):
1726         (JSC::setProtoFuncValues):
1727         (JSC::setProtoFuncEntries):
1728         (JSC::setProtoFuncKeys): Deleted.
1729
1730 2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>
1731
1732         Allow for pausing a JSContext when opening a Web Inspector
1733         <rdar://problem/20564788>
1734
1735         Reviewed by Timothy Hatcher.
1736
1737         * inspector/remote/RemoteInspector.mm:
1738         (Inspector::RemoteInspector::receivedSetupMessage):
1739         * inspector/remote/RemoteInspectorConstants.h:
1740         * inspector/remote/RemoteInspectorDebuggable.h:
1741         * inspector/remote/RemoteInspectorDebuggableConnection.h:
1742         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
1743         (Inspector::RemoteInspectorDebuggableConnection::setup):
1744         On any incoming setup message, we may want to automatically
1745         pause the debuggable. If requested, pause the debuggable
1746         after we have setup the frontend connection.
1747
1748         * runtime/JSGlobalObjectDebuggable.h:
1749         * runtime/JSGlobalObjectDebuggable.cpp:
1750         (JSC::JSGlobalObjectDebuggable::pause):
1751         Pass through to the inspector controller.
1752
1753         * inspector/JSGlobalObjectInspectorController.h:
1754         * inspector/JSGlobalObjectInspectorController.cpp:
1755         (Inspector::JSGlobalObjectInspectorController::pause):
1756         Enable pause on next statement.
1757
1758 2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>
1759
1760         class methods should be non-enumerable
1761         https://bugs.webkit.org/show_bug.cgi?id=143181
1762
1763         Reviewed by Darin Adler.
1764
1765         Fixed the bug by using Object.defineProperty to define methods.
1766
1767         This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
1768         inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
1769
1770         * bytecode/CodeBlock.cpp: 
1771         (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
1772         index of zero.
1773         * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
1774         exactly one entry for Object.defineProperty.
1775         * bytecode/UnlinkedCodeBlock.h:
1776         (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
1777         constant register for the link time constant we're adding.
1778         (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
1779         * bytecompiler/BytecodeGenerator.cpp:
1780         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
1781         register for the specified link time constant and notify UnlinkedCodeBlock about it.
1782         (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
1783         Object.defineProperty with it.
1784         * bytecompiler/BytecodeGenerator.h:
1785         * bytecompiler/NodesCodegen.cpp:
1786         (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
1787         non-enumerable by using emitCallDefineProperty to define them.
1788         (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
1789         (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
1790         property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
1791         * runtime/CommonIdentifiers.h:
1792         * runtime/JSGlobalObject.cpp:
1793         (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
1794         (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
1795         * runtime/JSGlobalObject.h:
1796         (JSC::JSGlobalObject::definePropertyFunction): Added.
1797         (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
1798         (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
1799         returns a JSCell; e.g. Object.defineProperty.
1800         * runtime/ObjectConstructor.cpp:
1801         (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
1802         * runtime/ObjectConstructor.h:
1803
1804 2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>
1805
1806         [ES6] Implement String.fromCodePoint
1807         https://bugs.webkit.org/show_bug.cgi?id=144160
1808
1809         Reviewed by Darin Adler.
1810
1811         This patch implements String.fromCodePoint.
1812         It accepts multiple code points and generates a string that consists of given code points.
1813         The range [0x0000 - 0x10FFFF] is valid for code points.
1814         If the given value is out of range, throw a range error.
1815
1816         When a 0xFFFF <= valid code point is given,
1817         String.fromCodePoint generates a string that contains surrogate pairs.
1818
1819         * runtime/StringConstructor.cpp:
1820         (JSC::stringFromCodePoint):
1821         (JSC::constructWithStringConstructor):
1822         * tests/stress/string-from-code-point.js: Added.
1823         (shouldBe):
1824         (shouldThrow):
1825         (toCodePoints):
1826         (passThrough):
1827
1828 2015-04-25  Martin Robinson  <mrobinson@igalia.com>
1829
1830         Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
1831         https://bugs.webkit.org/show_bug.cgi?id=144182
1832
1833         Reviewed by Simon Fraser.
1834
1835         * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
1836
1837 2015-04-25  Mark Lam  <mark.lam@apple.com>
1838
1839         mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
1840         https://bugs.webkit.org/show_bug.cgi?id=144152
1841
1842         Reviewed by Filip Pizlo.
1843
1844         Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
1845         StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
1846         OSR exits.  This was overlooked in the original code.
1847
1848         While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
1849         the Branch node, the other 3 may also trigger the same bug for other nodes.
1850         To prevent this bug from manifesting with other nodes (and future ones that
1851         are yet to be added to mayExits()'s "potential won't exit" set), we fix the
1852         EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
1853
1854         Also added a test to exercise a code path that will trigger this bug with
1855         the Branch node before the fix is applied.
1856
1857         * dfg/DFGMayExit.cpp:
1858         * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
1859         (inlinedFunction):
1860         (foo):
1861
1862 2015-04-24  Commit Queue  <commit-queue@webkit.org>
1863
1864         Unreviewed, rolling out r183288.
1865         https://bugs.webkit.org/show_bug.cgi?id=144189
1866
1867         Made js/sort-with-side-effecting-comparisons.html time out in
1868         debug builds (Requested by ap on #webkit).
1869
1870         Reverted changeset:
1871
1872         "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
1873         array."
1874         https://bugs.webkit.org/show_bug.cgi?id=144013
1875         http://trac.webkit.org/changeset/183288
1876
1877 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
1878
1879         CRASH in operationCreateDirectArgumentsDuringExit()
1880         https://bugs.webkit.org/show_bug.cgi?id=143962
1881
1882         Reviewed by Geoffrey Garen.
1883         
1884         We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
1885         recoverable so long as they are live. Therefore, OSR exit should track liveness of
1886         constants instead of assuming that they are always live.
1887
1888         * dfg/DFGGenerationInfo.h:
1889         (JSC::DFG::GenerationInfo::noticeOSRBirth):
1890         (JSC::DFG::GenerationInfo::appendBirth):
1891         * dfg/DFGSpeculativeJIT.cpp:
1892         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1893         * dfg/DFGVariableEvent.cpp:
1894         (JSC::DFG::VariableEvent::dump):
1895         * dfg/DFGVariableEvent.h:
1896         (JSC::DFG::VariableEvent::birth):
1897         (JSC::DFG::VariableEvent::id):
1898         (JSC::DFG::VariableEvent::dataFormat):
1899         * dfg/DFGVariableEventStream.cpp:
1900         (JSC::DFG::VariableEventStream::reconstruct):
1901         * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
1902         (foo):
1903         (bar):
1904         * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
1905         (foo):
1906         (bar):
1907
1908 2015-04-24  Benjamin Poulain  <bpoulain@apple.com>
1909
1910         [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
1911         https://bugs.webkit.org/show_bug.cgi?id=144169
1912
1913         Reviewed by Geoffrey Garen.
1914
1915         * runtime/JSObject.cpp:
1916         (JSC::JSObject::convertInt32ForValue):
1917         DoubleArray do not store NaN, they are used for holes.
1918         What happened was:
1919         1) We fail to insert the NaN in the Int32 array because it is a double.
1920         2) We were converting the array to DoubleArray.
1921         3) We were trying to insert the value again. We would fail again because
1922            DoubleArray does not store NaN.
1923         4) We would convert the DoubleArrayt to Contiguous Array, converting the values
1924            to boxed values.
1925
1926         * tests/stress/int32array-transition-on-nan.js: Added.
1927         The behavior is not really observable. This only test nothing crashes in those
1928         cases.
1929
1930         (insertNaNWhileFilling):
1931         (testInsertNaNWhileFilling):
1932         (insertNaNAfterFilling):
1933         (testInsertNaNAfterFilling):
1934         (pushNaNWhileFilling):
1935         (testPushNaNWhileFilling):
1936
1937 2015-04-21  Geoffrey Garen  <ggaren@apple.com>
1938
1939         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
1940         https://bugs.webkit.org/show_bug.cgi?id=144013
1941
1942         Reviewed by Mark Lam.
1943
1944         This patch implements Array.prototype.sort in JavaScript, removing the
1945         C++ implementations. It is simpler and less error-prone to express our
1946         operations in JavaScript, which provides memory safety, exception safety,
1947         and recursion safety.
1948
1949         The performance result is mixed, but net positive in my opinion. It's
1950         difficult to enumerate all the results, since we used to have so many
1951         different sorting modes, and there are lots of different data patterns
1952         across which you might want to measure sorting. Suffice it to say:
1953
1954             (*) The benchmarks we track are faster or unchanged.
1955
1956             (*) Sorting random input using a comparator -- which we think is
1957             common -- is 3X faster.
1958
1959             (*) Sorting random input in a non-array object -- which jQuery does
1960             -- is 4X faster.
1961
1962             (*) Sorting random input in a compact array of integers using a
1963             trivial pattern-matchable comparator is 2X *slower*.
1964
1965         * builtins/Array.prototype.js:
1966         (sort.min):
1967         (sort.stringComparator):
1968         (sort.compactSparse): Special case compaction for sparse arrays because
1969         we don't want to hang when sorting new Array(BIG).
1970
1971         (sort.compact):
1972         (sort.merge):
1973         (sort.mergeSort): Use merge sort because it's a reasonably efficient
1974         stable sort. We have evidence that some sites depend on stable sort,
1975         even though the ES6 spec does not mandate it. (See
1976         <http://trac.webkit.org/changeset/33967>.)
1977
1978         This is a textbook implementation of merge sort with three optimizations:
1979
1980             (1) Use iteration instead of recursion;
1981
1982             (2) Use array subscripting instead of array copying in order to
1983             create logical sub-lists without creating physical sub-lists;
1984
1985             (3) Swap src and dst at each iteration instead of copying src into
1986             dst, and only copy src into the subject array at the end if src is
1987             not the subject array.
1988
1989         (sort.inflate):
1990         (sort.comparatorSort):
1991         (sort): Sort in JavaScript for the win.
1992
1993         * builtins/BuiltinExecutables.cpp:
1994         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
1995         names so we can use helper functions.
1996
1997         * bytecode/CodeBlock.h:
1998         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
1999         * bytecode/UnlinkedCodeBlock.cpp:
2000         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2001         * bytecode/UnlinkedCodeBlock.h:
2002         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
2003         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
2004         * bytecompiler/BytecodeGenerator.cpp:
2005         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
2006         * bytecompiler/BytecodeGenerator.h:
2007         * bytecompiler/NodesCodegen.cpp:
2008         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
2009         on pattern matching anymore. This was mainly an optimization to avoid 
2010         the overhead of calling from C++ to JS, which we now avoid by
2011         sorting in JS.
2012
2013         * heap/Heap.cpp:
2014         (JSC::Heap::markRoots):
2015         (JSC::Heap::pushTempSortVector): Deleted.
2016         (JSC::Heap::popTempSortVector): Deleted.
2017         (JSC::Heap::visitTempSortVectors): Deleted.
2018         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
2019         in JavaScript using a normal JavaScript array for our temporary storage.
2020
2021         * parser/Parser.cpp:
2022         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
2023         helper functions.
2024
2025         * runtime/ArrayPrototype.cpp:
2026         (JSC::isNumericCompareFunction): Deleted.
2027         (JSC::attemptFastSort): Deleted.
2028         (JSC::performSlowSort): Deleted.
2029         (JSC::arrayProtoFuncSort): Deleted.
2030
2031         * runtime/CommonIdentifiers.h: New strings used by sort.
2032
2033         * runtime/JSArray.cpp:
2034         (JSC::compareNumbersForQSortWithInt32): Deleted.
2035         (JSC::compareNumbersForQSortWithDouble): Deleted.
2036         (JSC::compareNumbersForQSort): Deleted.
2037         (JSC::compareByStringPairForQSort): Deleted.
2038         (JSC::JSArray::sortNumericVector): Deleted.
2039         (JSC::JSArray::sortNumeric): Deleted.
2040         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
2041         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
2042         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
2043         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
2044         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
2045         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
2046         (JSC::JSArray::sortCompactedVector): Deleted.
2047         (JSC::JSArray::sort): Deleted.
2048         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
2049         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
2050         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
2051         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
2052         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
2053         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
2054         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
2055         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
2056         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
2057         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
2058         (JSC::JSArray::sortVector): Deleted.
2059         (JSC::JSArray::compactForSorting): Deleted.
2060         * runtime/JSArray.h:
2061
2062         * runtime/JSGlobalObject.cpp:
2063         (JSC::JSGlobalObject::init):
2064         * runtime/ObjectConstructor.cpp:
2065         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
2066         by sort.
2067
2068 2015-04-24  Matthew Mirman  <mmirman@apple.com>
2069
2070         Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
2071         https://bugs.webkit.org/show_bug.cgi?id=141865
2072         rdar://problem/19927273
2073
2074         Reviewed by Filip Pizlo.
2075
2076         * runtime/JSGlobalObjectFunctions.cpp:
2077         (JSC::globalFuncProtoGetter):
2078         (JSC::globalFuncProtoSetter):
2079
2080 2015-04-23  Benjamin Poulain  <bpoulain@apple.com>
2081
2082         Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
2083         https://bugs.webkit.org/show_bug.cgi?id=144118
2084
2085         Reviewed by Geoffrey Garen.
2086
2087         * dfg/DFGGraph.h:
2088         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
2089         Both block do the same thing.
2090
2091 2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2092
2093         Web Inspector: Speculative fix for non-main thread auto-attach failures
2094         https://bugs.webkit.org/show_bug.cgi?id=144134
2095
2096         Reviewed by Timothy Hatcher.
2097
2098         * inspector/remote/RemoteInspector.mm:
2099         (Inspector::RemoteInspector::singleton):
2100
2101 2015-04-23  Basile Clement  <basile_clement@apple.com>
2102
2103         Allow function allocation sinking
2104         https://bugs.webkit.org/show_bug.cgi?id=144016
2105
2106         Reviewed by Filip Pizlo.
2107
2108         This adds the ability to sink function allocations in the
2109         DFGObjectAllocationSinkingPhase.
2110
2111         In order to enable this, we add a new PhantomNewFunction node that is
2112         used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
2113         a sunk NewFunction and keep track of the allocations that have to be performed
2114         in case of OSR exit after the sunk allocation but before the real one.
2115         The FunctionExecutable and JSLexicalEnvironment (activation) of the function
2116         are stored onto the PhantomNewFunction through PutHints in order for them
2117         to be recovered on OSR exit.
2118
2119         Contrary to sunk object allocations, sunk function allocations do not
2120         support any kind of operations (e.g. storing into a field) ; any such operation
2121         will mark the function allocation as escaping and trigger materialization. As
2122         such, function allocations can only be sunk to places where it would have been
2123         correct to syntactically move them, and we don't need a special
2124         MaterializeNewFunction node to recover possible operations on the function. A
2125         sunk NewFunction node will simply create new NewFunction nodes, then replace
2126         itself with a PhantomNewFunction node.
2127
2128         In itself, this change is not expected to have a significant impact on
2129         performances other than in degenerate cases (see e.g.
2130         JSRegress/sink-function), but it is a step towards being able to sink recursive
2131         closures onces we support CreateActivation sinking as well as allocation cycles
2132         sinking.
2133
2134         * dfg/DFGAbstractInterpreterInlines.h:
2135         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2136         * dfg/DFGClobberize.h:
2137         (JSC::DFG::clobberize):
2138         * dfg/DFGDoesGC.cpp:
2139         (JSC::DFG::doesGC):
2140         * dfg/DFGFixupPhase.cpp:
2141         (JSC::DFG::FixupPhase::fixupNode):
2142         * dfg/DFGNode.h:
2143         (JSC::DFG::Node::convertToPhantomNewFunction):
2144         (JSC::DFG::Node::isPhantomAllocation):
2145         * dfg/DFGNodeType.h:
2146         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2147         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2148         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2149         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2150         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2151         * dfg/DFGPredictionPropagationPhase.cpp:
2152         (JSC::DFG::PredictionPropagationPhase::propagate):
2153         * dfg/DFGPromotedHeapLocation.cpp:
2154         (WTF::printInternal):
2155         * dfg/DFGPromotedHeapLocation.h:
2156         * dfg/DFGSafeToExecute.h:
2157         (JSC::DFG::safeToExecute):
2158         * dfg/DFGSpeculativeJIT32_64.cpp:
2159         (JSC::DFG::SpeculativeJIT::compile):
2160         * dfg/DFGSpeculativeJIT64.cpp:
2161         (JSC::DFG::SpeculativeJIT::compile):
2162         * dfg/DFGValidate.cpp:
2163         (JSC::DFG::Validate::validateCPS):
2164         * ftl/FTLCapabilities.cpp:
2165         (JSC::FTL::canCompile):
2166         * ftl/FTLLowerDFGToLLVM.cpp:
2167         (JSC::FTL::LowerDFGToLLVM::compileNode):
2168         * ftl/FTLOperations.cpp:
2169         (JSC::FTL::operationMaterializeObjectInOSR):
2170         * tests/stress/function-sinking-no-double-allocate.js: Added.
2171         (call):
2172         (.f):
2173         (sink):
2174         * tests/stress/function-sinking-osrexit.js: Added.
2175         (.g):
2176         (sink):
2177         * tests/stress/function-sinking-put.js: Added.
2178         (.g):
2179         (sink):
2180
2181 2015-04-23  Basile Clement  <basile_clement@apple.com>
2182
2183         Make FunctionRareData allocation thread-safe
2184         https://bugs.webkit.org/show_bug.cgi?id=144001
2185
2186         Reviewed by Mark Lam.
2187
2188         The two things we want to prevent are:
2189
2190          1. A thread seeing a pointer to a not-yet-fully-created rare data from
2191             a JSFunction
2192          2. A thread seeing a pointer to a not-yet-fully-created Structure from
2193             an ObjectAllocationProfile
2194
2195         For 1., only the JS thread can be creating the rare data (in
2196         runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
2197         worry about concurrent writes, and we don't need any fences when *reading* the
2198         rare data from the JS thread. Thus we only need a storeStoreFence between the
2199         rare data creation and assignment to m_rareData in
2200         JSFunction::createAndInitializeRareData() to ensure that when the store to
2201         m_rareData is issued, the rare data has been properly created.
2202
2203         For the DFG compilation threads, the only place they can access the
2204         rare data is through JSFunction::rareData(), and so we only need a
2205         loadLoadFence there to ensure that when we see a non-null pointer in
2206         m_rareData, the pointed object will be seen as a fully created
2207         FunctionRareData.
2208
2209
2210         For 2., the structure is created in
2211         ObjectAllocationProfile::initialize() (which appears to be called only by the
2212         JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
2213         which always happen in the JS thread), and read through
2214         ObjectAllocationProfile::structure() and
2215         ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
2216         put a storeStoreFence in ObjectAllocationProfile::initialize() and a
2217         loadLoadFence in ObjectAllocationProfile::structure() (and change
2218         ObjectAllocationProfile::inlineCapacity() to go through
2219         ObjectAllocationProfile::structure()).
2220
2221         We don't need a fence in ObjectAllocationProfile::clear() because
2222         clearing the structure is already as atomic as it gets.
2223
2224         Finally, notice that we don't care about the ObjectAllocationProfile's
2225         m_allocator as that is only used by ObjectAllocationProfile::initialize() and
2226         ObjectAllocationProfile::clear() that are always run in the JS thread.
2227         ObjectAllocationProfile::isNull() could cause some trouble, but it is
2228         currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
2229         thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
2230         thread anyway.
2231
2232         * bytecode/ObjectAllocationProfile.h:
2233         (JSC::ObjectAllocationProfile::initialize):
2234         (JSC::ObjectAllocationProfile::structure):
2235         (JSC::ObjectAllocationProfile::inlineCapacity):
2236         * runtime/JSFunction.cpp:
2237         (JSC::JSFunction::allocateAndInitializeRareData):
2238         * runtime/JSFunction.h:
2239         (JSC::JSFunction::rareData):
2240         (JSC::JSFunction::allocationStructure): Deleted.
2241         This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
2242
2243 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2244
2245         DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
2246         https://bugs.webkit.org/show_bug.cgi?id=143735
2247
2248         Reviewed by Geoffrey Garen.
2249         
2250         We've always had bugs arising from the fact that we would MovHint something into a local,
2251         and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
2252         on those Nodes that were MovHinted. But this became increasingly tricky. Given the
2253         sophistication of the transformations we are doing today, this approach is just not sound
2254         anymore.
2255         
2256         This comprehensively fixes these bugs by having the DFG backend automatically insert
2257         Phantoms just before codegen based on bytecode liveness. To make this practical, this also
2258         makes it much faster to query bytecode liveness.
2259         
2260         It's about as perf-neutral as it gets for a change that increases compiler work without
2261         actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
2262         which should then speed us up. I can't really report concrete slow-down numbers because
2263         they are low enough to basically be in the noise. For example, a 20-iteration run of
2264         SunSpider yields "maybe 0.8% slower", whatever that means.
2265
2266         * CMakeLists.txt:
2267         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2268         * JavaScriptCore.xcodeproj/project.pbxproj:
2269         * bytecode/BytecodeLivenessAnalysis.cpp:
2270         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
2271         * bytecode/FullBytecodeLiveness.h:
2272         (JSC::FullBytecodeLiveness::getLiveness):
2273         * bytecode/VirtualRegister.h:
2274         (JSC::VirtualRegister::operator+):
2275         (JSC::VirtualRegister::operator-):
2276         * dfg/DFGForAllKills.h:
2277         (JSC::DFG::forAllLiveNodesAtTail):
2278         (JSC::DFG::forAllKilledOperands):
2279         (JSC::DFG::forAllKilledNodesAtNodeIndex):
2280         * dfg/DFGGraph.cpp:
2281         (JSC::DFG::Graph::isLiveInBytecode):
2282         (JSC::DFG::Graph::localsLiveInBytecode):
2283         * dfg/DFGGraph.h:
2284         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2285         (JSC::DFG::Graph::forAllLiveInBytecode):
2286         * dfg/DFGMayExit.cpp:
2287         (JSC::DFG::mayExit):
2288         * dfg/DFGMovHintRemovalPhase.cpp:
2289         * dfg/DFGNodeType.h:
2290         * dfg/DFGPhantomInsertionPhase.cpp: Added.
2291         (JSC::DFG::performPhantomInsertion):
2292         * dfg/DFGPhantomInsertionPhase.h: Added.
2293         * dfg/DFGPlan.cpp:
2294         (JSC::DFG::Plan::compileInThreadImpl):
2295         * dfg/DFGScoreBoard.h:
2296         (JSC::DFG::ScoreBoard::sortFree):
2297         (JSC::DFG::ScoreBoard::assertClear):
2298         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2299         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2300         * ftl/FTLLowerDFGToLLVM.cpp:
2301         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2302         * tests/stress/phantom-inadequacy.js: Added.
2303         (bar):
2304         (baz):
2305         (foo):
2306
2307 2015-04-23  Filip Pizlo  <fpizlo@apple.com>
2308
2309         Rename HardPhantom to MustGenerate.
2310
2311         Rubber stamped by Geoffrey Garen.
2312         
2313         We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
2314         is more than that; it's a utility for forcing the execution of otherwise killable nodes.
2315         NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
2316         node should just be called MustGenerate.
2317
2318         * dfg/DFGAbstractInterpreterInlines.h:
2319         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2320         * dfg/DFGArgumentsEliminationPhase.cpp:
2321         * dfg/DFGClobberize.h:
2322         (JSC::DFG::clobberize):
2323         * dfg/DFGDCEPhase.cpp:
2324         (JSC::DFG::DCEPhase::run):
2325         * dfg/DFGDoesGC.cpp:
2326         (JSC::DFG::doesGC):
2327         * dfg/DFGFixupPhase.cpp:
2328         (JSC::DFG::FixupPhase::fixupNode):
2329         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
2330         * dfg/DFGIntegerCheckCombiningPhase.cpp:
2331         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
2332         * dfg/DFGMayExit.cpp:
2333         (JSC::DFG::mayExit):
2334         * dfg/DFGNode.h:
2335         (JSC::DFG::Node::willHaveCodeGenOrOSR):
2336         * dfg/DFGNodeType.h:
2337         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2338         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2339         * dfg/DFGPhantomCanonicalizationPhase.cpp:
2340         (JSC::DFG::PhantomCanonicalizationPhase::run):
2341         * dfg/DFGPhantomRemovalPhase.cpp:
2342         (JSC::DFG::PhantomRemovalPhase::run):
2343         * dfg/DFGPredictionPropagationPhase.cpp:
2344         (JSC::DFG::PredictionPropagationPhase::propagate):
2345         * dfg/DFGSafeToExecute.h:
2346         (JSC::DFG::safeToExecute):
2347         * dfg/DFGSpeculativeJIT32_64.cpp:
2348         (JSC::DFG::SpeculativeJIT::compile):
2349         * dfg/DFGSpeculativeJIT64.cpp:
2350         (JSC::DFG::SpeculativeJIT::compile):
2351         * dfg/DFGTypeCheckHoistingPhase.cpp:
2352         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2353         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2354         * dfg/DFGVarargsForwardingPhase.cpp:
2355         * ftl/FTLCapabilities.cpp:
2356         (JSC::FTL::canCompile):
2357         * ftl/FTLLowerDFGToLLVM.cpp:
2358         (JSC::FTL::LowerDFGToLLVM::compileNode):
2359
2360 2015-04-23  Jordan Harband  <ljharb@gmail.com>
2361
2362         Implement `Object.assign`
2363         https://bugs.webkit.org/show_bug.cgi?id=143980
2364
2365         Reviewed by Filip Pizlo.
2366
2367         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
2368
2369         * builtins/ObjectConstructor.js: Added.
2370         (assign):
2371         * runtime/CommonIdentifiers.h:
2372         * runtime/JSGlobalObject.cpp:
2373         (JSC::JSGlobalObject::init):
2374         * runtime/ObjectConstructor.cpp:
2375         * runtime/ObjectConstructor.h:
2376
2377 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2378
2379         Unreviewed, fix debug build.
2380
2381         * dfg/DFGGraph.h:
2382         (JSC::DFG::Graph::performSubstitutionForEdge):
2383
2384 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2385
2386         Nodes should have an optional epoch field
2387         https://bugs.webkit.org/show_bug.cgi?id=144084
2388
2389         Reviewed by Ryosuke Niwa and Mark Lam.
2390         
2391         This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
2392         https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
2393         used.
2394
2395         * dfg/DFGCPSRethreadingPhase.cpp:
2396         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2397         * dfg/DFGCSEPhase.cpp:
2398         * dfg/DFGEpoch.h:
2399         (JSC::DFG::Epoch::fromUnsigned):
2400         (JSC::DFG::Epoch::toUnsigned):
2401         * dfg/DFGGraph.cpp:
2402         (JSC::DFG::Graph::clearReplacements):
2403         (JSC::DFG::Graph::clearEpochs):
2404         * dfg/DFGGraph.h:
2405         (JSC::DFG::Graph::performSubstitutionForEdge):
2406         * dfg/DFGNode.h:
2407         (JSC::DFG::Node::Node):
2408         (JSC::DFG::Node::replaceWith):
2409         (JSC::DFG::Node::replacement):
2410         (JSC::DFG::Node::setReplacement):
2411         (JSC::DFG::Node::epoch):
2412         (JSC::DFG::Node::setEpoch):
2413         * dfg/DFGSSAConversionPhase.cpp:
2414         (JSC::DFG::SSAConversionPhase::run):
2415
2416 2015-04-22  Mark Lam  <mark.lam@apple.com>
2417
2418         Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
2419         https://bugs.webkit.org/show_bug.cgi?id=143898
2420
2421         Reviewed by Filip Pizlo.
2422
2423         CodeBlock::dumpSource() will access SourceCode strings in a way that requires
2424         ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
2425         compilation threads because StringImpls are not thread safe. As a result, we get
2426         an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
2427         build.
2428
2429         This patch fixes the issue by only collecting the CodeBlock (and associated info)
2430         into a DeferredSourceDump record while compiling, and stashing it away in a
2431         deferredSourceDump list in the DeferredCompilationCallback object to be dumped
2432         later.
2433
2434         When compilation is done, the callback object will be notified that
2435         compilationDidComplete().  We will dump the SourceCode strings from there. 
2436         Since compilationDidComplete() is guaranteed to only be called on the thread
2437         doing JS execution, it is safe to access the SourceCode strings there and ref
2438         their underlying StringImpls as needed.        
2439
2440         * CMakeLists.txt:
2441         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2442         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2443         * JavaScriptCore.xcodeproj/project.pbxproj:
2444         * bytecode/DeferredCompilationCallback.cpp:
2445         (JSC::DeferredCompilationCallback::compilationDidComplete):
2446         (JSC::DeferredCompilationCallback::sourceDumpInfo):
2447         (JSC::DeferredCompilationCallback::dumpCompiledSources):
2448         * bytecode/DeferredCompilationCallback.h:
2449         * bytecode/DeferredSourceDump.cpp: Added.
2450         (JSC::DeferredSourceDump::DeferredSourceDump):
2451         (JSC::DeferredSourceDump::dump):
2452         * bytecode/DeferredSourceDump.h: Added.
2453         * dfg/DFGByteCodeParser.cpp:
2454         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2455         * dfg/DFGDriver.cpp:
2456         (JSC::DFG::compileImpl):
2457
2458 2015-04-22  Benjamin Poulain  <benjamin@webkit.org>
2459
2460         Implement String.codePointAt()
2461         https://bugs.webkit.org/show_bug.cgi?id=143934
2462
2463         Reviewed by Darin Adler.
2464
2465         This patch adds String.codePointAt() as defined by ES6.
2466         I opted for a C++ implementation for now.
2467
2468         * runtime/StringPrototype.cpp:
2469         (JSC::StringPrototype::finishCreation):
2470         (JSC::codePointAt):
2471         (JSC::stringProtoFuncCodePointAt):
2472
2473 2015-04-22  Mark Lam  <mark.lam@apple.com>
2474
2475         SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
2476         https://bugs.webkit.org/show_bug.cgi?id=144067
2477
2478         Reviewed by Michael Saboff.
2479
2480         Currently, there are a few places where the JSObject that owns the
2481         SparseArrayValueMap is designated as the owner of the SparseArrayEntry
2482         write barrier.  This is a bug and can result in the GC collecting the
2483         SparseArrayEntry even though it is being referenced by the
2484         SparseArrayValueMap.  This patch fixes the bug.
2485
2486         * runtime/JSObject.cpp:
2487         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
2488         (JSC::JSObject::putIndexedDescriptor):
2489         * tests/stress/sparse-array-entry-update-144067.js: Added.
2490         (useMemoryToTriggerGCs):
2491         (foo):
2492
2493 2015-04-22  Mark Lam  <mark.lam@apple.com>
2494
2495         Give the heap object iterators the ability to return early.
2496         https://bugs.webkit.org/show_bug.cgi?id=144011
2497
2498         Reviewed by Michael Saboff.
2499
2500         JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
2501         candidate cell pointers, and, when in use, is called a lot more often than
2502         the normal way those iterators are used.  As a result, I see my instrumented
2503         VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
2504         callback functor the ability to tell the iterators to return early when the
2505         functor no longer needs to continue iterating.  With this, my instrumented
2506         VM is useful again for debugging.
2507
2508         Since heap iteration is not something that we do in a typical fast path,
2509         I don't expect this to have any noticeable impact on performance.
2510
2511         I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
2512         it checks JSCell addresses, not just JSObjects.
2513
2514         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2515         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2516         * JavaScriptCore.xcodeproj/project.pbxproj:
2517         * debugger/Debugger.cpp:
2518         * heap/GCLogging.cpp:
2519         (JSC::LoggingFunctor::operator()):
2520         * heap/Heap.cpp:
2521         (JSC::Zombify::visit):
2522         (JSC::Zombify::operator()):
2523         * heap/HeapStatistics.cpp:
2524         (JSC::StorageStatistics::visit):
2525         (JSC::StorageStatistics::operator()):
2526         * heap/HeapVerifier.cpp:
2527         (JSC::GatherLiveObjFunctor::visit):
2528         (JSC::GatherLiveObjFunctor::operator()):
2529         * heap/MarkedBlock.cpp:
2530         (JSC::SetNewlyAllocatedFunctor::operator()):
2531         * heap/MarkedBlock.h:
2532         (JSC::MarkedBlock::forEachCell):
2533         (JSC::MarkedBlock::forEachLiveCell):
2534         (JSC::MarkedBlock::forEachDeadCell):
2535         * heap/MarkedSpace.h:
2536         (JSC::MarkedSpace::forEachLiveCell):
2537         (JSC::MarkedSpace::forEachDeadCell):
2538         * inspector/agents/InspectorRuntimeAgent.cpp:
2539         (Inspector::TypeRecompiler::visit):
2540         (Inspector::TypeRecompiler::operator()):
2541         * runtime/IterationStatus.h: Added.
2542         * runtime/JSGlobalObject.cpp:
2543         * runtime/VM.cpp:
2544         (JSC::StackPreservingRecompiler::visit):
2545         (JSC::StackPreservingRecompiler::operator()):
2546         * tools/JSDollarVMPrototype.cpp:
2547         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2548         (JSC::CellAddressCheckFunctor::operator()):
2549         (JSC::JSDollarVMPrototype::isValidCell):
2550         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
2551         (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
2552
2553 2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
2554
2555         [[Set]] should be properly executed in JS builtins
2556         https://bugs.webkit.org/show_bug.cgi?id=143996
2557
2558         Reviewed by Geoffrey Garen.
2559
2560         Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
2561         However,
2562
2563         1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
2564         2. It's different from the default JS behavior.
2565
2566         In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
2567         And dropping the current hack for builtins.
2568
2569         * builtins/Array.prototype.js:
2570         (filter):
2571         (map):
2572         (find):
2573         * bytecompiler/BytecodeGenerator.cpp:
2574         (JSC::BytecodeGenerator::emitPutByVal):
2575         * tests/stress/array-fill-put-by-val.js: Added.
2576         (shouldThrow):
2577         (.set get array):
2578         * tests/stress/array-filter-put-by-val-direct.js: Added.
2579         (shouldBe):
2580         (.set get var):
2581         * tests/stress/array-find-does-not-lookup-twice.js: Added.
2582         (shouldBe):
2583         (shouldThrow):
2584         (.get shouldBe):
2585         * tests/stress/array-from-put-by-val-direct.js: Added.
2586         (shouldBe):
2587         (.set get var):
2588         * tests/stress/array-from-set-length.js: Added.
2589         (shouldBe):
2590         (ArrayLike):
2591         (ArrayLike.prototype.set length):
2592         (ArrayLike.prototype.get length):
2593         * tests/stress/array-map-put-by-val-direct.js: Added.
2594         (shouldBe):
2595         (.set get var):
2596
2597 2015-04-22  Basile Clement  <basile_clement@apple.com>
2598  
2599         Don't de-allocate FunctionRareData
2600         https://bugs.webkit.org/show_bug.cgi?id=144000
2601
2602         Reviewed by Michael Saboff.
2603
2604         A function rare data (containing most notably its allocation profile) is currently
2605         freed and re-allocated each time the function's prototype is cleared.
2606         This is not optimal as it means we are invalidating the watchpoint and recompiling the
2607         scope each time the prototype is cleared.
2608
2609         This makes it so that a single rare data is reused, clearing the underlying
2610         ObjectAllocationProfile instead of throwing away the whole rare data on
2611         .prototype updates.
2612
2613         * runtime/FunctionRareData.cpp:
2614         (JSC::FunctionRareData::create):
2615         (JSC::FunctionRareData::finishCreation):
2616         * runtime/FunctionRareData.h:
2617         * runtime/JSFunction.cpp:
2618         (JSC::JSFunction::allocateAndInitializeRareData):
2619         (JSC::JSFunction::initializeRareData):
2620
2621 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2622
2623         Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
2624
2625         * dfg/DFGSpeculativeJIT32_64.cpp:
2626         (JSC::DFG::SpeculativeJIT::compile):
2627
2628 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2629
2630         DFG should allow Phantoms after terminals
2631         https://bugs.webkit.org/show_bug.cgi?id=126778
2632
2633         Reviewed by Mark Lam.
2634         
2635         It's important for us to be able to place liveness-marking nodes after nodes that do
2636         things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
2637         terminals. That made things awkward, especially for Switch and Branch, which may do
2638         things that necessitate liveness markers (for example they might want to use a converted
2639         version of a value rather than the value that was MovHinted). We previously made this
2640         work by disallowing certain optimizations on Switch and Branch, which was probably a bad
2641         thing.
2642         
2643         This changes our IR to allow for the terminal to not be the last node in a block. Asking
2644         for the terminal involves a search. DFG::validate() checks that the nodes after the
2645         terminal are liveness markers that have no effects or checks.
2646         
2647         This is perf-neutral but will allow more optimizations in the future. It will also make
2648         it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
2649
2650         * dfg/DFGBasicBlock.cpp:
2651         (JSC::DFG::BasicBlock::replaceTerminal):
2652         * dfg/DFGBasicBlock.h:
2653         (JSC::DFG::BasicBlock::findTerminal):
2654         (JSC::DFG::BasicBlock::terminal):
2655         (JSC::DFG::BasicBlock::insertBeforeTerminal):
2656         (JSC::DFG::BasicBlock::numSuccessors):
2657         (JSC::DFG::BasicBlock::successor):
2658         (JSC::DFG::BasicBlock::successorForCondition):
2659         (JSC::DFG::BasicBlock::successors):
2660         (JSC::DFG::BasicBlock::last): Deleted.
2661         (JSC::DFG::BasicBlock::takeLast): Deleted.
2662         (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
2663         (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
2664         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
2665         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
2666         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
2667         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
2668         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
2669         (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
2670         (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
2671         * dfg/DFGBasicBlockInlines.h:
2672         (JSC::DFG::BasicBlock::appendNonTerminal):
2673         (JSC::DFG::BasicBlock::replaceTerminal):
2674         * dfg/DFGByteCodeParser.cpp:
2675         (JSC::DFG::ByteCodeParser::addToGraph):
2676         (JSC::DFG::ByteCodeParser::inlineCall):
2677         (JSC::DFG::ByteCodeParser::handleInlining):
2678         (JSC::DFG::ByteCodeParser::parseBlock):
2679         (JSC::DFG::ByteCodeParser::linkBlock):
2680         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2681         * dfg/DFGCFGSimplificationPhase.cpp:
2682         (JSC::DFG::CFGSimplificationPhase::run):
2683         (JSC::DFG::CFGSimplificationPhase::convertToJump):
2684         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
2685         * dfg/DFGCPSRethreadingPhase.cpp:
2686         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2687         * dfg/DFGCommon.h:
2688         (JSC::DFG::NodeAndIndex::NodeAndIndex):
2689         (JSC::DFG::NodeAndIndex::operator!):
2690         * dfg/DFGFixupPhase.cpp:
2691         (JSC::DFG::FixupPhase::fixupBlock):
2692         (JSC::DFG::FixupPhase::fixupNode):
2693         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
2694         (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
2695         * dfg/DFGForAllKills.h:
2696         (JSC::DFG::forAllLiveNodesAtTail):
2697         * dfg/DFGGraph.cpp:
2698         (JSC::DFG::Graph::terminalsAreValid):
2699         (JSC::DFG::Graph::dumpBlockHeader):
2700         * dfg/DFGGraph.h:
2701         * dfg/DFGInPlaceAbstractState.cpp:
2702         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
2703         * dfg/DFGLICMPhase.cpp:
2704         (JSC::DFG::LICMPhase::run):
2705         (JSC::DFG::LICMPhase::attemptHoist):
2706         * dfg/DFGMovHintRemovalPhase.cpp:
2707         * dfg/DFGNode.h:
2708         (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
2709         (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
2710         (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
2711         (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
2712         (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
2713         (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
2714         (JSC::DFG::Node::SuccessorsIterable::begin):
2715         (JSC::DFG::Node::SuccessorsIterable::end):
2716         (JSC::DFG::Node::successors):
2717         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2718         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
2719         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
2720         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
2721         * dfg/DFGPhantomRemovalPhase.cpp:
2722         (JSC::DFG::PhantomRemovalPhase::run):
2723         * dfg/DFGPutStackSinkingPhase.cpp:
2724         * dfg/DFGSSAConversionPhase.cpp:
2725         (JSC::DFG::SSAConversionPhase::run):
2726         * dfg/DFGSpeculativeJIT.h:
2727         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
2728         * dfg/DFGSpeculativeJIT32_64.cpp:
2729         (JSC::DFG::SpeculativeJIT::compile):
2730         * dfg/DFGSpeculativeJIT64.cpp:
2731         (JSC::DFG::SpeculativeJIT::compile):
2732         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
2733         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
2734         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2735         (JSC::DFG::TierUpCheckInjectionPhase::run):
2736         * dfg/DFGValidate.cpp:
2737         (JSC::DFG::Validate::validate):
2738         * ftl/FTLLowerDFGToLLVM.cpp:
2739         (JSC::FTL::LowerDFGToLLVM::compileNode):
2740         * tests/stress/closure-call-exit.js: Added.
2741         (foo):
2742
2743 2015-04-21  Basile Clement  <basile_clement@apple.com>
2744
2745         PhantomNewObject should be marked NodeMustGenerate
2746         https://bugs.webkit.org/show_bug.cgi?id=143974
2747
2748         Reviewed by Filip Pizlo.
2749
2750         * dfg/DFGNode.h:
2751         (JSC::DFG::Node::convertToPhantomNewObject):
2752         Was not properly marking NodeMustGenerate when converting.
2753
2754 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2755
2756         DFG Call/ConstructForwardVarargs fails to restore the stack pointer
2757         https://bugs.webkit.org/show_bug.cgi?id=144007
2758
2759         Reviewed by Mark Lam.
2760         
2761         We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
2762         if isForwardVarargs.
2763
2764         * dfg/DFGSpeculativeJIT32_64.cpp:
2765         (JSC::DFG::SpeculativeJIT::emitCall):
2766         * dfg/DFGSpeculativeJIT64.cpp:
2767         (JSC::DFG::SpeculativeJIT::emitCall):
2768         * tests/stress/varargs-then-slow-call.js: Added.
2769         (foo):
2770         (bar):
2771         (fuzz):
2772         (baz):
2773
2774 2015-04-21  Basile Clement  <basile_clement@apple.com>
2775
2776         Remove AllocationProfileWatchpoint node
2777         https://bugs.webkit.org/show_bug.cgi?id=143999
2778
2779         Reviewed by Filip Pizlo.
2780
2781         * dfg/DFGAbstractInterpreterInlines.h:
2782         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2783         * dfg/DFGByteCodeParser.cpp:
2784         (JSC::DFG::ByteCodeParser::parseBlock):
2785         * dfg/DFGClobberize.h:
2786         (JSC::DFG::clobberize):
2787         * dfg/DFGDoesGC.cpp:
2788         (JSC::DFG::doesGC):
2789         * dfg/DFGFixupPhase.cpp:
2790         (JSC::DFG::FixupPhase::fixupNode):
2791         * dfg/DFGHeapLocation.cpp:
2792         (WTF::printInternal):
2793         * dfg/DFGHeapLocation.h:
2794         * dfg/DFGNode.h:
2795         (JSC::DFG::Node::hasCellOperand):
2796         * dfg/DFGNodeType.h:
2797         * dfg/DFGPredictionPropagationPhase.cpp:
2798         (JSC::DFG::PredictionPropagationPhase::propagate):
2799         * dfg/DFGSafeToExecute.h:
2800         (JSC::DFG::safeToExecute):
2801         * dfg/DFGSpeculativeJIT32_64.cpp:
2802         (JSC::DFG::SpeculativeJIT::compile):
2803         * dfg/DFGSpeculativeJIT64.cpp:
2804         (JSC::DFG::SpeculativeJIT::compile):
2805         * dfg/DFGWatchpointCollectionPhase.cpp:
2806         (JSC::DFG::WatchpointCollectionPhase::handle):
2807         * ftl/FTLCapabilities.cpp:
2808         (JSC::FTL::canCompile):
2809         * ftl/FTLLowerDFGToLLVM.cpp:
2810         (JSC::FTL::LowerDFGToLLVM::compileNode):
2811         * runtime/JSFunction.h:
2812         (JSC::JSFunction::rareData):
2813         (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
2814
2815 2015-04-19  Filip Pizlo  <fpizlo@apple.com>
2816
2817         MovHint should be a strong use
2818         https://bugs.webkit.org/show_bug.cgi?id=143734
2819
2820         Reviewed by Geoffrey Garen.
2821         
2822         This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
2823         so is a major step towards allowing more fancy DFG transformations and also probably fixing
2824         some bugs.
2825         
2826         Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
2827         introducing a MovHint removal phase that runs in FTL.
2828         
2829         This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
2830
2831         * CMakeLists.txt:
2832         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2833         * JavaScriptCore.xcodeproj/project.pbxproj:
2834         * bytecode/CodeOrigin.cpp:
2835         (JSC::InlineCallFrame::dumpInContext):
2836         * dfg/DFGDCEPhase.cpp:
2837         (JSC::DFG::DCEPhase::fixupBlock):
2838         * dfg/DFGDisassembler.cpp:
2839         (JSC::DFG::Disassembler::createDumpList):
2840         * dfg/DFGEpoch.cpp: Added.
2841         (JSC::DFG::Epoch::dump):
2842         * dfg/DFGEpoch.h: Added.
2843         (JSC::DFG::Epoch::Epoch):
2844         (JSC::DFG::Epoch::first):
2845         (JSC::DFG::Epoch::operator!):
2846         (JSC::DFG::Epoch::next):
2847         (JSC::DFG::Epoch::bump):
2848         (JSC::DFG::Epoch::operator==):
2849         (JSC::DFG::Epoch::operator!=):
2850         * dfg/DFGMayExit.cpp:
2851         (JSC::DFG::mayExit):
2852         * dfg/DFGMovHintRemovalPhase.cpp: Added.
2853         (JSC::DFG::performMovHintRemoval):
2854         * dfg/DFGMovHintRemovalPhase.h: Added.
2855         * dfg/DFGNodeType.h:
2856         * dfg/DFGPlan.cpp:
2857         (JSC::DFG::Plan::compileInThreadImpl):
2858         * dfg/DFGSpeculativeJIT.cpp:
2859         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2860         * dfg/DFGSpeculativeJIT64.cpp:
2861         (JSC::DFG::SpeculativeJIT::compile):
2862         * runtime/Options.h:
2863
2864 2015-04-21  Basile Clement  <basile_clement@apple.com>
2865
2866         REGRESSION (r182899): icloud.com crashes
2867         https://bugs.webkit.org/show_bug.cgi?id=143960
2868
2869         Reviewed by Filip Pizlo.
2870
2871         * runtime/JSFunction.h:
2872         (JSC::JSFunction::allocationStructure):
2873         * tests/stress/dfg-rare-data.js: Added.
2874         (F): Regression test
2875
2876 2015-04-21  Michael Saboff  <msaboff@apple.com>
2877
2878         Crash in JSC::Interpreter::execute
2879         https://bugs.webkit.org/show_bug.cgi?id=142625
2880
2881         Reviewed by Filip Pizlo.
2882
2883         We need to keep the FunctionExecutables in the code block for the eval flavor of 
2884         Interpreter::execute() in order to create the scope used to eval.
2885
2886         * bytecode/CodeBlock.cpp:
2887         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
2888         * bytecode/CodeBlock.h:
2889         * dfg/DFGGraph.cpp:
2890         (JSC::DFG::Graph::registerFrozenValues):
2891
2892 2015-04-21  Chris Dumez  <cdumez@apple.com>
2893
2894         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
2895         https://bugs.webkit.org/show_bug.cgi?id=143970
2896
2897         Reviewed by Darin Adler.
2898
2899         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
2900         constructor explicit as it copies the vector and it is easy to call it
2901         by mistake.
2902
2903         * bytecode/UnlinkedInstructionStream.cpp:
2904         (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
2905         * bytecode/UnlinkedInstructionStream.h:
2906         * ftl/FTLLowerDFGToLLVM.cpp:
2907         (JSC::FTL::LowerDFGToLLVM::lower):
2908
2909 2015-04-20  Basile Clement  <basile_clement@apple.com>
2910
2911         PhantomNewObject should be marked NodeMustGenerate
2912         https://bugs.webkit.org/show_bug.cgi?id=143974
2913
2914         Reviewed by Filip Pizlo.
2915
2916         * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
2917
2918 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
2919
2920         Cleanup some StringBuilder use
2921         https://bugs.webkit.org/show_bug.cgi?id=143550
2922
2923         Reviewed by Darin Adler.
2924
2925         * runtime/Symbol.cpp:
2926         (JSC::Symbol::descriptiveString):
2927         * runtime/TypeProfiler.cpp:
2928         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
2929         * runtime/TypeSet.cpp:
2930         (JSC::TypeSet::toJSONString):
2931         (JSC::StructureShape::propertyHash):
2932         (JSC::StructureShape::stringRepresentation):
2933         (JSC::StructureShape::toJSONString):
2934
2935 2015-04-20  Mark Lam  <mark.lam@apple.com>
2936
2937         Add debugging tools to test if a given pointer is a valid object and in the heap.
2938         https://bugs.webkit.org/show_bug.cgi?id=143910
2939
2940         Reviewed by Geoffrey Garen.
2941
2942         When doing debugging from lldb, sometimes, it is useful to be able to tell if a
2943         purported JSObject is really a valid object in the heap or not.  We can add the
2944         following utility functions to help:
2945             isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
2946             isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
2947             isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
2948             isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
2949
2950         Also moved lldb callable debug utility function prototypes from
2951         JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
2952         JSDollarVMPrototype class.  This is so that we can conveniently #include that
2953         file to get the prototypes when we need to call them programmatically from
2954         instrumentation that we add while debugging an issue.
2955
2956         * heap/Heap.h:
2957         (JSC::Heap::storageSpace):
2958         * tools/JSDollarVMPrototype.cpp:
2959         (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
2960         (JSC::ensureCurrentThreadOwnsJSLock):
2961         (JSC::JSDollarVMPrototype::gc):
2962         (JSC::functionGC):
2963         (JSC::JSDollarVMPrototype::edenGC):
2964         (JSC::functionEdenGC):
2965         (JSC::JSDollarVMPrototype::isInHeap):
2966         (JSC::JSDollarVMPrototype::isInObjectSpace):
2967         (JSC::JSDollarVMPrototype::isInStorageSpace):
2968         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
2969         (JSC::ObjectAddressCheckFunctor::operator()):
2970         (JSC::JSDollarVMPrototype::isValidCell):
2971         (JSC::JSDollarVMPrototype::isValidCodeBlock):
2972         (JSC::JSDollarVMPrototype::codeBlockForFrame):
2973         (JSC::functionCodeBlockForFrame):
2974         (JSC::codeBlockFromArg):
2975         (JSC::JSDollarVMPrototype::printCallFrame):
2976         (JSC::JSDollarVMPrototype::printStack):
2977         (JSC::JSDollarVMPrototype::printValue):
2978         (JSC::currentThreadOwnsJSLock): Deleted.
2979         (JSC::gc): Deleted.
2980         (JSC::edenGC): Deleted.
2981         (JSC::isValidCodeBlock): Deleted.
2982         (JSC::codeBlockForFrame): Deleted.
2983         (JSC::printCallFrame): Deleted.
2984         (JSC::printStack): Deleted.
2985         (JSC::printValue): Deleted.
2986         * tools/JSDollarVMPrototype.h:
2987
2988 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
2989
2990         Web Inspector: Improve Support for WeakSet in Console
2991         https://bugs.webkit.org/show_bug.cgi?id=143951
2992
2993         Reviewed by Darin Adler.
2994
2995         * inspector/InjectedScriptSource.js:
2996         * inspector/JSInjectedScriptHost.cpp:
2997         (Inspector::JSInjectedScriptHost::subtype):
2998         (Inspector::JSInjectedScriptHost::weakSetSize):
2999         (Inspector::JSInjectedScriptHost::weakSetEntries):
3000         * inspector/JSInjectedScriptHost.h:
3001         * inspector/JSInjectedScriptHostPrototype.cpp:
3002         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
3003         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
3004         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
3005         Treat WeakSets like special sets.
3006
3007         * inspector/protocol/Runtime.json:
3008         Add a new object subtype, "weakset".
3009
3010 2015-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
3011
3012         HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
3013         https://bugs.webkit.org/show_bug.cgi?id=143947
3014
3015         Reviewed by Darin Adler.
3016
3017         Type profiler has map between PropertyKey (StringImpl*) and offset.
3018         StringImpl* is also used for Symbol PropertyKey.
3019         So equality of hash tables is considered by interned StringImpl*'s pointer value.
3020         To do so, use IdentifierRepHash instead of StringHash.
3021
3022         * runtime/SymbolTable.h:
3023
3024 2015-04-20  Jordan Harband  <ljharb@gmail.com>
3025
3026         Implement `Object.is`
3027         https://bugs.webkit.org/show_bug.cgi?id=143865
3028
3029         Reviewed by Darin Adler.
3030
3031         Expose sameValue to JS, via Object.is
3032         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
3033
3034         * runtime/ObjectConstructor.cpp:
3035         (JSC::objectConstructorIs):
3036         * runtime/PropertyDescriptor.cpp:
3037         (JSC::sameValue):
3038
3039 2015-04-19  Darin Adler  <darin@apple.com>
3040
3041         Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
3042         https://bugs.webkit.org/show_bug.cgi?id=143941
3043
3044         Reviewed by Gyuyoung Kim.
3045
3046         * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
3047         * API/JSCallbackObjectFunctions.h: Ditto.
3048
3049         * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
3050         create function and the constructor and for m_impl.
3051         * API/ObjCCallbackFunction.mm:
3052         (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
3053         class by using RetainPtr<Class>.
3054         (ArgumentTypeDelegate::typeInteger): Use make_unique.
3055         (ArgumentTypeDelegate::typeDouble): Ditto.
3056         (ArgumentTypeDelegate::typeBool): Ditto.
3057         (ArgumentTypeDelegate::typeVoid): Ditto.
3058         (ArgumentTypeDelegate::typeId): Ditto.
3059         (ArgumentTypeDelegate::typeOfClass): Ditto.
3060         (ArgumentTypeDelegate::typeBlock): Ditto.
3061         (ArgumentTypeDelegate::typeStruct): Ditto.
3062         (ResultTypeDelegate::typeInteger): Ditto.
3063         (ResultTypeDelegate::typeDouble): Ditto.
3064         (ResultTypeDelegate::typeBool): Ditto.
3065         (ResultTypeDelegate::typeVoid): Ditto.
3066         (ResultTypeDelegate::typeId): Ditto.
3067         (ResultTypeDelegate::typeOfClass): Ditto.
3068         (ResultTypeDelegate::typeBlock): Ditto.
3069         (ResultTypeDelegate::typeStruct): Ditto.
3070         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
3071         unique_ptr for the arguments to the constructor, m_arguments, and m_result.
3072         Use RetainPtr<Class> for m_instanceClass.
3073         (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
3074         for non-Objective-C object pointer null.
3075         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
3076         the arguments to the constructor and for m_impl.
3077         (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
3078         (skipNumber): Mark this static since it's local to this source file.
3079         (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
3080         explicit adoptPtr since the types in the traits are now unique_ptr. Also use
3081         nullptr instead of nil for JSObjectRef values.
3082         (objCCallbackFunctionForMethod): Tweaked comment.
3083         (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
3084
3085         * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
3086
3087         * heap/GCThread.cpp:
3088         (JSC::GCThread::GCThread): Use unique_ptr.
3089         * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
3090         m_slotVisitor and m_copyVisitor.
3091         * heap/GCThreadSharedData.cpp:
3092         (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
3093
3094         * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
3095
3096 2015-04-19  Benjamin Poulain  <benjamin@webkit.org>
3097
3098         Improve the feature.json files
3099
3100         * features.json:
3101
3102 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3103
3104         Introduce bytecode intrinsics
3105         https://bugs.webkit.org/show_bug.cgi?id=143926
3106
3107         Reviewed by Filip Pizlo.
3108
3109         This patch introduces bytecode level intrinsics into builtins/*.js JS code.
3110         When implementing functions in builtins/*.js,
3111         sometimes we require lower level functionality.
3112
3113         For example, in the current Array.from, we use `result[k] = value`.
3114         The spec requires `[[DefineOwnProperty]]` operation here.
3115         However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
3116         So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
3117
3118         Ideally, reaching here, we would like to use put_by_val_direct bytecode.
3119         However, there's no syntax to generate it directly.
3120
3121         This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
3122         Like @call, @apply, we introduce a new node, Intrinsic.
3123         These are generated when calling appropriate private symbols in privileged code.
3124         AST parser detects them and generates Intrinsic nodes and
3125         BytecodeCompiler detects them and generate required bytecodes.
3126
3127         Currently, Array.from implementation works fine without this patch.
3128         This is because when the target code is builtin JS,
3129         BytecodeGenerator emits put_by_val_direct instead of put_by_val.
3130         This solves the above issue. However, instead of solving this issue,
3131         it raises another issue; There's no way to emit `[[Set]]` operation.
3132         `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
3133         So to implement it precisely, introducing bytecode level intrinsics is necessary.
3134
3135         In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
3136         for `result[k] = value` under builtin JS environment. Instead of that special handling,
3137         use bytecode intrinsics instead. It solves problems and it is more intuitive
3138         because written JS code in builtin works as the same to the usual JS code.
3139
3140         * CMakeLists.txt:
3141         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3142         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3143         * JavaScriptCore.xcodeproj/project.pbxproj:
3144         * builtins/ArrayConstructor.js:
3145         (from):
3146         * bytecode/BytecodeIntrinsicRegistry.cpp: Added.
3147         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3148         (JSC::BytecodeIntrinsicRegistry::lookup):
3149         * bytecode/BytecodeIntrinsicRegistry.h: Added.
3150         * bytecompiler/NodesCodegen.cpp:
3151         (JSC::BytecodeIntrinsicNode::emitBytecode):
3152         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
3153         * parser/ASTBuilder.h:
3154         (JSC::ASTBuilder::makeFunctionCallNode):
3155         * parser/NodeConstructors.h:
3156         (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
3157         * parser/Nodes.h:
3158         (JSC::BytecodeIntrinsicNode::identifier):
3159         * runtime/CommonIdentifiers.cpp:
3160         (JSC::CommonIdentifiers::CommonIdentifiers):
3161         * runtime/CommonIdentifiers.h:
3162         (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
3163         * tests/stress/array-from-with-accessors.js: Added.
3164         (shouldBe):
3165
3166 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3167
3168         Make Builtin functions non constructible
3169         https://bugs.webkit.org/show_bug.cgi?id=143923
3170
3171         Reviewed by Darin Adler.
3172
3173         Builtin functions defined by builtins/*.js accidentally have [[Construct]].
3174         According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
3175         This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.
3176
3177         Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
3178         However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
3179         In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
3180         So in this patch, we check `isBuiltinFunction()` in those places.
3181
3182         * dfg/DFGByteCodeParser.cpp:
3183         (JSC::DFG::ByteCodeParser::inliningCost):
3184         * jit/JITOperations.cpp:
3185         * llint/LLIntSlowPaths.cpp:
3186         (JSC::LLInt::setUpCall):
3187         * runtime/JSFunction.cpp:
3188         (JSC::JSFunction::getConstructData):
3189         * tests/stress/builtin-function-is-construct-type-none.js: Added.
3190         (shouldThrow):
3191
3192 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3193
3194         [ES6] Implement WeakSet
3195         https://bugs.webkit.org/show_bug.cgi?id=142408
3196
3197         Reviewed by Darin Adler.
3198
3199         This patch implements ES6 WeakSet.
3200         Current implementation simply leverages WeakMapData with undefined value.
3201         This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].
3202
3203         And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
3204         Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
3205         methods return false (or undefined for WeakMap.prototype.get)
3206         when a key is not Object instead of throwing a type error.
3207
3208         [1]: https://bugs.webkit.org/show_bug.cgi?id=143919
3209
3210         * CMakeLists.txt:
3211         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3212         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3213         * JavaScriptCore.xcodeproj/project.pbxproj:
3214         * runtime/CommonIdentifiers.h:
3215         * runtime/JSGlobalObject.cpp:
3216         * runtime/JSGlobalObject.h:
3217         * runtime/JSWeakSet.cpp: Added.
3218         (JSC::JSWeakSet::finishCreation):
3219         (JSC::JSWeakSet::visitChildren):
3220         * runtime/JSWeakSet.h: Added.
3221         (JSC::JSWeakSet::createStructure):
3222         (JSC::JSWeakSet::create):
3223         (JSC::JSWeakSet::weakMapData):
3224         (JSC::JSWeakSet::JSWeakSet):
3225         * runtime/WeakMapPrototype.cpp:
3226         (JSC::getWeakMapData):
3227         (JSC::protoFuncWeakMapDelete):
3228         (JSC::protoFuncWeakMapGet):
3229         (JSC::protoFuncWeakMapHas):
3230         * runtime/WeakSetConstructor.cpp: Added.
3231         (JSC::WeakSetConstructor::finishCreation):
3232         (JSC::callWeakSet):
3233         (JSC::constructWeakSet):
3234         (JSC::WeakSetConstructor::getConstructData):
3235         (JSC::WeakSetConstructor::getCallData):
3236         * runtime/WeakSetConstructor.h: Added.
3237         (JSC::WeakSetConstructor::create):
3238         (JSC::WeakSetConstructor::createStructure):
3239         (JSC::WeakSetConstructor::WeakSetConstructor):
3240         * runtime/WeakSetPrototype.cpp: Added.
3241         (JSC::WeakSetPrototype::finishCreation):
3242         (JSC::getWeakMapData):
3243         (JSC::protoFuncWeakSetDelete):
3244         (JSC::protoFuncWeakSetHas):
3245         (JSC::protoFuncWeakSetAdd):
3246         * runtime/WeakSetPrototype.h: Added.
3247         (JSC::WeakSetPrototype::create):
3248         (JSC::WeakSetPrototype::createStructure):
3249         (JSC::WeakSetPrototype::WeakSetPrototype):
3250         * tests/stress/weak-set-constructor-adder.js: Added.
3251         (WeakSet.prototype.add):
3252         * tests/stress/weak-set-constructor.js: Added.
3253
3254 2015-04-17  Alexey Proskuryakov  <ap@apple.com>
3255
3256         Remove unused BoundsCheckedPointer
3257         https://bugs.webkit.org/show_bug.cgi?id=143896
3258
3259         Reviewed by Geoffrey Garen.
3260
3261         * bytecode/SpeculatedType.cpp: The header was included here.
3262
3263 2015-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3264
3265         [ES6] Fix name enumeration of static functions for Symbol constructor
3266         https://bugs.webkit.org/show_bug.cgi?id=143891
3267
3268         Reviewed by Geoffrey Garen.
3269
3270         Fix missing symbolPrototypeTable registration to the js class object.
3271         This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.
3272
3273         * runtime/SymbolConstructor.cpp:
3274
3275 2015-04-17  Basile Clement  <basile_clement@apple.com>
3276
3277         Inline JSFunction allocation in DFG
3278         https://bugs.webkit.org/show_bug.cgi?id=143858
3279
3280         Reviewed by Filip Pizlo.
3281
3282         Followup to my previous patch which inlines JSFunction allocation when
3283         using FTL, now also enabled in DFG.
3284
3285         * dfg/DFGSpeculativeJIT.cpp:
3286         (JSC::DFG::SpeculativeJIT::compileNewFunction):
3287
3288 2015-04-16  Jordan Harband  <ljharb@gmail.com>
3289
3290         Number.parseInt is not === global parseInt in nightly r182673
3291         https://bugs.webkit.org/show_bug.cgi?id=143799
3292
3293         Reviewed by Darin Adler.
3294
3295         Ensuring parseInt === Number.parseInt, per spec
3296         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
3297
3298         * runtime/CommonIdentifiers.h:
3299         * runtime/JSGlobalObject.cpp:
3300         (JSC::JSGlobalObject::init):
3301         * runtime/JSGlobalObject.h:
3302         (JSC::JSGlobalObject::parseIntFunction):
3303         * runtime/NumberConstructor.cpp:
3304         (JSC::NumberConstructor::finishCreation):
3305
3306 2015-04-16  Mark Lam  <mark.lam@apple.com>
3307
3308         Gardening: fix CLOOP build after r182927.
3309
3310         Not reviewed.
3311
3312         * interpreter/StackVisitor.cpp:
3313         (JSC::StackVisitor::Frame::print):
3314
3315 2015-04-16  Basile Clement  <basile_clement@apple.com>
3316
3317         Inline JSFunction allocation in FTL
3318         https://bugs.webkit.org/show_bug.cgi?id=143851
3319
3320         Reviewed by Filip Pizlo.
3321
3322         JSFunction allocation is a simple operation that should be inlined when possible.
3323
3324         * ftl/FTLAbstractHeapRepository.h:
3325         * ftl/FTLLowerDFGToLLVM.cpp:
3326         (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
3327         * runtime/JSFunction.h:
3328         (JSC::JSFunction::allocationSize):
3329
3330 2015-04-16  Mark Lam  <mark.lam@apple.com>
3331
3332         Add $vm debugging tool.
3333         https://bugs.webkit.org/show_bug.cgi?id=143809
3334
3335         Reviewed by Geoffrey Garen.
3336
3337         For debugging VM bugs, it would be useful to be able to dump VM data structures
3338         from JS code that we instrument.  To this end, let's introduce a
3339         JS_enableDollarVM option that, if true, installs an $vm property into each JS
3340         global object at creation time.  The $vm property refers to an object that
3341         provides a collection of useful utility functions.  For this initial
3342         implementation, $vm will have the following:
3343
3344             crash() - trigger an intentional crash.
3345
3346             dfgTrue() - returns true if the current function is DFG compiled, else returns false.
3347             jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
3348             llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.