`StaticBinaryELF.cpp` was listed as an optional source but then unused
by any build target. As a result, it escaped detection that the file
was no longer in use.
Unfortunately, `std::atomic` in msvcprt as of 14.21.27702 is broken for
double-width atomics on ARM64. This has been reported to Microsoft and
is going to be fixed in VC++ 2019u3. For the time being, add a partial
template specialisation for the two double-word sized types temporarily
as a workaround. This allows the standard library build to get further.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
This one’s screwily specific--if you have:
* a private generic type,
* with a nested generic type in it,
* and the nested type conforms to a protocol with an associated type,
* and that associated type’s witness is a generic type,
* and some of the witness type’s generic parameters are generic parameters of the nested type,
demangling would fail. The problem is that the substitution machinery in the runtime would consider there to be three, not two, generic context depths involved. Depth 1, which should correspond to the nested type, would instead have no generic parameters. The fix is to skip over depths with zero generic parameters.
Fixes <rdar://problem/47773183>.
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
Android doesn't support the GNU backtrace call, but unwind.h is there to
help. The code is a little bit more complicated than a simple backtrace
call, but it is just a callback and the context struct.
Sadly, it seems that -funwind-tables is needed in every piece of code
that the backtrace needs to traverse, which means that at least the
runtime and the stubs need -funwind-tables. However, the flag has been
enabled for all targets (only on Android), just in case some other code
ends up being in the stack. This might only be necessary for ARM
targets, but currently we only build ARM targets in Android. The Swift
parts of the stack seems to have unwind information and can be unwind.
Another problem at the moment is the symbols from the executable are
normally missing. To get symbol names two things need to happen: the
symbol has to be public (so it is an exported symbol, and not just a
local symbol that dladdr seems to not provide the name), and the linker
has to be invoked with -export-dynamic. Without those two pieces, the
addresses are returned (and match the binary just fine), but no names
are printed.
When building without assertions, the variable will be unreferenced on
non-ObjC runtimes. Sink the evaluation into the assertion and move the
declaration into the ObjC runtime case.
Instead of a thunk insert the dispatch into the original function.
If the original function should be executed the prolog just jumps to the "real" code in the function. Otherwise the replacement function is called.
There is one little complication here: when the replacement function calls the original function, the original function should not dispatch to the replacement again.
To pass this information, we use a flag in thread local storage.
The setting and reading of the flag is done in two new runtime functions.
rdar://problem/51043781
Build a static archive that can be linked into executables and take advantage of the Swift runtime's
hooking mechanism to work around the issue Doug fixed in https://github.com/apple/swift/pull/24759.
The Swift 5.0 version of swift_conformsToProtocol would return a false negative in some cases where
a subclass conforms using an inherited conformance, so work around this by successively retrying
the original implementation up the superclass chain to try to find a match.
When we find a protocol conformance descriptor for a given type, make sure
we adjust to the conforming type of that descriptor (following the superclass
chain as needed) before instantiating the witness table.
Fixes rdar://problem/49741838.
Older OSes may not have this value or may have a different value. We only want to check going forward, because newer runtimes don't run on older OSes except in certain testing scenarios.
rdar://problem/50700856
This will allow us to emit class stubs unconditionally, rather than
checking the -enable-resilient-objc-class-stubs flag.
Part of <rdar://problem/49090631>.
This allows _swift_getClassOfAllocated to use a constant instead of loading from a global, and allows swift_isaMask to be computed without a static initializer. Debug builds verify that the #define matches the value from libobjc.
rdar://problem/22375602 rdar://problem/46385113
swift_getInitializedObjCClass called [c class] to trigger class initialization, and returned the value. This wreaked havoc when the class in question overrides +class. Instead, ignore the return value and return c. Switch from +class to +self, which is much less likely to be overridden. Calling an overridden method could have performance downsides or even cause unwanted side effects.
rdar://problem/49853091
We could introduce non-nominal-type context descriptors, such as those for opaque declarations,
which are also interesting to be able to look up for reflection or remote purposes. This should be
a backward compatible change with old runtimes, which always ignore any context descriptor kind
they don't know about.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
In protocol extensions, and in the future parameterized extensions, have their own generic arguments
independent of an originating nominal type's formal generic parameters. Instead of crashing, handle
this gracefully. rdar://problem/50038754
