This could fail to build due to BackDeployment.h not always being included in Config.h. Check an additional condition to ensure that this code is only active when BackDeployment.h is included.
rdar://problem/56735154
It is causing bots to fail.
* Revert "The __has_include(<os/system_version.h>) branch here wasn't quite right, we'll just use the dlsym one for now"
This reverts commit f824922456.
* Revert "Remove stdlib and runtime dependencies on Foundation and CF"
This reverts commit 3fe46e3f16.
rdar://54709269
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 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
Currently ignored, but this will allow future compilers to pass down source location information for cast
failure runtime errors without backward deployment constraints.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Silence warnings about deleted defaulted constructors due to the
non-trivial constructor for the atomic type. Guard a conditionally used
function with the appropriate guard.
The Allocations Instrument overrides swift_retain with a function that records the retain count by calling swift_retainCount. Its assert for bits.getIsDeiniting() is incorrect in that case, so remove it.
The recent change to ObjC tagged pointer bits on x86-64 also caused the various bridgeObjectRetain/Release functions to call through to swift_retain for BridgeObject tagged values on Mac. swift_retain ignored those values so there was no functional change, except when Instruments overrode it and passed them to swift_retainCount, which tried to dereference them and crashed. Modify bridgeObjectRetain/Release to bail out early again. Also modify swift_retainCount to ignore those values in case anything else expects retainCount to work on any pointer swift_retain accepts.
rdar://problem/45102538
Previously we had a single mask for all x86-64 targets which included both the top and bottom bits. This accommodated simulators, which use the top bit, while macOS uses the bottom bit, but reserved one bit more than necessary on each. This change breaks out x86-64 simulators from non-simulators and reserves only the one bit used on each.
rdar://problem/34805348 rdar://problem/29765919
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
Update the instances of checks for architectures to be more broad for different
spellings of the architecture macro. Certain targets use `_M_ARM` and others
use `__arm__`. Similarly, arm64/aarch64 has `_M_ARM64`, `__arm64__` and
`__aarch64__` as spellings. This just mechanically goes through and encodes the
various spellings.
Take the opportunity to replace some raw checks with `defined` checks which
avoids a pedantic warning due to the undefined macro when performing the check
as the preprocessor may warn about an undefined condition evaluating to `0`.
These functions don't accept local variable heap memory, although the names make it sound like they work on anything. When you try, they mistakenly identify such things as ObjC objects, call through to the equivalent objc_* function, and crash confusingly. This adds Object to the name of each one to make it more clear what they accept.
rdar://problem/37285743
Use ProtocolDescriptorRefs within the runtime representation of
existential type metadata (TargetExistentialTypeMetadata) instead of
bare protocol descriptor pointers. Start rolling out the use of
ProtocolDescriptorRef in a few places in the runtime that touch this
code. Note that we’re not yet establishing any strong invariants on
the TargetProtocolDescriptorRef instances.
While here, replace TargetExistentialTypeMetadata’s hand-rolled pointer
arithmetic with swift::ABI::TrailingObjects and centralize knowledge of
its layout better.
We want to be able to potentially introduce new metadata kinds in future Swift compilers, so a runtime ought to be able to degrade gracefully in the face of metadata kinds it doesn't know about. Remove attempts to exhaustively switch over metadata kinds and instead treat unknown metadata kinds as opaque.
When we use type(of: x) on a class in an ObjC bridged context, the optimizer turns this into a SIL `value_metatype @objc` operation, which is supposed to get the dynamic type of the object as an ObjC class. This was previously lowered by IRGen into a `object_getClass` call, which extracts the isa pointer from the object, but is inconsistent with the `-class` method in ObjC or with the Swift-native behavior, which both look through artificial subclasses, proxies, and so on. This inconsistency led to observably different behavior between debug and release builds and between ObjC-bridged and native entry points, so provide an alternative runtime entry point that replicates the behavior of getting a native Swift class. Fixes SR-7258.
Check that an ``withoutActuallyEscaping(noescape_closure) { // scope}`` closure
has not escaped in the scope using the ``is_escaping_closure %closure``
instruction.
rdar://35525730
Will be used to verify that withoutActuallyEscaping's block does not
escape the closure.
``%escaping = is_escaping_closure %closure`` tests the reference count. If the
closure is not uniquely referenced it prints out and error message and
returns true. Otherwise, it returns false. The returned result can be
used with a ``cond_fail %escaping`` instruction to abort the program.
rdar://35525730
This can eventually be made more efficient by avoiding copies in all the
callees, but this is the minimal fix. Remove an unnecessary bit of
reverse-dependency on the Foundation overlay while we're here.
rdar://34222540
Minimize the generic class metadata template by removing the
class header and base-class members. Add back the set of
information that's really required for instantiation.
Teach swift_allocateGenericClass how to allocate classes without
superclass metadata. Reorder generic initialization to establish
a stronger phase-ordering between allocation (the part that doesn't
really care about the generic arguments) and initialization (the
part that really does care about the generic arguments and therefore
might need to be delayed to handle metadata cycles).
A similar thing needs to happen for resilient class relocation.
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
clang is miscompiling some swiftcall functions on armv7s.
Stop using swiftcall in some places until it is fixed.
Reverts c5bf2ec (#13299).
rdar://35973477
Swift class metadata has a bit to distinguish it from non-Swift Objective-C
classes. The stable ABI will use a different bit so that stable Swift and
pre-stable Swift can be distinguished from each other.
No bits are actually changed yet. Enabling the new bit needs to wait for
other coordination such as libobjc.
rdar://35767811
