Introduce flags `-enable-actor-data-race-checks` and
`-disable-actor-data-race-checks` to enable/disable emission of code
that checks that we are on the correct actor. Default to `false` for
now but make it easy to enable in the future.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
If the driver is only set up to get the frontend invocation (e.g. from sourcekitd), don't validate that we can link against ARCLite because
a) we don't care about link-time when we are only interested in the frontend invocation
b) finding arclite might cause us to find clang using xcrun which in turn can cause sourcekitd to hang.
rdar://50659268
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
The frontend supports this via new options -index-unit-output-path and
-index-unit-output-path-filelist that mirror -o and -output-filelist. These are
intended to allow sharing index data across builds in separate directories (so
different -o values) that are otherwise equivalent as far as the index data is
concerned (e.g. an ASAN build and a non-ASAN build) by supplying the same
-index-unit-output-path for both.
This change updates the driver to add these new options to the frontend
invocation 1) when a new "index-unit-output-path" entry is specified for one
or more input files in the -output-file-map json or 2) if -index-file is
specified, when a new -index-unit-output-path driver option is passed.
Resolves rdar://problem/74816412
To help support incremental adoption of the concurrency model, a number
of concurrency-related diagnostics are enabled only in "new" code that
takes advantage of concurrency features---async, @concurrent functions,
actors, etc. This warning flag opts into additional warnings that better
approximate the eventual concurrency model, and which will become
errors a future Swift version, allowing one to both experiment with
the full concurrency model and also properly prepare for it.
In the legacy driver, these flags will merely be propagated to the
frontends to indicate that they should disable serialization of
incremental information in swift module files.
In the new driver, these flags control whether the Swift driver performs
an incremental build that is aware of metadata embedded in the module.
Kudos to David for coming up with our new marketing name: Incremental
Imports.
rdar://74363450
Add a new swift-frontend driver option that extract APIs in the swift
module and print in JSON format. This is to allow tooling to understand
and process swift APIs without the need to be a swift compiler or
understand swift module/AST.
Unlike the frontend, the driver doesn't account for any VFS overlays set up
by the -vfsoverlay option when processing its input files. It also errors
if any of those input files don't exist on the file system. This makes it
impossible to use a file that only exists in the VFS as input to the driver,
even though the same file would be handled without issue by the frontend.
If the file doesn't exist even accounting for the VFS the frontend emits
a missing file diagnostic, so this change just suppresses the existence
check for inputs when a -vfsoverlay option is present.
Resolves rdar://problem/72485443
We've seen bad file descriptor errors in certain build environments (rdar://73157185) and retrying
opening those files seems to be a walkaround. In this change, we allow the
compiler to retry expanding reponse files in argument lists.
rdar://73892564
Remove this distinction without a difference. Originally, the thought
was to
1) Isolate the cross-module build infrastructure
2) Provide a signal to the driver that a dependency had swiftdeps info
in it
But the driver need only notice swiftmodule files as external
dependencies and try to extract that information if it can to divine the
signal it needs. Additionally, we can give it fingerprints as priors to
let it know there might be incremental info to be had.
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
Introducing new entry-points that can be used from both Driver and Frontend clients, using an intermediary new type: `DetailedMessagePayload`, when needed.
VS2017 seems to have problems with ternaries where the two branches are
given as std::move() (see https://stackoverflow.com/questions/53374182)
and the compiler was given a warning C4172 "returning address of local
or temporary".
Switching the ternary operator into a `if/else` works correctly for
VS2017 and should work for other compilers too, without changing the
meaning (as far as I see).
This was causing the Windows VS2017 CI to fail compiling the stdlib.
When bisecting, the problem was reduced to the changes in #35034. In a
debugger I managed to see the problem being a heap corruption. With all
the moves I was suspicious that something was being used while
destroyed, but the code was correct. While recompiling the compiler
warning gave me the clue.
Starting at a crude -1000, each invocation primary input will get its own unique quasi-Pid.
Invocations with only one primary (non-batch) will get a real OS Pid.
The selection of the constant starting point matches what the driver does when outputting its parseable output.
We're going to play a dirty, dirty trick - but it'll make our users'
lives better in the end so stick with me here.
In order to build up an incremental compilation, we need two sources of
dependency information:
1) "Priors" - Swiftdeps with dependency information from the past
build(s)
2) "Posteriors" - Swiftdeps with dependencies from after we rebuild the
file or module or whatever
With normal swift files built in incremental mode, the priors are given by the
swiftdeps files which are generated parallel to a swift file and usually
placed in the build directory alongside the object files. Because we
have entries in the output file map, we can always know where these
swiftdeps files are. The priors are integrated by the driver and then
the build is scheduled. As the build runs and jobs complete, their
swiftdeps are reloaded and re-integrated. The resulting changes are then
traversed and more jobs are scheduled if necessary. These give us the
posteriors we desire.
A module flips this on its head. The swiftdeps information serialized
in a module functions as the *posterior* since the driver consuming the
module has no way of knowing how to rebuild the module, and because its
dependencies are, for all intents and purposes, fixed in time. The
missing piece of the puzzle is the priors. That is, we need some way of
knowing what the "past" interface of the module looked like so we can
compare it to the "present" interface. Moreover, we need to always know
where to look for these priors.
We solve this problem by serializing a file alongside the build record:
the "external" build record. This is given by a... creative encoding
of multiple source file dependency graphs into a single source file
dependency graph. The rough structure of this is:
SourceFile => interface <BUILD_RECORD>.external
| - Incremental External Dependency => interface <MODULE_1>.swiftmodule
| | - <dependency> ...
| | - <dependency> ...
| | - <dependency> ...
| - Incremental External Dependency => interface <MODULE_2>.swiftmodule
| | - <dependency> ...
| | - <dependency> ...
| - Incremental External Dependency => interface <MODULE_3>.swiftmodule
| - ...
Sorta, `cat`'ing a bunch of source file dependency graphs together but
with incremental external dependency nodes acting as glue.
Now for the trick:
We have to unpack this structure and integrate it to get our priors.
This is easy. The tricky bit comes in integrate itself. Because the
top-level source file node points directly at the external build record,
not the original swift modules that defined these dependency nodes, we
swap the key it wants to use (the external build record) for the
incremental external dependency acting as the "parent" of the dependency
node. We do this by following the arc we carefully laid down in the
structure above.
For rdar://69595010
Goes a long way towards rdar://48955139, rdar://64238133
