Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
This removes the last reference to the `llvm::` namespace in the
standard library. All uses of the LLVMSupport library now are
namespaced into the `__swift::__runtime` namespace. This allows us to
incrementally vend the LLVMSupport library and make the separation
explicit.
Resolve mangled names containing symbolic references to indirect opaque type descriptors from other
dylibs by demangling the referenced symbol name, like we do for other kinds of context descriptor.
Add an OpaqueArchetypeTypeRef that can represent unresolved opaque types in the Reflection library.
ownsAddress was a simple range check on images, but that won't find Metadatas that get allocated on the heap. If an address isn't found, try reading it as a Metadata and doing a range check on the type context descriptor too.
rdar://problem/60981575
Newer Objective-C runtimes implement a size optimization in class_rw_t
which requires an additional indirection to get to the class_ro_t pointer.
Thanks to Davide for getting to the bottom of this!
Pointer data in some remote reflection targets may required relocation, or may not be
fully resolvable, such as when we're dumping info from a single image on disk that
references other dynamic libraries. Add a `RemoteAbsolutePointer` type that can hold a
symbol, offset, or combination of both, and add APIs to `MemoryReader` and `MetadataReader`
for reading pointers that can get unresolved relocation info from an image, or apply
relocations to pointer information. MetadataReader can use the symbol name information to
fill in demanglings of symbolic-reference-bearing mangled names by using the information
from the symbol name to fill in the name even though the context descriptors are not
available.
For now, this is NFC (MemoryReader::resolvePointer just forwards the pointer data), but
lays the groundwork for implementation of relocation in ObjectMemoryReader.
TypeRefBuilder and MetadataReader had nearly identical symbolic reference resolvers,
but diverged because TypeRefBuilder had its own local/remote address management mechanism,
and because TypeRefBuilder tries to resolve opaque types to their underlying types, whereas
other MetadataReader clients want to preserve them as written in source. The first problem
has been addressed by making TypeRefBuilder use `RemoteRef` everywhere, and the second
can be handled with a flag (and might be able to be handled more elegantly with some more
refactoring of general opaque type handling in MetadataReader).
Instead of passing around raw local pointers and references, and spreading
tricky offset arithmetic around with the Local/RemoteAddress fields in
ReflectionInfo, have the TypeRefBuilder code use RemoteRefs everywhere,
which keep the remote/local mapping together in one unit and provide
centralized API for this logic.
This doesn't yet change how code uses the RemoteRef address data to
follow pointers across objects, for things like reading type refs, but
that should be much easier to do after this lands.
By including the trailing mangled name reference in the baseSize, we computed the wrong offset for
the generic parameter header, and then miscomputed the size of the trailing generic context info.
This would lead to accesses into the context sometimes reading from uninitialized memory.
Fixes rdar://problem/55711107
Resolving a direct relative reference given a RemoteRef doesn't need the MetadataReader,
since the offset should already be in the local buffer; we can add it to RemoteRef's
saved remote address and get a new remote address. Refactor the API to make as much as
possible of it available directly on RemoteRef.
The only thing the Runtime affects is the width of the StoredPointer for the remote address, for
which storing a uint64_t ought to be enough for anyone we care about so far. This will make it
easier to store and use RemoteRefs in code that isn't or shouldn't ideally be templatized on
Runtime (such as TypeRefBuilder, and ultimately ReflectionContext, from the Reflection library.)
This makes for a cleaner and less implicit-context-heavy API, and makes it easier for symbolic
reference resolvers to do context-dependent things (like map the in-memory base address back to a
remote address in MetadataReader).
When building for debug, the opaque return type context is nested under an anonymous context for
the defining function. Demangle the anonymous context name to reconstruct the mangling for the
opaque type.
This is done by disallowing nodes with children to also have index or text payloads.
In some cases those payloads were not needed anyway, because the information can be derived later.
In other cases the fix was to insert an additional child node with the index/text payload.
Also, implement single or double children as "inline" children, which avoids needing a separate node vector for children.
All this reduces the needed size for node trees by over 2x.
An Error existential value can directly store a
reference to an NSError instance without wrapping
it in an Error container.
When "projecting" such an existential, the dynamic type
is the NSError's isa pointer, and the payload is the
address of the instance itself.
Turns out the tags are shuffled around by XORing with a
per-process hash, and we have to deobfuscate the tag
before checking if its an extended tag.
There's no test for this; just running the existing tests
several times in a row is sufficient to trigger the problem.
If resolving the type of an instance produces a class metadata for
which we cannot build a type (for example, a special class like
__NSCFNumber, which the ClangImporter does not produce a ClassDecl
for), we try the superclass.
The caching logic was broken in this case, so subsequent calls
would return an empty type.
