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.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
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.
* [SR-4005] Allow heterogenous comparisons in elementsEqual
When a user is supplying a predicate to compare the type equivalence
isn’t required
* elementsEqualWithPredicate tests
Compares a string of a number with an integer value by using the
elementsEqualPredicate closure
* Update test expectations to use new sequence element types
* Update hardcoded test to reference sequence
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
A variety of enhancements from SE-154 and SE-165:
- Custom Keys and Values collections for Dictionary
- Two sequence-based Dictionary initializers
- Merging methods for Dictionary
- Capacity checking and reserving for Dictionary and Set
- Type-specific filter(_:) methods for Dictionary and Set
- A mapValues(_:) method for Dictionary
- A grouping Dictionary initializer
* 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.
