This fixes a bug found while building Swift for Windows. The CMake invocation
assumed that the host system had a utility called `create_symlink`. That
assumption breaks down on Windows, where `copy` is the equivalent tool.
- 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.
* Simplify TupleTypeRepr parsing
This patch introduces a TupleTypeReprElement struct that holds the
locations for all relevant bits of tuple elements. It removes the
NameLoc and UnderscoreLoc arrays from TupleTypeReprElement in favor of
holding each of these on TupleTypeReprElement. These extra bits of info
are required for full-fidelity representation in the Syntax library.
* Remove TupleTypeReprBitfields and move EllipsisLoc out of TrailingObjects
* Update users of TupleTypeRepr
* Don't resize the elts if we're going to push_back
* getType -> getElementType
* Move ellipsis back into TrailingObjects.
* Move NumElements into TupleTypeReprBitfields
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.
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
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
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
