Most of linkers pull object files from static archives only if any
symbol from that object file is referenced, even if the object contains
a ctor code. `Setup.cpp` didn't have any symbols referenced from
other code, so it was not linked in when the concurrency runtime was
linked in statically. This commit moves the ctor code to `Task.cpp`
to ensure that it is always linked in.
The availability flags keep increasing the number of characters on the
command line overflowing the maximum character length on Windows and
making the commands harder to read. This patch moves the generated
arguments into a separate response file so that they can continue to
grow without running into argument length limitations.
When building the standard libraries with the LLVM ADT types, we use the
local definition which have been modified to avoid ODR violations.
However, due to the intermingling of the compiler and runtime
implementations, we cannot isolate the headers properly to ensure that
the right definition is used. We need to ensure that we pass along
`SWIFT_RUNTIME` when processing headers to avoid references to the
unsafe references to the LLVM Support library.
`_Concurrency` is being implicitly imported and then linked into the
runtime. Disable the implicit import of the concurrency runtime to allow
proper control over the linkage for the library.
**Description**: This adds "task name" parameter to all task creating
functions.
This is done in a few ways, e.g. we can backdeploy this to 5.1 in APIs
which do not accept the `TaskExecutor` but it they do we provide a
version for 6.0+ etc. This was requested in the SE acceptable of this
proposal [Acceptance post
SE-0469](https://forums.swift.org/t/accepted-with-modifications-se-0469-task-naming/79438).
This moves all these declarations to gyb since going through them one by
one has become unmaintainable otherwise.
**Scope/Impact**: All task creation APIs now gain a new task name
parameter.
**Risk:** Medium, changes existing APIs rather than adding "even more
overloads" though this risk was discussed in the team and accepted. This
has a potential to be source breaking it someone used Task.init and
friends as function.
**Testing**: CI testing, source compatibility suite testing
**Reviewed by**:
**Original PR:**
- https://github.com/swiftlang/swift/pull/81107 build changes required
for this
- https://github.com/swiftlang/swift/pull/80984
**Radar:**
---------
Co-authored-by: Kuba Mracek <mracek@apple.com>
This is basically the same as the one for Linux, but it would be
somewhat awkward to add the platform conditional on a file named for
Linux when OpenBSD is not Linux.
Important note: if Dispatch is disabled, then this will cause a
compilation error (probably not just for OpenBSD either), because
PlatformExecutorFactory is both defined in PlatformExecutorNone.swift
and PlatformExecutor<...>.swift in this case.
Because this only bites OpenBSD bootstrap builds, and since OpenBSD
support has been upstreamed to Dispatch, default to the Dispatch
implementation for now to get this in, and we'll refactor in a different
pr.
We can always get it back from the git history.
rdar://150695113
(cherry picked from commit 9d59dbed17)
Conflicts:
include/swift/AST/DiagnosticsSema.def
include/swift/Basic/Features.def
test/abi/macOS/arm64/concurrency.swift
test/abi/macOS/x86_64/concurrency.swift
Swift concurrency defines a default platform executor. This was not
defined for FreeBSD resulting in build failures. Defining it to use the
Dispatch executor.
Scope: This only impacts FreeBSD.
Risk: Low. This change only affects FreeBSD.
Reviewers: @compnerd, @ktoso, @al45tair
Testing: Local testing to ensure Concurrency builds on FreeBSD.
Fixes: rdar://150643436
(cherry picked from commit 4a41e50730)
The new build system set `SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS` to 0.
Unfortunately, the check in the Swift runtime used `#ifdef`, so even
though it was turned off, it was actually enabled in some cases.
Fixing the issue in the build system as well as switching the check to
verify that value of `SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS` is taken into
account in the sources. C/C++ implicitly defines macro values to 1 when
set without a value and 0 when it is not set.
Also making the hex a bit more recognizable and grep'able by including
it as a comment.
Fixes: rdar://149210738
(cherry picked from commit 6f39a52afc)
We need this so that older compilers can handle the .swiftinterface
files we generate. It's unnecessary for newer compilers and can be
removed later.
Fixes rdar://148529962.
(cherry picked from commit 0100104ff7)
Explicit module builds help prevent the dependency scanner from getting
lost and attempting to pull the SwiftShims module from the resource
directory, existing SDK, and the just-built standard library.
They aren't part of the library interface, but make it possible to build
the runtime libraries without seeing duplicate shims. Moving the flag to
a top-level compile command.
When building the standard library, the SDK is not fully staged and so
the compiler would not be able to inject the VFS overlay for the
modularisation of the Windows SDK. Manually construct the mappings and
apply them.
The expected install locations for the SwiftCoreConfig.cmake and
SwiftCoreTargets.cmake file was inconsistent between the build directory
and the install location. Making everything consistent across install
locations. In both cases, the files are installed under
`./cmake/SwiftCore`. This is one of the formats that `find_package` uses
to automatically search for package config files so that we can avoid
passing `SwiftCore_DIR` to all sub-projects.
We want to move StringProcessing sources out of the experimental string
processing repository. Use the Resync script to copy the files from the
experimental repository into position in the StringProcessing library.
This removes the workaround for the exporting of the registrar and
enables proper dependency tracking across projects (primarily geared
towards the Overlay).
