Replace them with swift_cxx_newObject/swift_cxx_deleteObject to avoid calling overridden global operators. Overridden global operators can sometimes fail when called from places the authors didn't expect.
The particular uses being changed here are:
1. Creation of new SingletonMetadataCacheEntry objects.
2. Allocation of the _globalIvarOffsets array in initGenericObjCClass.
3. Creation/destruction of SwiftTLSContext objects.
rdar://106238547
We don't have any language or runtime support for noncopyable types as generic
or dynamic types yet, and existing reflection code almost certainly assumes it
can copy the values it's working with, and will trap or corrupt state if it does
so with noncopyable types. But a class can have noncopyable fields while the
type itself is copyable, and existing code assumes that it can use `Mirror` or
other reflection mechanisms to safely traverse the contents of an arbitrary
class.
Allow this sort of code to continue working, while still preparing for forward
compatibility with future runtimes that do support noncopyable generics, by
emitting the type references for fields using a function that probes the
address of a new symbol in the Swift runtime. The symbol will either be missing
or defined with an absolute address of zero in current or previous runtime
versions, but can be changed to a non-null address in the future.
For now this has SWIFT_RUNTIME_LIBRARY_VISIBILITY, but in the
future we might want to make it public so that IRGen can use it
to build packs out of concrete types.
We'd still like to try to be forwardly compatible with future runtimes
that do properly handle noncopyable types, so emit them in a separate section from
copyable type records for now. This should prevent `_typeByName` from letting
someone get a hold of a noncopyable type's metatype as a (copyable) `Any.Type` and
then trying to use it to copy uncopyable values.
While we can't assume that pointer equality implies semantic equality
with witness table packs, it still makes sense to unique their storage
opportunistically.
* [IRGen] Add layout strings for generic and resilient types
rdar://105837048
* Add some corner cases
* Add flag to enable generic instantiation and some fixes
* Fix resilient types
* Fix metadata accessor function pointers in combined layout strings
Some symbolication frameworks have a symbol cache; we probably don't want
to use that for test cases, to avoid running into problems where the cache
holds stale information.
rdar://105409147
We really, really shouldn't be running the external backtracer for setuid
binaries. It's just too dangerous.
So don't do that. And if someone tries to force us, emit a warning.
rdar://105391747
This adds a bunch of new code but once I finish refactoring the other
demangling stuff, I should be able to remove
- gatherWrittenGenericArgs()
- _gatherGenericParameters()
- SubstGenericParametersFromWrittenArgs
This was added when Saleem suggested using <filesystem> to avoid having
to do lots of string manipulation, but it turns out we can't use it on
macOS because of minimum deployment versions, and we also can't use it
on Ubuntu 18.04 because it doesn't exist there.
The code related to it was backed out already, but I missed the include.
rdar://106183273
When available, use objc_addLoadImageFunc2 and _dyld_register_func_for_add_image to look up mach-o sections instead of using getsectiondata. When not available, we fall back to objc_addLoadImageFunc or _dyld_register_func_for_add_image and getsectiondata as before.
rdar://51760462
We need to be able to locate `swift-backtrace` relative to the current
location of the runtime library.
This needs to work:
* In a Swift build directory.
* On Darwin, where we're installed in /usr/lib/swift and /usr/libexec/swift.
* On Linux, where we're in /usr/lib/swift/linux and /usr/libexec/swift/linux.
* On Windows, where we may be in a flat directory layout (because of limitations
of Windows DLL lookups).
rdar://103071801
