rdar://143401725
Replacing the (non-inlined) call to `swift_once` with a relaxed atomic significantly improves the generated code and reduces the memory footprint. The mechanism itself now does not cause a stack frame to be generated and the expected case (no override) should be perfectly predicted and executed in straight line code. The override case should also be well predicted, with only two branches on the same value.
We're using C++ 14+ at least now across the project so these should not be necessary. It's also kind of wild that the definitions we had across different subsystems had different definitions.
In the Dispatch implementation, clamp the delay to INT64_MAX. Swift's nanoseconds value is unsigned, but we ultimately use it with dispatch_time, which takes a signed int64_t. Extremely large values get interpreted as negative, which results in not sleeping.
INT64_MAX nanoseconds is about 292 years, so it should be difficult to notice a practical effect from sleeping for less time than requested due to the clamping.
rdar://143278824
If we ended up with a `/` at the beginning of a string segment, we
were erroneously not adding to the expansion dictionary when we
should have been.
rdar://124913332
Our Bazel builds have become more strict about libc++
dependencies recently, so these are required to pick up
declarations of `malloc` and `uint32_t`, respectively.
Also removed a spurious `print()` that got left in by accident,
and disabled the `CodableBacktrace.swift` test on Linux since we
need Foundation and we don't have it there.
rdar://124913332
This PR adds basic support for storing lifetime dependence information,
transform Span return types, and generate lifetime annotations.
rdar://139074571
This prepares the runtime to be closed with its dependencies when
performing static linking. The pragma ensures that the linker will
automatically pick up the dependent libraries avoiding the need to
explicitly add the dependencies.
Remove a `-disable-implicit-backtracing-module-import` that was added
in `Runtimes/Core/CMakeLists.txt`, and also remove the reference to
`swiftCxxStdlib` from `RuntimeModule` as that causes the build to fail
when attempting to build the static version of `swift-backtrace` on
Linux.
rdar://124913332
We already try using `CFStringGetCStringPtr` to see if we can get ASCII;
we should also try `CFStringGetCharactersPtr` as the native encoding of
`CFNSString` is very often UTF-16. While we're at it, try asking explicitly
for UTF-8 as well. That won't work for `CFNSString` because AFAIK it's
currently never encoded that way, but it might work if something hands us
a Swift-backed string or if some future implementation of `CFString`
happens to support UTF-8 encoded data.
rdar://124913332
We want to be able to efficiently serialise lists of images, and to do so
it makes most sense to create a separate `ImageMap` type. This also provides
a useful place to put methods to e.g. find an image by address or by build
ID.
rdar://124913332
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
Doc comments for DiscontiguousSlice, MutableCollection, RangeSet, and
RangeReplaceableCollection all refer to a Collection method subranges(where:)
which is intended to return a RangeSet of matching ranges. I believe this is
likely an old or formerly-contemplated spelling of the method now known as
indices(where:). This commit changes "subranges" to "indices".
* Import __counted_by for function return values
Instead of simply passing a parameter index to _SwiftifyInfo, the
_SwiftifyExpr enum is introduced. It currently has two cases:
- .param(index: Int), corresponding to the previous parameter index
- .return, corresponding to the function's return value.
ClangImporter is also updated to pass this new information along to
_SwiftifyImport, allowing overloads with buffer pointer return types to
be generated. The swiftified return values currently return Span when
the return value is marked as nonescaping, despite this not being sound.
This is a bug that will be fixed in the next commit, as the issue is
greater than just for return values.
* Fix Span variant selection
There was an assumption that all converted pointers were either
converted to Span-family pointers, or UnsafeBufferPointer-family
pointers. This was not consistently handled, resulting in violating the
`assert(nonescaping)` assert when the two were mixed. This patch removes
the Variant struct, and instead each swiftified pointer separately
tracks whether it should map to Span or UnsafeBufferPointer.
This also fixes return pointers being incorrectly mapped to Span when
marked as nonescaping.
Fixes the immediate problem, but the presence of demangling code in the
runtime means that we'll need a follow-up to fix the compiler so that it
doesn't try to use the demangler to materialize metadata for function types
that have both isolation and a sending result.
rdar://142443925
