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
If a REPL input parses to an expression, bind it to the next available variable 'r<n>', and print the result as if it were a name binding. Don't bind a variable if the expression consists of a lone DeclRef, and don't print the binding if it has void type.
Swift SVN r4201
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
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
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
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
By splitting out the expression used to allocate 'this' (which exists
in the AST but cannot be written in the Swift language proper), we
make it possible to emit non-allocating constructors for imported
Objective-C classes, which are the only classes that have an
allocate-this expression.
Swift SVN r3558
This change enables inheritance constraints such as "T : NSObject",
which specifies that the type parameter T must inherit (directly or
indirectly) from NSObject. One can then implicit convert from T to
NSObject and perform (checked) downcasts from an NSObject to a T. With
this, we can type-
IR generation still needs to be updated to handle these implicit
conversions and downcasts. New AST nodes may follow.
Swift SVN r3459
The interesting thing here is that we need runtime support in
order to generate references to metatypes for classes, mostly
because normal ObjC classes don't have all the information we want
in a metatype (which for now just means the VWT pointer).
We'll need to be able to reverse this mapping when finding a
class pointer to hand off to, say, an Objective-C class method,
of course.
Swift SVN r3424
There is no protection whatsoever if the Clang-to-Swift type
conversion produces something that Swift doesn't lower in an
ABI-compatible way. That will be dealt with later.
Swift SVN r3249
rdar://11259972
Add a bit to LValueType representing NonSettable, and set it in the constraint-
based checker where a property or subscript expression resolves to a decl
without a setter or to a settable member of an unsettable value type. Tweak
constraint rules for subscript, address-of, assignment, and implicit byref
arguments to rule out operands that are not settable in a context that
requires settability, such as assignment or pass-by-reference.
Swift SVN r3136
rdar://10157547
This just adds the bit to Decl. Actually making use of it looks like it'll require some type checker work, which should probably wait till the new checker settles down. Also add some xfail tests of the sorts of cascading diagnostic errors we should be able to prune using invalid bits on decls.
Swift SVN r3099
dispatch. Currently there is no possibility of override.
This was really not as difficult as I managed to make it
the first time through.
Swift SVN r2960
a reliable way to track whether a particular type has been
validated. Instead, add some bits to the type to indicate which stage
of checking it has received. I hate it, but it works and I don't know
of a better way to ensure that types get validated. This subsystem
will need to get rearchitected at some point (ugh).
Reduce the number of places where we build new BoundGenericTypes,
since they need to be validated fully to get substitutions, and then
introduces a number of validateTypeSimple() calls to validate types in
places where we know the validation will succeed, but we need that
information regardless.
Swift SVN r2681
been type-checked. The initialize constructed types are not (and
cannot be) canonical because archetypes aren't assigned until the
generic parameters in the current and outer contexts are
type-checked.
Test forthcoming as part of IRgen support for nested generics.
Swift SVN r2569
checker. There are a few related sets of changes here:
- Generic parameter lists have a link to their "outer" generic
parameter lists, so its easy to establish the full generic context
of an entity.
- Bound and unbound generic types now carry a parent type, so that
we distinguish between, e.g., X<Int>.Inner<Int> and
X<Double>.Inner<Int>. Deduction, substitution, canonicalization,
etc. cope with the parent type.
- Opening of polymorphic types now handles multiple levels of
generic parameters when needed (e.g., when we're substituting into
the base).
Note that the generics module implied by this representation restricts
what one can do with requirements clauses in nested generics. For
example, one cannot add requirements to outer generic parameters or
their associated types, e.g., this is ill-formed:
struct X<T : Range> {
func f<U requires T.Element : Range>() {}
}
The restriction has some precedent (e.g., in C#), but could be
loosened by rearchitecting how we handle archetypes in nested
generics. The current approach is more straightforward.
Swift SVN r2568
member of a oneof/struct/class/extension to support types nested
within generic classes, e.g., Vector<Int>.ElementRange.
Most importantly, nominal types are no longer inherently canonical. A
nominal type refers to both a particular nominal type declaration as
well as its parent, which may be non-canonical and will vary. For
example, the variance in the parent makes Vector<Int>.ElementRange and
Vector<Float>.ElementRange different types.
Introduce deduction and substitution for nominal types. Deduction is
particular interesting because we actually do allow deduction of T
when comparing X<T>.Inner and X<Int>.Inner, because (unlike C++) there
is no specialization to thwart us.
Swift SVN r2507
type. This has remarkably little effect on type checking, because the
destructors themselves are never referenced by the AST after initially
type-checking them.
Swift SVN r2474
including the weird implicit one-of element declarations that end up in struct
types. Teach overload resolution and the type-checking of
ConstructorRefExprs how to specialize these polymorphic function types.
Swift SVN r2473
polymorphic function type. For example, given
struct X<T> {
func f(a : T) -> Int { }
}
The type of X.f is
<T> (this : [byref] X<T>) -> (a : T) -> Int
If we have a call to f, e.g.,
var xi : X<Int>
xi.f(5)
it will be represented as X.f specialized to type
(this : [byref] X<Int>) -> (a : Int) -> Int
and then called with 'xi' (DotSyntaxCallExpr) and finally 5
(ApplyExpr). The actual deduction of arguments is not as clean as I'd
like, generic functions of generic classes are unsupported, static
functions are broken, and constructors/destructors are broken. Fixes
for those cases will follow.
Swift SVN r2470
and derived) so they can be stored within the generic parameter list
for use 'later'.
More immediately, when we deduce arguments for a polymorphic function
type, check that all of the derived archetypes conform to all of the
protocol requirements, stashing that protocol-conformance information
in the coercion context (also for use 'later'). From a type-checking
perspective, we now actually verify requirements on associated types
such as the requirement on R.Element in, e.g.,
func minElement<R : Range requires R.Element : Ordered>(range : R)
-> R.Element
Swift SVN r2460
type substitution for a nested type reference (Foo.Bar.Wibble) whose
substituted parent reference (Foo.Bar) yields an archetype can simply
look for the appropriate nested type in the archetype.
This allows us to eliminate the hideous ASTContext::AssociatedTypeMap
and simply the archetype builder.
Swift SVN r2438
builder. For this to work, the 'parameter' used to seed the archetype
builder is the 'This' associated type, which implicitly conforms to
the protocol. All other archetype assignments flow from that
archetype.
In the same vein, when faking a polymorphic function type for an
operator found within a protocol, we only need to substitute for the
'This' associated type. The rest are derived due to the implicit
requirement that 'This' conforms to its protocol.
Finally, because archetype assignment within protocols occurs during
type-checking, and that archetype assignment may visit any protocol
visible in the translation unit, we need to validate the types used in
archetype assignment for *all* protocols before attempting archetype
assignment on any one protocol. Thus, perform this type validation
before the main declaration type-checking phase.
Swift SVN r2436
subject of a conformance constraint (e.g., T : Foo) and both types of
a same-type constraint need to be generic parameters of nested types
thereof. The latter actually prohibits code like, e.g.,
func f<R : Range requires R.Element == Int>()
which is something we may very well want to bring back into the
language in the future.
Swift SVN r2411
