We have to set the SILFunction's 'weakLinked' flag in the defining
module too, so that it can be serialized. Otherwise when we
deserialize it we are not weak linking calls to the function.
If the conforming type is generic, we have to treat the conformance as
resilient if it is defined outside of the current module.
This is because it can resiliently change from being non-dependent
to dependent.
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.
Basically the pattern to optimize is:
inject_enum_addr %stackloc, #SomeCase
switch_enum_addr %stackloc ...
This works even if the enum is resilient and the case does not have a payload. As long as we don't have opaque values in SIL we need this peephole to optimize the pattern.
This change fixes the code generation for Float.rounded().
rdar://problem/46353885
@_fixed_layout classes have resilient vtables now, so we can add and
re-order methods.
Removing overrides is not legal though because they are subject to
devirtualization.
- We don't want to support changing a root class of a class, so don't
pretend that works. Some of these tests got removed recently in
d8104e7e43 but one still remained.
- For the tests that insert a non-root superclass in the inheritance
hierarchy, also test calling a method of the derived class. This
works now that we no longer hardcode vtable offsets and instead use
dispatch thunks.
We want removing a property override to be a resilient change, so
keypaths should not reference them, preferring to reference the
base declaration instead.
Instead of passing in a DeclContext, which we don't have when emitting a keypath
accessor, pass in a ModuleDecl and ResilienceExpansion.
Keypaths now work well enough in inlinable contexts that we can check in an
end-to-end resilience test.
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>.
Get the attribute working for more link entity kinds, which addresses
all the FIXME:s in the original test case.
Now the protocol resilience tests can be updated to use @_weakLinked
for all newly-added protocol requirements and default implementations.
This allows the tests to pass in the backward deployment test scenario
as well.
Eventually this will be based on availability instead of a special
attribute.
This completes <rdar://problem/29888071>.
The witness table for an empty, resilient protocol might need to be
instantiated, if a newer version of the protocol contains defaulted
associated type requirements. In such cases, we would either fail to
instantiate or assert in the runtime. Replace the assertion with a
proper check (to require instantiation in such cases) and cope with
filling in defaults even when the provided generic witness table has
no resilient witnesses.
For a resilient protocol that has defaulted associated types, emit
default associated conformance witnesses that compute associated
conformances based on that default witness.
This completes the implementation of resilience protocols that
add new, defaulted associated types, rdar://problem/44167982.
When an associated type witness has a default, record that as part of
the protocol and emit a default associated type metadata accessor into the
default witness table. This allows a defaulted associated type to be
added to a protocol resiliently.
This is another part of rdar://problem/44167982, but it’s still very
limiting because the new associated type cannot have any conformances.
Generic parameter references, which occur in generic requirement
metadata, were hardcoding associated type indices. Instead, use
relative references to associated type descriptors and perform the
index calculation at runtime.
Associated types can now be reordered resiliently (without relying on
sorting), which is the first main step toward rdar://problem/44167982.
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
Builds on 36eae9d4f6 to emit a message instead of just trapping
when a switch over a non-frozen enum ends up not matching anything.
If the enum is known to be an @objc enum, the message is
unexpected enum case 'MyEnum(rawValue: -42)'
and if it's anything else (a Swift enum, a tuple containing enums,
whatever), it's a more opaque
unexpected enum case while switching on value of type 'MyEnum'
The reason for this is to avoid calling String(describing:) or
String(reflecting:) an arbitrary value when the enum might conform to
CustomStringConvertible and therefore /itself/ have a switch that's
going to fall off the end. By handling plain @objc enums (using a
bitcast), we've at least covered the 90% case.
rdar://problem/37728359
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
We're okay with saying this is a binary-breaking change, and its
presence in these tests is interfering with testing other things.
rdar://problem/36932507
Since field offsets are now encoded after generic parameters, it
is useful to validate that using generic parameter metadata is now
more resilient in presence of new fields.
