op_throw_static_error's use of its first operand should be reflected in DFG BytecodeU...
authormark.lam@apple.com <mark.lam@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 8 May 2017 22:24:29 +0000 (22:24 +0000)
committermark.lam@apple.com <mark.lam@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 8 May 2017 22:24:29 +0000 (22:24 +0000)
commit9eb2815098999046d3d9db908cfe12c38fc335f6
treebbc5614897ab3c5e4c22bfa4c62607d7d98edb3c
parented9300e949d4e685c1c6bdfddf036b5b0b9995dd
op_throw_static_error's use of its first operand should be reflected in DFG BytecodeUseDef as well.
https://bugs.webkit.org/show_bug.cgi?id=171786
<rdar://problem/32051023>

Reviewed by Saam Barati.

JSTests:

* stress/bug-171786.js: Added.

Source/JavaScriptCore:

* bytecode/BytecodeDumper.cpp:
(JSC::BytecodeDumper<Block>::dumpBytecode):
- Fix BytecodeDumper to dump op_throw_static_error correctly.  Previously,
  it was expecting op1 to always be a constant.  r206870 changed it to take a
  variable string as well.

* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
- Fix the bug.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
- Move the Phantom of op1 after the ThrowStaticError node, because technically,
  the ThrowStaticError represents op_throw_static_error, and op_throw_static_error
  uses op1.  In practice, this probably doesn't matter, but let's have the code
  accurately communicate the behavior we're expecting.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@216459 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JSTests/ChangeLog
JSTests/stress/bug-171786.js [new file with mode: 0644]
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/bytecode/BytecodeDumper.cpp
Source/JavaScriptCore/bytecode/BytecodeUseDef.h
Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp