This frontend flag can be used as an alternative to
-experimental-skip-non-inlinable-function-bodies that doesn’t skip
functions defining nested types. We want to keep these types as they are
used by LLDB. Other functions ares safe to skip parsing and
type-checking.
rdar://71130519
Adds a new frontend option
"-experimental-allow-module-with-compiler-errors". If any compilation
errors occur while generating the .swiftmodule, this mode will skip SIL
entirely and only serialize the (likey invalid) AST.
This existence of this option during generation is serialized into the
resulting .swiftmodule. Errors found in deserialization are only allowed
if it is set.
Primarily intended for IDE requests (eg. indexing and code completion)
to ensure robust cross-module results, despite possible errors.
Resolves rdar://69815975
Adds a new flag "-experimental-skip-all-function-bodies" that skips
typechecking and SIL generation for all function bodies (where
possible).
`didSet` functions are still typechecked and have SIL generated as their
body is checked for the `oldValue` parameter, but are not serialized.
Parsing will generally be skipped as well, but this isn't necessarily
the case since other flags (eg. "-verify-syntax-tree") may force delayed
parsing off.
If a conformance is defined in an extension, we now look for
references to the conformance in types and expressions and
respect's the extension's availability (or deprecation, etc).
The conformance checker itself still needs to check conformance
availability of associated conformances and the like; that will
be a separate change.
Note that conformances defined on types don't require any
special handling, since they are as available as the
intersection of the conforming type and the protocol.
By default, we diagnose conformance availability violations
where the OS version is not sufficiently new as warnings, to
avoid breaking source compatibility. Stricter behavior where
these violations are diagnosed as errors is enabled by passing
the -enable-conformance-availability-errors flag. There are
test cases that run both with and without this flag. In the
future, we hope to make the stricter behavior the default,
since after all, violations here can result in link errors and
runtime crashes.
Uses of completely unavailable conformances are still always
diagnosed as errors, even when this flag is not passed in.
Progress on <rdar://problem/35158274>.
Introduce availability macros defined by a frontend flag.
This feature makes it possible to set the availability
versions at the moment of compilation instead of having
it hard coded in the sources. It can be used by projects
with a need to change the availability depending on the
compilation context while using the same sources.
The availability macro is defined with the `-define-availability` flag:
swift MyLib.swift -define-availability "_iOS8Aligned:macOS 10.10, iOS 8.0" ..
The macro can be used in code instead of a platform name and version:
@available(_iOS8Aligned, *)
public func foo() {}
rdar://problem/65612624
Cross-Module incremental dependencies are a new experimental mode of the Swift driver and frontend. Through a tight partnership between the two, we enable the driver to have far greater visibility into the dependency structure of a Swift module.
Rather than invent a new model, we have chosen to extend the existing incremental compilation model that works for a single module to multiple modules. To do this, we need the frontend to emit Swift dependencies in a form the driver can consume. We could emit these metadata in the form of an extra supplementary output that summarizes the contents of a generated module. However, this approach comes with a number of downsides:
- It requires additional integration with the build system
- It assumes swiftmodule files will be consumed directly from the build directory; they are not
- It incorrectly assumes a swiftmodule has but one interface. Taken in aggregate, a swiftmodule directory has one interface *per triple*
Given this, the approach we take here is to encode these dependencies directly into the swiftmodule file itself. When frontends load these souped-up incremental swiftmodule files, they record in their own swiftdeps files that they depend on an incremental swiftmodule. Upon the next build, the driver is then able to read that module file, extract the swiftdeps information from it, and use it to influence the way it schedules jobs.
The sum total is that we neatly extend the intra-module case of incremental builds to the inter-module case by treating swiftmodule inputs not as opaque entities, but as "big ol' flat Swift files" that just export an interface like any other Swift file within the module. As a further optimization, and because clients literally cannot observe this aspect of the incremental build, we only serialize the provides (the "defs" side of a "use-def" edge) when emitting swiftdeps metadata into swiftmodule files.
rdar://69595010
With this option enabled, the dependency scanner gathers all import statements in source files of the main module (non-transitive) and outputs a list of imported modules.
This will be used by build systems and the swift-driver as a way to avoid redundant re-scanning in incremental contexts.
Specifically the option: -sil-stop-optzns-before-lowering-ownership. This makes
it possible to write end-to-end tests on OSSA passes. Before one would have to
pattern match after ownership was lowered, losing the ability to do finegrained
FileCheck pattern matching on ossa itself.
This scanning mode allows swift-driver to query module dependencies in a batch
and in a more granular way. In short term, it could help solve a problem that
clang module dependencies may vary if target triple changes. In a longer term,
we could break a holistic dependencies graph into smaller pieces for better caching
and reusing.
This change doesn't include the implementation of using the specified scanner
arguments to set up Clang dependencies scanner. It will come in later commits.
For the issue mentioned in rdar://67079780, swift-driver needs to run clang dependencies
scanner multiple times with different target triples for a Swift target. This patch adds
a new scanning action to generate the JSON file for a given clang module to accommodate
this requirement.
Resolves: rdar://problem/67269210
The driver can now schedule jobs which typecheck just-emitted module interfaces to ensure that they can be consumed later. This can be enabled manually by passing `-verify-emitted-module-interface` to the driver.
Add a debugging mechanism that enables the JIT to dump the LLVM IR and
object files to enable debugging the JIT. This makes it easier to debug
the JIT mode failures. The idea was from Lang Hames!
