We use three tag bits on Expr*, Stmt*, Decl*, TypeBase* and SILTypeInfo*, and four on DeclContext*, so set the alignment of the pointed-to types formally with alignas(N) instead of relying on operator new passing down the right alignment to the allocator. Get rid of the informal T::Alignment members of these classes and pass alignof(T) to their allocators. Fix the 'operator new' of DeclContext subclasses so that we can actually use the four tag bits PointerLikeTypeTraits<DeclContext*> claims are available.
Swift SVN r4587
Provide distinct syntax 'a as T' for coercions and 'a as! T' for unchecked downcasts, and add type-checker logic specialized to coercions and downcasts for these expressions. Change the AST representation of ExplicitCastExpr to keep the destination type as a TypeLoc rather than a subexpression, and change the names of the nodes to UncheckedDowncast and UncheckedSuperToArchetype to make their unchecked-ness explicit and disambiguate them from future checked casts.
In order to keep the changes staged, this doesn't yet affect the T(x) constructor syntax, which will for the time being still perform any construction, coercion, or cast.
Swift SVN r4498
Now that we don't allow static methods to be invoked from instances we no longer need an AST node to represent an implicit instance-to-metatype conversion. MetatypeExpr encodes the explicit '.metatype' operation.
Swift SVN r4472
Some SIL operations only make sense on no-context functions, such as creating a context for a function with "curry" or specializing. We're going to need this concept in Swift for interop with C functions too, so I'm adding it to the Swift type system. This patch only adds the attribute bit to function types without exposing the attribute to Swift syntax or providing any means in Swift to produce values of thin function type or to type-check them.
Swift SVN r4416
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
Implement switch statements with simple value comparison to get the drudge work of parsing and generating switches in place. Cases are checked using a '=~' operator to compare the subject of the switch to the value in the case. Unlike a C switch, cases each have their own scope and don't fall through. 'break' and 'continue' apply to an outer loop rather to the switch itself. Multiple case values can be specified in a comma-separated list, as in 'case 1, 2, 3, 4:'. Currently no effort is made to check for duplicate cases or to rank cases by match strength; cases are just checked in source order, and the first one wins (aside from 'default', which is branched to if all cases fail).
Swift SVN r4359
Pack the uncurry level onto SILConstant, and modify SILConstant constructors to determine the natural uncurry level of their referenced entity by default. While we're here, improve how SILConstant represents different kinds of constants by using a real enum for the kind. Type closure entry points by giving them an extra curry level for their context. The implementation of ApplyInst and ClosureInst hasn't been updated yet, so tests that lower closures to SIL are temporarily broken.
Swift SVN r4354
We use uniqued "locators" to describe how a particular constraint was
derived, starting from the constraints generated on expressions (e.g.,
the argument to a function application must be convertible to the
input type of the function being applied) and narrowing down to
specific parts of the types (e.g., the result type of tuple element
2).
Note that locators are not present in all constraints yet, nor are
they actually used for anything other than slightly-more-interesting
debug dumps.
Swift SVN r4353
(fixing an abstraction leak of the constraint checker into details of constraint
gathering). One upside of this is that it avoids constructing SetVector, which
defaults to using a std::vector to back it.
Swift SVN r4333
'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
Modify TupleToTuple and ScalarToTuple conversion to try to preserve the sugared types of their inputs when coercing. After typechecking a function application, try to determine if there is a consistent type sugar used for all of the elements of the input tuple whose types are equivalent to the result type, and if so, map the result type to that same sugar type. This makes it so that 1+1 returns an 'Int' and Foo(1) + Foo(1) returns a 'Foo' (if 'typealias Foo = Int'). Still to come: cases where the input tuple is shuffled, has varargs or default initializers; and some cases with literals where the constraint checker favors the declared argument type over the default literal type.
Swift SVN r4247
Emit getter and setter ObjC methods and selectors for Swift properties declared in ObjC classes or extensions. If the type of the property is an ObjC class, also emit special-cased ObjC formal property metadata for the property as if it were declared @property (nonatomic, {readonly,strong}) in ObjC.
Swift SVN r4207
Add 'isObjC' as a property of ValueDecl, and set it during type checking if a class is either explicitly annotated with an [objc] attribute or inherits from an isObjC class, or if a func is a method of an isObjC class. Tweak the ClangImporter and other places that summon magic ValueDecl nodes to set up the decls they synthesize as isObjC. Replace logic in typechecking and IRGen that branched on the 'isObjC' attribute to now branch on the 'isObjC' property of ValueDecls.
Swift SVN r4078
Walk backward from a '.' through balanced () [] <> to find context. Fix a problem with parseCompletionContextExpr where UnresolvedIdentifierTypes wasn't getting properly transferred to the TranslationUnit after parsing, causing 'Foo<T>.' completion to blow up.
Swift SVN r4075
If the completion prefix has a '.' behind it, guesstimate a context expression by lexing backward through an identifier(.identifier)* dotted path, then attempt to parse and typecheck that expression to decide on a base type in which to find completions.
Swift SVN r4063
Integrating Clang's FindVisibleDecls with Swift's by importing every decl created too much per-repl-entry compile time overhead, so as a workaround, just wire completions directly to FindVisibleDecls on the clang translation unit itself. Unfortunately this means we get completions for things Swift can't import yet, but it also means we don't have to wait 30 seconds to compile every entry after doing a completion.
Swift SVN r4061
Implement a 'lookupVisibleDecls' API similar to Clang's that replicates the UnqualifiedLookup logic for walking through a given scope looking for decls. Use it to populate the completion list in the repl.
Still to be done: Clang module lookup via Clang's lookupVisibleDecls, and context deduction from dotted path expressions.
Swift SVN r4056
Use UnresolvedSpecializeExprs to set up equality constraints on the opened generic type variables of their subexpressions, and when the system is solved, resolve the expression away to its specialized base expression. Fix the solution logic for DeclRefExprs so that they obtain the type the constraint checker solved for them and not the original unbound type of the decl. This means that constructions and static member accesses of generic types now parse! This also incidentally fixes <rdar://problem/13212959>, so 'A(0)' for generic 'A<T>' now works when T can be inferred from constructor arguments.
One thing that doesn't work yet is generics as type members, as in 'A.B<C>' or 'A<B>.C<D>'. The UnresolvedDotExpr for these generates an unbound type variable, and I'm not sure how to express opening a type variable as a generic type $TO<A, B, C>.metatype constraint system in which the thing being specialized is a variable. This patch also doesn't allow explicit specialization of functions; although we could do so in theory, the constraint system that currently gets generated for functions loses the type parameters, so it would require some redesign in the constraint checker.
Swift SVN r4047
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
Add support to the constraint checker for typechecking UnresolvedSuperMemberRef expressions and constructing SuperMemberRef or SuperCall expressions as appropriate. We’ll also need a GenericSuperMemberRefExpr to refer to properties of generic supertypes, but in the interests of demo expedience I’m leaving that case partially-implemented for now.
Swift SVN r4020
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
The ClangImporter doesn't synthesize PatternBindingDecls around imported struct fields, but the ASTPrinter assumes that a non-property VarDecl will later show up in a PatternBindingDecl. In the ASTPrinter, don't skip VarDecls that originated from Clang.
Swift SVN r3925
explicitly conforms to protocols, mirror any protocol methods that
aren't also declared in the class/category/extension within the
extension. Among other things, this makes sure that "-hash" and
"-isKindOfClass:" are available on NSObject (they come from the
NSObject protocol).
Fixes <rdar://problem/13074691>.
Swift SVN r3920
In the StmtChecker, consider a ConstructorDecl or DestructorDecl context to be a function context that returns (). In IRGen for constructors and destructors, set up proper return blocks so that 'return' does the right thing, and in constructors, pretend that the body has no return value even though the underlying constructor mechanism totally returns a value. Fixes <rdar://problem/12950817>.
Swift SVN r3915
Add a mangling for 'block converter' functions and for [objc_block] function types. [objc_block] types also need their own HeapTypeInfo representation that uses ObjC retain/release. When we see a BridgeToBlockExpr, feed the function pointer and context from the Swift closure to the external conversion function and hope we get a block back.
Swift SVN r3899
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
For the demo we'll import block types as [objc_block] (A) -> B types in Swift and rely on the type attribute to handle bridging Swift closures to ObjC blocks.
Swift SVN r3895
Recognize super.constructor calls in IRGen and generate them as calls to the superclass initializing constructor. Note that super.constructor code still won't execute just yet because classic IRGen doesn't generate initializing constructors.
Swift SVN r3859
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
We have no intention of ever supporting actual semicolon statements
(separators, statements no), nor do we ever want to because that would
mean the behavior of the program would potentially change if semicolons
were naively removed.
This patch tracks the trailing semicolon now in the decl/expr/stmt,
which will enable someone to write a good "swift indent" tool in the
future.
Swift SVN r3824
Archetypes and projected existentials have the type %swift.opaque* and not i8*, so I need a corresponding SIL type to be able to model the ProjectExistential operation. We might also end up needing the builtin type for other low-level things down the line.
Swift SVN r3793
