This is mostly NFC; the output of the api-digester test changed because
the interface type of an enum element now has parentheses around the
'Self' parameter type. This is more consistent with everything else
(and in the future, all function types will have "parentheses").
The information about whether a variable/property is initialized is lost in the
public interface, but is, unfortunately, required because it results in a symbol
for the initializer (if a class/struct `init` is inlined, it will call
initializers for properties that it doesn't initialize itself). This is
important to preserve for TBD file generation.
Using an attribute rather than just a bit on the VarDecl means this fits into
the scheme for module interfaces: textual/valid Swift.
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.
We previously shied away from this in order to not /accidentally/
depend on it, but it becomes interesting again with textual
interfaces, which can certainly be read by humans. The cross-file
order is the order of input files, which is at least controllable by
users.
hash(into:) needs to be included in expectations; tests looking at synthesized Hashable implementation bodies need to be updated for resilient hashing.
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.
Framework authors can use SwiftWraper:none to bring back string enums
to type alias of String. When diagnosing source breaking changes, these
type alias are shown as removed. Therefore, it's hard to tell whether these
changes are automatically migratable. This patch refines the
removed-type-alias by further analyzing whether a
RawRepresentable with the same usr appeared in the later version of
SDK. If there is, another kind of message is emitted for differentiation.
This allows us to map back from a type to the declaration in the dump,
so that we can perform more fine-grained analysis like whether a string
has been changed to string enum.
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.
When diagnosing API source-breaking changes, we
should also output the header file name from where the affected Clang
declaration is defined.
This may expedite screening process.
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
When we compare the APIs of entire SDKs, we can assume super classes
are always present in the API dump. However, this assumption is invalid
for framework-level API diff checking, where super classes can come from
other modules whose contents are not serialized.
rdar://33110442
This patch restricts the detection of moved members to be static members,
since only in this case we need to update qualified access to
them. The move of instance members will be either handled by rename or
we don't need to update anything at all.
Additionally, this patch introduces a sub-kind of type member diff item
called qualified replacement to describe the aforementioned case. However,
the migrator part has not started to honor this sub-kind yet.
rdar://32466196
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
* swift-api-digester: ensure constructors are detected as removed if not moved. rdar://31694119
* swift-api-digester: types with the same printed name are considered behavior-preserving. rdar://31694085
* [test] Using tmp directory from build.
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.
* swift-api-digester: Add a test for generating migrator script.
* swift-api-digester: Add #ifndef guard before each macro category.
* swift-api-digester: Avoid printing macro categories with empty content.
* swift-api-digester: Add test for multiple type changes in a single decl.
* swift-api-digester: simplify some code. NFC
