We cannot link against the DSO (dll) on Windows and instead link against
the import library. Let the driver understand this and use the standard
linking technique. Adjust the name of the emitted files accordingly and
use the `%target-library-name` macro more freely.
Two tests remain:
- multifile.protocol-conformance-member
The getter is synthesized by not exported so `llvm-nm` is unable to
see it
- multifile.nested_types
Windows uses the singleton strategy, so the emitted full type
metadata does not have the reference to the value witness table for
Void
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.
Our walk over the requirement interface types meant that
computing the access level of an extension member depended
on type resolution and the GSB.
Fix this by adding a new request that simply collects all
TypeDecls referenced from a TypeRepr, and compute the
extension's maximum access level using that.
If we use Structural rather than Interface type resolution when
walking the extension's requirements, we don't have to build its
generic signature first.
When adding a designated initializer to a nominal type in another
module, we would call getType() on deserialized VarDecls, which
is not allowed.
Instead, it is more correct to use SILTypes throughout and call
SILType::getFieldType() to get a substituted field type.
Fixes <https://bugs.swift.org/browse/SR-3545>.
