Introduce a last resort check reporting references to
implementation-only dependencies that would appear in the generated
swiftmodule. This check is applied at serialization, long after
exportability checking applied at typechecking. It should act as a back
stop to references missed by typechecking or @_implementationOnly decls
that should have been skipped.
This check is gated behind CheckImplementationOnlyStrict and should be
used with embedded only.
rdar://160697599
Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
Whenever we have a reference to a foreign function/variable in SIL, use
a mangled name at the SIL level with the C name in the asmname
attribute. The expands the use of asmname to three kinds of cases that
it hadn't been used in yet:
* Declarations imported from C headers/modules
* @_cdecl @implementation of C headers/modules
* @_cdecl functions in general
Some code within the SIL pipeline makes assumptions that the C names of
various runtime functions are reflected at the SIL level. For example,
the linking of Embedded Swift runtime functions is done by-name, and
some of those names refer to C functions (like `swift_retain`) and
others refer to Swift functions that use `@_silgen_name` (like
`swift_getDefaultExecutor`). Extend the serialized module format to
include a table that maps from the asmname of functions/variables over
to their mangled names, so we can look up functions by asmname if we
want. These tables could also be used for checking for declarations
that conflict on their asmname in the future. Right now, we leave it
up to LLVM or the linker to do the checking.
`@_silgen_name` is not affected by these changes, nor should it be:
that hidden feature is specifically meant to affect the name at the
SIL level.
The vast majority of test changes are SIL tests where we had expected
to see the C/C++/Objective-C names in the tests for references to
foreign entities, and now we see Swift mangled names (ending in To).
The SIL declarations themselves will have a corresponding asmname.
Notably, the IRGen tests have *not* changed, because we generally the
same IR as before. It's only the modeling at the SIL lever that has
changed.
Another part of rdar://137014448.
For clients, such as the debugger, who do not have access the full
output of the dependency scanner, it is a huger performance and
correctness improvement if each explicitly built Swift module not just
serialized all its Clang .pcm dependencies (via the serialized Clang
compiler invocation) but also its direct Swift module dependencies.
This patch changes the Swift module format to store the absolute path
or cas cache key for each dependency in the INPUT block, and makes
sure the deserialization makes these available to the ESML.
rdar://150969755
Remove the DeclContext parameter from ResolveMacroRequest, we can now
retrieve the DeclContext either from the CustomAttr or macro expansion
expr/decl directly.
Add support for the `Swift` availability domain, which represents availability
with respect to the Swift runtime. Use of this domain is restricted by the
experimental feature `SwiftRuntimeAvailability`.
ResultConvention::Guaranteed will be used by borrow accessors when the storage type can be returned by value.
ResultConvention::GuaranteedAddress will be used by mutate accessors and borrow accessors when the storage type
cannot be returned by value.
This PR is another attempt at landing #76903. The changes compared to
the original PR:
* Instead of increasing the size of SILDeclRef, store the necessary type
information in a side channel using withClosureTypeInfo.
* Rely on SGFContext to get the right ClangType
* Extend BridgingConversion with an AbstractionPattern to store the
original clang type.
* The PR above introduced a crash during indexing system modules that
references foreign types coming from modules imported as
implementation only. These entities are implementation details so they
do not need to be included during serialization. This PR adds a test
and adds logic to exclude such clang types in the serialization
process.
rdar://131321096&141786724
Macro search paths are generally absolute paths which will cause
non-deterministic output for build systems that build remotely.
When the -prefix-serialized-debugging-options flag is set remap
the macro search paths as well as the other debug paths.
Introduce an experimental feature DeferredCodeGen, that defers the
generation of LLVM IR (and therefore object code) for all entities
within an Embedded Swift module unless they have explicitly requested
to not be emitted into the client (e.g., with
`@_neverEmitIntoClient`).
This feature is meant to generalize and subsume
-emit-empty-object-file, relying on lazy emission of entities rather
than abruptly ending the compilation pipeline before emitting any IR.
Part of rdar://158363967.
Conditionally available opaque return types should support availability
conditions that are evaluated in any availability domain. Update
`ConditionallyAvailableSubstitutions` to model its conditions with
`AvailabilityQuery` instead of assuming that conditions are always a single
version query for the current platform.
Gracefully handle `LocatableType` types if they show up during
serialization. This is a temporary fix until we can remove
`TransitivelyConformsTo` constraint from the solver which is
the underlying cause of the issue (see https://github.com/swiftlang/swift/pull/82541).
Resolves: rdar://153461854
