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
- Don't require "OverloadedBuiltinKind::" to be in the invocation
of a bunch of builtins for their specification of overload info.
Eliminating this makes the file fit in 80 columns.
- Eliminate a bunch of classifications that only classify one thing,
in favor of a "BUILTIN_MISC_OPERATION" dumping ground for all the
custom stuff. This eliminates a bunch of boilerplate.
No functionality change.
Swift SVN r3615
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
is really a deficiency in TypeInfo::initializeWithTake, which
is now virtual and not implemented in TypeInfo anymore. This
fixes rdar://problem/12153619.
While I'm at it, fix an inefficiency in how we were handling
ignored results of generic calls, and add 4 new builtins:
Builtin.strideof is like sizeof, but guarantees that it
returns a multiple of the alignment (i.e., like C sizeof,
it is the appropriate allocation size for members of an
array).
Builtin.destroy destroys something "in place"; previously
this was being simulated by moving and ignoring the result.
Builtin.allocRaw allocates raw, uninitialized memory, given
a size and alignment.
Builtin.deallocRaw deallocates a pointer allocated with
Builtin.allocRaw; it must be given the allocated size.
Swift SVN r2720
static method to call it, to make it more explicit what is happening. Avoid
using TypeLoc::withoutLoc for function definitions; instead, just use an empty
TypeLoc.
Swift SVN r2606
Builtin.ObjectPointer, and Builtin.RawPointer. I don't really like the way
these builtins are defined (specifically, the part where messing up
gives a mysterious IRGen error), but it's workable. <rdar://problem/11976323>.
Swift SVN r2585
in SpecializeExpr, so that we have complete substitution and
protocol-conformance information. On the IR generation side, pass
witness tables for all of the archetypes (again, including derived
archetypes) into generic functions, so that we have witness tables for
all of the associated types.
There are at least two major issues:
(1) This is a terribly inefficient way to pass witness tables for
associated types. The witness tables for associated types should be
accessible via the witness tables of their parent. However, we need
more information in the ASTs here, because there may be additional
witness tables that will need to be passed for requirements that are
placed on the associated type by the generic function itself.
(2) Something about my test triggers a void/non-void verification failure
in the witness build for an instance function whose abstracted form
returns an associated type archetype and whose concrete form returns
an empty struct. See the FIXME in the test.
Swift SVN r2464
wrap it in an 'id' type in the standard library.
Also fix a bug noticed by inspection where initWithTake for
function types wasn't entering a cleanup for the taken value.
This probably doesn't matter for existing possibilities, but
it's potentially important under exceptions.
Swift SVN r1902
allows access to any LLVM IR intrinsic that has types that can be mapped
to swift types. Notably, this excludes vector stuff, but there is a lot
of other goodness that can now be poked at.
Swift SVN r1890
and is just an unmanaged pointer. Also, introduce a basic swift.string type.
This is progress towards rdar://10923403 and strings. Review welcome.
Swift SVN r1349
in favor of a single-element non-canonical TupleType) broke the type
system, in that supposed sugar (the TupleType) supported a different
set of operations from the canonical type. For example, a
single-element unlabelled tuple type supports elementwise projection
(foo.$0), but the underlying element does not (or supports it
differently).
The IR-gen failure was due to a very related problem: IR-gen
was not updated to reflect that a single unlabelled tuple element
is the same type as its element type, and therefore it was giving
different representations to these types ({ %foo } and %foo,
respectively), which broke widespread assumptions.
The removal of ParenType was done in pursuit of an AST invariant
that's not actually particularly interesting in the first place
and which, furthermore, is problematic to attain.
Swift SVN r1182
