A number of tests exercise features only available in Apple OSes that
shipped with Swift 5.0 in the OS; this includes the following versions:
- macOS 10.14.4
- iOS 12.2
- tvOS 12.2
- watchOS 5.2
Previously these tests were restricted to running on macOS only, with
an explicit -target x86_64-apple-macosx10.14.4. To get better test
coverage, add a new %target-stable-abi-triple substitution which
expands to a triple with the correct OS version on all Apple platforms.
On non-Apple platforms, this is the same as %target-variant-triple,
but for now any test that uses this exercises Apple platform features
anyway.
One caveat is that since iOS 12.2 does not have a 32-bit slice, we
have to skip any tests that use -target %target-stable-abi-triple
on this platform. A new swift_stable_abi feature flag can be tested
with 'REQUIRES: swift_stable_abi'. To get maximum test coverage,
I split off a 'stable_abi' version of a few tests that build with both
an old and new deployment target. This allows the old deployment
target case to still be tested on 32-bit iOS.
That OS doesn't have objc_readClassPair(). This test uses -target to
explicitly select a newer deployment target and then runs the binary
on an old OS to test the behavior. However this means arclite won't
get linked in unless we also pass in -link-objc-runtime.
Fixes <rdar://problem/50610877>.
Way back in Swift 1 I was trying to draw a distinction between
"overlays", separate libraries that added Swift content to an existing
Objective-C framework, and "the Swift part of a mixed-source
framework", even though they're implemented in almost exactly the same
way. "Adapter module" was the term that covered both of those. In
practice, however, no one knew what "adapter" meant. Bring an end to
this confusion by just using "overlay" within the compiler even for
the mixed-source framework case.
No intended functionality change.
If a class does not have a custom @objc name, objc_getClass() can find
it at runtime by calling the Swift runtime's metadata demangler hook.
This avoids the static initializer on startup. If the class has a
custom runtime name we still need the static initializer unfortunately.
Fixes <rdar://problem/49660515>.
These would never be decoded in normal use, but it's possible to construct an archive that will attempt to decode them. Without this override, that throws an exception or worse.
rdar://problem/48429185
Different tests used different os checks for importing Darwin, Glibc and
MSVCRT. This commit use the same pattern for importing those libraries,
in order to avoid the #else branches of the incorrect patterns to be
applied to the wrong platform. This was very normal for Android, which
normally should follow the Linux branches, but sometimes was trying to
import Darwin or not importing anything.
The standarized pattern imports Darwin for macOS, iOS, tvOS and watchOS.
It imports Glibc for Linux, FreeBSD, PS4, Android, Cygwin and Haiku; and
imports MSVCRT for Windows. If a new platform is introduced, the else
branch will report an error, so the new platform can be added to one of
the branches (or maybe add a new specific branch).
In some cases the standard pattern was modified because some test required
it (importing extra modules, or extra type aliases), and in some other
cases some branches were removed because the test will not have used
them (but it is not exhaustive, so there might be some unnecessary
branches).
This should, at least, fix three tests for Android (the three
dynamic_replacement*.swift ones).
This undoes some of Joe's work in 8665342 to add a guarantee: if an
@objc convenience initializer only calls other @objc initializers that
eventually call a designated initializer, it won't result in an extra
allocation. While Objective-C /allows/ returning a different object
from an initializer than the allocation you were given, doing so
doesn't play well with some very hairy implementation details of
compiled nib files (or NSCoding archives with cyclic references in
general).
This guarantee only applies to
(1) calling `self.init`
(2) where the delegated-to initializer is @objc
because convenience initializers must do dynamic dispatch when they
delegate, and Swift only stores allocating entry points for
initializers in a class's vtable. To dynamically find an initializing
entry point, ObjC dispatch must be used instead.
(It's worth noting that this patch does NOT check that the calling
initializer is a convenience initializer when deciding whether to use
ObjC dispatch for `self.init`. If we ever add peer delegation to
designated initializers, which is totally a valid feature, that should
use static dispatch and therefore should not go through objc_msgSend.)
This change doesn't /always/ result in fewer allocations; if the
delegated-to initializer ends up returning a different object after
all, the original allocation was wasted. Objective-C has the same
problem (one of the reasons why factory methods exist for things like
NSNumber and NSArray).
We do still get most of the benefits of Joe's original change. In
particular, vtables only ever contain allocating initializer entry
points, never the initializing ones, and never /both/ (which was a
thing that could happen with 'required' before).
rdar://problem/46823518
These tests require the ObjC Foundation framework currently (although it
should be possible have them use the swift corelibs Foundation project
to satisfy this requirement). Marking the tests indicates that these
tests do not have the dependencies to run on Windows.
Create a new capturing substitution for adding a rpath to a target
library. This is needed as Windows doesn't really support the concept
of a rpath. This also makes it possible to remove the parameter from
the command line on windows.
Thanks to @jrose for the hint about the substitution ordering, the new
substitution now works even inside the capture group. Replace the
remaining uses to the new macro.
The naming convention is different on Windows than on Unix-like
environments. In order to follow the convention we need to substitute
the prefix and the suffix. Take the opportunity to rename the
`target-dylib-extension` to the CMake-like variable
`target-shared-library-suffix` and introduce
`target-shared-library-prefix`. This helps linking the test suite
binaries on Windows.
libobjc needs to look up classes by name. Some Swift classes, such as
instantiated generics and their subclasses, are created only on demand.
Now a by-name lookup from libobjc counts as a demand for those classes.
rdar://problem/27808571
Completely mechanical changes:
- Explicit @objc in a few places
- Some imported APIs changed
- For the mix-and-match tests, just test version 4/5 instead of 3/4
...like LLDB does, instead of parsing into a single SourceFile.
This does break some functionality:
- no more :dump_ast
- no redeclaration checking, but no shadowing either---redeclarations
just become ambiguous
- pretty much requires EnableAccessControl to be off, since we don't
walk decls to promote them to 'public'
...but it allows us to remove a bit of longstanding support for
type-checking / SILGen-ing / IRGen-ing only part of a SourceFile that
was only used by the integrated REPL.
...which, need I remind everyone, is still /deprecated/...but sometimes
convenient. So most of it still works.
Most of this is just "remember to specify the inputs and outputs on
the command line, so remote-run can see them". A bit is "prefix
environment variables with '%env-'". And the last few are "yeah,
this was never going to work in a remote environment".
In the few cases where I couldn't think of anything reasonable, I just
marked the test as "UNSUPPORTED: remote_run", a new "feature".
