-enable-subst-sil-function-types-for-function-values
-enable-large-loadable-types
These defaulted to on, and there were no corresponding flags for
turning them off, so the flags had no effect.
This option allows the compiler to retry opening an input file if the previous
opening returns an error of bad file descriptor. Swift-driver will set this
argument in certain circumstances to walk-around such error.
rdar://73157185
Currently the `-assert-config` flag is not serialized into the module interface. This can cause a subtle issue when rebuilding a Swift module from the corresponding .swiftinterface when the module cache has gone stale.
This change adds `-assert-config` as a module interface option so that
it will be serialized into the header of the .swiftinterface file of the
module.
rdar://72452477
Previously Swift enabled the "UseOdrIndicator" ASan instrumentation mode
and gave no option to disable this. This probably wasn't intentional but
happened due to the fact the
`createModuleAddressSanitizerLegacyPassPass()` function has a default
value for the `UseOdrIndicator` parameter of `true` and in Swift we
never specified this parameter explicitly.
Clang disables the "UseOdrIndicator" mode by default but allows it to be
enabled using the `-fsanitize-address-use-odr-indicator` flag.
Having "UseOdrIndicator" off by default is probably the right
default choice because it bloats the binary. So this patch changes the
Swift compiler to match Clang's behavior.
This patch disables the "UseOdrIndicator" mode by default but adds a
hidden driver and frontend flag (`-sanitize-address-use-odr-indicator`)
to enable it. The flag is hidden so that we can remove it in the future
if needed.
A side effect of disabling "UseOdrIndicator" is that by we will no
longer use private aliases for poisoning globals. Private aliases were
introduced to avoid crashes
(https://github.com/google/sanitizers/issues/398) due to ODR violations
with non-instrumented binaries. On Apple platforms the use of two-level
namespaces probably means that using private aliases wasn't ever really
necessary to avoid crashes. On platforms with a flat linking namespace
(e.g. Linux) using private aliases might matter more but should users
actually run into problems they can either:
* Fix their environment to remove the ODR, thus avoiding the crash.
* Instrument the previously non-instrumented code to avoid the crash.
* Use the new `-sanitize-address-use-odr-indicator` flag
rdar://problem/69335186
Passing the frontend flag -Rmodule-loading makes the compiler emit
remarks with the path of every module loaded. The path for Swift modules
is either the swiftinterface file for modules built with library
evolution or the binary swiftmodule otherwise. The path for clangmodules
is always in the cache which could be improved as it may be less useful.
Here's an extract of the output for a simple SwiftUI app:
<unknown>:0: remark: loaded module from
/Users/xymus/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/2VJP7CNCGWRF0/SwiftShims-18ZF6992O9H75.pcm
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/usr/lib/swift/Swift.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
<unknown>:0: remark: loaded module from
/Users/xymus/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/2VJP7CNCGWRF0/os-1HVC6DNXVU37C.pcm
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/usr/lib/swift/os.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
<unknown>:0: remark: loaded module from
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.2.sdk/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/x86_64-apple-ios-simulator.swiftinterface
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
