Diagnose a metatype reference that doesn't appear as part of a call or member reference, offering fixits to either default-construct the type or get at the metatype explicitly using '.self'. Also diagnose an attempt to refer to 'T.type' by fixiting it to '.self'.
Swift SVN r14433
Factor an IdentityExpr base class out of ParenExpr, and migrate most of the logic to see through ParenExprs to see through IdentityExprs instead. Add DotSelfExpr as a new subclass of IdentityExpr, produced by parsing 'x.self'.
Swift SVN r14381
- Add a "isDirectPropertyAccess" bit to DeclRefExpr, serving the
same purpose as MemberRefExprs for non-member properties.
- Teach sema to synthesize correct non-member get/set implementations
for observing properties.
- Teach silgen to handle the isDirectPropertyAccess bit.
Swift SVN r13600
that have both storage AND accessors are accessed by-default through
their accessors. This bit indicates that a specific MRE should access
the storage instead.
Use this new bit in the synthesized getter/setter for "StorageObjC"
properties (it will also be used for other things in the future).
This also teaches SILGen about it.
One interesting aspect of this representation is that it makes it trivial
to add some expression syntax for directly accessing a store+computed
property (e.g. ObjC properties, also someday didSet/willSet properties)
someday if we care. This would be analogous to the "self->ivar" syntax
in objc (vs self.ivar). No, we will not use "->" for this. :-)
NFC since this is the use is still hidden under the -enable-new-objc-properties
staging option.
Swift SVN r12965
There was a test for this but it wasn't really accurate. We now look for
MemberRefExprs where the base is literally just an implicit DeclRefExpr,
rather than something loaded from an implicit DeclRefExpr. This could break
with future AST refinement, but that will at least fail the test now.
Swift SVN r12456
We still want to allow line wrapping, so only issue the warning when the indentation of the expression and the return keyword is the same.
radar://11945406
Swift SVN r9984
rdar://14151649 suggests that it should be a warning, but I don’t see a reason
why it should not be an error. We have no legacy code that relies on this.
Swift SVN r9976
