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.
* Update usage checking to account for __shared parameters as immutable
* Allow pattern type checking to resolve Shared parameters to the appropriate parameter specifiers
* Add the __shared protocol requirement restriction
just for pointer identity.
The current technique for deciding whether that's the case is *extremely*
hacky and need to be replaced with an attribute, but I'm reluctant to
take that on so late in the schedule. The hack is terrible but not too
hard to back out in the future. Anyone who names a method like this just
to get the magic behavior knows well that they are not on the side of
righteousness.
rdar://33265254
Also, begin to pass around base types instead of raw InOutType types. Ideally, only Sema needs to deal with them, but this means that a bunch of callers need to unwrap any inouts that might still be lying around before forming these types.
Multiple parts of the compiler were slicing, dicing, or just dropping these flags. Because I intend to use them for the new function type representation, I need them to be preserved all across the compiler. As a first pass, this stubs in what will eventually be structural rules as asserts and tracks down all callers of consequence to conform to the new invariants.
This is temporary.
When inside a declaration or extension of TypeName, humans usually don't write
the full typename like #selector(TypeName.foo), but instead prefer the neater
form #selector(self.foo). The compiler has enough information to do this too.
Fixes rdar://problem/25284692 .
Saying "implicitly non-escaping because it was declared @autoclosure"
does not make sense. Since Swift 3, parameters of function type are
non-escaping by default, whether or not they are @autoclosure.
We would also inhibit the fixit for inserting @escaping if the
@autoclosure attribute was present. Again, a holdover from the
Swift 2 days, when @autoclosure implied @noescape and the special
@autoclosure(escaping) attribute was used to define an escaping
autoclosure.
