Tests importing AppKit have a tendency to be flaky if they share a
module cache with other builds using a different set of framework search
flags. Make sure they use a local cache to avoid picking incompatible
cached modules.
Alternatively, we could align all builds using the same cache to have
exactly the same framework search paths or enable explicit module
builds. I picked the module cache as it's the most reliable solution in
the short and long term.
The 5 tests below import AppKit and have been known to be flaky.
Adapting them to use a custom cache with require more care. For now,
let's use them as control group to validate that the fix works. If these
5 fail without the fixed ones, we should extend the same corresponding
fix to them.
- Interpreter/SDK/GLKit.swift
- Interpreter/SDK/cf_extensions.swift
- Interpreter/SDK/cf_type_bridging.swift
- Interpreter/SDK/mapkit_header_static.swift
- Interpreter/SDK/objc_ns_enum.swift
rdar://142296731
This test checks the behavior of class_getImageName before the runtime's hook is installed with objc_setHook_getImageName. Foundation now triggers installation of that hook very early, causing the test to fail. Reliably avoiding this is difficult, and the test is redundant with the ObjC runtime's tests, so just remove it.
rdar://132478164
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
We fix up the VWT pointer, but not the heap destroyer. This doesn't matter for classes which use ObjC refcounting, which is the common case for dynamic subclasses, because that doesn't use the heap destroyer pointer. But it does matter for classes that use native Swift refcounting, such as classes that don't inherit from NSObject, or actors.
rdar://113657917
The bit twiddling done by this test falls afoul of ptrauth on ARM64e. We don't support pre-stable Swift ABI code on ARM64e anyway, so just disable the test there.
rdar://92469961
Change actor destruction to call swift_deallocClassInstance instead of swift_deallocObject. When ObjC interop is enabled, swift_deallocClassInstance will check the "pure swift deallocation" bit and call into the ObjC runtime to destruct the instance when needed. This is what clears weak references and associated objects.
rdar://91270492
The "regular" CMO is done with the option `-cross-module-optimization`. It's good for performance but can increase code size.
Now, which this change CMO is also done if the option is not given, but in a very conservative way. Only very small functions are serialized and not additional type metadata is kept alive.
rdar://70082202
The conditional should have been "Intel simulators" but it was actually "x86-64 simulators." The i386 simulator doesn't have the weak formation callout, which causes it to miss cleaning up associated objects when the Swift runtime thinks it does.
rdar://79672466
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
This replaces swiftMSVCRT with swiftCRT. The big difference here is
that the `visualc` module is no longer imported nor exported. The
`visualc` module remains in use for a singular test wrt availability,
but this should effectively remove the need for the `visualc` module.
The difference between the MSVCRT and ucrt module was not well
understood by most. MSVCRT provided ucrt AND visualc, combining pieces
of the old MSVCRT and the newer ucrt. The ucrt module is what you
really wanted most of the time, however, would need to use MSVCRT for
the convenience aliases for type-generic math and the deprecated math
constants.
Unfortunately, we cannot shadow the `ucrt` module and create a Swift SDK
overlay for ucrt as that seems to result in circular dependencies when
processing the `_Concurrency` module.
Although this makes using the C library easier for most people, it has a
more important subtle change: it cleaves the dependency on visualc.
This means that this enables use of Swift without Visual Studio for the
singular purpose of providing 3 header files. Additionally, it removes
the need for the installation of 2 of the 4 support files. This greatly
simplifies the deployment process on Windows.
* Dynamic Cast Rework: Runtime
This is a completely refactored version of the core swift_dynamicCast
runtime method.
This fixes a number of bugs, especially in the handling of multiply-wrapped
types such as Optional within Any. The result should be much closer to the
behavior specified by `docs/DynamicCasting.md`.
Most of the type-specific logic is simply copied over from the
earlier implementation, but the overall structure has been changed
to be uniformly recursive. In particular, this provides uniform
handling of Optional, existentials, Any and other common "box"
types along all paths. The consistent structure should also be
easier to update in the future with new general types.
Benchmarking does not show any noticable performance implications.
**Temporarily**, the old implementation is still available. Setting the
environment variable `SWIFT_OLD_DYNAMIC_CAST_RUNTIME` before launching a program
will use the old runtime implementation. This is only to facilitate testing;
once the new implementation is stable, I expect to completely remove the old
implementation.
Remove the target specific binary and instead compile a test binary on
the fly. Because this test is restricted to macOS platforms, we know
that we assume that we will have a compatible Objective-C runtime at our
disposal. Use that to create a stub library for testing
`NSClassFromString`.
This allows this test to execute on ARM64.
Move the ObjC class name stability check logic to the Swift runtime, exposing it as a new SPI called _swift_isObjCTypeNameSerializable.
Update the reporting logic. The ObjC names of generic classes are considered stable now, but private classes and classes defined in function bodies or other anonymous contexts are unstable by design.
On the overlay side, rewrite the check’s implementation in Swift and considerably simplify it.
rdar://57809977
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
I don't see any reason to split the tests like this. I merged the tests
into the biggest and best-organized test file.
I also removed the `REQUIRES: OS=macosx` line and made some small
adjustments to the test to make it cross-platform.
This commit focuses the basics: setting up the relevant stanzas in
lit.cfg and adding platform conditionals for importing Glibc. Future
commits will deal with other portability fixes.
