For performance annotations we need the generic specializer to trop non-generic metatype argumentrs
(which we don't do in general). For this we need a separate mangling.
Upgrade the old mangling from a list of argument types to a
list of requiremnets. For now, only same-type requirements
may actually be mangled since those are all that are available
to the surface language.
Reconstruction of existential types now consists of demangling (a list of)
base protocol(s), decoding the constraints, and converting the same-type
constraints back into a list of arguments.
rdar://96088707
The layout of constant static arrays differs from non-constant static arrays.
Therefore use a different mangling to get symbol mismatches if for some reason two modules don't agree on which version a static array is.
We currently don't have any tests for remangler error handling, because in
asserts builds it asserts. This patch adds a flag that only exists in !NDEBUG
builds to turn off assertions when inside the unit tests.
Add requirements to the Builder concept to construct generic signatures and substitution maps. Then introduce a `subst` requirement that uses the substitution map to call through to the builder's notion of type (ref) substitution.
This infrastructure is sufficient to model the notion of a RuntimeGenericSignature.
I wrote out this whole analysis of why different existential types
might have the same logical content, and then I turned around and
immediately uniqued existential shapes purely by logical content
rather than the (generalized) formal type. Oh well. At least it's
not too late to make ABI changes like this.
We now store a reference to a mangling of the generalized formal
type directly in the shape. This type alone is sufficient to unique
the shape:
- By the nature of the generalization algorithm, every type parameter
in the generalization signature should be mentioned in the
generalized formal type in a deterministic order.
- By the nature of the generalization algorithm, every other
requirement in the generalization signature should be implied
by the positions in which generalization type parameters appear
(e.g. because the formal type is C<T> & P, where C constrains
its type parameter for well-formedness).
- The requirement signature and type expression are extracted from
the existential type.
As a result, we no longer rely on computing a unique hash at
compile time.
Storing this separately from the requirement signature potentially
allows runtimes with general shape support to work with future
extensions to existential types even if they cannot demangle the
generalized formal type.
Storing the generalized formal type also allows us to easily and
reliably extract the formal type of the existential. Otherwise,
it's quite a heroic endeavor to match requirements back up with
primary associated types. Doing so would also only allows us to
extract *some* matching formal type, not necessarily the *right*
formal type. So there's some good synergy here.
Crash reporter integration was only enabled for iOS. Enable it for
any Darwin platform, but disable it for the minimal build.
Also fix up a couple of issues that popped up when it was enabled.
rdar://89139049
The demangling library can't use the error handling from the main runtime
because it isn't always linked with it. However, it's useful to have
some error handling, and in particular to be able to get data into the
crash logs.
This is complicated because of the way the demangling library gets used,
the upshot of which is that I've had to add a second object library just
for libswiftCore's use, so that the demangler will use the runtime's
error handling functions when present, and fall back on its own when
they aren't.
rdar://89139049
Change `SimplifiedUIDemangleOptions` to remove "partial function" prefixes when demangling async coroutine symbols.
This removes the prefixes "await resume partial function" and "suspend resume partial function" from demangled names, in doing so hides the effect of async/coroutine function splitting from stack traces and other symbolication. This output will produce the source level function name.
For example, a symbol that previously would have demangled to:
```
(1) await resume partial function for static Main.main()
```
will, with this change, demangle to:
```
static Main.main()
```
See https://github.com/apple/swift/pull/36978 where `ShowAsyncResumePartial` was introduced for lldb.
rdar://90455541
Add a few includes of Optional.h and Hashing.h. These files are failing
ot build in the "next" branch due to changes in llvm's own includes, but
it's general goodness to include them on main as well.
* [Distributed] Implement func metadata and executeDistributedTarget
dont expose new entrypoints
able to get all the way to calling _execute
* [Distributed] reimplement distributed get type info impls
* [Distributed] comment out distributed_actor_remoteCall for now
* [Distributed] disable test on linux for now
The `Qr` mangling is used to refer to the opaque type within the
declaration that produces the opaque type. When there are multiple
opaque types, e.g., due to structural or named opaque result types, it
does not specify which of the opaque type parameters it refers to.
Introduce a new mangling `QR INDEX` for opaque type parameters after
the first, retaining the `Qr` mangling for the first opaque type
parameter. This way, existing (non-structural) uses of opaque result
types retain the same manglings, but uses of structural or named
opaque result types (new features) will have distinct manglings.
Note that this mangling within a declaration is only used for the
declaration itself, and not for references to the opaque type of the
declaration, so there is no impact on the runtime demangler.
The internal compiler headers should not include swift shim headers. Removing this dependency allows libSwift to import Swift compiler headers (otherwise, we get name conflics, because we import SwiftShims headers twice: from the source includes and build includes).
Distributed thunks were using the same mangling as direct method
reference thunks (i.e., for "super" calls). Although not technically
conflicting so long as actors never gain inheritance, it's confusing
and could cause problems in the future. So, introduce a distinct
mangling for distributed thunks and plumb them through the demangling
and remangler.
