Surprisingly, there are some situations where an extension can end up
with _fewer_ constraints than the extended type. That was baked-in as an
assertion in this new-ish method.
I haven't figured out why that can happen in the reproducer only when
using `-interpret` mode. It didn't trigger the assertion for me when
compiling normally.
The fix is simple: check all the requirements, rather than using a
short-cut.
resolves rdar://125659789 / https://github.com/apple/swift/issues/72719
When computing linkage, the compiler would treat unavailable declarations as if
they were "always available" when they lack an `introduced:` version:
```
// Library
@available(macOS, unavailable)
public func foo() {
// …
}
// Client
import Library
@available(macOS, unavailable)
func bar() {
// Even though foo() and bar() are unavalable on macOS the compiler still
// strongly links foo().
foo()
}
```
This created an unnecessary dependency between libraries and their clients and
also can interfere with back deployment, since unavailable declarations may not
be present in a library on all OS versions. Developers could work around these
issues by conditionally compiling the code that references an unavailable
declaration, but they shouldn't have to given that unavailable code is meant to
be provably unreachable at runtime. Additionally, it could improve library code
size if we allowed the compiler to strip unavailable declarations from a binary
completely.
Resolves rdar://106673713
lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
Here we fix a few portability issues affecting running the validation tests on OpenBSD. The remaining failures will be dealt with separately.
1. In the `rth` tool, ensure `-z origin` is specified to the linker when
using `$ORIGIN`, as required on this platform.
2. Explicitly set the rpath in the `dsohandle-multi-module` execution
test, since the test uses built dynamic libraries during the test.
3. Erase the environment variable instead of using `env -u`, the latter
of which is not portable.
This changes the install layout to be similar across Darwin and
non-Darwin platforms. This will enable simplifying the user experience,
build infrastructure, and the driver as the SDK layout converges towards
a single layout on all the platforms.
The `-force-single-frontend-invocation` flag predates WMO and is now an
alias for `-whole-module-optimization`. We should use the latter and let
the former fade into history.
TBD generation is not constrained to Darwin and it trips on the linker
synthetic `__ImageBase`. XFAIL this until the TBD generation is either
constrained or is taught to ignore the synthetic. This should
temporarily allow us to enable validation tests on Windows.
This just uses the `%target-build-swift-dylib` instead of
`%target-build-swift` substitution along with `%target-library-name` to
ensure that we are target independent.
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
Test requiring ASan are currently failing on internal bots that test
back deployment because of a test infrastructure problem with ASan bac
deployment.
Mark those tests as unsupported for remote_run (which is currently only used
for those back-deployment tests) until we can address the underlying issue.
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.
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".
Finally, remove the parent type metadata argument from type
constructors.
Now that type constructors don't take a parent metadata pointer,
we can hit some asserts concerning type constructors that do not
have any parameters. This happens when you define a concrete type
in a fully-constrained extension of a generic type.
A more efficient ABI would use concrete type metadata for these
cases, but that would be a bigger change that we can do later, so
for now just relax these assertions.
This resolves a runtime crasher since a circular metadata case is
no longer circular. I renamed the crasher to reference the more
specific radar since the more general issue of circular metadata
is still unresolved.
Investigating a problem with execution tests on other platforms
when building multiple dylibs and an executable that builds them.
rdar://problem/27620565
There wasn't an execution test involving #dsohandle, so add one here.
Also, the DSO handle coming from different modules should never be
the same.
rdar://problem/26565092
This is the Linux equivalent of 3731a2ff0. There's probably a way to
merge them into one file cleanly, but the extra linker args on OS X
make it a little tricky. I'm deciding not to worry about it right now.
...when interpreting. Otherwise, the script may depend on library X, which
depends on library Y, where library Y is a standard Swift library, located
in lib/swift/$PLATFORM/.
Finishes rdar://problem/23588774
...as described in rdar://problem/23588774. We don't really have a good way
to make this test cross-platform as such, but I'll add a Linux version soon.
