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
* Refactor Tuple Type Syntax
This patch:
- Refactors TypeArgumentListSyntax and
TypeArgumentListSyntaxData to use the SyntaxCollection and
SyntaxCollectionData APIs.
- Refactors TupleTypeElementSyntax to own its trailing comma, and
updates the tests accordingly.
- Provides an infrastructure for promoting types to use
the SyntaxCollection APIs
* Addressed comments.
* Renamed makeBlankTypeArgumentList()
* Update makeTupleType
* Changed makeTupleType to take an element list.
* Updated comment.
* Improved API for creating TupleTypeElementListSyntax'es
* Added round-trip test
* Removed last TypeArgumentList holdovers.
* Fixed round-trip test invocation
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
Implements the following grammar productions:
- function-parameter-list
- function-parameter
This is mostly reusable for other flavors of function declarations,
such as initializers and whatnot, but those will have separate
top-level syntax nodes.
https://bugs.swift.org/browse/SR-4067
This will make it easier to incrementally implement syntax nodes,
while allowing us to embed nodes that we do know about inside ones
that we don't.
https://bugs.swift.org/browse/SR-4062
Also includes for its substructure:
- function-call-argument
- function-call-argument-list
- symbolic-reference-expression (for the call target)
https://bugs.swift.org/browse/SR-4044
A return statement needs something to return, so implement
integer-literal-expression too. This necessarily also forced
UnknownExprSyntax, UnknownStmtSyntax, and UnknownDeclSyntax,
which are stand-in token buckets for when we don't know
how to transform/migrate an AST.
This commit also contains the core function for caching
SyntaxData children. This is highly tricky code, with some
detailed comments in SyntaxData.{h,cpp}. The gist is that
we have to atomically swap in a SyntaxData pointer into the
child field, so we can maintain pointer identity of SyntaxData
nodes, while still being able to cache them internally.
To prove that this works, there is a multithreaded test that
checks that two threads can ask for a child that hasn't been
cached yet without crashing or violating pointer identity.
https://bugs.swift.org/browse/SR-4010
Add a little visualization for a code snippet showing the main
players in the Syntax tree, showing where the strong references
flow.
NFC - documentation only.
