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.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
```swift
func foo(f: Void) -> ()) {}
```
This compiler currently suggests we change this to:
```swift
func foo(f: (Void) -> ()) {}
```
That's `(()) -> ()`, almost certainly not what someone wants in Swift
4. We should suggest changing that to:
```swift
func foo(f: () -> ()) {}
```
Additionally,
```swift
func foo(f: (Void) -> ()) {}
```
Should trigger a warning that the `(Void)` input type is `(())`, and you
can't supply `()` to it in Swift 4, and suggest a fix-it change it to:
```swift
func foo(f: () -> ()) {}
```
rdar://problem/32143617
If the replacement type was a function type or protocol-constrained type (e.g. 'Class & Proto) and the existing type had a postfix ? or !, we weren't wrapping the replacement in parens. This would result in an incorrect/ambiguous new type. This patch wraps the replacement in parens if it contains an & or ->, the existing type has a trailing ? or !.
Resolves rdar://problem/32082269.
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
This changed to be resolved by overload resolution in Swift 4, and so
can suddenly be shadowed by similarly named properties and functions
that are visible at the expression's location. When in Swift 3 mode, if
there is a visible declaration named "type", add the `Swift.` prefix to
disambiguate in Swift 4 mode.
rdar://problem/31997321
Some APIs that expected a String now expect a Substring and vice
versa. To ease the transition, emit fix-its on conversion errors
between these types that the migrator can pick up.
When converting from Substring -> String, suggest wrapping in
`String.init`.
When converting from String -> Substring, suggest appending the
void subscript `[]`. (This isn't implemented yet so this is
hidden behind a flag).
This can possibly be generalized later when converting between
some sequence and its subsequence, such as Array and ArraySlice,
for example.
rdar://problem/31665649
rdar://problem/31666638
There is no implicit conversion between String and Substring, so
the migrator can offer fix-its to convert between the two by wrapping
in String.init or adding the void subscript [] accordingly. This
commit just adds the tests for migration for the time being.
rdar://problem/30928902
With SE-110, the migrator may get a recommendation to add a Void
placeholder in the call to f in:
func foo(f: (Void) -> ()) {
f()
}
Here, f was () -> () in Swift 3 but now (()) -> () in Swift 4. Adding a
type placeholder in the f() call isn't helpful for migration, although
this particular fix-it should be to fix the f parameter's type.
rdar://problem/31895432
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
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
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
