The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems into a
single overlay file system, and using that. To make this possible, we
always initialize the file manager with an overlay file system. In the
clang importer, we then create a new overlay file system, starting with
the one coming from clang, and adding overlays from swift on top.
The motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
The Bitstream part of Bitcode moved to llvm/Bitstream in LLVM. This
updates the uses in swift.
See r365091 [Bitcode] Move Bitstream to a separate library.
This adjusts the runtime library import paths to add the OS/architecture
subdirectory to the path. This allows the use of `-sdk` with the
compiler to target Android and Windows as well (and Linux). The SDK
image is identical to that generated by the current CMake setup without
the host tools. Ideally, we would change the layout for the modules on
other targets to be identical to the Darwin layout which converts to
OS/<module>/architecture.<extension> rather than
OS/architecture/<module>.<extension>.
- Check the target triple at runtime to decide whether to use the fallback.
- Change isInResourceDir to actually check the resource dir.
- Use ArrayRef<std::string> instead of std::vector<std::string>.
Enums have a handful of conformances that are implied by their
structure: Equatable and Hashable if they have no payloads, and
RawRepresentable if they have a raw value. In the spirit of making
implicit things explicit, these should be printed in the module
interface.
rdar://problem/50100142
Previously the module interface printing would scrape the
AvailableAttrs from the containing decl in order to print synthesized
extensions for conformances that wouldn't otherwise be printed...but
that missed the case where a containing lexical scope had the
availability attributes instead. Now it walks up the chain of parent
DeclContexts and collects the most specific AvailableAttr for each
platform.
This /still/ isn't formally correct because it doesn't merge
availability for one platform (if something inside is deprecated
unconditionally but outside has an "introduced" version), but it's
going to match the vast majority of code out there.
Pre-requisite for rdar://problem/50100142
Sometimes, if one module we tried failed, we would leave the dependencies from the previous check and fail a different module which would have succeeded.
This manifested as the prebuilt-module-cache-forwarding test testing the wrong thing, because it retained a mod-time based dependency in the prebuilt cache, which should have been hash based, and used it.
If there’s a `.swiftmodule` corresponding to the `.swiftinterface` we’re loading, but it’s out of date or otherwise unusable, still make it a dependency of the cached module.
The general assumption with cached modules is that, by virtue of them being in the cache, they have a more up-to-date view of the world than the adjacent compiled module. However, if a new `.swiftmodule` comes along that’s totally valid, we should consider it as having a newer view of the world than the cached one, so we should use it instead.
Fixes rdar://51959788
A dependency being removed is not a hard error, because the recovery step is to recompile the interface. That might fail because of the change in dependencies, but that is a more actionable error.
Fixes rdar://51959698
...specifically, diagnosed in the parent DiagnosticEngine. This not
only provides a better user experience, but makes sure that the
compiler exits with a nonzero exit code even if the module goes
unused.
rdar://problem/50789839
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
Add the command line option -require-explicit-availability to detect public
or `@usableFromInline` declarations and warn if they don't declare
an introduction OS version. This option should catch forgotten `@available`
attributes in frameworks where all services are expected to be introduced
by an OS version.
The option -require-explicit-availability-target "macOS 10.14, iOS 12.0"
can be specified for the compiler to suggest fix-its with the missing
attributes `@available(macOS 10.14, iOS 12.0, *)`.
rdar://51001662
There are still cases (a module with a type that's the same name as the
module) where we cannot fully qualify all types. In those cases, allow
them to remain unqualified with a flag, `-Xfrontend
-preserve-types-as-written-in-module-interface`.
This mode is supposed to get all its configuration information from
the switftinterface being read in, but that means that the ASTContext
and ClangImporter that get created by default may not be a sensible
configuration (for example, a mismatched target and SDK, which Clang
emits a warning about). Avoid this by just not creating the ASTContext
if it's already been determined that the frontend is building a module
from a parseable interface.
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
swift-tools-version as used by SwiftPM is an actual, parsed field with
semantic meaning. swift-compiler-version as used when generating
module interfaces is just to record what version of the compiler
generated the interface. They shouldn't have the same name.
@_dynamicReplacement(for: selfRec(x: acc:))
func selfRec_r(x: Int, acc: Int) -> Int {
if x <= 0 {
return acc
}
// Normally, this will call selfRec(x: acc:)'s implementation.
// With the option, this will call to selfRec_r(x: acc:).
return selfRec(x: x - 1, acc: acc + 1)
}
rdar://51229650
This change PCMacro and PlaygroundTransform to return an a moduleID and
fileID in addition to the source location information. The Frontend has
been changed to run PCMacro and PlaygroundTransform on all input files
instead of the main file only.
The tests have been updated to conform to these changes with an addition
of module and file ID specific tests. The Playgrounds related tests were
adjusted to make a module out of the stub interface files since those
files should not have PCMacro and PlaygroundTransform applied to them.
rdar://problem/50821146
This option no longer works but was still in the option file and help
message.
Add a temporary pass-specific option instead for debugging until this
pass has been sufficiently tested yet.
I thought it would be useful to allow some uses of a module to be
'@_implementationOnly' and others to not be in case someone wanted to
change from one to the other gradually, but it turns out that if
you're trying to /make/ an import implementation-only, you want to
know everywhere you used it.
rdar://problem/50748157
Try a little harder to avoid printing empty extensions by seeing if
any of the inherited protocols are actually going to be printed.
Previously this just made things a little prettier, but with
implementation-only imports it's a correctness issue, since there may
be extensions of implementation-only types that do in fact conform to
non-public protocols.
rdar://problem/50748072
Otherwise, we can synthesize an extension that's extending a type
that's unavailable on a particular platform, or that conforms to a
protocol that hasn't been introduced on the minimum deployment target.
Previously, we wouldn't pass this flag to sub-invocations, which means
that if we had to fall back and recompile a transitive import, we
wouldn't get a remark.
rdar://50729662
