When performing a binding/assignment to a weak or unowned variable/property from an initialiser call, emit a warning that the instance will be immediately deallocated.
For example, the implicit coercion from `Int!` to `Any` now produces a warning. Previously a warning wasn't emitted despite the optional being implicitly erased to `Any` (but warnings were emitted in some other cases, such as `Int?!` to `Any?`; this commit fixes that inconsistency).
When implicitly coercing a collection of optional elements to a collection of less-optional `Any` elements, e.g `[Any?]` to `[Any]`, emit a slightly better diagnostic:
Expression implicitly coerced from '[Any?]' to '[Any]'
and allow for silencing of the diagnostic with an explicit coercion, e.g `as [Any]`.
When implicitly coercing a nested optional to a less optional `Any`, e.g `Any??` to `Any?`, emit a slightly better diagnostic:
Expression implicitly coerced from 'Any??' to 'Any?'
and allow for silencing of the diagnostic with an explicit coercion, e.g `as Any?`.
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.
Swift's ASTContext contained all of the logic to find the complete list
of properties for an Objective-C class, which is used by the Clang importer
to influence the mapping of Objective-C names into Swift. Swift's
ASTContext also included a *cache* for this information, indexed by
the Clang `ObjCInterfaceDecl *`. However, this cache was getting
populated/queried from the Clang importer's name importer, such that
the keys would be Clang declarations used to build modules and then
deallocated. If that memory eventually gets reused for a different
`ObjCInterfaceDecl *`, we would get incorrect/stale all-properties
information.
Almost Surely fixes rdar://problem/35347167, which is a
nondeterministic failure where UIView's `addGestureRecognizer(_:)` gets
occasionally imported as `add(_:)`.
This fixes a pre-existing bug where implicit DeclRefExprs involving
*any* expression of the same type within a getter were flagged with
warnings, even if they were references to something other than "self".
The base mutability of storage is part of the signature, so be sure
to compute that during validation. Also, serialize it as part of
the storage declaration, and fix some places that synthesize
declarations to set it correctly.
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
In diagnoseUnintendedOptionalBehavior, guard against recursing into
non-single-expression closures. If we recurse into these, we can end
up hitting malformed ASTs that we do not expect. These happen when we
successfully type-check the code outside of the closure, but the
closure body has errors.
There are potentially other similar issues in other miscellaneous
diagnostics walks.
I opened https://bugs.swift.org/browse/SR-5758 to remind us to review
these and ensure they do not have similar issues.
