The current implementation of `-application-extension` has a problem that affects the generation of ObjC headers for regular Swift modules.
The primary purpose of `-application-extension` is to prevent the use of unavailable APIs in app extensions. However, it has an impact on the generation of -Swift.h headers and exposes Swift's internal declarations to ObjC. This behavior is appropriate for mixed modules that are not consumed externally, such as app extensions, but it fails to address the situation when a module is not an extension itself but is consumed by the extension (c90cd11).
To resolve this issue while maintaining the desired behavior, we can introduce a new flag for this particular use-case.
With the growing popularity of using Features, I think it's important to
ensure our Features querying set is as fast as possible. In particular,
we sometimes may end up putting a feature check in a hot function, so
the `contains` overhead is important.
While I haven't done *any* measurements to verify this, I think a
`llvm::SmallSet<Feature, 2>` is slower than a FixedBitSet. For the
former, if the set grows more than the constant size, it switches over
to using a `std::set`. Setting the size to `numFeatures()` is not
particularly attractive or possible, because `SmallSet` is limited to a
size of 32 to be considered small, as it uses linear search over a
SmallVector to service a `contains` query.
Meanwhile, a FixedBitSet has a small constant factor overhead for
querying if the element is contained: two divisions by a
constant power-of-two, a bit shift, and a memory-read / compare. I think
that'll beat a SmallSet in all cases.
Remove the default constructor footgun present with
the struct implementations, and sprinkle some
`SWIFT_NAME` and bridging utilities to make them
nicer to work with.
Merge with BasicBridging and ASTBridging
respectively. The changes here should be pretty
uncontroversial, I tried to keep it to just moving
code about.
Introduce a macro that can stamp out wrapper
classes for underlying C++ pointers, and use
it to define BridgedDiagnosticEngine in
ASTBridging. Then, migrate users of
BridgedDiagEngine onto it.
Previously, inverses were only accounted-for in inheritance clauses.
This batch of changes handles inverses appearing in other places, like:
- Protocol compositions
- `some ~Copyable`
- where clauses
with proper attribution of default requirements in their absence.
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
By default the compiler will now replace the bodies of unavailable functions
with stubs that call `_diagnoseUnavailableCodeReached()` instead.
Resolves rdar://116019744
Introduce the upcoming feature `FullTypedThrows`. When enabled, infer
the error type of a `throw` statement based on its original type,
instead of always being `any Error`. This is technically a
source-breaking change, hence the upcoming feature flag.
Always print the real module name for references in private
swiftinterfaces, ignoring export-as declarations. Keep using the
export-as name for the public swiftinterface only.
The flag `ModuleInterfaceExportAs` used to enable this behavior and
we're removing it to make it the default.
rdar://115922907
Update swift cache key computation mechanism from one cache key per
output, to one cache key per primary input file (for all outputs that
associated with that input).
The new schema allows fewer cache lookups while still preserving most of
the flexibility for batch mode and incremental mode.
Instead of emitting an warning to the diagnostic engine, return the
plugin loading error as the result of the request. So that the user
can decide to emit it as a warning or an error.
This is to match the one SwiftDriver expects, so that we generate API
descriptors when they are specified in supplementary output files.
Addresses rdar://116809713
