The tool should use decl attribute kinds from AST rather than defining
its own list of attributes. Thus we can keep track of all attributes kinds
rather than the selected ones.
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.
We've also seen type changes in the frameworks from "[String: Any]?" to
"[StringRepresentable: Any]?". This patch adds specific logic and
attribute for this kind of change on the top of nonnull dictionary
changes.
The tool should diagnose the change of extension's applicability since
such change can be source-breaking. We need first to support the
requirements in the module dump. Currently, we decorate each
member defined in extension with a field called extension info. The
field will keep track of the generic requirements that need to be satisfied
for this decorated member to be applicable. This patch doesn't implement the checking
of requirements change.
Different from type hoist that moves global variables to static member
variables, we've also seen member variables being moved among different
types via apinotes. Swift-api-digester should be able to detect such
case so that migrator can handle them properly.
rdar://32466196
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.
This structure serves multiple purposes:
a. Allow migrator to speak in the same language with swift-api-digester in terms of API changes.
b. Serialize/Deserialize detected API change items in JSON format.
c. Manage memory after deserializing API change items.
d. Facilitate look up by USRs of APIs under migration.
The structure is tested by round-trip serialization and deserialization.
