A label range of 0 length was being reported as the label of trailing closure
arguments, just before the opening '{'.
For the rename refactoring, this meant that if the corresponding parameter had
an external label (e.g. 'a') the occurrence would be treated as not matching the
expected symbol name, and so not be updated at all.
For the migrator, when renaming a function with an unlabelled closure for its
last parameter to have a label, it would incorrectly insert the new label in
front of the opening '{' on all of that function's callsites with trailing
closures.
Resolves rdar://problem/42162571
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
This had to be reworked a bit to deal with the fact that IUOs are no
longer a distinct type and there were uses of IUOs that are not
supported after SE-0054.
Fixes: rdar://problem/37040141
The migrator only applies changes from the APIDiffMigratorPass in the primary
file. This means that if a nominal type was renamed, for example, any members
users have added in an extension in a separate file won't be visible, because
the extension would still have the old name. This can result in 'wrong argument
label' errors with fixits to change the argument labels that, when applied by
the fixit pass, completely change which function was being called and cause
post-migration errors.
This patch updates the fixit pass to ignore diag::wrong_argument_labels.
diag::extra_argument_labels and diag::missing_argument_labels were already
filtered out for other reasons.
Resolves rdar://problem/40170377
The APIDiffMigrator pass was ignoring them in all cases, but function type
argument parens are significant and the API differ includes them as an index
level in the generated json. This was causing a segmentation fault when trying
to migrate anything inside a function type argument. E.g given the function
below:
func member(_ x: ([Any]?) -> Void) {}
to migrate Any to Int, the API differ produces an index into the signauture of
1:1:0:0:0, meant to indicate Any. The APIDiffMigratorPass was interpreting this
incorrectly, however:
1: The type of first parameter of member: ([Any]?) -> Void
Migrator agreed.
1: The type of the function type's argument: ([Any]?)
Migrator saw this as [Any]? due to the parens not being an index level
0: The 0th child of the paren type: [Any]?
Migrator saw the 0th child of the optional, [Any]
0: the 0th child of the optional type, [Any]
Migrator saw the 0th child of the array, Any
0: the 0th child of the array type, Any
Migrator tried to look up the 0th child of Any, causing a crash.
Resolves rdar://problem/40225476.
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
Previously, we only handle dot syntax call expression for qualified
replacement, i.e. changing from A.a to B.b. This patch teaches the tool
to handle the migration of member reference expression tool.
