Also rename it to `getExplicitReturnStmts` for clarity and have it
take a `SmallVector` out parameter instead as a small optimization and
to discourage use of this new method as an alternative to
`AnyFunctionRef::bodyHasExplicitReturnStmt`.
`participatesInInference` is now always true for
a non-empty body, remove it along with the separate
type-checking logic such that empty bodies are
type-checked together with the context.
Remove this bit from function decls and closures.
Instead, for closures, infer it from the presence
of a single return or single expression AST node
in the body, which ought to be equivalent, and
automatically takes result builders into
consideration. We can also completely drop this
query from AbstractFunctionDecl, replacing it
instead with a bit on ReturnStmt.
Teach the constraint system to use the same primitives as elsewhere to
determine the type context for a `throw` statement and the caught
error type within a `do..catch` statement. This makes
explicitly-specified `throws` work on `do..catch` that occurs in
closures.
Cleans up some redundant computations for caught error types.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
`__shared` and `__owned` would always get mangled, even when they don't have any effect
on ABI, making it unnecessarily ABI-breaking to apply them to existing API to make
calling conventions explicit. Avoid this issue by only mangling them in cases where they
change the ABI from the default.
Deserializing a source location will compute the declaration's USR, which
might trigger another request cycle, etc.
Tentative fix for rdar://problem/80546848, but I don't have a test case.
While 'defer' is implemented as a local function, it doesn't
behave as one. In particular, since SILGen runs it after
destroying all local bindings that appear after the 'defer'
definition, the body of a 'defer' cannot forward reference
captured bindings the way that local functions can.
Note that I had to remove a SILGen test case for an older,
related issue. The new diagnostic in Sema catches these cases
earlier.
Fixes rdar://problem/75088379.
when it has property wrapper parameters.
The property wrapper type will be replaced with either the wrapped-value
or projected-value type, depending on the argument label/parameter name,
and CSApply will build a thunk to construct the property wrapper and call
the function.
Replace the existing warning about any access to a local variable from
concurrently-executing code with a more tailored error:
concurrently-executing code may read a mutable varable, but cannot
modify it. This is safe so long as we either always do by-value
captures in concurrent closures or we ensure that no mutation of that
variable can occur after the point of capture.
We'll follow up with one of those. For now... be careful out there.
Since we're promoting this to an error, narrow it down to concurrent
closures and local functions, dropping the assumption that escaping
closures "may execute concurrently."
Slim down CSApply.cpp by moving the logic for applying a solution to a
closure into CSClosure.cpp. Also, eliminate duplicated logic for applying
function builders to the body of a closure or function. This should
not change semantics at all.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
* Diagnose missing expr in non-void single-expr func. [52025782]
After SE-0255, compiling
```
func foo() -> Int {
return
}
```
would result in a diagnostic without source location:
```
<unknown>:0: error: cannot convert return expression of type '()' to
```
Now, it results in
```
filename.swift:8:5: error: non-void function should return a value
return
^
```
as it did prior to SE-0255.
To achieve that, during type checking for statements, when the
StmtChecker visits return statements, check whether we are within a
non-void-returning, single-expression function and that that single
expression is an implicit empty tuple. (An empty implicit tuple is
added as the result of a resultless return statement that appears as the
only element in a single-expression function.)
To facilitate that, `hasSingleExpressionBody` and
`getSingleExpressionBody` was added to `AnyFunctionRef` and added
`getSingleExpressionBody` to `AbstractClosureExpr` (which already had
`hasSingleExpressionBody`).
rdar://problem/52025782
The new analysis simply checks if the captured value has been defined
yet; instead of asserting if it hasn't, we can now emit a diagnostic
using the source location tracked in the capture list.
Fixes <https://bugs.swift.org/browse/SR-4812>, <rdar://problem/40600800>.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
When lowering closures, we avoid capturing the enclosing generic context when possible. However, the generic context may still be necessary to canonicalize types mentioned inside the closure, such as when an associated type is referred to that is same-typed to a concrete type. Fixes rdar://problem/30254048.
