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
We have some problems on Linux where Glibc pulls in `<elf.h>` and then
we end up with conflicting definitions. Fix by using C++ interop and
putting our definitions into a namespace.
rdar://137201928
When building the standard library statically on Windows, we should not
use any __declspec(dllimport) or __declspec(dllexport) on the runtime
functions or data. Furthermore, we should internalise all of the
standard library functions so that they are not re-exported if used to
build a shared library. The code generation changes required for this
are easier to identify once a static SDK is available for Windows.
