Centralize the exportability checking logic for nested functions in the
`DeclExportabilityVisitor` utility. This logic was previously added to SILGen
but there should not be special casing for nested functions at that layer.
In https://github.com/apple/swift/pull/65267 deserialization safety was made
more conservative, allowing deserialization of any protocol and
deserialization of any extension declaring an explicit conformance to any
protocol. We can refine this to only allow deserialization of safe protocols
and deserialization of extensions declaring conformances to safe protocols.
Importantly, though, we must look up all conformances declared by the
extension, not just the explicit ones.
Resolves rdar://114673761
Given a scenario where a public type A, conforms to an internal protocol
B, which conforms to a public protocol C. A conforms indirectly to C
through a protocol that's hidden from the clients.
This is handled in module interface by printing the indirect conformance
of A to C explicitly at the end of the swiftinterface.
We have the same problem with deserialization safety that used to hide
the internal protocols from clients, thus breaking the knowledge of the
indirect dependency. To keep the indirect conformances, let's consider
all protocols as safe and preserve their conformance information.
rdar://105241772
Disabling access control is fundamentally incompatible with
deserialization safety. Let's turn off safety automatically when in use.
This was reported by a few tests:
stdlib/Dictionary.swift
stdlib/Set.swift
stdlib/SetOperations.swift.gyb
stdlib/SwiftNativeNSBase.swift
Clients of a resilient module using opaque types don't need access to
the underlying type unless it's used in an inlinable context. Plus, the
underlying type can reference internal details which can lead to crashes
when they reference implementation-only dependencies. To clean up this
behavior, let's only serialize the underlying type if used by an
inlinable function.
rdar://105128784
Some compilation paths access the opaque return type type by itself
without going through its function. So access to the type must be
protected, otherwise deserialization fails at getting the naming decl
when it's unsafe.
rdar://105085860
Resilient modules with testing enabled expose internal non-resilient
internal types. These types cannot be reliably used by testable clients
if they don't have all of their members known. For this reason, this
disabled deserialization safety in modules when testing is enabled.
rdar://104923020
Deserialization recovery lead the compiler to drop public constructors
overridding internal constructors. This limits the logic to dropping the
overriding relationship instead of the whole constructor. This applies
when the overriden constructor fails to deserialize and only when the
overriding relationship was marked as not affecting ABI.
rdar://104704832
Loading all possible members for the static type AnyObject can trigger
deserialization of members of non-public types. Deserialization safety
should prevent this by refusing to load the members themselves and even
avoid accessing their context.
When writing decls to a swiftmodule files, the serialization logic
evaluates whether the decl will be safe to deserialize. This is inferred
from the access level of the decl, whether it's local, if the module is
built for testing, etc. If the decl in unsafe to deserialize, a record
will be written down before the decl itself in the swiftmodule file.
On the reader side, attempting to deserialize a decl marked as unsafe
raises a deserialization error early. This error is handled by the existing
deserialization recovery logic.
In theory, we want to consider as safe only decls that are actually needed by
the client. Marking as many internal details as possible as unsafe will
prevent more errors. Getting the right scope may require more work in
the future.
This change reflects the behavior of `DeclAttribute.printImpl` that
prints the `override` keyword in a swiftinterface only when the
overriden decl is also public.
This issue was detected when working on deserialization safety by public
overrides of private functions in the following tests:
test/Interpreter/vtables_multifile.swift
test/Interpreter/vtables_multifile_testable.swift
test/SILGen/accessibility_vtables_testable.swift
test/SILGen/accessibility_vtables_usableFromInline.swift
test/SILGen/vtables_multifile.swift
