Add a new flag to enable package interface loading.
Use the last value of package-name in case of dupes.
Rename PrintInterfaceContentMode as InterfaceMode.
Update diagnostics.
Test package interface loading with various scenarios.
Test duplicate package-name.
It has an extension .package.swiftinterface and contains package decls
as well as SPIs and public/inlinable decls. When a module is loaded
from interface, it now looks up the package-name in the interface
and checks if the importer is in the same package. If so, it uses
that package interface found to load the module. If not, uses the existing
logic to load modules.
Resolves rdar://104617854
I also included changes to the rest of the SIL optimizer pipeline to ensure that
the part of the optimizer pipeline before we lower tuple_addr_constructor (which
is right after we run TransferNonSendable) work as before.
The reason why I am doing this is that this ensures that diagnostic passes can
tell the difference in between:
```
x = (a, b, c)
```
and
```
x.0 = a
x.1 = b
x.2 = c
```
This is important for things like TransferNonSendable where assigning over the
entire tuple element is treated differently from if one were to initialize it in
pieces using projections.
rdar://117880194
This commit just introduces the instruction. In a subsequent commit, I am going
to add support to SILGen to emit this. This ensures that when we assign into a
tuple var we initialize it with one instruction instead of doing it in pieces.
The problem with doing it in pieces is that when one is emitting diagnostics it
looks semantically like SILGen actually is emitting code for initializing in
pieces which could be an error.
A client shouldn't know about the underlying type of an opaque type
unless it can see the body of the naming decl. Attempting to read it can
lead to accessing a hidden dependency and a compiler crash.
This was protected by a check specific to function decls but var decls
and subscripts were not handled. To support them we have to move this
logic to the writer side where we have access to the full
AbstractStorageDecl and write in the swifmodule whether the underlying
type should be visible outside of the module.
rdar://117607906
When building complex projects, there may cases of static libraries
which expose `@inlinable` functions which reference functions from
dynamically linked dependencies. In such a case, we need to consider the
provenance of the `function_ref` when determining the DLL storage for
linkage. We would previously use the deserialised metadata on the
`SILFunction` as there are entities where the `DeclContext` may not be
deserialised. However, this leaves us in a state where we are unable to
determine the actual provenance correctly in some cases. By simply
accessing the parent module directly from the `SILFunction` we ensure
that we properly identify the origin of the function allowing us to
query the DLL storage property. This further allows us to remove the
extra storage required for whether the `SILFunction` is statically
linked.
This type will become the corresponding type that is resolved for an
`InverseTypeRepr`. This kind of type is not expected to appear past type
checking (currently, not even past requirement lowering!).
The Attr.h is shared with SwiftCompilerSources through C++ interop and
C++ interop somehow crashes with libc++'s std::optional. So use legacy
llvm::Optional for now.
Serialization depended on a longstanding bug in NeedsNewVTableEntryRequest: For a member of a non-class, it always returned `true`, not `false`. It turns out this was because serialization was conflating the concepts of vtable entries and witness table entries, so it needed NeedsNewVTableEntryRequest to return true for members of protocols. Untangle this logic so that NeedsNewVTableEntryRequest can be given the logical behavior.
[Explicit Module Builds] Restore prior behavior of consuming `.h` dependencies of binary module dependencies directly, instead of attempting to load their PCH
We only record these dependencies in CAS mode, because we require explicit PCH tasks to be produced for imported header of binary module dependencies. In the meantime, in non-CAS mode loading clients will consume the `.h` files encoded in the `.swiftmodules` directly.
Followup changes to SwiftDriver will enable explicit PCH compilation of such dependenceis, but for the time being restore prior behavior for non-CAS explicit module builds.
Resolves rdar://116006619
In explicit module builds, bridging header is passed directly as a '.pch' input.
Loading clients may not be able to directly import this PCH because it was built against mis-matched dependencies with a different context hash. So instead they should directly injest the '.h' depndency and build it against their own set of dependencies.
