This aligns the old driver with the behavior of the new driver.
When building with C++ interop enabled, it's important that we link a
C++ runtime, which is handled by the clang++ driver.
The new driver uses clang++ when linking with C++ enabled, either
through the c++ interoperability mode flag or the experimental C++
interop flag. The old driver only enabled it with the experimental C++
interop flag. This results in the C++ interop tests failing on FreeBSD
and a behavioral difference between what we are testing and what we are
shipping.
This was used a long time ago for a design of a scanner which could rely on the client to specify that some modules *will be* present at a given location but are not yet during the scan. We have long ago determined that the scanner must have all modules available to it at the time of scan for soundness. This code has been stale for a couple of years and it is time to simplify things a bit by deleting it.
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.
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
This is the C++ driver counterpart to a change that landed in the Swift
driver a while ago to use the clang-linker to determine what the default
linker is. This is to avoid hard-coding gold, which is deprecated and
not available on some newer Linux distributions. The challenge is that
these newer Linux distributions don't already have Swift so we have to
use the old C++ driver implementation.
To work-around #80059, we need to stop return address signing and
opt-out of BTCFI enforcement via enabling a platform linker option.
We don't want to completely undo the BTCFI work in the rare case that
we later figure out how to properly address the above issue, or allow
users who might want to benefit from BTCFI enforcement and won't use
Concurrency. To do this, condition the existing BTCFI flag enforcement
into a configuration option that defaults to off for now.
Because the new swift-driver needs to "know" whether the frontend is
configured to opt-out or not, and since the new driver communicates with
the frontend via the target info JSON to begin with, we add a field
that emits the build flavor to signal the right behavior.
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
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.
BTI enforcement is mandatory, which means if PAC and BTI instructions
are not emitted, then the compiled binary gets killed with SIGILL. The
platform default compiler achieves enabling PAC and BTI by embedding the
relevant enabled Clang compilation option flags into the local platform
toolchain, which affects C/C++ code generation.
For Swift however, to achieve the same effect, we would need to add the
relevant LLVM module flags in the IRGen process. But, since Swift uses
the Clang code generator when doing this, using the same option flag
approach will work here as well, and is probably preferable to
introducing operating system-dependent logic to the ClangImporter, for
example.
Finally, the stdlib needs to be built with PACBTI as well, since the
stdlib's global constructors get run when a compiled binary does. Since
the Swift build uses the just-built Clang for the stdlib, just embed the
necessary options into `CMAKE_C_FLAGS` and `CMAKE_CXX_FLAGS` via
`build-script-impl`. This will be redundant with the host compiler, but
at least it will be thorough.
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.
Add a -nostdlibimport (analagous to clang's -nostdlibinc) to remove the SDK paths from the import search paths, but leave the toolchain paths.
rdar://139322299
The symbol graph output from a module can contain an arbitrary number of
files, depending on what extensions it contains, so cache a list of
symbol graph files with their base name and contents so that they can be
replayed.
rdar://140286819
CAS support in compiler relies on supplementary paths to decide the mapping between input and output files. Therefore, we
have to compute the paths of the module ObjC trace files in this canonical place to have CAS support for
this newly added ObjC message trace files.
The legacy driver is still used to build the compiler on Windows, so we need it
to handle these new flags correctly in order to adopt them in the stdlib.
