Checking each module dependency info if it is up-to-date with respect to when the cache contents were serialized in a prior scan.
- Add a timestamp field to the serialization format for the dependency scanner cache
- Add a flag "-validate-prior-dependency-scan-cache" which, when combined with "-load-dependency-scan-cache" will have the scanner prune dependencies from the deserialized cache which have inputs that are newer than the prior scan itself
With the above in-place, the scan otherwise proceeds as-is, getting cache hits for entries still valid since the prior scan.
Batch dependency scanning was added as a mechanism to support multiple compilation contexts within a single module dependency graph.
The Swift compiler and the Explicitly-built modules model has long since abandoned this approach and this code has long been stale. It is time to remove it and its associated C API.
Instead of requested action. In implicit builds, implicit interface build sub-invocations inherit their parent invocation's requested action, which the code was failing to detect that we were building an interface, not source, and erroneously resulted in enabling in-package module dependency resolution.
Resolves rdar://143505814
Specifically, this means `-dump-ast-format json` is
incompatible with `-dump-parse`. This is because the JSON
format is meant to export more details about the AST that
require type checking to have been performed.
I'm open to lifting this restriction in the future.
This only takes the existing AST information and writes it as JSON
instead of S-expressions. Since many of these fields are stringified,
they're not ideal for the kind of analysis clients of the JSON format
would want to do. A future commit will update these values to use a
more structured representation.
This failure will most-likely result in the dependency query failure which will fail the scan. It will be helpful if the scanner emitted diagnostic for each such module it rejected to explain the reason why.
Resolves rdar://142906530
The AppKit/UIKit overlay refers to symbols declared via NS_OPTIONS
macro, which is causing issues in C++ language mode due to the macro
definition being different. This teaches the module interface loader to
drop the C++ interop flag when rebuilding the AppKit and UIKit overlay
from its interface.
This is the same fix as #78636, but for different modules.
rdar://143033209
We're not planning on removing the splitter because it is a big win
in some cases, but we want to run it less often since it can also
be a source of overhead. This flag allows us to compare performance
to understand the tradeoffs better.
Parsing for `-enable-upcoming-feature` and `-enable-experimental-feature` is
lenient by default because some projects need to be compatible with multiple
language versions and compiler toolchains simultaneously, and strict
diagnostics would be a nuisance. On the other hand, though, it would be useful
to get feedback from the compiler when you attempt to enable a feature that
doesn't exist. This change splits the difference by introducing new diagnostics
for potential feature enablement misconfigurations but leaves those diagnostics
ignored by default. Projects that wish to use them can specify `-Wwarning
StrictLanguageFeatures`.
Diagnostics may be emitted while parsing command line arguments. This implies
that the options which affect how diagnostics are emitted and presented need to
be parsed first.
Diagnostics are suppressed when parsing swiftinterface files, since the
warnings emitted from compiling the swiftinterface of a dependency would just
be a nuisance. It follows that warnings generated when parsing the arguments in
a swiftinterface file should also be suppressed, but that wasn't happening
because the diagnostic engine of the main compile was used for parsing. Pass
the diagnostic engine of the compiler subinstance instead, and proactively
suppress warnings before parsing begins.
Resolves rdar://142814164.
The CoreGraphics overlay refers to symbols declared via `CF_OPTIONS` macro, which is causing issues in C++ language mode due to the macro definition being different.
This teaches the module interface loader to drop the C++ interop flag when rebuilding the CoreGraphics overlay from its interface.
rdar://142762174
This effects local swift development only and is needed now to use -enable-ossa-modules in local tests that
import Synchronization and Distributed which are non-ossa.
decl being accessed is correct. When this assumption fails due to a deserialization error
of its members, the use site accesses the layout with a wrong field offset, resulting in
UB or a crash. The deserialization error is currently not caught at compile time due to
LangOpts.EnableDeserializationRecovery being enabled by default to allow for recovery of some
of the deserialization errors at a later time. In case of member deserialization, however,
it's not necessarily recovered later on.
This PR tracks whether member deserialization had an error by recursively loading members and
checking for deserialization error, and fails and emits a diagnostic. It provides a way to
prevent resilience bypassing when the deserialized decl's layout is incorrect.
Resolves rdar://132411524
In https://github.com/swiftlang/swift/pull/77156, normalization was introduced
for -target-variant triples. That PR also caused -target-variant arguments to
be inherited from the main compilation options whenever building dependency
modules from their interfaces, which is incorrect. The -target-variant option
must only be specified when compiling a "zippered" module, but the dependencies
of zippered modules are not necessarily zippered themselves and
indiscriminantly propagating the option can cause miscompilation.
The new, more targeted approach to normalizing arm64e triples simply uses the
arch and subarch of the -target argument of the main compile to decide whether
the subarch of both the -target and -target-variant arguments of a dependency
need adjustment.
Resolves rdar://135322077 and rdar://141640919.
