Add a bit to the module to determine whether the dependency’s stored bit pattern is a hash or an mtime.
Prebuilt modules store a hash of their dependencies because we can’t be sure their dependencies will have the same modtime as when they were built.
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
In addition to capturing more detailed preprocessor info, the
DetailedPreprocessorRecord option sets the clang module format to 'raw'
rather than the default 'object'. Sourcekitd doesn't link the code
generation libs, which it looks like the default 'object' format requires,
so it sets this option to true. The subinvocation generated when loading a
module from a .swiftinterface file still used the default prior to this
change though, so it would end up crashing sourcekitd.
This change sets the DetailedProccessorRecord option if the DetailedRecord
option is set on the preprocessor options of parent context's clang module
loader. This fixes interface generation crashing for modules that only have
a .swiftinterface file.
rdar://problem/43906499
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
The layouts of resilient value types shipped in the Swift 5 standard library
x and overlays will forever be frozen in time for backward deployment to old
Objective-C runtimes. This PR ensures that even if the layouts of these types
evolve in the future, binaries built to run on the old runtime will continue
to lay out class instances in a manner compatible with Swift 5.
Fixes <rdar://problem/45646886>.
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
The LLVM API for the temporary paths behaves differently on Windows and Unix.
Windows always returns the absolute path, and on Unix, you get whatever is in
the environment. Furthermore, windows allows both `\` and `/` as separators.
Normalise the path and make it absolute before doing the comparision to get a
comparable string.
Rather than eagerly doing a bunch of name lookups to establish the known
protocol kind, lazily match the ProtocolDecl to the list of known
protocols as-needed. This eliminates a bunch of up-front unqualified
name lookups when spinning up a type checker.
Previously, we included the PCH hash components in the cache key. While they didn’t do any harm, they didn’t contribute any unique information about the module in question.
Additionally, passing the effective language version in means that each dependency that uses a different -swift-version would re-compile all of its dependencies. This is unfortunate, as that means the standard library is recompiled potentially several times.
Hashing the contents of the interface files is overkill. In practice, size and last modification time are enough to determine if a file has changed on disk, and therefore should be rebuilt.
When -enable-anonymous-context-mangled-names is provided, emit mangled
names as part of the metadata of an anonymous context. This will allow
us to match textual mangled names to the metadata.
This is a backward-compatible ABI extension. Part of rdar://problem/38231646/.
If the frontend is invoked with
-build-module-from-parseable-interface, we might be trying to persist
and distribute the swiftmodule that gets built. In that case, any
dependencies we list might not be relevant.
This probably isn't really the final answer here; what we want is some
way to say /which/ dependencies are relevant, and how they're related
to how the swiftmodule that gets used. Most likely the right answer
here is to limit this to dependencies within the SDK or something.
Otherwise, the top-level compilation gets the benefit of the prebuilt
cache path, but the sub-invocations for swiftinterfaces that /do/
need to be compiled do not.
This is a little trickier than it sounds because we have 'friend'
access into the FrontendInputsAndOutputs structure, which means all
the helpers need to be declared in the header file. But it makes the
two use sites simpler, and does slightly less work in the cache hit
path.
The previous 'openModuleFiles' interface in SerializedModuleLoaderBase
still assumed that swiftmodule files and swiftdoc files would be found
next to each other, but that's not true anymore with
swiftinterfaces-built-to-modules. Give up on this assumption (and on
the minor optimization of passing down a scratch buffer) and split out
the interface into the customization point
'findModuleFilesInDirectory' and the implementation 'openModuleFiles'.
The latter now takes two full paths: one for the swiftmodule, one for
the swiftdoc.
Makes it easier to test the caching behavior, and may also be useful
for "prebuilding" swiftinterfaces in the future, or having the Driver
kick off a bunch of separate builds as proper tasks.
The goal here is to separate the parts that compute an output file
name from the parts that do the actual compilation, so that we can
test the swiftinterface -> swiftmodule behavior more directly. No
functionality change in this commit; the next will take advantage
of the refactoring.
Instead of creating multiple CodeBlockItemList nodes, that need to get merged and discarded later on, do this:
* Ensure for libSyntax parsing that we parse the whole file
* Create top-level CodeBlockItem nodes that we just directly wrap with a single CodeBlockItemList node at the end
The importance of this change will become more obvious later on when we'll decouple syntax parsing from the formation of libSyntax tree nodes.
This was a nice feature when people said "-swift-version 3.1"...
up until we got "-swift-version 4.2" as an actual valid version.
Just drop the special case.
https://bugs.swift.org/browse/SR-8850
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
