Given any heap object, this method dumps:
* The pointer address of the heap object.
* The pointer address of the heap metadata of the object.
* The strong reference count.
* The unowned reference count.
* The weak reference count.
* Whether or not the value is in the deinit state.
* Whether or not the heap object uses swift_retain or objc_retain.
* The address of the object's side table if one exists.
This makes it really easy when debugging quickly to get all of the information
that you could possibly need from a HeapObject.
`_typeByMangledName` could encounter types which have ownership attributes
associated with them which are not representable by the metadata object
but nevertheless are important, so such ownership information should be
returned along with metadata itself from the call.
When evaluating whether a given type conforms to a protocol, evaluate the
conditional requirements and pass the results to the witness table
accessor function. This provides the ability to query conditional
conformances at runtime, and is the last major part of implementing
SE-0143.
The newly-added unlock/lock dance in the conformance lookup code is a
temporary stub. We have some ideas to do this better.
Fixes rdar://problem/34944655.
The default attribute on the section is read/write. This would cause
the section to have different attributes when compiled. The linker
would then preserve the section rather than merge it into the right
location. This was noticed when linking with `link.exe`.
The Windows constructor was not populated properly, with the protocol
list being dropped. Ensure that all the fields are initialised
properly. Thanks to clang's `-Wmissing-field-initializers` warning to
help catch this.
On windows, we create synthetic markers with grouping identifiers to
ensure that the markers are sorted properly and merged. We would
previously mark the section as read/write rather than read-only causing
warnings when linking. Correct the attributes. This ensures the proper
linking of the modules.
Extend the runtime's ability for evaluating generic requirements to
handle same-type requirements, demangling/substituting the name from
the generic requirement metadata.
Extend the support for mangled-name-to-type-metadata's handling of generic
types to handle nested types, including gathering type arguments from
parent contents and checking generic requirements.
Extend support for mapping a mangled name -> type metadata to include
support for checking protocol conformance requirements, using the
encoding of generic requirements that is now available within context
descriptors. For example, this allows
_typeByMangledName(mangled-name-of-Set<Int>) to construct proper type
metadata, filling in the Int: Hashable requirement as appropriate.
We dump the following information:
1. The Kind.
2. Pointer to the value witnesses.
3. Pointer to the class object if one is available.
4. Pointer the type context description if one is available.
5. Pointer to the generic arguments if one is available.
This makes it significantly easier to poke around Metadata.
rdar://34222540
This is useful when trying to track down data corruption in the runtime. I am
currently running into such issues with the +0-all-arg work, so I am adding
stuff like this to help debug this issue and future such issues.
rdar://34222540
Some of the free functions have method like names, so it is impossible to know
whether or not the given functions use the method convention or the thin
convention. At least now it is documented.
rdar://34222540
This new format more efficiently represents existing information, while
more accurately encoding important information about nested generic
contexts with same-type and layout constraints that need to be evaluated
at runtime. It's also designed with an eye to forward- and
backward-compatible expansion for ABI stability with future Swift
versions.
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
This mainly was just removing #if{,n}def in favor of SWIFT_CC_* macros. But I
did add a missing retain needed in swift_StructMirror_subscript since owner is
no longer passed at +1 and mirrors consume the owner.
rdar://34222540
clang is miscompiling some swiftcall functions on armv7s.
Stop using swiftcall in some places until it is fixed.
Reverts c5bf2ec (#13299).
rdar://35973477
