They were always enabled, meaning migrating from Swift 4 -> 4.2 would pick up
the associated fixits and add @objc unnecessarily in many places.
Resolves rdar://problem/39951671
To support migration from both Swift 3 and 4, this patch
teaches the driver to pick up the right set of migration scripts
according to the given Swift version. We also pushed some placeholder script
files for migration from Swift 4. This patch also brings the migrator
up-to-date by avoiding migration if the Swift version is already 4.2.
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
Encapsulate uses of the variables in FrontendInputs with intention-describing functions. Move some code that sets these variables into FrontendInputs and FrontendOptions classes.
Create new FrontendInputs class to encapsulate InputFilenames, InputBuffers and PrimaryInput, which were formerly in Frontend.
Includes one change in SwiftEditor.cpp to resolve a merge conflict.
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
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
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
This code is too clever to survive and is causing crashes in the
migrator. It doesn't appear to be providing a noticeable performance
benefit, so disable line-level diffing and just do a fine-grained
diff throughout.
rdar://problem/32281108
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
Xcode has some interesting behavior w.r.t. standalone removal
entries. In the previous migrator, there was an adjustment for
that, so port that over.
rdar://problem/31976029
- Don't include inserts in the offset calculation
- Fix colon placement when printing JSON
- Consolidate adjacent insert/removal pairs into a single replacement,
as this is what the remap applier expects.
rdar://problem/31872288
After both the syntactic and fix-it passes have run, perform
a diff of the start and end states' texts and output the remap
file.
rdar://problem/30926019
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
The SyntacticMigratorPass is getting Too Big To Fail and covers
multiple migrations. There was already an early exit to not run
the pass if APIDigesterDataStorePath wasn't supplied, so SE-0110
tuple splat fix-its weren't getting run. This manifested in Migrator
tests not printing migrated contents on Linux.
New: ASTMigratorPass
Renamed: SyntacticMigratorPass -> APIDiffMigratorPass
New: TupleSplatMigratorPass
These implementations are entirely hidden and can only be invoked
by a swift::migrator function.
rdar://problem/32025974
The warnings about deprecated @objc inference in Swift 3 mode can be a
bit annoying; and are mostly relevant to the migration workflow. Make
the warning emission a three-state switch:
* None (the default): don't warn about these issues.
* Minimal (-warn-swift3-objc-inference-minimal): warn about direct
uses of @objc entrypoints and provide "@objc" Fix-Its for them.
* Complete (-warn-swift3-objc-inference-complete): warn about all
cases where Swift 3 infers @objc but Swift 4 will not.
Fixes rdar://problem/31922278.
Based on recommendations in SE-0160, there are two migration workflows:
- Conservative: Maintain @objc visibility that was inferred in Swift 3
by adding @objc to all declarations that were implicitily visible to
the Objective-C runtime. This is invoked in the migrator by adding the
-migrate-keep-objc-visibility flag.
- Minimal: Only declarations that must be visible to Objective-C based
on their uses (or in cases like dynamic vars) are migrated.
rdar://problem/31876357
This handles optionality changes and type rewrites in function param and return types and constructor param and failability types.
Resolves rdar://problem/31766010
In the Migrator, the AST passes (effectively syntactic edits only)
run before the fix-it passes. We try to reuse as much as possible
from the original CompilerInvocation, but we need to replace the
primary input. Nuking all of the inputs is a bit foolish :-).
rdar://problem/31858212
I had set up the driver to invoke a separate frontend invocation with
the "update code" mode. We sort of did this last release, except we
forked to the swift-update binary instead. This is causing problems with
testing in Xcode.
Instead, let's perform a single compile and add the remap file as an
additional output during normal compiles. The driver, seeing
-update-code, will add -emit-remap-file-path $PATH to the -c frontend
invocation.
rdar://problem/31857580
When running the fix-it passes, we should explicitly set the effective
language version to 4, since passing language version 3 may be the
default at first.
rdar://problem/31854159
This adds an adapter class that wraps Clang's lib/Edit
Commit and EditedSource classes for use in the initial
"syntactic" passes. Once the passes have completed,
the resulting source file is then passed to the Swift compiler
fix-it passes.
rdar://problem/30926261
These data files are installed into runtime resource directory so that migrator can pick them automatically according to specific platforms. To support testing, a front-end option -api-diff-data-file can be used to specify the data file to use and it will overwrite the default ones from resource directory.
The Swift 4 Migrator is invoked through either the driver and frontend
with the -update-code flag.
The basic pipeline in the frontend is:
- Perform some list of syntactic fixes (there are currently none).
- Perform N rounds of sema fix-its on the primary input file, currently
set to 7 based on prior migrator seasons. Right now, this is just set
to take any fix-it suggested by the compiler.
- Emit a replacement map file, a JSON file describing replacements to a
file that Xcode knows how to understand.
Currently, the Migrator maintains a history of migration states along
the way for debugging purposes.
- Add -emit-remap frontend option
This will indicate the EmitRemap frontend action.
- Don't fork to a separte swift-update binary.
This is going to be a mode of the compiler, invoked by the same flags.
- Add -disable-migrator-fixits option
Useful for debugging, this skips the phase in the Migrator that
automatically applies fix-its suggested by the compiler.
- Add -emit-migrated-file-path option
This is used for testing/debugging scenarios. This takes the final
migration state's output text and writes it to the file specified
by this option.
- Add -dump-migration-states-dir
This dumps all of the migration states encountered during a migration
run for a file to the given directory. For example, the compiler
fix-it migration pass dumps the input file, the output file, and the
remap file between the two.
State output has the following naming convention:
${Index}-${MigrationPassName}-${What}.${extension}, such as:
1-FixitMigrationState-Input.swift
rdar://problem/30926261
