There was a ton of copy-paste in the various embedded swift library
builds. Centralize most of that logic into a new
add_embedded_swift_target_library function that will make it easier to
make additional libraries build as embedded swift.
Sink settings for various Swift library build options that have fixed
values for Embedded Swift down into the AddSwiftStdlib logic, rather
than duplicating them in every embedded library build.
The ONLY_SWIFTMODULE option was used for some of the Embedded Swift
library builds to produce just a .swiftmodule without any
corresponding object files or static archives. This presupposes a
build model where we never emit object code for these libraries;
rather, it all gets inlined into the clients.
To make it possible to add more flexibility to the build model here,
drop this option. Instead, pass along the flags to emit an empty
object file and set the code generation model to "implementation".
This is effectively the same code generation model (since the object
file is empty), but made more explicit and done in a manner that fits
in better with the build system.
Use this as an excuse to centralize setting a number of other Embedded
Swift-specific flags, rather than copy-pasting them for every library
built as Embedded Swift.
It's far better to write characters in bulk than one at a time,
putchar-style. Start moving the platform abstraction layer over to a
function that does so.
The Embedded Swift concurrency library needs a way to exit the program
at the end of async main. The existing implementation calls through a
_swift_exit() function to the POSIX/C exit(). Enshrine _swift_exit()
as part of the Platform Abstraction Layer, with the same signature
(albeit in C), and implement it in the PAL-on-POSIX library as a call
through to exit().
The bridging PCH created by the driver uses a temporary directory,
which introduces nondeterminism into the results. We don't need to
precompile this tiny header, so turn off the precompiled bridging
header.
Fixes rdar://172741975
rdar://158239258
This change adds logic in the compiler to compute malloc type ids and emit them together with typed allocation calls. It also adds the new runtime function swift_allocObjectTyped, which calls typed malloc.
The new library, swiftEmbeddedPlatformPOSIX, implements all of the
_swift_XYZ functions needed to support Embedded Swift as shims on top
of a POSIX system that provides posix_memalign, free, putchar, and so
on. This offers an easier way to bridge between the prior ad hoc
requirements of Embedded Swift and the newer platform abstraction
layer.
Part of rdar://164057124
Embedded Swift depends on a number of functions from the platform,
including posix_memalign, free, and arc4random_buf. While these
dependencies are documented, they aren't documented in a manner that
makes them easy to implement. Additionally, most of these are C
library functions that may or may not be available, and can have
requirements that are more stringent than Embedded Swift actually
requires.
Try to address both problems at once by introducing a new header,
`swift/EmbeddedPlatform.h`, that provides a new set of C declarations
for functions that need to be provided by a platform. For
each function, we provide documentation on what it does, what Embedded
Swift facilities will end up using it (e.g.,
`_swift_generateRandomHashSeed` is needed for seeding the hash
functions used for `Set` and `Dictionary`, among other things), and
some guidance on how to implement it---including those cases where
directly calling an existing C standard library or POSIX function will
suffice.
There is a new CMake option, SWIFT_USE_SWIFT_EMBEDDED_PLATFORM, that
enables the use of these entrypoints in the Embedded Swift runtime. It
is currently disabled, because enabling it would break existing
clients of Embedded Swift. We're looking for a way to stage this in.
Addresses rdar://164057124.
Mishal Shah
Doug Gregor
Dario Rexin