SourceKit-LSP tests depend on the exact behavior of this diagnostic (which I
don't plan to preserve) so I'm reverting the consolidation temporarily to get
unblocked.
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
We use the formal source type do decide whether a checked_cast_br is
known to succeed/fail. If we don't update it we loose that optimization
That is:
```
checked_cast_br AnyObject in %2 : X to X, bb1, bb2
```
Will not be simplified even though the operand and the destintation type
matches.
Batch dependency scanning was added as a mechanism to support multiple compilation contexts within a single module dependency graph.
The Swift compiler and the Explicitly-built modules model has long since abandoned this approach and this code has long been stale. It is time to remove it and its associated C API.
Remove the multiple definitions of `std::bit_cast` into a header. While
this is still not great, it does reduce the duplication. This also
silently works towards reducing a bit of the UB introduced here by
adding an inline namespace for `std` which you are not technically
allowed to use. However, by doing this, we have a clear migration path
away from this once we adopt C++20.
Indexing while building sometimes triggers module deserialization issues, exemplified
by a recent issue of rdar://141357099. This change introduces the blocklist support
to avoid indexing specific module names so we could rely on external data source for
unblocking builds, instead of modifying the compiler source.
Resolves: rdar://143770366
