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.
Implementation-only dependencies may be referenced from internal decls.
When that module is imported as @testable, clients see the internal
decls and may fail accessing them if the transitive implementation-only
dependencies are not loaded.
Let's consider such transtive implementation-only dependencies as
optional for @testable imports. As such, the compiler will attempt to
load them for test targets, and won't fail if the dependency is missing.
We can make these dependencies required for non-public imports, but it
could be project breaking to do so for implementation-only dependencies.
Considering them as optional is a decent compromise.
rdar://79459263
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
Realign the module loading behavior with the one of the package
access-level. If the package name is an empty string, don't accept other
modules with an empty package name as being part of the same module and
don't load package dependencies in such a case.
The previous behavior kept going even after we reported an invalid
swiftmodule. As such it ended up losing the precise invalid reason and
returned Malformed later on.
Weaken the precise tag check at loading swiftmodule to accept binary
modules build by a compiler with a tag where only the last digit is
different. We assume that the other digit in the version should ensure
compiler and stdlib compatibility. If the last digit doesn't match,
still raise a remark.
rdar://105158258
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
`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
For release-management purposes during development, LLDB's embedded Swift
compiler's version number can sometimes be off-by-one in the last digit
compared to the Swift compiler.
This patch restores the old behavior from before 17183629e4.
rdar://101299168
There are a bunch of places where we expect to find a record with a particular record ID/kind in the decls_block and have to bail out if we see something we don’t expect. Add an `InvalidRecordKindError` we can use in this situation to produce a useful error message and adopt it in various places.
This change also makes deserialization errors print the path to the invalid file.
Basic should not be allowed to link Parse, yet it was doing so
to allow Version to provide a constructor that would conveniently
parse a StringRef. This entrypoint also emitted diagnostics, so it
pulled in libAST.
Sink the version parser entrypoint down into Parse where it belongs
and point all the clients to the right place.
Many deserialization failures at this points are caused by archives
installed over the SDK. Let's extend the current error message with a
solution for such a case.
rdar://86280699
Use only the SWIFT_COMPILER_VERSION macro to check for swiftmodules
being written by the same compiler that reads it. In practice, it's the
macro used for release builds of the compiler.
rdar://96868333
Only production compilers should apply the per-SDK restriction on
loading swiftmodules. Use the "is the compiler tagged" information over
a release build to align with the other main swiftmodule loading
restriction accepting only swiftmodules built by the same tag.
Also use an env var SWIFT_DEBUG_FORCE_SWIFTMODULE_PER_SDK to enable
testing this feature in any compilers.
Change the way swiftmodules built against a different SDK than their
clients are rejected. This makes them silently ignored when the module
can be rebuilt from their swiftinterface, instead of reporting a hard
error.
rdar://93257769
When two different serialization formats share a version number but are
different enough, it can defeat the check to restrict loading
swiftmodules built by the same compiler. Add a backup check in case the
REVISION block is unseen, for swiftmodules only not swiftdoc or
sourceinfo.
rdar://93188070
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.
