Introduces the first use of `@_DebugDescription` in the standard library, applying it
to `ObjectIdentifier`. In order to use the DebugDescription macro in the stdlib, the
following changes are required:
1. Compilation must reference the just built macros (ie `libSwiftMacros.dylib`), not
those from the SDK. This is addressed by adding an explicit `-external-plugin-path`
flag that overrides the defaults generated by the compiler (which uses SDK paths, where
the macro may or may not exist, and may not be the current version).
2. As DebugDescription uses `@_section`, compilation enables the `SymbolLinkageMarkers`
feature.
Note that the use of DebugDescription is conditionally enabled for the following
reasons:
1. Use is disabled in freestanding builds, where the stdlib macros are not built.
2. Use is temporarily disabled in Linux builds due to a dynamic loader issue that needs
further investigation
The dynamic loader error causing issues with Linux CI is:
> swift-plugin-server: error while loading shared libraries: libswiftGlibc.so: cannot
open shared object file: No such file or directory
This PR depended on #71639, #71588, and #71685.
Implementation of the DebugDescription macro pitched on the forums:
https://forums.swift.org/t/pitch-debug-description-macro/67711. In this initial commit,
the macro is named `_DebugDescription` to indicate it's internal use at this time,
pending Swift Evolution.
rdar://115180949
This is the 3rd attempt to fix the mismatch, where the actual definition
(e.g. `swift_retainCount`) are defined with C calling-convention and the
callers wrongly expect Swift calling-convention.
The 1st fix broke ABI compatibility by introducing new symbol references
from app-side without any availability checks.
The 2nd fix broke lldb's retain counting feature due to new x-ref to
Clang module in serialized function body by `@_alwaysEmitIntoClient`.
This attemps to avoid introducing serialized x-ref to Clang module by
using new `@_extern(c)` attribute.
Resolves rdar://113910821
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
The functions `swift_retainCount`, `swift_unownedRetainCount`, and
`swift_weakRetainCount` are declared in `HeapObject.h` as using
the C calling convention, but the Swift declarations referenced them
by `@_silgen_name`, which uses the Swift calling convention. This
patch fixes the mismatch without any ABI/API breakage by calling the
utility functions through C interop.
* Dynamic Cast Rework: Runtime
This is a completely refactored version of the core swift_dynamicCast
runtime method.
This fixes a number of bugs, especially in the handling of multiply-wrapped
types such as Optional within Any. The result should be much closer to the
behavior specified by `docs/DynamicCasting.md`.
Most of the type-specific logic is simply copied over from the
earlier implementation, but the overall structure has been changed
to be uniformly recursive. In particular, this provides uniform
handling of Optional, existentials, Any and other common "box"
types along all paths. The consistent structure should also be
easier to update in the future with new general types.
Benchmarking does not show any noticable performance implications.
**Temporarily**, the old implementation is still available. Setting the
environment variable `SWIFT_OLD_DYNAMIC_CAST_RUNTIME` before launching a program
will use the old runtime implementation. This is only to facilitate testing;
once the new implementation is stable, I expect to completely remove the old
implementation.
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
