ABI placeholders are decls with attribute '@available(macOS 9999, iOS
9999, tvOS 9999, watchOS 9999, *)'. The diagnostics phase could be
forgiving for ABI breakages on these decls since they are added
recently. This patch adds a new flag to the json file indicating whether
a declaration or a conformance is an ABI placeholder. The checking of
placeholder is transitive, meaning a decl is an ABI placeholder if its
decl context is one.
rdar://49502365
Protocol requirements may not necessarily add new entries to the witness table if
it's inherited from super protocol. This patch teaches the json dump to
include a flag indicating whether a protocol requirement requires new
witness table entry and diagnoses the change of such flag as ABI
breakages.
rdar://47657204
Modeling ProtocolConformance as a standalone node allows us to keep
track of all type witnesses and re-use existing matching algorithm
to diagnose type witness changes.
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
