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.
When trying to figure out errors from an import failure, the nullability
completeness warnings would clutter the output making it difficult to
identify the errors. Sprinkle the declaarations with
`_Null_unspecified` to maintain the current nullability semantics and
silence the warnings. NFC.
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.
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
