lldb will use it to reimplement `language swift refcount <obj>`
which is currently not working. Asking the compiler allows us
to avoid maintinaing a bunch of information in the debugger which
are likely to change and break.
<rdar://problem/30538363>
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
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
When pretty-printing objects, attempt to expand & print objects which
have the `.class` display style even if they do not have any instance
variables. The pretty-printer will still bail out if the object does not
conform to CustomReflectable.
This is enough to teach the pretty-printer to format bridged NSStrings.
rdar://36843869
Inlining it causes the lldb "po" command to generate a 50KB binary blob that
needs to be injected into the target process. It is much faster to just call
into the standard-library binary.
<rdar://problem/27710066>
Bridging was causing an issue where some value types were being bridged into references and ending up randomly causing collisions which would make certain data not be printed when it should have
Make it so that we only tuck away references we know are natively references for uniqueness purposes
Fixes rdar://problem/27319054
