Checking each module dependency info if it is up-to-date with respect to when the cache contents were serialized in a prior scan.
- Add a timestamp field to the serialization format for the dependency scanner cache
- Add a flag "-validate-prior-dependency-scan-cache" which, when combined with "-load-dependency-scan-cache" will have the scanner prune dependencies from the deserialized cache which have inputs that are newer than the prior scan itself
With the above in-place, the scan otherwise proceeds as-is, getting cache hits for entries still valid since the prior scan.
Typically, access control denies access to member implementations, so the imported interface decl will be used instead. However, in contexts that permit direct access to stored properties—such as accessors, inits, and deinits—their member implementations are accessible; the compiler then relies on a shadowing rule favoring Swift decls over ObjC decls to eliminate the imported interface decl.
However, there are many rules that are higher-priority than the Swift vs. ObjC decls one. In particular, a recent change to availability checking in #77886 caused a higher-priority rule to begin eliminating member implementations which belonged to unavailable extensions. This caused regressions in projects using `@objc @implementation` with classes that are unavailable in Mac Catalyst.
Introduce a fairly high-priority shadowing rule that favors a member implementation over its interface when both are present (i.e. when direct access to storage is permitted).
Fixes rdar://143582383.
This commit removes the guardrails in ImportDecl.cpp:SwiftDeclConverter
that prevent it from importing non-public C++ members. It also
accordingly adjusts all code that assumes generated Swift decls should
be public. This commit does not import non-public inherited members;
that needs its own follow-up patch.
Note that Swift enforces stricter invariants about access levels than C++.
For instance, public typealiases cannot be assigned private underlying types,
and public functions cannot take or return private types. Meanwhile,
both of these patterns are supported in C++, where exposing private types
from a class's public interface is considered feature. As far as I am aware,
Swift was already importing such private-containing public decls from C++
already, but I added a test suite, access inversion, that checks and
documents this scenario, to ensure that it doesn't trip any assertions.
Starting in Swift 6.0, `package` access level and `@_spiOnly` attribute have been increasingly used in import statements.
However, existing import filtering prevented serialization of package APIs that included such decls, leading to a
significant drop in overall serialization. This PR removes these restrictive filters, and allows decls from SDK or system
modules to be included in serialization.
rdar://130788606
Binary module built with Package CMO can be loaded for package-external client
modules which do not have direct access to decls that are serialized_for_package.
Downgrade build-time error to warning when a deserialization error is found for
a decl that should be allowed to access by package-external clients resiliently.
rdar://143800032
Checking whether a declaration is in a `.swiftinterface` is a very common query
that is made somewhat awkward because declarations are not always in source
files. To make these checks more ergonomic, expose a convenience on
DeclContext.
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.
MemberImportVisibility rules should only apply to source code in the main
module. The rules were being applied when resolving witnesses for synthesized
Hashable conformances on CF types imported by ClangImporter, which caused the
lookups to fail and bad conformances to be generated.
Resolves https://github.com/swiftlang/swift/issues/78870 and rdar://142433039.
Representing introduced, deprecated, and obsoleted versions at rest as optional
version tuples is redundant, since the empty version tuple already represents
"version not present".
NFC.
This request will finish type checking an AvailableAttr by resolving its domain
and then enforcing any restrictions that the domain has on the attribute, like
disallowing version specifications.
This change just introduces the request and plumbs it through. NFC.
