The initial version of the debugger testing transform instruments
assignments in a way that allows the debugger to sanity-check its
expression evaluator.
Given an assignment expression of the form:
```
a = b
```
The transform rewrites the relevant bits of the AST to look like this:
```
{ () -> () in
a = b
checkExpect("a", stringForPrintObject(a))
}()
```
The purpose of the rewrite is to make it easier to exercise the
debugger's expression evaluator in new contexts. This can be automated
by having the debugger set a breakpoint on checkExpect, running `expr
$Varname`, and comparing the result to the expected value generated by
the runtime.
While the initial version of this testing transform only supports
instrumenting assignments, it should be simple to teach it to do more
interesting rewrites.
There's a driver script available in SWIFT_BIN_DIR/lldb-check-expect to
simplfiy the process of launching and testing instrumented programs.
rdar://36032055
This may help us reproduce a failing build when all we have is a build
log, and will become much more important in batch mode when we
/really/ need to know what ended up in what batch.
For now, this doesn't include /output/ filelists, because David's
about to mess with that code anyway to make things better around
supplementary outputs in batch mode. There is one weirdness there,
though, which is that ArgsToFrontendInputsConverter peeks at the
outputs to see whether we're doing single-threaded or multi-threaded
WMO.
This means moving the output path into SupplementaryOutputPaths, and
using the same sort of diagnostic dispatching that serialized
diagnostics use. This is part of what's needed to run the migrator
in batch mode.
