AST passes assume that you are migrating from a version earlier
than Swift 4, where declaration references and type names may be
unconditionally renamed if their USRs match.
For example, this can happen for TypeMemberDiffItem entries where the
Objective-C USR is the same in Swift 3 and Swift 4, but the type is
spelled differently in Swift 4. A concrete example of this is:
`NSDocumentTypeDocumentAttribute` (Swift 3) ->
`NSAttributedString.DocumentAttributeKey` (Swift 4).
Although this declaration is imported differently in Swift 4, its
Objective-C USR is `c:@NSDocumentTypeDocumentAttribute` for both.
rdar://problem/32604558
In https://github.com/apple/swift/pull/10414, some SE-0110 features
were backed out, so the Migrator no longer needs to add `$0` shorthand
prefixing.
rdar://problem/32907276
Some changes for SE-0110 were backed out in
https://github.com/apple/swift/pull/10414, so the migrator no longer
needs to add its own tuple destructuring.
rdar://problem/32513074
The migrator pass that converts single-argument function input types
doesn't handle the case when the function input has a label and is
therefore a tuple. Expand it to handle that possibility.
rdar://problem/32477319
If a file is run through the migration workflow a second or third time,
but fails to compile in its current state in Swift 4, it might be possible
for the previous remap file to get picked up, resulting in the old changes
getting applied twice or at the wrong offsets. At the start of the migration,
proactively remove the remap file to prevent this.
rdar://problem/32545844
We already had this functionality in the FixitApplyDiagnosticConsumer,
but we also need it in the AST passes because different entries in the
API diff data may drive identical fix-its, namely a general type rename,
which can occur anywhere a DeclRef appears, but also for function overrides'
parameter type changes, which are context specific.
rdar://problem/32431533
Setting up an invocation adds -aarch64-use-tbi if the target is for
AArch64. In the fix-it passes, we inherit the frontend options which
already has it from the driver passing it down to the frontend.
rdar://problem/32284152
The clang::RewriteBuffer can do weird things when seeing multiple
replacements where the replacement text is one character longer or
one character shorter than the range it is replacing.
rdar://problem/32234525
The migrator pass to add tuple destructuring that now needs to add a
`return` statement for closures that were once single-expression but are
no longer because of the added statement to do the binding.
rdar://problem/32433206
This can be incorrectly reported by the type-checker when
argument arity doesn't match in trailing closure arguments.
This diagnostic isn't generally useful for the migrator.
rdar://problem/32477119
rdar://problem/32432254
This isn't generally useful for Swift 4 migration and in some cases
can result in code that doesn't compile, like `for let i in ...`.
rdar://problem/32390791
rdar://problem/32390726
We used to only migrate them in call sites, e.g. changing from
``p.getHeight()`` to ``p.Height``. However, with experimenting on more real-world
projects, we realize migrating overrides is equally important.
rdar://32265583
If code is irreparably broken when migrating, make sure to
check that the pre-fix-it compiler instance is `nullptr` and
bail if so.
rdar://problem/32240138
In Swift 3:
1) a closure referring to $1 or above type checked against a function type that takes a single tuple argument with that arity
2) a closure referring only to $0 (or $0.1 etc) type checked against a function type that takes multiple arguments
but neither compiles in Swift 4.
This patch migrates shorthand references for
1) by prefixing "0." in front of the existing references, e.g. "$1" to "$0.1"
2) by removing the leading 0. if one existing or substituting a tuple of the correct arity if it doesn't, e.g. "$0.1" to "$1" and "$0" to "($0, $1, $2)"
Resolves rdar://problem/31969538
This allows the migrator to pick up fix-its from notes such as:
“Argument of #selector refers to instance method '___' that is not
exposed to Objective-C”
Add some more testing for minimal/complete workflows, and upstream
the cross-file fix-it test.
rdar://problem/32228948
Some diagnostics showing up during migration may not have valid source
locations, so we obviously can't map that onto a buffer onto which we'd
apply a fix-it.
rdar://problem/32213595
This item is to associate a usr with a special case Id, however, it's
up to the migrator to interpret the special case Id and apply proper
transformations.