SILOptions::EnableSerializePackage info is lost.
SILVerifier needs this info to determine whether resilience
can be bypassed for decls serialized in a resiliently
built module when Package CMO optimization enabled.
This PR adds SerializePackageEnabled bit to Module format
and uses that in SILVerifier.
Resolves rdar://126157356
we only check if the loaded module is built from a package interface. This is
not enough as a binary module could just contain exportable decls if built with
experimental-skip-non-exportable-decls, essentially resulting in content equivalent
to interface content. This might be made a default behavior so this PR requires
a module to opt in to allow non-resilient access by a participating client in the
same package.
Since it affects module format, SWIFTMODULE_VERSION_MINOR is updated.
rdar://123651270
The diagnostics/remarks out of the ModularizationError wrapped in a
TypeError (eg. coming from resolveCrossReference) is otherwise just
dropped but could help better understand C/C++ interop issues.
- Add a flag to the serialized module (IsEmbeddedSwiftModule)
- Check on import that the mode matches (don't allow importing non-embedded module in embedded mode and vice versa)
- Drop TBD support, it's not expected to work in embedded Swift for now
- Drop auto-linking backdeploy libraries, it's not expected to backdeploy embedded Swift for now
- Drop prespecializations, not expected to work in embedded Swift for now
- Use CMO to serialize everything when emitting an embedded Swift module
- Change SILLinker to deserialize/import everything when importing an embedded Swift module
- Add an IR test for importing modules
- Add a deserialization validation test
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Intro the service `diagnoseAndConsumeError` as the ultimate site to drop
deserialization issues we can recover from. It will be used to raise
diagnostics on the issues before dropping them silently.
Move some deserialization error handling services to methods under ModuleFile.
This will give access to the ASTContext and allow to report diagnostics.
Also rename `consumeErrorIfXRefNonLoadedModule` into the more general
`consumeExpectedError` that is more appropriate for future improvements.
The Swift compiler expects the context to remain stable between when a
module is built and loaded by a client. Usually the build system would
rebuild a module if a dependency changes, or the compiler would rebuilt
the module from a swiftinterface on a context change. However, such
changes are not always detected and in that case the compiler may crash
on an inconsistency in the context. We often see this when a clang
module is poorly modularized, the headers are modified in the SDK, or
some clang define change its API.
These are project issues that used to make the compiler crash, it
provided a poor experience and doesn't encourage the developer to fix
them by themselves. Instead, let's keep track of modularization issues
encountered during deserialization and report them as proper errors when
they trigger a fatal failure preventing compilation.
If we have both loaded a swiftdoc, and the decl we
have should have had its doc comment serialized into
it, we can check it without needing to fall back
to the swiftsourceinfo.
This requires a couple of refactorings:
- Factoring out the `shouldIncludeDecl` logic
into `getDocCommentSerializationTargetFor` for
determining whether a doc comment should end up
in the swiftdoc or not.
- Factoring out `CommentProviderFinder` for searching
for the doc providing comment decl for brief
comments, in order to allow us to avoid querying
the raw comment when searching for it. This has the
added bonus of meaning we no longer need to fall
back to parsing the raw comment for the brief
comment if the comment is provided by another decl
in the swiftdoc.
This diff is best viewed without whitespace.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
A @testable import allows a client to call internal decls which may
refer to non-public dependencies. To support such a use case, load
non-public transitive dependencies of a module when it's imported
@testable from the main module.
This replaces the previous behavior where we loaded those dependencies
for any modules built for testing. This was risky as we would load more
module for any debug build, opening the door to a different behavior
between debug and release builds. In contrast, applying this logic to
@testable clients will only change the behavior of test targets.
rdar://107329303
Differentiate `internal` and `fileprivate` imports from
implementation-only imports at the module-wide level to offer a
different module loading strategy. The main difference is for non-public
imports from a module with testing enabled to be loaded by transitive
clients.
Ideally, we would only load transitive non-public dependencies on
testable imports of the middle module. The current module loading logic
doesn't allow for this behavior easily as a module may be first loaded
for a normal import and extra dependencies would have to be loaded on
later imports. We may want to refactor the module loading logic to allow
this if needed.
rdar://106514965
When loading a swiftmodule A, read its package information to tell if
the current client should load A's dependencies imports by a package
import. Only clients belonging to the same package as A should load
those dependencies, clients outside of the package likely don't have
access to those dependencies.
This is specific to swiftmodules as swiftinterfaces never display a
package-only import. Clients are unaware of package dependencies when
building against a swiftinterface.
rdar://106164813
If a module was first read using the adjacent swiftmodule and then
reloaded using the swiftinterface, we would do an up to date check on
the adjacent module but write out the unit using the swiftinterface.
This would cause the same modules to be indexed repeatedly for the first
invocation using a new SDK. On the next run we would instead raad the
swiftmodule from the cache and thus the out of date check would match
up.
The impact of this varies depending on the size of the module graph in
the initial compilation and the number of jobs started at the same time.
Each SDK dependency is re-indexed *and* reloaded, which is a drain on
both CPU and memory. Thus, if many jobs are initially started and
they're all going down this path, it can cause the system to run out of
memory very quickly.
Resolves rdar://103119964.
Introduce a new flag `-export-as` to specify a name used to identify the
target module in swiftinterfaces. This provides an analoguous feature
for Swift module as Clang's `export_as` feature.
In practice it should be used when a lower level module `MyKitCore` is
desired to be shown publicly as a downstream module `MyKit`. This should
be used in conjunction with `@_exported import MyKitCore` from `MyKit`
that allows clients to refer to all services as being part of `MyKit`,
while the new `-export-as MyKit` from `MyKitCore` will ensure that the
clients swiftinterfaces also use the `MyKit` name for all services.
In the current implementation, the export-as name is used in the
module's clients and not in the declarer's swiftinterface (e.g.
`MyKitCore`'s swiftinterface still uses the `MyKitCore` module name).
This way the module swiftinterface can be verified. In the future, we
may want a similar behavior for other modules in between `MyKitCore` and
`MyKit` as verifying a swiftinterface referencing `MyKit` without it
being imported would fail.
rdar://103888618
Currently, ModuleFileSharedCore::fatal() calls abort(), which may be reasonable
in a swift-frontend invocation, but has dire consequences when the Swift
frontend is embedded into another process, for example, LLDB where the abort()
kills the entire debugging session.
This patch introduces a few alternatives to the ModuleFile::fatal() familiy of
functions that instead push a fatal diagnostic to the ASTContext's
DiagnosticsEngine and return an llvm::Error so the error can be roperly
communicated and the ASTContext can be wound down without killing the parent
process.
The transition is not complete, this patch does not yet handle
fatalIfUnexpected(), for example.
This patch is NFC for the Swift compiler: When DebuggerSupport in off
ModuleFile::diagnoseFatal() will still call abort(), but if it is on, the error
will be passed up, together with a pretty stack trace.
rdar://64511878
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
The ObjCMethodLookupTable for protocols was not being serialized and rebuilt on load, so NominalTypeDecl::lookupDirect() on selectors was not working correctly for deserialized types. Correct this oversight.
This class is a perennial source of bugs when we add new type nodes because there is no signal when you forget to update it since it's just comparing record IDs in the switch. Break this class down and add new macros that enforce structural checks and require exhaustiveness at compile time.
This TYPE_LAYOUT(...) macro replaces the usual \c BCRecordLayout coding structure by enforcing structural checks for the definition of deserialization members. If you forget to define a TYPE_LAYOUT(...) for a TYPE(...) there will be a gnarly SFINAE error pointing at it in DeclTypeRecordNodes.def.
This macro pairs with \c DESERIALIZE_TYPE(...) in Deserialization.cpp such that if you forget \c DESERIALIZE_TYPE(...) you will come up with a linker error.
We now schedule conformance emissions in basically the same way
we do for types and declarations, which means that we'll emit them
uniquely in the module file instead of redundantly at every use.
This should produce substantially smaller module files overall,
especially for modules that heavily use generics. It also means
that we can remove all the unfortunate code to support using
different abbrev codes for them in different bitcode blocks.
Requirement lists are now emitted inline in the records that need
them instead of as trailing records. I think this will improve
space usage, but mostly it assists in eliminating the problem
where abbrev codes are shared between blocks.
