Swift has diagnosed implicit uses of class-reference `self` in
escaping closures for a long time as potentially leading to reference
cycles. PR #35898 fixed a bug where we failed to diagnose this
condition in nested closures. Unfortunately, treating this as an
error has proven problematic because there's a lot of code doing
it. Requiring that code to be thoroughly stamped out before we
ship a compiler is just too much to ask. Stage the fix in by
treating it as a warning in Swift versions prior to 6.
As with the non-nested case, this warning can be suppressed by
explicitly either capturing `self` or spelling out `self.` in the
access.
Fixes rdar://80847025.
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
A lookup on the name provided by `renamed` in `@available` returns the
VarDecl. If the name specified a getter or setter, make sure to grab the
corresponding accessor when comparing candidates.
We currently ignore the basename and parameters specified in the name
for accessors. Checking them would only cause a getter/setter not to
match, there can never be a conflict. Since this is a best effort match
anyway, this seems fine.
In Swift < 6 warn about plain type name passed as an
argument to a subscript, dynamic subscript, or ObjC
literal since it used to be accepted.
Resolves: rdar://80270126
Make sure that both arguments are valid before checking conformance
to `FloatingPoint`. This helps us to debug reports of crashes in
`conformsToKnownProtocol` referencing arguments (rdar://78920375).
Since this diagnostic should only be run on type-checked AST,
it's unclear what caused one of the arguments to have null type.
Previously we were walking them once when visiting
the capture list, and then again as a part of the
pattern binding decl. Change the logic to only
visit them as a part of their pattern binding decl.
Abstract away the TupleExpr gunk and expose
`getLHS` and `getRHS` accessors. This is in
preparation for completely expunging the use
of TupleExpr as an argument list.
Add a new parameter attribute `@_implicitSelfCapture` that disables the
requirement to explicitly use `self.` to refer to a member of `self`
in an escaping closure.
Part of rdar://76927008.
Implicitly add the @completionHandlerAsync attribute for ObjCMethodDecl
that have a completion handler. Adds a link from the non-async to the
async function for use in diagnostics and refactorings.
Resolves rdar://74665226
The basic rule is that the protocol requirement
describes the maximal set of effects that the
property is allowed to have. Thus, witnesses
must have the same or fewer effects specifiers
on the getter.
For class inheritance overrides, you can remove
effects freely, as long as you stay within
the bounds of the normal override restrictions.
But, you cannot override with more effects than
the base member has. Same goes for protocol
member overrides.
Furthermore, we disallow key paths to effectful
properties/subscripts, which also cannot be @objc.
The walker was crashing if something failed to typecheck since the type
wasn't available. I've added a little test to ensure that not only do we
not crash, but continue checking within the closure.
If a tuple is passed as the only argument to a function that takes two unnamed arguments, we try to diagnose the missing argument label. However, in the old diagnose code we didn’t distinguish between non-existing arguments and arguments without labels; both behaved the same.
Thus, the missing second argument in the function call would line up with the empty second argument label, not producing a diagnostic, but hitting an assertion later on.
Distinguish between the two to fix the issue.
Fixes rdar://64319340
There is no problem with having an existential value that involves a
marker protocol. However, since there is no runtime checking for
marker protocols, ban "as?" and "is" casts to them.
The DiagnoseLifetimeIssuesPass pass prints a warning if an object is stored to a weak property (or is weakly captured) and destroyed before the property (or captured reference) is ever used again.
This can happen if the programmer relies on the lexical scope to keep an object alive, but copy-propagation can shrink the object's lifetime to its last use.
For example:
func test() {
let k = Klass()
// k is deallocated immediately after the closure capture (a store_weak).
functionWithClosure({ [weak k] in
// crash!
k!.foo()
})
}
Unfortunately this pass can only catch simple cases, but it's better than nothing.
rdar://73910632
In derivatives of loops, no longer allocate boxes for indirect case payloads. Instead, use a custom pullback context in the runtime which contains a bump-pointer allocator.
When a function contains a differentiated loop, the closure context is a `Builtin.NativeObject`, which contains a `swift::AutoDiffLinearMapContext` and a tail-allocated top-level linear map struct (which represents the linear map struct that was previously directly partial-applied into the pullback). In branching trace enums, the payloads of previously indirect cases will be allocated by `swift::AutoDiffLinearMapContext::allocate` and stored as a `Builtin.RawPointer`.
Rather than performing actor isolation checking as part of
"miscellaneous" diagnostics on an expression, do it on the whole
function at once. This should not change behavior by itself.
When a completion handler parameter has a selector piece that ends with
"WithCompletion(Handler)", prepend the text before that suffix to the
base name or previous argument label, as appropriate. This ensures that
we don't lose information from the name, particularly with delegate names.
We used to diagnose references to unavailable declarations in
two places:
- inside Exprs, right after type checking the expression
- inside TypeReprs, from resolveType()
In broad terms, resolveType() is called with TypeReprs
stored inside both Stmts and Decls.
To handle the first case, I added a new overload of
diagAvailability() that takes a Stmt, to be called from
typeCheckStmt(). This doesn't actually walk into any Exprs
stored inside the statement; this means it only walks
Patterns and such.
For the second case, a new DeclAvailabilityChecker is
now defined in TypeCheckAccess.cpp. It's structure is
analogous to the other three walkers there:
- AccessControlChecker
- UsableFromInlineChecker
- ExportabilityChecker
The new implementation of availability checking for types
introduces a lot more code than the old online logic
it replaces. However, I hope to consolidate some of the
code duplication among the four checkers that are defined
in TypeCheckAccess.cpp, and do some other cleanups that
will make the benefit of the new approach apparent.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
Enforce the actor-isolation constraint that an actor-isolated member
(e.g., a non-async instance method or an instance property) cannot be
used to conform to a protocol requirement.
Implement a basic set of isolation rules for actors, which includes:
* Asynchronous actor methods can be invoked on any actor instance.
* All mutable instance properties and synchronous instance methods are
only accessible via "self" or "super" within the context of the actor.
* Closures defined within an actor method are considered to be a
context distinct from the actor itself, are therefore are subject to
the same restrictions as above.
Together with a scheduler that ensures that asynchronous invocations
for a particular actor are serialized (at least up until they hit a
suspension point or return), this serves to isolate the actor's
instance state in a shallow manner: references to shared mutable state
can still be passed among actors, code can access global variables,
and one can still form and pass around unsafe pointers.
Pair this with some basic checking within actor contexts that
identifies a few obvious potential kinds of race conditions:
* References to captured mutable local variables from within closures.
* References to mutable global and static/class variables.
The latter are warnings, for which we currently don't have a great
suppression mechanism. That, and a lot of tuning, are still to come.
* [AST] Add 'FloatingPoint' known protocol kind
* [Sema] Emit a diagnostic for comparisons with '.nan' instead of using '.isNan'
* [Sema] Update '.nan' comparison diagnostic wording
* [Sema] Explicitly check for either arguments to be '.nan' and tweak a comment
* [Test] Tweak some comments
* [Diagnostic] Change 'isNan' to 'isNaN'
* [Sema] Fix a bug where firstArg was checked twice for FloatingPoint conformance and update some comments
* [Test] Fix comments in test file
* [NFC] Add a new 'isStandardComparisonOperator' method to 'Identifier' and use it in ConstraintSystem
* [NFC] Reuse argument decl extraction code and switch over to the new 'isStandardComparisonOperator' method
* [NFC] Update conformsToKnownProtocol to accept DeclContext and use it to check for FloatingPoint conformance
