Riding off of project_existential[_ref] was convenient, but the
resuls are used quite differently. Note that open_existential[_ref]
still don't print/parse reasonably yet.
Swift SVN r13878
Change GenericFunctionType to reference a GenericSignature instead of containing its generic parameters and requirements in-line, and clean up some interface type APIs that awkwardly returned ArrayRef pairs to instead return GenericSignatures instead.
Swift SVN r13807
When applying a function that was produced via a covariant function
conversion, strip off that covariant function conversion and introduce
a covariant (function or return) conversion outside of the
application. This allows us to perform the covariant conversion very
late, eliminating the need to produce reabstraction thunks for any
call to a DynamicSelf method.
Swift SVN r13779
Introduce a new expression kind, OpenExistentialExpr, that "opens" up
an existential value into a value of a fresh archetype type that
represents the dynamic type of the existential. That value can be
referenced (via an OpaqueValueExpr) within the within the
subexpression of OpenExistentialExpr. For example, a call to a
DynamicSelf method on an existential looks something like this:
(open_existential_expr implicit type='P'
(opaque_value_expr implicit type='opened P' @ 0x7fd95207c290
unique)
(load_expr implicit type='P'
(declref_expr type='@lvalue P' decl=t.(file).func
decl.p@t.swift:5:37 specialized=no))
(erasure_expr implicit type='P'
(call_expr type='opened P'
(archetype_member_ref_expr type='() -> opened P'
decl=t.(file).P.f@t.swift:2:8 [with Self=opened P]
(opaque_value_expr implicit type='opened P' @
0x7fd95207c290 unique))
(tuple_expr type='()')))))
Note that we're using archetype_member_ref_expr rather than
existential_member_ref_expr, because the call is operating on the
opaque_value_expr of archetype type. The outer erasure turns the
archetype value back into an existential value.
The SILGen side of this is somewhat incomplete; we're using
project_existential[_ref] to open the existential, which is almost
correct: it gives us access to the value as an archetype, but IRGen
doesn't know to treat the archetype type as a fresh archetype whose
conformances come from the existential. Additionally, the output of
the opened type is not properly parsable. I'll fix this in follow-on
commits.
Finally, the type checker very narrowly introduces support for
OpenExistentialExpr as it pertains to DynamicSelf. However, this can
generalize to support all accesses into existentials, eliminating the
need for ExistentialMemberRef and ExistentialSubscript in the AST and
protocol_method in SIL, as well as enabling more advanced existential
features should we want them later.
Swift SVN r13740
- 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
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
Introduce a new Pattern::forEachVariable that takes a lambda and iterates
over all the variables encompassed by the pattern (the ones found by
collectVariables) and runs the lambda on it.
Use this to implement collectVariables, so we only have one copy of the code.
Convert several places to use this, removing a bunch of duplicated code for
walking the pattern structure and extracting decls.
Convert a few uses of collectVariables to forEachVariable, leading to more
clear code without a temporary smallvector.
Remove simplifyPatternTypes in CSApply.cpp, which is dead.
Swift SVN r13545
Introduce a new AST node to capture the covariant function type
conversion for DynamicSelf. This conversion differs from the normal
function-conversion expressions because it isn't inherently type-safe;
type safety is assured through DynamicSelf.
On the SIL side, map DynamicSelf down to the type of the declaring
class to keep the SIL type system consistent. Map the new
CovariantFunctionConversionExpr down to a convert_function
instruction, slightly loosening the constraints on convert_function to
allow for this (it's always been ABI-compatible-only conversions
anyway).
We currently generate awful SIL when calling a DynamicSelf method,
because SILGenApply doesn't know how to deal with the implicit return
type adjustment associated with the covariant function
conversion. That optimization will follow; at least what we have here
is (barely) functional.
Swift SVN r13286
Introduce a new AST node to capture the covariant function type
conversion for DynamicSelf. This conversion differs from the normal
function-conversion expressions because it isn't inherently type-safe;
type safety is assured through DynamicSelf.
On the SIL side, map DynamicSelf down to the type of the declaring
class to keep the SIL type system consistent. Map the new
CovariantFunctionConversionExpr down to a convert_function
instruction, slightly loosening the constraints on convert_function to
allow for this (it's always been ABI-compatible-only conversions
anyway).
We currently generate awful SIL when calling a DynamicSelf method,
because SILGenApply doesn't know how to deal with the implicit return
type adjustment associated with the covariant function
conversion. That optimization will follow; at least what we have here
is (barely) functional.
Swift SVN r13269
When referring to a DynamicSelf method, treat DynamicSelf as an alias
for the class type in which the method was declared, then perform a
function conversion to a method with the appropriate subclass as the
result result type. This is always a (trivial) subtype conversion on
the method.
Swift SVN r13268
In the interface type for such a method, use the owning nominal type
within the type of the 'self' parameter. Practically speaking, this
means that a call to the method will perform a superclass conversion
when on 'self', which is what already happens for generic methods that
return DynamicSelf.
Swift SVN r13178
Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
With that change, all calls to adjustSelfTypeForMember are in the
argument list of coerceObjectArgumentToType. Instead of doing this,
just call adjustSelfTypeForMember from coerceObjectArgumentToType
instead.
Swift SVN r13023
variable are direct in init/destructor and in the didSet/willSet specifiers
themselves (to avoid infinite loops in reassignments).
Also, teach adjustSelfTypeForMember to handle direct accesses properly,
and move isImplicitDirectMemberReference early enough that it can find out
about inferred directness.
Swift SVN r13022
This patch:
- Changes sema to set the "IsDirectPropertyAccess" on MemberRefExprs
in inits/destructors that should be done directly because they are
on the local object.
- Removes the "SGF.AlwaysDirectStoredPropertyAccess" bool in SILGen,
which was the source of the problem above and was otherwise problematic.
This will get a bit simpler when -enable-new-objc-properties rolls out.
Swift SVN r12967
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
with two kinds, and some more specific predicates that clients can use.
The notion of 'computed or not' isn't specific enough for how properties
are accessed. We already have problems with ObjC properties that are
stored but usually accessed through getters and setters, and a bool here
isn't helping matters.
NFC.
Swift SVN r12593
takes the archetype as an rvalue, not an lvalue. This defines away the need
for MaterializeExpr at sema time, reusing the existing temporary mechanics in
SILGen. This also opens future optimizations.
Swift SVN r12123
to non-@mutating methods work in the AST: now the base expression is
always computed as an rvalue, instead of computing them as an lvalue. The
optimization that we were accidentally getting before is now explicitly
modeled, and the non-optimized case is now handled by standard temporary
emission in SILGen instead of with MaterializeExpr. The upshot of this
carefully choreographed step is that there is no change in generated code (!).
Archetype member references still need to be switched over to this new
scheme (at which point materializeexpr is dead), and the optimization
needs to be replicated for 'let' bases (at which point arguments
becoming 'let' is only gated on debug info).
Swift SVN r12120
Make the compiler fully support both UTF-8 and UTF-16 string
literals. A (standard-library-defined) string type (such as String)
that wants UTF-16 string literals should conform to the
BuiltinUTF16StringLiteralConvertible protocol; one that wants UTF-8
string literals should conform to the BuiltinStringLiteralConvertible
protocol.
Note that BuiltinUTF16StringLiteralConvertible inherits from
BuiltinStringLiteralConvertible, so a string type that wants UTF-16
string literals also has to implement support for UTF-8. The UTF-16
entry point is preferred when the compiler knows that UTF-16 is
supported. This only tends to happen when we have a generic parameter
that is required to conform to StringLiteralConvertible, e.g.,
func f<T: StringLiteralConvertible>() {
var t: T = "Hello, World!" // uses UTF-8 entry point
}
because the UTF-8 entry point is the only one guaranteed to be available.
Swift SVN r12014
