Make the functions support a wider range of builtins and store types to make
it possible.
This is an optimization - the cached ID will be used for builtin identification,
instead of retrieval of the string name and using it as the key.
Swift SVN r7390
SequentialTypeInfo types need to recursively packUnionPayload/unpackUnionPayload their elements, so have packUnionPayload/unpackUnionPayload take a starting offset and fix up the implementations so they pass down proper offsets for aggregate types.
Swift SVN r7362
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
Add packUnionPayload and unpackUnionPayload methods to LoadableTypeInfo that pack an explosion into a union payload and unpack an explosion from a union payload.
Swift SVN r7321
the new LoadableTypeInfo refinement interface.
This protects against bugs which would introduce unbalanced
allocations of temporary memory.
Swift SVN r7227
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
When an existential's contained type is used as a generic parameter, unwrap the existential container and save its metadata and witnesses to be used as polymorphic arguments.
Our AST representation can't quite express the distinction between a type parameter being satisfied by the existential type itself from being satisfied by the existential's contained yet. I use a goofy heuristic where I assume a protocol type bound to a type variable with no requirements is satisfied by the protocol type itself; this covers all of the existing <T> (Slice<T>, T) cases that come up in the library, while enabling the <T:Foo> (T) cases. This hopefully addresses <rdar://problem/14470097> well enough to unblock library work until we get a solid AST representation of this difference.
Swift SVN r6352
This adds builtin types Builtin.VecNxT, where N is a natural number
and T is a builtin type, which map down to the LLVM type <N x T>.
Update varous builtins to support vector arguments, e.g., binary
operations, comparisons, negation. Add InsertElement and
ExtractElement builtins for vectors.
On top of these builtins, add Vec4f and Vec4b structs to the standard
library, which provide 4xFloat and 4xBool vectors, respectively, with
basic support for arithmetic. These are mostly straw men, to be burned
down at our leisure.
Some issues as yet unresolved:
- Comparisons of Vec4f'ss are producing bogus Vec4b's, which I
haven't tracked down yet.
- We still don't support the shuffle builtin, although it should be
easy
- More testing!
Swift SVN r5820
Just refer to "class archetypes" and "class protocols". Change 'isClassBounded' methods to 'requiresClass', which is a character shorter.
Swift SVN r5674
Split ArchetypeTypeInfo into ClassBoundedArchetypeTypeInfo, for class-bounded archetypes, and OpaqueArchetypeTypeInfo, for fully generalized archetypes (the existing case). ClassBoundedArchetypeTypeInfo is represented using a single refcounted ObjCPointer. Implement abstraction remapping from class instances to class-bounded archetypes and back, and from class-bounded archetypes to non-class-bounded and back.
Witness tables are still generated only for opaque archetypes, so method calls on class-bounded archetypes won't work just yet.
Swift SVN r5569
Add an index_raw_pointer instruction that acts like index_addr but for RawPointers, and use it to lower Builtin.gep into SIL instead of into IR.
Swift SVN r5479
Now that SILGen and IRGen can both handle capturing archetypes from generic scopes, we can set the DeclContext of ImplicitClosureExprs correctly, so that SILGen captures their context archetypes. &&, and ||, and assert now work in generic contexts, at least in simple test cases.
Swift SVN r5476
If a specialization is partially applied, emit a single thunk bundling the bound polymorphic arguments and the partially-applied argument values into a single context object. This should almost get closures in generic contexts (at least, ones that never cross abstraction boundaries) working.
Swift SVN r5475
Delete the non-placement operator new/delete in the SILAllocated CRTP base so that the compiler saves us from accidentally allocating and leaking SILInstructions on the main heap instead of the owning SILModule's BPA.
Swift SVN r5468
If -nsstring-is-string is enabled, lower Strings in cc(c) and cc(objc) function types to NSString, and when calling them, insert calls to StringToNSString/NSStringToString to perform the bridging conversion.
This isn't quite ready for prime-time yet, because we still need to emit the inverse bridging for ObjC method thunks, and I haven't tested the IRGen end of things yet.
Swift SVN r5355
Generate and cache SILFunctionTypeInfo from Swift types on the fly, and simplify the SILType representation down to a CanType and isAddress bit.
Swift SVN r5298
Remove uncurry level as a property of SILType/SILFunctionTypeInfo. During SIL type lowering, map a (Type, UncurryLevel) pair to a Swift CanType with the uncurried arguments as a Swift tuple. For example, T -> (U, V) -> W at uncurry level 1 becomes ((U, V), T) -> W--in reverse order to match the low-level calling convention. Update SILGen and IRGen all over the place for this representation change.
SILFunctionTypeInfo is still used in the SILType representation, but it's no longer load-bearing. Everything remaining in it can be derived from a Swift type.
This is an ABI break. Be sure to rebuild clean!
Swift SVN r5296
This cleans up some wishy-washy control flow that relied on the uncurryLevel of a type to distinguish ObjC methods from freestanding C functions. While we're here, clean up all the places we use ad-hoc comparison logic on the AbstractCC enum to use switches that properly cover the enum.
Swift SVN r5251
We decided we're going to want to surface fine-grained representational control of functions to the user, so move AbstractCC and the calling convention attributes into the Swift type system. Like the [thin] attribute, we don't set this in the type-checker or importer at all yet, and let SILGen set the attribute where it wants it for now.
Swift SVN r5222
Use the SIL-generated ObjC thunk symbols instead of generating them in IRGen. Kill all the now-dead IRGen OwnershipConventions stuff. Teach IRGenSILFunction how to emit a C-calling-convention function, and getFunctionType how to map a C-calling-convention function type. Fix a bug in SILGen where ObjC thunks for methods and properties from extensions weren't getting emitted.
Swift SVN r5180
This commit implements closure syntax that places the (optional)
parameter list in pipes within the curly braces of a closure. This
syntax "slides" well from very simple closures with anonymous
arguments, e.g.,
sort(array, {$1 > $0})
to naming the arguments
sort(array, {|x, y| x > y})
to adding a return type and/or parameter types
sort(array, {|x : String, y : String| -> Bool x > y})
and with multiple statements in the body:
sort(array, {|x, y|
print("Comparing \(x) and \(y)\n")
return x > y
})
When the body contains only a single expression, that expression
participates in type inference with its enclosing expression, which
allows one to type-check, e.g.,
map(strings, {|x| x.toUpper()})
without context. If one has multiple statements, however, one will
need to provide additional type information either with context
strings = map(strings, {
return $0.toUpper()
})
or via annotations
map(strings, {|x| -> String
return x.toUpper()
}
because we don't perform inter-statement type inference.
The new closure expressions are only available with the new type
checker, where they completely displace the existing { $0 + $1 }
anonymous closures. 'func' expressions remain unchanged.
The tiny test changes (in SIL output and the constraint-checker test)
are due to the PipeClosureExpr AST storing anonymous closure arguments
($0, $1, etc.) within a pattern in the AST. It's far cleaner to
implement this way.
The testing here is still fairly light. In particular, we need better
testing of parser recovery, name lookup for closures with local types,
more deduction scenarios, and multi-statement closures (which don't
get exercised beyond the unit tests).
Swift SVN r5169
Emit thunks for [objc] class methods and properties as SILFunctions, using SILGen's OwnershipConventions. This will help kill some redundant ownership code in IRGen, and will allow msgSend thunks to handle string and block bridging. IRGen doesn't actually codegen the thunks yet; that will require teaching IRGenSILFunction how to be AbstractCC-aware, so for now, we just reemit the thunks using the old IRGen code.
Swift SVN r5168
