swift_allocBox was correctly computing allocation size/alignment.
swift_deallocBox was compiting it differently (and incorrectly).
Factor out the logic into a separate function that we use from both
places.
The Embedded Swift dynamic casting logic was getting a bit tangled, and
used some heuristics for figuring out the existential representation
that didn't always work, e.g., with class-bound types.
Reimplement the entire thing using the same general approach that the
non-Embedded runtime uses, albeit simplified greatly because Embedded
Swift doesn't permit casting to existential types (only *from*
existential types). The new implementation correctly unwraps all levels
of existential, short-circuits where appropriate, and "takes" wherever
possible.
This change does require emitting some more metadata than we did
before, because it is necessary to handle the different existential
representations correctly. Previously, the compiler would pass a NULL
pointer as the "source" metadata to `swift_dynamicCast`, then try to
figure out what it was given by inspecting the source pointer. This is
insufficient for distinguishing the various existential representations
(opaque, class-bound, error) and relied on heuristics. Start passing
destination metadata to this function, just as we do in non-Embedded
Swift. This means we'll end up generating some more metadata for
existential types (like `any P`) that we wouldn't have before, but
it's still pay-per-use and they are relatively small. All of the other
metadata that can flow here will already have been created for other
reasons, e.g., because classes already have it in their vtable.
This also extends the metadata associated with existential types by one
more word (from 2 to 3). The new word is used to provide the
existential representation, which is needed for dynamic casting as
described above.
Teach swift_dynamicCast to repeatedly unwrap "any Error" existentials
before matching the concrete type.
Required to make rdar://175590869 work through AsyncStream.
**Explanation**: We would like untyped throws to be available in Embedded Swift when system allocator is available.
**Scope**: limited to Embedded Swift.
**Risk**: low due to isolated scope, additive nature of the change, and no adoption of untyped throws in Embedded Swift so far.
**Testing**: added new lit tests.
**Issue**: rdar://171325402
In release builds that enable dynamic exclusivity checking, we are
including all of the printing code for producing the nice
"simultaneous access" failure message. That increases code size too
much, so only include this in debug builds. For release builds, we
just trap here.
Fixes rdar://173338152.
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.
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.
Improve debugging from core dumps for Embedded Swift by using condfail
rather than trap within _debugPrecondition, and make the call stack
transparent enough that we promote these out to callers.
Fixes rdar://159471659.
Start building the dynamic exclusivity checking code in Embedded Swift.
It will be used when dynamic exclusivity checking is enabled (via
`-enforce-exclusivity=checked`), and dead-code-stripped otherwise. Note
that we deliberately avoid linking `swift_(begin|end)Access` in
modules that don't have exclusivity enforcement enabled to aid with
dead-code stripping.
Also note that, unlike in non-Embedded Swift, exclusivity checking
cannot be disabled at runtime by setting
_swift_disableExclusivityChecking to `false`. We need the ability to
constant-initialize global variables to bring that functionality into
Embedded Swift.
Tracked by rdar://159115910.
The exclusivity enforcement command-line flags currently impact the
generation of SIL within the current module. However, it does not
impact any SIL that was deserialized from another module, which means
that `-enforce-exclusivity=unchecked` doesn't actually remove all of
the dynamic exclusivity checks.
When dynamic exclusivity is disabled, lower SIL
begin_access/end_access instructions to nothing to ensure that we
won't do any dynamic exclusivity checks.
Use this to better model the reality of dynamic exclusivity checking
in Embedded Swift, which effectively turned off all dynamic
exclusivity checking by having empty stub implementations of
swift_(begin|end)Access. Instead, have Embedded Swift default to
`-enforce-exclusivity=unchecked`, so that it never emits calls to
swift_(begin|end)Access. Remove the stub implementations of
swift_(begin|end)Access from the Embedded Swift runtime, since we will
no longer generate calls to them by default.
Moving forward, this will allow us to conditionally enable the new
implementation of dynamic exclusivity checking by specifying
`-enforce-exclusivity=checked` for Embedded Swift builds. We'll stage
that in over time to avoid breaking existing Embedded Swift clients.
Users frequently run into a missing runtime symbol for Cxx exceptions
(`_swift_exceptionPersonality`) when mixing Embedded Swift and Cxx with
exceptions enabled. This leads to a confusing an hard to debug linker
error. This commit adds an implementation of this function to the
Embedded Swift runtime which simply fatal errors if a cxx exception is
caught in a Swift frame.
Issue: rdar://164423867
Issue: #85490
Code using the outline heap storage path will crash and burn because
support is incomplete. But at least inline storage existential
inhabitants should compile and run.
This change moves us toward the official feature, and eliminates the
extra level of "thunk" that was implied by `@_cdecl`. Amusingly, this
trips up the LLVM-level ARC optimizations, because we are trying to
perform ARC optimizations within the retain/release runtime functions.
Teach those optimization passes to leave swift_retainN et al alone.
`swift_coroFrameAlloc` is needed by `_read`/`_modify` accessors
`swift_deallocUninitializedObject` which I believe is needed for failable class initializers
Resolves rdar://157028375
Resolves rdar://157276375
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
The results of `swift_retain(object:)` and `swift_bridgeObjectRetain(object:)`
should be discardable since it's typcial to not need the pointer returned from
these calls. Suppresses unused result warnings that were generated previously.
This makes ManagedBuffer available and usable in Embedded Swift, by:
- Removing an internal consistency check from ManagedBuffer that relies on metatypes.
- Making the .create() API transparent (to hoist the metatype to the callee).
- Adding a AllocRefDynamicInst simplification to convert `alloc_ref_dynamic` to `alloc_ref`, which removes a metatype use.
- Adding tests for the above.
Doug Gregor
Max Desiatov
Allan Shortlidge
Dario Rexin
Arnold Schwaighofer
Guillaume Lessard
Rauhul Varma
Valeriy Van
Tim Kientzle
Gabor Horvath
Kuba Mracek
Konrad `ktoso` Malawski
Konrad `ktoso` Malawski
Alex Hoppen