Implement the syntax 'if x then y else z', which evaluates to 'y' if 'x' is true or 'z' if 'x' is false. 'x' must be a valid logic value, and 'y' and 'z' must be implicitly convertible to a common type.
Swift SVN r4407
'super.constructor' shouldn't be referenceable without being called, and 'super.constructor(...)' shouldn't return a value. Require super.constructor expressions to be called at parse time, and wrap the call expression in a new RebindThisInConstructorExpr that represents consuming the delegated-to constructor by using it to reassign 'this'. This should theoretically allow super.constructor to an ill-behaved self-modifying ObjC class to work. It's also necessary to support delegating constructors of value types.
Swift SVN r4326
Replace the more specific Super*RefExpr nodes with a single SuperRefExpr that resolves members of 'this' relative to its superclass. Add an OtherConstructorDeclRefExpr for referring to a constructor as called from another constructor, and use it to represent resolved 'super.constructor' expressions. (It should also be able to represent delegating constructors for free, if we decide we want to add syntax for that.)
Swift SVN r4286
This node represents a type parameter list application in an unresolved expr context. The type checker will use these to explicitly bind type variables of generic types.
Swift SVN r4046
Analyze an expression of the form [<tuple contents>] into a call to T.convertFromArrayLiteral(<tuple contents>) for some T conforming to an ArrayLiteralConvertible protocol. Because of some limitations in the constraint checker and protocol conformance checkers, it currently does an ad-hoc conformance check using member constraints. It also currently fails to typecheck for generic container types, and does not provide a default fallback to 'T[]' if unable to deduce a better type from context.
Swift SVN r3953
Provide a BridgeToBlockExpr AST node as a temporary representation of func-to-block conversions. In Sema, when we see an [objc_block] type, insert a BridgeToBlock node and coerce the subexpression to the non-block func type.
Swift SVN r3897
Set up AST nodes for 'super.<identifier>', 'super.constructor', and 'super[<expr>]' expressions, and implement parsing for them without any sema or backend support.
Swift SVN r3847
The IR generation for this conversion is different from
derived-to-base conversions, because converting from an archetype to
its superclass type means projecting the buffer and then performing
the conversion.
Swift SVN r3462
This introduces support for the syntax
Derived(baseObj)
to downcast from a class type to one of its subclasses. This still
needs more language design and implementation work, including:
- This overloads the X(y) syntax again, which already means either
"coerce y to type X, performing implicit conversions if necessary"
or "construct a value of type X from y". It's no actually ambiguous,
because the first case won't apply for downcasts and the second case
is limited to value types, but it makes me wonder whether we want a
different syntax for the first case.
- We need this to be a checked cast, but don't have the runtime
infrastructure to do so yet. I've left this as a FIXME.
However, the Objective-C importer is fairly useless because everything
that creates an object returns an "id", "id" maps to "NSObject", and
then the type system doesn't let you get from NSObject back to the
type you care about. So, this lets you explicitly do the cast.
Swift SVN r3279
No functionality change: the only subclass is CoerceExpr, for cases
where the user has forced an expression to a given type, e.g., Int32(17).
Swift SVN r3278
conversions on metatypes; at runtime it has no effect,
since those conversions are always trivial. Fix a number
of bugs involving the conversion of metatypes, in both
typecheckers.
Swift SVN r3055
Introduce a '.metatype' form in the syntax and do some basic
type-checking that I probably haven't done right. Change
IR-generation for that and GetMetatypeExpr to use code that
actually honors the dynamic type of an expression.
Swift SVN r3053
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
base type (e.g., the archetype type, when we're in a generic function)
used to refer to that operator as a member, e.g., given
func min<T : Ord>(x : T, y : T) {
if y < x { return y } else { return x }
}
'<' is found in the Ord protocol, and is referenced as
archetype_member_ref_expr type='(lhs : T, rhs : T) -> Bool' decl=<
(typeof_expr type='metatype<T>'))
using a new expression kind, TypeOfExpr, that simply produces a value
of metatype type for use as the base.
This solves half of the problem with operators in protocols; the other
half of the problem involves matching up operator requirements
appropriately when checking protocol conformance.
Swift SVN r2443
Add a couple other misc pieces necessary for semantic analysis of members of
generic types. We're now up to the point where we can actually construct a
useful AST for small testcases.
Swift SVN r2308
used in the very narrow case where we were converting from one
protocol type to another (super) protocol type. However, ErasureExpr
now handles this case via its null conformance entries (for the
"trivial" cases), and can cope with general existential types where
some conversions are trivial and others are not.
The IR generation side of this is basically just a hack to inline the
existing super-conversion code into the erasure code. This whole
routine will eventually need to be reworked anyway to deal with
destination types that are protocol-conformance types and with source
types that are archetypes (for generic/existential interactions).
Swift SVN r2213
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
values of existential type, e.g.,
var x : Printable
x.print()
Existential member references reify the type of the implicit object
argument (implicitly, because we have no way of expressing this in the
type system), and replace the types of any other archetypes
with existential types that (don't, but will eventually) conform to
the protocols to which the archetypes conform.
Swift SVN r1963
application expressions that provide a 'this' parameter to a
method. There will eventually be more than just DotSyntaxCallExpr, to
capture the other syntactic (and implicit) forms.
Swift SVN r1924
A user-defined conversion function is an instance method that accepts
an empty tuple and returns a value of the type we're converting to,
has the [conversion] attribute, and is named __conversion. The last of
these restrictions is a temporary hack to work around our inability to
perform a lookup across all extensions for "every function with the
conversion attribute", and shouldn't last too long.
As in C++, we only get one user-defined conversion function. Unlike in
C++, a constructor is not (and cannot) be a conversion function.
Introduce NSString <-> String conversion functions, but leave the
runtime implementations as stubs for Dave to fill in.
Swift SVN r1921
another function type, so long as the source is a subtype of the
target. The subtyping relation is fairly obvious, allowing parameter
renaming, qualification conversions for lvalue types, and
protocol-conformance conversions (at the top level of function
types). It is a strict subset of the allowed type coercions.
The representation of FunctionConversionExpr is temporary. It will
need to account for the capture of the source of the conversion in the
trivial-trivial case.
Swift SVN r1839
from a protocol to a protocol it inherits. This is a far simpler
operation that the general type-erasure expression, so generate this
AST when we can.
Swift SVN r1813
I'm not completely sure this is the representation we want, but it isn't much code to rip out if we decide to represent it some other way.
While I'm in the area, also fix a case where tuple->tuple conversion wasn't working.
Swift SVN r1748
e.g. "foo is \(i+j)". This implements rdar://11223686
Doug implemented all the hard parts of this. I ripped out support for nested string
literals (i.e. string literals within an interpolated string), which simplified the
approach and defined away some problems with his patch in progress. I plan a few refinements
on top of this basic patch.
Swift SVN r1738
