Rework the lazy function body parsing mechanism to use the
request-evaluator, so that asking for the body of a function will
initiate parsing. Clean up a number of callers to
AbstractFunctionDecl::getBody() that don't actually need the body, so
we don't perform unnecessary parsing.
This change does not delay parsing of function bodies in the general
case; rather, it sets up the infrastructure to always delay parsing of
function bodies.
Introduce callables: values of types that declare `func callAsFunction`
methods can be called like functions. The call syntax is shorthand for
applying `func callAsFunction` methods.
```swift
struct Adder {
var base: Int
func callAsFunction(_ x: Int) -> Int {
return x + base
}
}
var adder = Adder(base: 3)
adder(10) // desugars to `adder.callAsFunction(10)`
```
`func callAsFunction` argument labels are required at call sites.
Multiple `func callAsFunction` methods on a single type are supported.
`mutating func callAsFunction` is supported.
SR-11378 tracks improving `callAsFunction` diagnostics.
Double-underscored names are reserved for the C++ "implementation"
(language and standard library). Even though "__Consuming" isn't
likely to be part of the C++ standard any time soon, we should follow
the rules.
Note that the API digester will continue to use the string
"__Consuming" for now, even though the underscores aren't really
significant, to avoid invalidating existing dumps.
No functionality change.
The only place this was used in Decl.h was the failability kind of a
constructor.
I decided to replace this with a boolean isFailable() bit. Now that
we have isImplicitlyUnwrappedOptional(), it seems to make more sense
to not have ConstructorDecl represent redundant information which
might not be internally consistent.
Most callers of getFailability() actually only care if the result is
failable or not; the few callers that care about it being IUO can
check isImplicitlyUnwrappedOptional() as well.
Instead of visiting all members of all types and extensions, bail out
early if the type is not a class or protocol, or the extension is not
extending a class. This means we don't visit structs, enums or
protocol extensions at all, which will avoid delayed parsing.
Also, we were evaluating isObjC() on each member, which is an expensive
operation; if the member does not have an explicit @objc we would still
have to check if it overrides an @objc method or witnesses an @objc
protocol requirement.
Since most members are not ever found by dynamic lookup, this is wasted
work. Instead, let's rely on AnyObject lookup filtering non-@objc
members at the call site, which it was already doing anyway.
PatternBindingInitializer may not be attached to any
PatternBindingDecl. e.g.
struct S {
@CustomAttr(something)
}
In this case DeclContext for 'something' is PatternBindingInitializer,
but it doesn't have PatternBindingDecl because it's not written yet.
Fixes a crash in code-completion.
rdar://problem/53034550
If a var has optional type, e.g.
```
var x: Int?
```
It will be implicitly initialized to `nil`. However, there's a second,
undocumented behavior: tuples of optional type, potentially nested infinitely,
will also be initialized, to tuples of nil.
So this var
```
var w: ((Int?, (), Int?), (Int?, Int?))
```
Will be default-initialized to
```
((nil, (), nil), (nil, nil))
```
We need to handle this inside getDefaultValueStringRepresentation,
otherwise we will crash while emitting partial modules.
Fixes one instance of rdar://51560190
Since the return value of getAccessor() depends on mutable state, it
does not make sense in the request evaluator world. Let's begin by
removing some utility methods derived from getAccessor(), replacing
calls to them with calls to getAccessor().
Implicit accessors are sometimes transparent for performance reasons.
Previously this was done in Sema by maybeMarkTransparent(), which would
add a TransparentAttr. Replace this with a request.
These are two slightly different operations. Make them share code and
prepare them for when we stop adding accessors to their parent
DeclContext.
Note the FIXMEs; this code could use additional attention.
Fixes rdar://problem/53407949 | SR-11138. Previously, we'd only look at the outermost property wrapper to decide whether the wrapped property's getter and setter were `mutating` (or exist at all). In reality, this requires considering the semantics of the composed accesses of each wrapper layer's
`wrappedValue` property. Fixing this systematically addresses a number of issues:
- As SR-11138 reported, composing a nonmutating-get-set wrapper ought to produce a composed wrapper
that's nonmutating.
- We would previously allow a property wrapper with a mutating getter to be nested inside one with
only a getter, even though the resulting implementation was unsound (because there's no mutable
context for the inner wrapper to execute its get on.)
- Similarly, we would construct unsound setters in cases where the setter can't exist, such as when
the nested wrapper isn't settable but the outer wrapper is.
Fixes a regression where the compiler would reject something like:
@State var x: Int?
as not having an initializer, even though an Int? property ought to default to nil.
rdar://problem/53504653
