Add a `-min-runtime-version` option that can be used to avoid problems
when building on Linux and Windows where because the runtime isn't
part of the OS, availability doesn't solve the problem of trying to
build the compiler against an older runtime.
Also add functions to IRGen to make it easy to test feature
availability using both the runtime version and the existing Darwin
availability support.
rdar://121522431
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
Fix the ExplicitCASModuleLoader check for if `canImport` works for a
specific swift module. It was mistakenly using the clang caching schema
to load the underlying module but in reality, it should only load swift
module with swift caching schema.
In future, we should let dependency scanner to report version/underlying
version for the modules it enounters so the versioned canImport check
doesn't need to load and parse the module/TBD file to figure out if the
check is successful or not.
rdar://120554271
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.
A swiftmodule can only be correctly ingested by a compiler
that has a matching state of using or not-using
NoncopyableGenerics.
The reason for this is fundamental: the absence of a Copyable
conformance in the swiftmodule indicates that a type is
noncopyable. Thus, if a compiler with NoncopyableGenerics
reads a swiftmodule that was not compiled with that feature,
it will think every type in that module is noncopyable.
Similarly, if a compiler with NoncopyableGenerics produces a
swiftmodule, there will be Copyable requirements on each
generic parameter that the compiler without the feature will
become confused about.
The solution here is to trigger a module mismatch, so that
the compiler re-generates the swiftmodule file using the
swiftinterface, which has been kept compatible with the compiler
regardless of whether the feature is enabled.
Match up the additional flags in SwiftSources.cmake and
CompilerInvocation.cpp with respect to NoncopyableGenerics.
I think only CompilerInvocation is truly needed, though.
This patch introduces `--enable-experimental-noncopyable-generics` for
the build script. It replaces
`--swift-stdlib-experimental-noncopyable-generics`
The old build option only enables the feature when building the
stdlib, but if we've built the stdlib with NoncopyableGenerics, the
compiler should be hardwired to have that feature enabled, too.
This patch also introduces the `noncopyable_generics` lit parameter, so
that tests assuming the system was built with the feature can live
in-tree and be tested, if they specify `REQUIRES: noncopyable_generics`.
Previously, canImport lookup is not completely working with explicit
module due to two issues:
* For clang modules, canImport check still do a full modulemap lookup
which is repeated work from scanner. For caching builds, this lookup
cannot be performed because all modulemap and search path are dropped
after scanning.
* For swift module, if the canImport module was never actually imported
later, this canImport check will fail during the actual compilation,
causing different dependencies in the actual compilation.
To fix the problem, first unified the lookup method for clang and swift
module, which will only lookup the module dependencies reported by
scanner to determine if `canImport` succeed or not. Secondly, add all
the successful `canImport` check modules into the dependency of the
current module so this information can be used during actual
compilation.
Note the behavior change here is that if a module is only checked in
`canImport` but never imported still needs to be built. Comparing to
implicit module build, this can bring in additional clang modules if
they are only check inside `canImport` but should not increase work for
swift modules (where binary module needs to be on disk anyway) or the
most common usecase for `canImport` which is to check the same module
before importing.
rdar://121082031
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
When loading input from CAS, `swift-frontend` relies on the input file
name to determine the type to look from CAS entry. In the case where
file extension is `.private.swiftinterface`, swift mis-identify that as
`.swiftinterface` file and look up the wrong input file. Add a new
file type lookup function that can figure out the type from the full
filename.
Also add few diagnostics during the CAS lookup for the input file to
error out immediately, rather than rely on the lookup failure later.
Merge `$<Feature>` and `hasFeature` implementations.
- `$<Feature>` did not support upcoming language features.
- `hasFeature` did not support promoted language features and also
didn't take into account `Options` in `Features.def`.
Remove `Options` entirely, it was always one of three cases:
- `true`
- `langOpts.hasFeature`
- `hasSwiftSwiftParser`
Since `LangOptions::hasFeature` should always be used anyway, it's no
longer necessary. `hasSwiftSwiftParser` can be special cased when adding
the default promoted language features (by removing those features).
Resolves rdar://117917456.
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
Diagnose rather than exit when using experimental features that cannot
be enabled in production. Also diagnose if using a compiler without
`SwiftCompilerSources` when enabling embedded.
This is especially important for long-running services like sourcekitd,
which shouldn't exit just because an invalid argument was passed.
Resolves rdar://119724074.
Redirecting file system can canonicalize the file path before forwarding
the path to IncludeTreeFileSystem, which is a simplied FS that can only
intepret the paths that has been seen by dep-scanner. Since all files
that need redirecting already added to underlying FS via DepScan, there
is no need for such layer when compiling using clang-include-tree.
rdar://119727344
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.
Avoid path encoding difference (for example, real_path vs. path from
symlink) by eliminating the path from cache key. Cache key is now
encoded with the index of the input file from all the input files from
the command-line, reguardless if those inputs will produce output or
not. This is to ensure stable ordering even the batching is different.
Add a new cache computation API that is preferred for using input index
directly. Old API for cache key is deprecated but still updated to
fallback to real_path comparsion if needed.
As a result of swift scan API change, rename the feature in JSON file to
avoid version confusion between swift-driver and libSwiftScan.
rdar://119387650
This patch adds a new flag sanitize-stable-abi to support linking
against the Sanitizers stable ABI added recently in compiler-rt. The
patch also passes extra options for the ASan pass when using this flag
to outline instrumentation code and remove version check.
rdar://112915278
