This replaces ArrayInit's vectorInit constructor. When we
know we're making a vector-shaped array, there's no need to
internally use the general array api; ArrayInit provides the
api, internally we do what's fastest.
Differential Revision: D903252
Breakpoints correspond to source lines, not byte code operations, so more than one operation may correspond to a break point. Each operation checks for breakpoints, so breakpoints are disabled when encountered, otherwise commands such as continue and next would get stuck on a line until all the byte code operation for a line have been carried out. Such break points are re-enabled as soon as a byte code for another line is executed. This does not work if no other byte codes are carried out (i.e. if JITted code runs) until control loops back to the disabled break point. Consequently the disable logic now keeps track of the offset of the byte that first triggered disablement. If the break point is still disabled by the time control comes back to that byte code, the break point is temporarily enabled.
Differential Revision: D909092
The debugger's API mode added a lot of extra complexity to the debugger client for minimal value. It also had a bunch of bugs, and unnecessarily tied alternate debugger clients to the command line client implementation. Deleting it.
Differential Revision: D912729
Flow control commands should not evaluate the conditions of conditional breakpoints when enabling and disabling breakpoints during stepping. Also, all breakpoints, rather than just the first matching breakpoint should be enabled/disabled.
A client couldn't break execution during eval. There used to be a lot of barriers to making that right, but I fixed most of them with a previous diff on unifying client-side event loops. Now the only barrier was that a server-side thread processing an interrupt was blocking the signal polling thread by holding a mutex while processing the interrupt. Changed to set a flag to disable polling when starting to process the interrupt (and unsetting it when done), while still synchronizing with the signal polling thread to ensure only one thread is sending the client messages at a time. Added logic to re-enable polling while executing PHP for eval, print, etc. Plumbed the proxy thru to the point where we check the clause on conditional breakpoints, too, since that's the third (and final) place we do this.
The debugger client now accepts feedback from the the debugger server about whether a breakpoint can be hit, absent further loads of files, classes or functions.
Small stepping, which is stepping over sub-expressions (kinda), worked but was a little goofy. The mode was set on the client, passed over with control flow commands, placed on the execution context, then retrieved from there and used by those same flow commands. Removed the execution context part of it, since it was useless, and factored grabbing the offsets into the flow cmds where they belong instead of doing it all the time.
The run cmd also had some notion of small stepping, but you'll note it was never sent over the wire. Nuked that, since it never mattered anyway.
We had two similar-but-different functions for getting a notification from the VM about an exception. Cleaned that up by using the proper one for a thrown exception where appropriate, and moving the old one into a hook (like the other VM->debugger hooks) specifically for error messages.
There were multiple issues with flow control when exceptions occur. Fixed these by ditching the reliance on the exception thrown interrupt and introduce an exception handler interrupt, which indicates control is about to pass to a catch clause. This gives us much better insight into how execution is flowing and how we might need to adjust an in-flight stepping operation.
Currently the debugger prints the line where an exception has been thrown, along with the type exception. Then it prints the source listing of the exception. Then it prints a serialization of the exception, which includes a full stack trace. Since the debugger has a command for printing stack traces, the latter bit information seems completely redundant when stopped in the command line client. This diff suppresses the stack trace in that case. It also suppresses redundant diagnostics that get generated during the debugger's attempt to find and print the source code in response to a list command. Finally, the quit command was too eager to let the client die after notifying the proxy, causing the proxy to get a pipe closed exception rather than the quit command, which often allowed the program to carry on running after the client has already quit. The quit command now waits for an acknowledgement from the proxy before shutting down.
Add reasonable behavior for stepping within continuations (generators). Stepping over a yield now does what one would expect. When the generator is driven from a C++ extension like ASIO, the next logical execution point is after the yield statement, and that's where we'll stop now. When driven from PHP, say in a loop calling send(), the next execution point is in fact the call site of send(), so we go there. Stepping off the end of the generator function, goes to the caller of send(), or the caller of the C++ extension. Stepping _out_ of a generator driven by a C++ extension ensures that we go to the caller and not back into the generator again. The logic for both cases is exactly the same. The difference comes from the fact that we don't actually debug C++ extensions.
This also fixes a long-standing problem where breakpoints would interfere with control flow cmds on the same source line. This caused funny behavior, like taking multiple steps to get off of a breakpoint.
Edwin Smith