Until stdlib can be built with noncopyable generics, stdlib types
can appear as ~Escapable and ~Copyable, leading to invalid inference.
Use a flag to test implicit lifetime dependence
Remove `-allow-unstable-cache-key-for-testing` frontend flag. It is a
test only flag when the infrastructure is not ready to write tests for
fully cachable tasks. It is no longer needed after all the related tests
are rewritten to use dependency scanner.
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
The compiler has not supported migrating Swift 3 code to Swift 4 for a long
time. The `-enable-swift3-objc-inference` option and related options were
originally designed to aid that transition and should be deprecated at this
point.
Resolves rdar://120490061
`frontend-parseable-output` related options only affects diagnostics and
should be cache invariant. This also fixes the bug that xcbuild can
sometimes modify this argument from execution pipeline, causing cache
key to change.
rdar://120552768
Now that the diagnostics are automatically errors in Swift 6, we don't need an
`-enable-conformance-availability-errors` flag to control whether unavailable
conformances are diagnosed as errors. Nobody was using the flag so it should be
safe to remove.
Part of rdar://88210812
Currently, `-direct-clang-cc1-module-build` and `-only-use-extra-clang-opts`
have to be passed together for clang importer creation to succeed.
Missing either will result in error. Simplified the swift-frontend flags
by removing `-only-use-extra-clang-opts` and let
`-direct-clang-cc1-module-build` to do both.
This option causes the -experimental-lazy-typecheck and
-experimental-skip-non-exportable-decls options to be inferred from the
presense of -experimental-skip-non-inlinable-function-bodies. This new option
is meant to be a temporary testing aid that allows lazy typechecking to be
tested on projects without full build system support for passing the other
flags to the right jobs.
Resolves rdar://118938251
This lets the flag be emitted in the swiftinterface file of the stdlib
(or other modules with -enable-ossa-modules specified),
so that whenever stdlib is recompiled, -enable-ossa-modules will be on.
Generalize the existing `-playground-high-performance` flag into a set of options that control various aspects of the "playground transformation" in Sema.
This commit adds the first two of those controllable parts of the transform, matching what the existing flag already controls (scope entry/exit and function arguments), but in an extensible way. The intent is for this to be a scalable way to control a larger set of upcoming options.
So instead of a single flag, we represent the playground transform options as a set of well-defined choices, with a new `-playground-option` flag to individually enable or disable those options (when prefixed with "No", the corresponding option is instead disabled). Enabling an already-enabled option or disabling an already-disabled option is a no-op.
For compatibility, the existing `-playground-high-performance` flag causes "expensive" transforms to be disabled, as before. We can also leave it as a useful shorthand to include or exclude new options even in the future, based on their cost. There is a comment on the old function indicating that new code should use the more general form, but it remains for clients like LLDB until they can switch over.
The machinery for implementing the playground options is similar to how `Features.def` works, with a new `PlaygroundOptions.def` that defines the supported playground transform options. Each playground definition specifies the name and description, as well as whether the option is enabled by default, and whether it's also enabled in the "high performance" case.
Adding a new option in the future only requires adding it to `PlaygroundOptions.def`, deciding whether it should be on or off by default, deciding whether it should also be on or off in `-playground-high-performance` mode, and checking for its presence from the appropriate places in `PlaygroundTransform.cpp`.
Note that this is intended to control the types of user-visible results that the invoker of the compiler wants, from an externally detectable standpoint. Other flags, such as whether or not to use the extended form of the callbacks, remain as experimental features, since those deal with the mechanics and not the desired observed behavior.
rdar://109911673
Switch to use clang-include-tree by default for clang module
building/caching when using a CAS. This is the default mode for clang
module and has less issues than CAS file system based implementation.
Rename -experimental-serialize-external-decls only to
-experimental-skip-non-exportable-decls in preparation for the flag being used
to influence more than just serialization.
Resolves rdar://116771543
This change adds the following options to allow for greater control over the compiler's autolinking directive use:
- '-disable-autolink-library': equivalent to an existing '-disable-autolink-framework', this option takes a library name as input and ensures the compiler does not produce an autolink directive '-l<library-name>'.
- '-disable-autolink-frameworks': a boolean disable flag which turns off insertion of autolinking directives for all imported frameworks (of the type '-framework <framework-name>')
- '-disable-all-autolinking': a boolean disable flag which turns off insertion of *any* autolinking directives.
Resolves rdar://100859983
Allow DependencyScanner to canonicalize path using a prefix map. When
option `-scanner-prefix-map` option is used, dependency scanner will
remap all the input paths in following:
* all the paths in the CAS file system or clang include tree
* all the paths related to input on the command-line returned by scanner
This allows all the input paths to be canonicalized so cache key can be
computed reguardless of the exact on disk path.
The sourceFile field is not remapped so build system can track the exact
file as on the local file system.
From being a scattered collection of 'static' methods in ScanDependencies.cpp
and member methods of ASTContext. This makes 'ScanDependencies.cpp' much easier
to read, and abstracts the actual scanning logic away to a place with common
state which will make it easier to reason about in the future.
For chains of async functions where suspensions can be statically
proven to never be required, this pass removes all suspensions and
turns the functions into synchronous functions.
For example, this function does not actually require any suspensions,
once the correct executor is acquired upon initial entry:
```
func fib(_ n: Int) async -> Int {
if n <= 1 { return n }
return await fib(n-1) + fib(n-2)
}
```
So we can turn the above into this for better performance:
```
func fib() async -> Int {
return fib_sync()
}
func fib_sync(_ n: Int) -> Int {
if n <= 1 { return n }
return fib(n-1) + fib(n-2)
}
```
while rewriting callers of `fib` to use the `sync` entry-point
when we can prove that it will be invoked on a compatible executor.
This pass is currently experimental and under development. Thus, it
is disabled by default and you must use
`-enable-experimental-async-demotion` to try it.
This enables one to use varying prefixes when checking diagnostics with the
DiagnosticVerifier. So for instance, I can make a test work both with and
without send-non-sendable enabled by adding additional prefixes. As an example:
```swift
// RUN: %target-swift-frontend ... -verify-additional-prefix no-sns-
// RUN: %target-swift-frontend ... -verify-additional-prefix sns-
let x = ... // expected-error {{This is always checked no matter what prefixes I added}}
let y = ... // expected-no-sns-error {{This is only checked if send non sendable is disabled}}
let z = ... // expected-sns-error {{This is only checked if send non sendable is enabled}}
let w = ... // expected-no-sns-error {{This is checked for a specific error when sns is disabled...}}
// expected-sns-error @-1 {{and for a different error when sns is enabled}}
```
rdar://114643840
This option is designed to be used in conjunction with
`-experimental-lazy-typecheck` and `-experimental-skip-all-function-bodies`
when emitting a resilient module. The emitted binary module should contain only
the decls needed by clients and should contain roughly the same contents as it
would if the corresponding swiftinterface were emitted instead and then built.
This functionality is a work in progress. Some parts of the AST may still get
typechecked unnecessarily. Additionally, serialization does not trigger the
appropriate typechecking requests for some ASTs and then fails due to missing
types.
Resolves rdar://114230586
When `-warn-on-potentially-unavailable-enum-case` was introduced, the build
system was required to invoke `swift-frontend` at artificially low deployment
targets when emitting `.swiftinterface` files for legacy architectures. Because
the deployment target was low, some availability diagnostics needed to be
de-fanged in order to allow module interface emission to succeed. Today, the
build system is able to use the correct deployment target when emitting module
interfaces and the `-warn-on-potentially-unavailable-enum-case` is superfluous,
so deprecate it.
Resolves rdar://114092047
Allow `-typecheck-module-from-interface` using explicit module instead
of building implicit module.
This setups swift-frontend to accept explicit module build arguments and
loading explicit module during verifying. SwiftDriver needs to setup
correct arguments including the output path for swift module to fully
enable explicit module interface check.
Rename `-enable-cas` to `-compile-cache-job` to align with clang option
names and promote that to a new driver only flag.
Few other additions to driver flag for caching behaviors:
* `-compile-cache-remarks`: now cache hit/miss remarks are guarded behind
this flag
* `-compile-cache-skip`: skip replaying from the cache. Useful as a
debugging tool to do the compilation using CAS inputs even the output
is a hit from the cache.
- Renames ExperimentalPlatformCCallingConvention to
PlatformCCallingConvention.
- Removes non-arm calling convention support as this feature is working
around a clang bug for some arm triples which we hope to see resolved.
- Removes misleading MetaVarName from platform-c-calling-convention
argument.
- Replaces other uses of LLVM::CallingConv::C with
IGM.getOptions().PlatformCCallingConvention().
Adds a new swift-frontend flag to allow users to choose which calling
convention is used to make c function calls. This hidden flag is called
`-experimental-platform-c-calling-convention`.
This behavior is needed to workaround rdar://109431863 (Swift-frontend
produces trapping llvm ir for non-trapping sil). The root cause of this
issue is that IRGen always emits c function calls with llvm's default C
calling convention. However clang may select a different (incompatible)
calling convention for the function, eventually resulting--via
InstCombine and SimplifyCFG--in a trap instead of the function call.
This failure mode is most readily seen with the triple
`armv7em-apple-none-macho` when attempting to call functions taking
struct arguments. Example unoptimized ir below:
```llvm-ir
call void @bar([4 x i32] %17, i32 2), !dbg !109
...
define internal arm_aapcs_vfpcc void @bar(
[4 x i32] %bar.coerce, i32 noundef %x)
```
In the future it would be better to use the clang importer or some other
tool to determine the calling convention for each function instead of
setting the calling convention frontend invocation wide.
Note: I don't know for sure whether or not clang should be explicitly
annotating these functions with a calling convention instead of
aliasing C to mean ARM_AAPCS_VFP for this particular combination of
`-target`, `-mfloat-abi`, and `-mcpu`.
Intro a deserialization mode controlled by the flag
`-experimental-force-workaround-broken-modules` to attempt unsafe
recovery from deserialization failures caused by project issues.
The one issue handled at this time is when a type moves from one module
to another. With this new mode the compiler may be able to pick a
matching type in a different module. This is risky to use, but may help
in a pinch for a client to fix and issue in a library over which they
have no control.
