10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
If allowing modules to be output with compile errors
(-experimental-allow-module-with-errors), import targets regardless of
whether they are compatible or not, and still output the module. The
error diagnostic will still be output (preventing SILGen), but the AST
will be available for various editor functionality.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
This does several different things to improve how platforms are described in availability diagnostics:
• Mentions the platform in diagnostics for platform-specific @available(unavailable) attributes.
• Replaces “OS X” with “macOS”.
• Replaces “fooOS application extension” with “application extensions for fooOS”.
• Replaces “on fooOS” with “in fooOS”.
Fixes <rdar://problem/49963341>.
Swift currently checks if an imported module has a deployment target
compatible with what’s currently being compiled. For a resilient
module, though, you really want to know the /oldest/ deployment target
the library supports, not the one it was most recently compiled with,
and we don’t currently save that information. Disable this check for
now when the module is resilient.
(Why not do this on the serialization side? Because the deployment
target you compile with is still relevant when trying to match the
compilation environment as closely as possible, which LLDB tries to
do. It's also just useful information for debugging the compiler.)
rdar://problem/42903218
Before:
module file's minimum deployment target is iOS 12.0:
/path/to/FooKit.swiftmodule
After:
compiling for iOS 11.0, but module 'FooKit' has a minimum deployment
target of iOS 12.0: /path/to/FooKit.swiftmodule
Also tweak the "incompatible target" error to include the module name.
rdar://problem/35546499
In particular, this is problematic when libraries are loaded dynamically, and
may have newer deployment targets than the main executable.
Swift SVN r26786
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Refuse to load a module if it was compiled for a different architecture or
OS, or if its minimum deployment target is newer than the current target.
Additionally, provide the target triple as part of pre-loading validation
for clients who care (like LLDB).
Part of rdar://problem/17670778
Swift SVN r24469
