This merges Sema's special logic for updating the ImplInfo of lazy properties
and property wrappers with the StorageImplInfoRequest.
I had to move some code from the parser into the StorageImplInfoRequest, to
avoid request cycles caused by hasStorage() calls; this is the right thing to
do anyway.
Since hasStorage() now answers false for lazy properties and property wrappers,
we have to move some diagnostic checks from checkDeclAttributesEarly() to
the StorageImplInfoRequest implementation itself.
Over time, I expect all of the checks currently in checkDeclAttributesEarly()
and checkDeclAttributes() to either migrate to requests, or typeCheckDecl().
This just moves the code from the parser into a request. Sema will
still overwrite the ImplInfo field for lazy properties and
property wrappers; refactoring that is next.
We want to compute the former independently of the latter.
It's only 16 bits so storing it inside the Decl is fine;
it also allows us to eliminate the 'compact' representation
where an AbstractStorageDecl without an accessor record is
assumed to be stored.
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.
- When parsing a type or extension declaration, attempt to parse a function or property declaration when meeting an identifier, an operator or a paren (for tuple declarations).
- Produce the diagnostic with a fix-it suggesting to insert the needed keyword
- Recover parsing as if the declaration with the missing keyword is a function/property declaration
Resolves https://bugs.swift.org/browse/SR-10477
Instead of creating the AST directly in the parser (and libSyntax or
SwiftSyntax via SyntaxParsingContext), make Parser to explicitly create
a tree of ParsedSyntaxNodes. Their OpaqueSyntaxNodes can be either
libSyntax or SwiftSyntax. If AST is needed, it can be generated from the
libSyntax tree.
When the outermost property wrapper associated with a property has a
`wrapperValue`, create the projection property (with the `$` prefix)
at the same access level as the original property. This puts the
wrapped-value interface and the projection interface at the same level.
The newly-introduced @_projectionValueProperty attribute is implicitly
created to establish the link between the original property and the
projection value within module interfaces, where both properties will
be explicitly written out.
```
@#^COMPLETE^#
public func something() {}
```
In this case, we can't say the user is adding attribute to the func or
starting a new declaration. So if there're one or more blank lines after the
completion, suggest context free attribute list.
rdar://problem/50441643
- preferred dyn_cast to is and get
- restored insertion of () on bare return statements
- used dyn_cast not dyn_cast_or_null when the argument is non-null
- used getSingleExpressionBody accessor during second AST modification
- eliminated erroneous access through null reference
When a custom attribute is given a direct initializer, save and re-use
the initializer context we create so that it can be associated with the
enclosing pattern binding. Fixes assertions involving explicit closures
in property delegates.
The initializer associated with a lazy property should not be executed
directly, because it is subsumed by code synthesized into the
getter. Generalize the terminology here so we can re-use this path for
property delegate initialization.
When printing a swiftinterface, represent opaque result types using an attribute that refers to
the mangled name of the defining decl for the opaque type. To turn this back into a reference
to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction
doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and
ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type
reconstruction.
(Since we're invoking type reconstruction during type checking, when the module hasn't yet been
fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe
there's a better way to do this... Longer term, at least, this surface design gives space for
doing things more the right way--a more request-ified decl validator ought to be able to naturally
lazily service this request without the LazyResolver reference, and if type reconstruction in
the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
