Updating third-party to latest to pull in update SQLite3.8.6
ini-ize the EvalFlags

Summary: Hopefully simple change to get the EvalFlags working with ini.

Reviewed By: @ptarjan

Differential Revision: D1505739
Have FrameState drop state when hitting an unprocessed predecessor.

Summary: Adds a bitvector to FrameState. When FrameState::startBlock is called
with a block that has a predecessor that wasn't previously visited by
this FrameState, then the FrameState resets its state. The entry block
gets marked in IRBuilder::IRBuilder, because we don't call startBlock
when constructing IR in selectRegion.

Also adds a BCMarker field to FrameState::startBlock to match
IRBuilder::startBlock. This helps with building IR, when we can't get
the BCMarker from the block's first instruction.

Reviewed By: @ottoni

Differential Revision: D1499056
Update NEWS for HHVM release "Queen Latifah"

Summary: news

Reviewed By: @ptarjan

Differential Revision: D1503623
Cover third version of freetype include

Summary: On Homebrew, we want

  #include <freetyp2/config/ftheader.h>

Because... Freetype.

Extend CMake/FindFreetype.cmake to check all three places
and set defines accordingly, then use those defines to
include the correct header.

Reviewed By: @ptarjan

Differential Revision: D1504378
Remove use of non-threadsafe strtok()

Summary: Interrestingly, someone decided to use strtok_r() because
the inner call to strtok() would collide.

That's true, of course, but they didn't seem to consider that
strtok() would also collide with any other strtok() in the
same process which might be running at the same time.

For instance, another request in another thread running the same
PHP script.

Let's just go ahead and make both loops be threadsafe, shall we?

Reviewed By: @ptarjan

Differential Revision: D1504531
remove duplicate json test dir

Summary: We had slow/ext_json and slow/json. Keep everything in ext_json
Closes #3471

Reviewed By: @JoelMarcey

Differential Revision: D1501008
Update warning/fatal detection in test runner

Summary: These changed a few months back to match php5

Reviewed By: @JoelMarcey

Differential Revision: D1505836
Updated guzzle framework tests

Summary: Closes https://github.com/facebook/hhvm/pull/3526

Reviewed By: @ptarjan

Differential Revision: D1506193
Updated idiorm tests to 1.5.1

Summary: Closes https://github.com/facebook/hhvm/pull/3527

Reviewed By: @fredemmott

Differential Revision: D1506205
Tweaked the json_schema framework config

Summary: Closes https://github.com/facebook/hhvm/pull/3528

Reviewed By: @ptarjan

Differential Revision: D1506211
Implemented xdebug server jit connecting

Summary: This diff adds an `XDebugHookHandler` that is intended to respond to debugger
hooks. This depends on D1474540. The handler is used used to start the xdebug
server on exceptions if "jit" mode is enabled.

This required exposing the server attaching code. To do this, I've merged the
request local data with the other xdebug globals as thread local members on
`XDebugExtension`. It didn't make sense to have two places for thread local
globals.

Reviewed By: @ptarjan

Differential Revision: D1474688
Fix normalize for `JitA` style config options

Summary: `normalize()` didn't handle the `JitA` case, such as `JitAHotSize`. It would output `hhvm.jit_ahot_size`
instead of `jit_a_hot_size`.

Since this is sort of specialized, and `normalize()` works pretty well for everything else, just
special case this like we did for `mysql`.

Reviewed By: @paulbiss

Differential Revision: D1506492
Merge pull request #3516 from MaideCa/thirdparty_sqlite_386

Updating third-party to latest to pull in update SQLite3.8.6
Implemented xdebug remote command infra, command parsing, and status and run commands

Summary: This diff primarily implements command parsing and the command infra. The
status and run commands were implemented for purposes of testing.

The parsing code (`XDebugServer::parseInput`) was translated from xdebug. This
way there are no inconsistencies between implementations dealing with command
parsing.

This also pulls in the xdebug error codes and stores them in an enum. Error
handling output should be identical to php5 xdebug.

Commands are abstracted into a class `XDebugCommand`. All valid xdebug commands
will be represented as subclasses of this class. They can be constructed from
the client input via `XDebugCommand::fromString`. Subclasses primarily override
`XDebugCommand::handleImpl` to perform the command and output the response,
but there are other functions that can be overridden to control options.

For testing purposes, I implemented the `status` command and the `run` command.
The status command just returns the status of the remote debug server. The
`run` command continues until the next breakpoint or program shutdown.

The server should also now respond properly if the client disconnects.

Reviewed By: @ptarjan

Differential Revision: D1479467
Remove `hhvm.eval.XXX` ini settings

Summary: We don't want `.eval.` in our ini settings (see `config.cpp::normalize()`). Let's get rid of them.

`hhvm.eval.jit` and `hhvm.eval.jit_psuedomain` are already being bound via the `EVALFLAGS() #define` in `runtime-option.cpp`, so that was duplication anyway.

`hhvm.eval.enable_xhp` was being duplicate bound as well. So just removed that duplication.

Reviewed By: @fredemmott

Differential Revision: D1506750
Implemented breakpoint_set

Summary: This diff implements the command breakpoint_set. This depends on D1494622.
This is another massive diff.@ptarjan and I discussed it probably wasn't worth
the time to break up at this point given how crunched we are on time, however.

breakpoint_set is the command used in remote debugging to add a new breakpoint.
See http://xdebug.org/docs-dbgp.php#id1 for a thorough description.

The imortant details are:
* There are line, function entry, function exit, and exception breakpoints.
* You can set "hit conditions". E.g break every x times, after x times, or
  on the xth time
* Breakpoints can be enabled/disabled and can be temporary
* Unmatched breakpoints are stored and then added as new files/classes/functions
  are loaded.

Not implemented:
* Conditions- these will be added when eval support is added
* Breakpoint removal- will add with breakpoint_remove. Added some notes for this

There are some other misc changes in here as well:
* Some commands (such as breakpoint_set) need to fail with xdebug error codes,
  so I exposed the error code enum and added a giant try/catch around the entire
  command handling routine.
* Apparently php5 xdebug allows extra/invalid command arguments without warning
  as long as all the necessary arguments are there. Changed command infra to
  match this.

This took a longer than expected due to:
 1. Bugs getting breakpoints to work in the JIT
 2. The decision to refactor in favor of hphpd-like breaking/flow
 3. This diff is huge and there's a ton of state to manage, fighting bugs took
    longer than previous diffs.

Reviewed By: @ptarjan

Differential Revision: D1497010
Added flow control to debug hooks and implemented xdebug step

Summary: * Added a function `phpDebuggerStepIn` that steps over the current line and into
  function calls. The implementation of this was taken from hphpd and
  translated to be more generic. Again, hphpd has not been refactored to use this
  approach, but it shouldn't be overly difficult to do so.
* Added flags to `RequestInjectionData` indicating if a flow control command is
  active. If it is, the jit flag is turned off.
* Modified `XDebugServer::breakpoint` to work flow control breakpoints.
* `ExecutionContext::m_lastLocFilter` has been renamed to
  `ExecutionContext::m_flowFilter`. This is a much less misleading name, as its
  purpose is simply to filter out locations for flow control commands.
* Added request init and shutdown debug hooks. Debuggers can hook into these
  in order to run code on request init and shutdown, but after everything
  has been intialized. Before, an external debugger would have to start/shutdown
  on the extension's request init or shutdown. This is not desirable as we
  aren't guaranteed everything is initialized at this point.

Reviewed By: @ptarjan

Differential Revision: D1501424
Added step out to debugger hooks and implemented step_out xdebug command

Summary: This diff implements the xdebug commands step_out. It does so by calling the
implemented function `phpDebuggerStepOut`.

I took a different approach than hphpd, I've outlined the core difference
below, but I can go into more detail if necessary. To a user of
`phpDebuggerStepOut` the two approaches would be identical. And my approach
could be used by hphpd as well.

I took a different approach because the addition of the
`phpDebuggerFuncEntryHook` and `phpDebuggerFuncExitHook` allows my approach to
be more general, less complex, and significantly less code. The cost is an extra
check every function exit when a debugger is attached.

The core difference between my approach and hphds is that my approach does not
try to set a breakpoint on the return address of the current function.
This is easy in the simple standard case, but when dealing with nested VM states
in things like generators, things get a lot more complicated. Hphpd
iterates up the stack trying to guess the sucessor to the return opcode in order
to set a breakpoint. Each iteration cases on the type of opcode. If the opcode
allows fallthrough we set a breakpoint on the next opcode, if it is a control flow
opcode a breakpoint set on the destination.

Instead, in my implementation we can check on function exit if the step-out
command is active and if the stack depth has decreased. If so, we then force the
interpreter and and we break on the next valid opcode.

Each of these explanations is simplified, hphpd especially. You can see
hphpd's implementation in `runtime/debugger/cmd/cmd_flow_control` and
`runtime/debugger/cmd/cmd_out`.

This diff also includes the following misc changes:
* Added separator for each section in the debug hooks. The sections already
  existed but I noticed when adding my changes the file was getting hard to
  follow.
* Added `phpDebuggerContinue`, which should be called by debuggers to continue
  execution. It just short-ciruits other commands if they are running.
* Unified the logic deciding if we should force debugger interrupts into
  a method of `RequestInjectionData` instead of duplicating it in
  `debugger-hooks`.

Reviewed By: @ptarjan

Differential Revision: D1502519
Added next command to debugger hooks and implemented step_over xdebug command

Summary: This implements the debugger hook command `phpDebuggerNext` and the xdebug
command `step_over`. These commands are used to step the current line of code,
stepping over function calls if necessary.

Hphpd "next" is, at a high level, a step in and then a step out if our stack
depth has increased. There is a lot of special casing, however, most of which
deals with resumable functions.

When stepping in, hphpd breaks on the next line, or in resumable functions, on
any exit opcode (return, yield, await). This is not used in the "step in" command
in hphpd and results in weird behavior as we are already on the line with
the exit opcode. However, This is used in the next command to determine which
opcode to step to next.

After breaking from a step in, the next command looks at the current opcode and,
if it is an await opcode, it sets a breakpoint on the opcode that will be
executed after the await. On yields it does either a step out or a step to the
next line, whichever happens first. On returns, it does a step out. In all of
these cases, in my implementation at least, simply letting the
step in continue would have achieved the same result: we would break on the next
opcode not on this line, which would be either be at a lower stack depth or at
or the resumed opcode for await/yield.

So my implementation does a step in and then a step out if our stack level has
increased. We maintain the "flow filter" from "step in" into "step out". This
allows us to ensure we break on the next line.

There is no casing over types of opcodes. This results in much simpler code and
empirically it results in in behavior identical to hphpd. I've tried to test this
thoroughly but it's possible I may have missed an edge case. Regardless, edge
cases could be much more easily integrated into this than if I had just pulled
hphpd's code.

Though it'd require an understanding of the hphpd next command in order to
refactor, this could be used by hphpd.

Reviewed By: @ptarjan

Differential Revision: D1502723