Temporarily disable replaying optimization remarks when cache hit.
Optimization remarks file are not setup to be cached because:
* the write of such files are not going through output backend
* when optimization remarks files are requested, it produces files that
are not intended to be produced in SupplementoryOutputs, which
confuses compiler when storing and loading compilation results, and
causes cache misses all the time when optimization remark file is
reuqested.
Disable optimization remarks for cache replay so it is currently only
produced when compiler actually did the compile locally.
Most of the logic for C++ foreign reference types can be applied to C types as well. Swift had a compiler flag `-Xfrontend -experimental-c-foreign-reference-types` for awhile now which enables foreign reference types without having to enable C++ interop. This change makes it the default behavior.
Since we don't expect anyone to pass `experimental-c-foreign-reference-types` currently, this also removes the frontend flag.
rdar://150308819
It is a maintenance burden and having the legacy driver exist in a simplified state reduces the possibility of things going wrong and hitting old bugs.
This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
It has indirect effects on the accessors, so it shouldn’t matter, but we can defensively redirect the query to the API counterpart anyway.
This was the last `InferredInABIAttr` attribute, so we can now remove all of the infrastructure involved in supporting attribute inference.
The "featues" part was never actually implemented and Swift Driver
is replying on information about arguments, so instead of removing
this mode, let's scope it down to "arguments" to be deprecated in
the future.
This is a replacement for `-emit-supported-features` that prints
all of the upcoming/experimental features supported by the compiler
with some additional meta information in JSON format to stdout.
We decided that using a magic typealias to set the executor factory was better
than using a compiler option. Remove the `-executor-factory` option, and replace
by looking up the `DefaultExecutorFactory` type, first in the main module, and
then if that fails in Concurrency.
rdar://149058236
Currently, the macro plugin options are included as cache key and the
absolute path of the plugin executable and library will affect cache
hit, even the plugin itself is identical.
Using the new option `-resolved-plugin-validation` flag, the macro
plugin paths are remapped just like the other paths during dependency
scanning. `swift-frontend` will unmap to its original path during the
compilation, make sure the content hasn't changed, and load the plugin.
It also hands few other corner cases for macro plugins:
* Make sure the plugin options in the swift module is prefix mapped.
* Make sure the remarks of the macro loading is not cached, as the
mesasge includes the absolute path of the plugin, and is not
cacheable.
rdar://148465899
This commit compares the attributes on the decl inside the `@abi` attribute to those in the decl it’s attached to, diagnosing ABI-incompatible differences. It also rejects many attributes that don’t need to be specified in the `@abi` attribute, such as ObjC-ness, access control, or ABI-neutral traits like `@discardableResult`, so developers know to remove them.
With '-sdk-module-cache-path', Swift textual interfaces found in the SDK will be built into a separate SDK-specific module cache.
Clang modules are not yet affected by this change, pending addition of the required API.
Make `-enable-deterministic-check` a driver option and teach dependency
scanner to propagate the option to explicit module build commmands. This
allows to the option to check every build output from the compiler is
deterministic.
Added an `-executor-factory` argument to the compiler to let you safely
specify the executors you wish to use (by naming a type that returns
them).
Also added some tests of the new functionality.
rdar://141348916
https://github.com/swiftlang/swift/pull/37774 added '-clang-target' which allows us to specify a target triple that only differs from '-target' by the OS version, when we want to provide a different OS version for API availability and type-checking, in order to set a common/unified target triple for the entire Clang module dependency graph, for presenting a unified API surface to the Swift client, serving as a maximum type-checking epoch.
This change adds an equivalent flag for the '-target-variant' configuration, as a mechanism to ensure that the entire module dependency graph presents a consistent os version.
For the options that specifies the output, it should be cache invariant.
Fix the one remaining option that is not correctly labelled and add an
unittest to make sure all the options with output path naming convertion
are correctly marked as CacheInvariant.
rdar://146155049
This patch adds support for emitting the flag
llvm::DINode::FlagAllCallsDescribed when generating LLVM IR from the
Swift compiler to get call-site information for swift source code.
With the acceptance of SE-0458, allow the use of unsafe expressions, the
@safe and @unsafe attributes, and the `unsafe` effect on the for..in loop
in all Swift code.
Introduce the `-strict-memory-safety` flag detailed in the proposal to
enable strict memory safety checking. This enables a new class of
feature, an optional feature (that is *not* upcoming or experimental),
and which can be detected via `hasFeature(StrictMemorySafety)`.
This is required to bootstrap the `-static-stdlib` support for Windows.
With this, we are able to properly build the Swift SDK both dynamically
and statically, which is needed to enable us to make further progress
towards an early swift-driver.
IterableDeclContext::checkDeserializeMemberErrorInPackage recursively checks if
decls and their member decls are deserialized correctly into another module.
This PR adds a check to make sure the inspected decls are from another module,
and provides an opt-in flag to fail fast on deserialization failure if found.
rdar://143830240
Add ability to automatically chaining the bridging headers discovered from all
dependencies module when doing swift caching build. This will eliminate all
implicit bridging header imports from the build and make the bridging header
importing behavior much more reliable, while keep the compatibility at maximum.
For example, if the current module A depends on module B and C, and both B and
C are binary modules that uses bridging header, when building module A,
dependency scanner will construct a new header that chains three bridging
headers together with the option to build a PCH from it. This will make all
importing errors more obvious while improving the performance.
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.
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.
