Emit vtable entries for abstract initializers. When we're constructing
an object using an abstract initializer based on a metatype value that
is not statically derivable, use the vtable entry to call the
subclass's allocating constructor.
Most of the IRGen work here is hacking around the lossy SILDeclRef ->
(Code|Function)Ref -> SILDeclRef conversion. I'd feel bad about this
if John hadn't already agreed to clean this up at some point.
Swift SVN r14238
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
automatically reparent VarDecls in their arg/body patterns and
GenericParameters to themselves. These all have to be created
before the actual context decl is created and then reparented,
so we might as well have the reparenting be done by the decl
itself. This lets us take out some setDeclContext reparenting
loops from around the parser.
I'm sure that there are a lot more places they can be removed
from as well.
NFC.
Swift SVN r13701
- 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
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
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
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
- Switch all the 'self' mutable arguments to take self as @inout, since
binding methods to uncurried functions expose them as such.
- Eliminate the subtype relationship between @inout and @inout(implicit),
which means that we eliminate all sorts of weird cases where they get
dropped (see the updated testcases).
- Eliminate the logic in adjustLValueForReference that walks through functions
converting @inout to @inout(implicit) in strange cases.
- Introduce a new set of type checker constraints and conversion kinds to properly
handle assignment operators: when rebound or curried, their input/result argument
is exposed as @inout and requires an explicit &. When applied directly (e.g.
as ++i), they get an implicit AddressOfExpr to bind the mutated lvalue as an
@inout argument.
Overall, the short term effect of this is to fix a few old bugs handling lvalues.
The long term effect is to drive a larger wedge between implicit and explicit
lvalues.
Swift SVN r11708
in various unfortunate cases, which is really wrong and causing unpleasantness
for the new mutability model. However, we can't fix this until the new
mutability model lands.
To get from here to there, add some assertions to RequalifyExpr expr's ctor
that are only enabled by the new model, to help me track down and purge these
infractions.
Swift SVN r11445
t.swift:10:5: error: instance variable 'self.y' not initialized at super.init call
super.init()
^
<unknown>:0: note: variable defined here
t.swift:15:5: error: use of base object 'SomeClass' before super.init call initializes it
x = 17
^
instead of:
variable 'self.y' captured by a closure before being initialized
for each of them. <unknown> is in the crosshairs next.
Swift SVN r11036
This allows expressions such as ".foo" and ".foo(1)" to refer to
static variables and static methods, respectively, as well as enum
cases.
To get here, rework the parsing of delayed identifier expressions a
bit, so that the argument itself is part of the delayed argument
expression rather than a separate call expression. This simplifies
both the handling of patterns of this form and the type checker, which
can now user simpler constraints.
If we really want to support (.foo)(1), we can make that work, but it
seems unnecessary and perhaps confusing.
Swift SVN r10626
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
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
Replace DeclRefExpr's stored ValueDecl* with a ConcreteDeclRef,
allowing it to store the complete set of substitutions applied to
the declaration. Start storing those substitutions (without using them
yet).
Swift SVN r9535
Allows us to properly infer the type (Int, Int)[] from the array
literal [(1, 2)]. This is the last piece of functionality in
<rdar://problem/11293232>.
Swift SVN r9408
wide
Currently integer literals are 64-bit. In order to allow checking for overflow
while converting an integer literal to swift.UInt/Int* types we need at least
65 bits. But floating point numbers (Float32, Float64, Float80) are
BuiltinIntegerLiteralConvertible. In order to allow spelling large floating
point constants, we allow 136-bit literals.
Rationale: 128 bits are enough to represent the absolute value of min/max IEEE
Binary32, and we need 1 bit to represent the sign. 136 is 129 rounded to the
next 8 bits.
The plan is to have builtins that do the overflow check and convert 136-bit
numbers to the required width. We need these builtins for both integers and
floating point numbers to ensure that 136-bit numbers are folded into sane
constants in SIL and don’t escape to LLVM IR.
Swift SVN r9253
Now that we have a solid Optional-based story for dynamic casts, it's no longer needed, and can be expressed as '(x as T)!'. Future refinement of the 'as' syntax will deal with the unfortunate extra parens.
Swift SVN r9181
An expression of DynamicLookup type can be unconditionally downcast to
any class type via the postfix '!'. This will allow one to replace
var w : NSWindow = (nsarray[0] as NSWindow)!
with
var w : NSWindow = nsarray[0]!
The current implementation is fairly limited: it only works when the
operand of '!' is an rvalue of type DynamicLookup, and we don't ensure
that the result is a class type. Nonetheless, it cleans up some of
ListMaker nicely.
This is the first client of disjunction constraints, which were added
in r9142.
Swift SVN r9151
As with the monadic '?', we treat any left-bound '!' as a postfix
operator. Currently, it extracts the value of its optional
subexpression, failing at run-time if the optional is empty.
Swift SVN r8948
If an enum has a valid raw type, synthesize a RawType associated type along with fromRaw and toRaw methods.
An implicit conformance to RawRepresentable is not yet set up. This synthesis may need to be done earlier in order for the names to be available during type-checking of definitions in the enum too.
Swift SVN r8890
