blocks:

• SR-257 Resilient value type support -- umbrella bug

Issue Description:

Right now, SILGen conservatively uses address-only semantics for types that are resilient anywhere. Resilient types defined in the current module however are allowed to be accessed directly, with the following caveats:

• Transparent function bodies are serialized with the module and inlined into other SIL modules, so they must continue using address-only semantics

• Entry points of public functions should use address-only semantics for parameters that are resilient anywhere

This means the prolog of a SIL function should load any indirect parameters that in fact have a loadable type lowering.

Private functions that pass around resilient types from the current module can use an efficient calling convention on the other hand.

• Function values should use an abstraction pattern with address-only semantics for parameters that are resilient anywhere, to avoid re-abstraction thunks.

This means that in the following, 's' and 'ss' will use different calling conventions, but the parameter 'g' of 'f' and 'ff' will use the same one:

struct S {}
func s(s: S) {ss(s) }
public func ss(s: S) {}

func f(g: S -> S) { ff(g) } // no thunking of 'g' here
public func ff(g: S -> S) {}

This requires adding a ResilienceExpansion to SILFunction and changing SILGenFunction's type lowering to pass this down to the TypeConverter. The TypeConverter will then need to cache different type lowerings for each ResilienceExpansion. This might increase memory usage too much – if so, some trick can be used where a type that has the same lowering in all expansions doesn't need to store the expansion as part of the key.