In https://github.com/swiftlang/swift/pull/78454 queries for the platform
availability of decl were consolidated into
`Decl::getAvailableAttrForPlatformIntroduction()`. In addition to checking the
attributes directly attached to the decl, this method also checks whether the
decl is a member directly contained inside of an extension and checks for
attributes attached to the extension as well. Previously, this logic was only
used for availability checking diagnostics, where special casing extension
members was a requirement. As a result of the consolidation, though, the logic
is now also shared by the query that determines whether to weakly link symbols
associated with a decl. That determination already had its own way of handling
members of extensions but it seemed like consolidating the logic would stil be
a net improvement that would reduce overall complexity.
Unfortunately, the existing approach to getting the availability of the
enclosing extension had a subtle bug for both AccessorDecl and OpaqueTypeDecl.
If an AvailableAttr was not directly attached to the immediate decl, then
`Decl::getAvailableAttrForPlatformIntroduction()` would check if the enclosing
decl context was an extension and look at its attributes as well. For
AccessorDecl and OpaqueTypeDecl, checking the enclosing decl context would
accidentally skip over the VarDecl and AbstractFunctionDecl that are formally
the parents of those decls for the purposes of attribute inheritance. As a
result, the availability of the enclosing property or function could be ignored
if the enclosing extension had explicit availability attributes.
The fix is to use `AvailabilityInference::parentDeclForInferredAvailability()`
instead of `getDeclContext()` when looking for the immediately enclosing
extension.
Resolves rdar://143139472.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
By default the compiler will now replace the bodies of unavailable functions
with stubs that call `_diagnoseUnavailableCodeReached()` instead.
Resolves rdar://116019744
The use of 'nocapture' for parameters and return values is incorrect for C++ types, as they can actually capture a pointer into its own value (e.g. std::string in libstdc++)
rdar://115062687
When computing linkage, the compiler would treat unavailable declarations as if
they were "always available" when they lack an `introduced:` version:
```
// Library
@available(macOS, unavailable)
public func foo() {
// …
}
// Client
import Library
@available(macOS, unavailable)
func bar() {
// Even though foo() and bar() are unavalable on macOS the compiler still
// strongly links foo().
foo()
}
```
This created an unnecessary dependency between libraries and their clients and
also can interfere with back deployment, since unavailable declarations may not
be present in a library on all OS versions. Developers could work around these
issues by conditionally compiling the code that references an unavailable
declaration, but they shouldn't have to given that unavailable code is meant to
be provably unreachable at runtime. Additionally, it could improve library code
size if we allowed the compiler to strip unavailable declarations from a binary
completely.
Resolves rdar://106673713
If a declaration is unavailable but also has an `introduced:` availability
version, treat that as an indication that it is considered ABI and should be
linked as if it were available.
Part of rdar://106673713
When computing linkage, the compiler would treat unavailable declarations as if
they were "always available" when they lack an `introduced:` version:
```
// Library
@available(macOS, unavailable)
public func foo() {
// …
}
// Client
import Library
@available(macOS, unavailable)
func bar() {
// Even though foo() and bar() are unavalable on macOS the compiler still
// strongly links foo().
foo()
}
```
This created an unnecessary dependency between libraries and their clients and
also can interfere with back deployment, since unavailable declarations may not
be present in a library on all OS versions. Developers could work around these
issues by conditionally compiling the code that references an unavailable
declaration, but they shouldn't have to given that unavailable code is meant to
be provably unreachable at runtime. Additionally, it could improve library code
size if we allowed the compiler to strip unavailable declarations from a binary
completely.
Resolves rdar://106673713
I am separating the concern of weakly linking symbols that are introduced at the deployment target from the concern of type checking this new type of potential unavailability.
Resolves rdar://97925900
When developing a module for an OS or SDK, one may use declarations from other modules that were recently introduced in the in-development OS. Those declarations will be annotated as available at the deployment target of the client module and yet the symbols for that declaration are not available in all development builds of that OS. If the module strongly links those symbols, it will crash on older development builds of the OS. The `-enable-experimental-ad-hoc-availability` flag is designed to give developers the option of weakly linking all symbols in other modules that were introduced at the deployment target.
This change introduces the basic change in linking behavior but does not address typechecking. Use of the declarations that are made unavailable in this mode will need to be diagnosed and developers will need a way to detect the unavailability at runtime before use.
Resolves rdar://96011550
When we generate code that asks for complete metadata for a fully concrete specific type that
doesn't have trivial metadata access, like `(Int, String)` or `[String: [Any]]`,
generate a cache variable that points to a mangled name, and use a common accessor function
that turns that cache variable into a pointer to the instantiated metadata. This saves a bunch
of code size, and should have minimal runtime impact, since the demangling of any string only
has to happen once.
This mostly just works, though it exposed a couple of issues:
- Mangling a type ref including objc protocols didn't cause the objc protocol record to get
instantiated. Fixed as part of this patch.
- The runtime type demangler doesn't correctly handle retroactive conformances. If there are
multiple retroactive conformances in a process at runtime, then even though the mangled string
refers to a specific conformance, the runtime still just picks one without listening to the
mangler. This is left to fix later, rdar://problem/53828345.
There is some more follow-up work that we can do to further improve the gains:
- We could improve the runtime-provided entry points, adding versions that don't require size
to be cached, and which can handle arbitrary metadata requests. This would allow for mangled
names to also be used for incomplete metadata accesses and improve code size of some generic
type accessors. However, we'd only be able to take advantage of the new entry points in
OSes that ship a new runtime.
- We could choose to always symbolic reference all type references, which would generally reduce
the size of mangled strings, as well as make runtime demangling more efficient, since it wouldn't
need to hit the runtime caches. This would however require that we be able to handle symbolic
references across files in the MetadataReader in order to avoid regressing remote mirror
functionality.
