When users override a SDK function whose parameter types have been changed,
we should introduce a local variable in the body of the function definition
to shadow the changed parameter. Also, a proper conversion function should
be applied to bridge the parameter to the local variable.
rdar://41828411
Some raw representable struct from SDK can be initialized without
explicit labels (rawValue:). When their types have been changed to type
alias, we should migrate the initializer calls to the argument alone.
When inserting conversion functions around expressions, we should check
whether the type of the expression is a recognized name alias that is
known to be changed to raw-value representable type. We should avoid
inserting conversion functions in this case because doing so causes
build errors.
resolves: rdar://40463990
By postponing the insertion of conversion function calls, we can filter
out the expressions that require more than one helper function wrapper.
resolves: rdar://40979943
When users' codebase assigns an attribute dictionary that used to be of
type [String: Any], this migration inserts a helper function call on the source of
the assignment to bridge the type.
For a function call used to take [String: Any]? as argument and now
takes [StringRepresentableStruct: Any]?, a helper function is inserted
to help the bridging of types.
When a user's code calls a function that used to take [String: Any] as
argument and now takes [StringRepresentableStruct: Any], this migration
inserts a helper function to convert the argument to the
expected type.
This patch migrates simple attribute assignment and reference when the
attribute used to be of type String and later became StringRepresentable struct.
Related: rdar://38192995
