This improves on the previous situation:
- The request ensures that the backing storage for lazy properties
and property wrappers gets synthesized first; previously it was
only somewhat guaranteed by callers.
- Instead of returning a range this just returns an ArrayRef,
which simplifies clients.
- Indexing into the ArrayRef is O(1), which addresses some FIXMEs
in the SIL optimizer.
Extend the "type check function body" request to also cover the case
where we have a specific ending source location. Fold all of this
functionality into a single request, so we consistently go through a
request to compute a type-checked function body.
When the parser wires up the body of a function, it's a legitimate use of
setting a parsed body. Separate these out from the other uses of
setBody() that we want to eliminate over time.
Instead of requiring that function body synthesizers will always call
setBody(), which is annoyingly stateful, have function body synthesizers
always return the synthesized brace statement along with a bit that
indicates whether the body was already type-checked. This takes us a
step closer to centralizing the mutation of the body of a function.
Introduce some template metaprogramming infrastructure to retrieve the
"nearest" source location to the inputs of a request, and use that to
provide default diagnoseCycle and noteCycleStep implementations. This
will help remove a bunch of boilerplate from new requests.
Currently only works for types that are /just/ a 'some' type, not in a
nested position. Also won't show them for opaque types with different
requirements, to avoid noise when it's not strictly necessary. This
does mean that 'some P' vs. 'some P & Q' won't get the origin part.
Part of rdar://problem/50346954
Store the captures for each stored property initializer separately,
instead of incorporating them into the capture list of each
designated initializer.
Fixes <rdar://problem/41490541>
When deserializing an opaque type xref inside an extension context, we were looking
incorrectly in the base module of the type being extended, rather than in the module
of the extension, where the opaque type would really be. Fixes rdar://problem/51775500.
This includes a small refactoring of OpaqueTypeDecl deserialization to break the inevitable
cycle between deserializing the namingDecl, and the namingDecl turning around and re-
deserializing its opaque return type. This is NFC but avoids some unnecessary work.
Otherwise, there's no guarantee of binary compatibility, and whoever
turned on library evolution support shouldn't be lulled into a false
sense of security.
This is just a warning for now, but will be promoted to an error later
once clients have shaken out any places where they're doing this.
Note that the still-experimental '@_implementationOnly' opts out of
this check, because that enforces that the import doesn't make its way
into the current module's public source or binary interface.
rdar://50261171
When multiple property wrapper attributes are provided on a declaration,
compose them outside-in to form a composite property wrapper type. For
example,
@A @B @C var foo = 17
will produce
var $foo = A(initialValue: B(initialValue: C(initialValue: 17)))
and foo's getter/setter will access "foo.value.value.value".
The way this predicate is used is closely intertwined with 'can have
open access'. For example, we don't want protocol requirements coming
from testable imports to have 'open' access level.
When the backing storage of a wrapped property is default-initialized via the
property wrapper type's init(), don't count that as a direct initialization
of the backing storage for the purposes of constructing the memberwise
initializer. Instead, treat this case the same as if there were no initializer,
keying the form of the memberwise initializer off the presence of
init(initialValue:).
