Moved the test for the metadata kind to MetadataLookup.cpp.
Added an assertion (for debug builds) to Metadata.cpp to catch the case where
something manages to bypass that test.
Added a special test for getObjCClassByMangledName; this needs testing
separately as it uses the DecodedMetadataBuilder, which doesn't get exercised
by the normal demangling tests.
Added all the test cases from rdar://63485806, rdar://63488139, rdar://63496478,
rdar://63410196 and rdar://68449341. The test cases from rdar://63485806 are
disabled for now because the problem there is the error handling mechanism (or
lack thereof), rather than us not handling errors.
Fixes the remaining cases from
rdar://63488139
rdar://63496478
Added SWIFT_RUNTIME_WEAK_IMPORT/CHECK/USE macros.
Everything supports fast dealloc except x86 iOS simulators, so we no longer need
to look up objc_has_weak_formation_callout.
Added direct references for
objc_setHook_lazyClassNamer
_objc_realizeClassFromSwift
objc_setHook_getClass
os_system_version_get_current_version
_dyld_is_objc_constant
Implement name mangling, type metadata, runtime demangling, etc. for
global-actor qualified function types. Ensure that the manglings
round-trip through the various subsystems.
Implements rdar://78269642.
Introduce a second level of standard substitutions to the mangling,
all of the form `Sc<character>`, and use it to provide standard
substitutions for most of the _Concurrency types.
This is a precursor to rdar://78269642 and a good mangling-size
optimization in its own right.
* Move differentiability kinds from target function type metadata to trailing objects so that we don't exhaust all remaining bits of function type metadata.
* Differentiability kind is now stored in a tail-allocated word when function type flags say it's differentiable, located immediately after the normal function type metadata's contents (with proper alignment in between).
* Add new runtime function `swift_getFunctionTypeMetadataDifferentiable` which handles differentiable function types.
* Fix mangling of different differentiability kinds in function types. Mangle it like `ConcurrentFunctionType` so that we can drop special cases for escaping functions.
```
function-signature ::= params-type params-type async? sendable? throws? differentiable? // results and parameters
...
differentiable ::= 'jf' // @differentiable(_forward) on function type
differentiable ::= 'jr' // @differentiable(reverse) on function type
differentiable ::= 'jd' // @differentiable on function type
differentiable ::= 'jl' // @differentiable(_linear) on function type
```
Resolves rdar://75240064.
Take the existing CompatibilityOverride mechanism and generalize it so it can be used in both the runtime and Concurrency libraries. The mechanism is preprocessor-heavy, so this requires some tricks. Use the SWIFT_TARGET_LIBRARY_NAME define to distinguish the libraries, and use a different .def file and mach-o section name accordingly.
We want the global/main executor functions to be a little more flexible. Instead of using the override mechanism, we expose function pointers that can be set by the compatibility library, or by any other code that wants to use a custom implementation.
rdar://73726764
Some ObjC runtime calls are weak or strong depending on the deployment target. When strong, we get warnings that the NULL checks always succeed; silence them.
Some of the adjacent code looked up functions using dlsym when they aren't provided by the SDK. Our current minimum SDK always has them, so remove the dlsym workaround.
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 cleans up some more `llvm::` leakage in the runtime when built into
a static library. With this change we are down to 3 leaking symbols in
the static library related to a missed ADT (`StringSwitch`).
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.
There are a set of headers shared between the Swift compiler and the
runtime. Ensure that we explicitly use `llvm::ArrayRef` rather than
`ArrayRef` which is aliased to `::llvm::ArrayRef`. Doing so enables us
to replace the `ArrayRef` with an inline namespaced version fixing ODR
violations when the swift runtime is loaded into an address space with
LLVM.
Rather than using the forward declaration for the LLVMSupport types,
expect to be able to use the full declaration. Because these are
references in the implementation, there is no reason to use a forward
declaration as the full types need to be declared for use. The LLVM
headers will provide the declaration and definition for the types. This
is motivated by the desire to ensure that the LLVMSupport symbols are
properly namespaced to avoid ODR violations in the runtime.
The demangler tolerates arbitrary suffixes on mangled names, and parses them as a Suffix node. When looking up a class by an ObjC mangled name, we don't want such demanglings to succeed, because this will result in false positives. It's expected that NSClassFromString(someClassName + "some suffix") will fail, unless something has actually created a class with that suffix.
rdar://problem/60012296
use getTypeByMangledName when abstract metadata state is requested
This can significantly reduce the code size of apps constructing deeply
nested types with conditional conformances.
Requires a new runtime.
rdar://57157619
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.
This reverts commit efaf1fbefa.
Add a much more palatable workaround for the unit tests. Rather than
adding the dllimport for the symbols, locally define the required
symbols. This list is sufficient to restore the ability to build tests
for Windows.
The runtime tests will statically link the runtime and dynamically link
to the standard library. This fails to build on Windows. This is a
horrible workaround for the time being.
Mangling these common types takes only two bytes, which is shorter than a symbolic reference. We
know where their metadata is in the standard library, too, so we don't need to search the lookup
tables for them.
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).
We don't want objc_getClass and NSClassFromString to be able to feed arbitrary symbolic reference
pointers into the Swift runtime. Fixes rdar://problem/54724618.
This is a one-to-many cache that's more speculative than the cache mapping mangled names to context descriptors. Entries found in the cache need to be verified for a match before they can be returned. However, this allows scanning conformance records up front and building up the cache in one scan rather than performing an expensive scan of all conformance records every time the mangled name cache misses.
rdar://problem/53560010
When looking for a context descriptor for a protocol extension, we
search based on the mangled name--"x", a generic type parameter with
depth and index 0--and are guaranteed to fail because there is no such
concrete type. However, _findContextDescriptor will fail very slowly,
spinning through all of the types and conformances in all of the
loaded images. Moreover, negative results aren't cached, so this can
happen repeatedly.
Short-circuit _findContextDescriptor when it receives a dependent
generic type parameter type, avoiding the expensive search when it
will find nothing.
Potential fix for rdar://problem/53560010.
Generic parameters for a context are normally classified as "key",
meaning they have actual metadata provided at runtime, or non-key,
meaning they're derivable from somewhere else. However, a nested
context or constrained extension can take what would be a "key"
parameter in a parent context and make it non-key in a child context.
This messes with the mapping between the (depth, index) representation
of generic parameters and the flat list of generic arguments. Fix this
by (1) consistently substituting out extension contexts with the
contexts of the extended types, and (2) using the most nested context
to decide which parameters are key, instead of the context a parameter
was originally introduced in.
Note that (1) may have problems if/when extensions start introducing
their /own/ generic parameters. For now I tried to be consistent with
what was there.
rdar://problem/52364601
