CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
Ensure the various entity walkers handle the implicit subscript
reference correctly (usually by ignoring it) and fall through to the
underlying declarations.
rdar://49028895
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
We were trying to get fancy rewriting cases where multiple 'if let' clauses were
used to unwrap a double optional, but in testing that turned out to be too
unreliable. Now we simply detect any 'try?' expressions whose behavior will change,
and add an explicit 'as OldType' to the expression, in order to preserve the original
behavior.
This migrates anything using the following pattern:
```swift
if let optX = try? someOptional(),
let x = optX,
...
```
to this:
```swift
if let x = try? someOptional(),
...
```
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
In Swift3, shadowning type(of:) was impossible, because it was a parser
magic. In Swift4, type(of:) is resolved as normal function in stdlib so
it can be shadowed. 'TypeOfMigratorPass' was a targeted migrator pass
that prepend 'Swift.' to 'type(of:)' so that it refers Swift.type(of:)
stdlib builtin function.
When users override a SDK function whose parameter types have been changed,
we should introduce a local variable in the body of the function definition
to shadow the changed parameter. Also, a proper conversion function should
be applied to bridge the parameter to the local variable.
rdar://41828411
Some raw representable struct from SDK can be initialized without
explicit labels (rawValue:). When their types have been changed to type
alias, we should migrate the initializer calls to the argument alone.
In Swift 4.2 the second parameter of UIApplicationMain exactly matches the type
of CommandLine.unsafeArgv so it can be called as below:
UIApplicationMain(CommandLine.argc, CommandLine.unsafeArgv, ...)
This is how it was intended to be in Swift 4 as well, but the types had
optionality differences, so callers instead had to do something like the below
example from the Firefox-iOS project:
let pointer = UnsafeMutableRawPointer(CommandLine.unsafeArgv).bindMemory(
to: UnsafeMutablePointer<Int8>.self, capacity: Int(CommandLine.argc))
UIApplicationMain(CommandLine.argc, pointer, ...)
This migration simply replaces the the second argument with
CommandLine.unsafeArgv if the first argument is CommandLine.argc.
There is an open issue for providing a deprecated version with the old type so
we simply leave as is any callers that don't pass argc for the first argument.
Resolves rdar://problem/40045693.
When inserting conversion functions around expressions, we should check
whether the type of the expression is a recognized name alias that is
known to be changed to raw-value representable type. We should avoid
inserting conversion functions in this case because doing so causes
build errors.
resolves: rdar://40463990
if users' member access doesn't specify the base name. rdar://40373279"
Previously, we saw that unconditionally omitting type names can lead to
build errors (rdar://40458118). This revised fix omits type names only when
the new member name is identical to the old one.
By postponing the insertion of conversion function calls, we can filter
out the expressions that require more than one helper function wrapper.
resolves: rdar://40979943
