Their definition is fully visible to clients to be copied into them, and there isn't necessarily
a symbol for the property descriptor in the defining module, so it isn't necessary or desirable to
try to use a property descriptor with them. Trying to reference the descriptor leads to missing
symbol errors at load time when trying to use keypaths with older versions of the defining dylib,
which goes against the purpose of `@_alwaysEmitIntoClient` meaning "no ABI liabilities for the
defining module". Fixes rdar://94049160.
The resilience test helper builds up invocations of the tooling. In
order to do this, we need to know what host we are building for. Plumb
the value for `-triple` from the test harness into the utility. This
will be used subsequently to enable additional testing for Windows.
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.
A resilient change should not *remove* previously-public symbols.
Note that currently, the test_superclass_properties test does not
meet this critierion, because we always emit keypath property
descriptors, even when the property is an override. Fixing this
is a larger change that I'll address in a follow-on PR, so for now
I'm just going to disable the symbol check for this one test only.
Part of <rdar://problem/40432647>.
With a few modifications:
- Changing computed get-only properties into 'let's breaks resilience in other ways we need to fix independent of key path resilience
- Fix the tests not to ask for impossible lib-before--client-after compatibility for changes that add API
