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
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.
Instead, just emit a deprecation warning and suggest switching to Optionals.
The old behavior caused several projects to break, so before we change
the behavior here we need to investigate whether we can mitigate most
of those breaks.
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
Post-commit review follow-up:
This works better for properties that were all-caps, such as `URL`.
Thanks @harlanhaskins for the tip!
rdar://problem/32845968
