This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
With the argument list refactoring, it's no
longer sufficient to stop walking when we encounter
an explicit tuple or paren. Add an additional
check to stop walking when we encounter an explicit
argument list.
rdar://85343171
Now that placeholder types are preserved, we can open them wherever they appear in positions where they are used as contextual types. Use the checks we already run in the primaries to ban placeholders in top-level positions. Only now, use the inferred type of any associated expressions or statements to present the user with a contextual return type.
For parameters in functions and enum cases, we use any default argument expressions to get the contextual type.
For functions, we use a traversal similar to the opaque result type finder to find the type of any return statements in the program and present those as options.
For a non-public property where the type is defined by an assignment, like
`internal var internalAssigned = NewStruct()`, type-checking the type's
availability is done via checking the initializer expression.
In -check-api-availaiblity-only mode, pass down a flag to not check
availability in expressions for initializer expressions of such
non-public properties.
rdar://84389825
We've always emitted an error if we saw an implicit use of a self
parameter of class type from an escaping closure. In PR #35898, I fixed
this to also emit an error if the reference was to an explicit capture
of self that wasn't made in the current closure. That was causing
some source incompatibilities that we decided were too severe, so in
PR #38947 I weakened that to a warning when the diagnostic walk was
within multiple levels of closures, because I have always thought of
this as a fix to nested closures. However, this was the wrong condition
in two ways.
First, the diagnostic walk does not always start from the outermost
function declaration; it can also start from a multi-statement closure.
In that case, we'll still end up emitting an error when we see uses
of explicit captures from the closure when we walk it, and so we still
have a source incompatibility. That is rdar://82545600.
Second, the old diagnostic did actually fire correctly in nested
closures as long as the code was directly referring to the original
self parameter and not any intervening captures. Therefore, #38947
actually turned some things into warnings that had always been errors.
The fix is to produce a warning exactly when the referenced declaration
was an explicit capture.
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
With the introduction of the ArgumentList type,
argument expressions will be direct decedents of
call expressions, without an intermediate TupleExpr.
As such, we need to tweak isValidTypeExprParent to
consider the child expression such that `T(x)` is
permissible, but `x(T)` is not.
Change isValidTypeExprParent to take a child expr
parameter, and update its use in MiscDiagnostics
and PreCheckExpr. For PreCheckExpr, switch from a
stack to walking the parent directly, as a
stack-based approach would be a bit more fiddly in
this case, and walking the parents shouldn't be
expensive.
This should be NFC, I'm splitting it off from the
ArgumentList refactoring to make the rebasing there
a little more straightforward.
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
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
