Remove the initialize_var instruction now that DI fully diagnoses initialization problems. Change String-to-NSString bridging to explicitly invoke String's default constructor; it was the last remaining user of initialize_var. Remove dead code to emit an implicit default constructor without a body.
Swift SVN r11066
Start using null-page values as extra inhabitants when laying out single-payload enums that contain class pointers as their payload type. Don't use inhabitants that set the lowest bit, to avoid trampling potential ObjC tagged pointer representations. This means that 'T?' for class type T now has a null pointer representation. Enums with multiple empty cases, as well as nested enums like 'T??', should now have optimal representations for class type T as well.
Note that we don't yet expose extra inhabitants for aggregates that contain heap object references, such as structs with class fields, Swift function types, or class-bounded existentials (even when the existential has no witness tables).
Swift SVN r10061
The payload type of a dependent single-payload enum is "empty" but we still need to run its destructor. Oops. Fixes <rdar://problem/15383966>.
Swift SVN r9932
Build a nominal type descriptor when we emit the metadata or generic metadata pattern for a nominal type, and put a reference into the formerly null slot in the struct or enum metadata. We need to make a place for them in class metadata; that'll come next.
Swift SVN r9492
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
John noted that LLVM's ABI rules for Integers of Unusual Size cause them to be aligned like the largest native integer type even inside packed structs, making them unsuited for byte-accurate layout in cases where the payload is a non-power-of-two size, so we have to bite the bullet and lay them out as arrays of i8, bitcasting to the payload type to load and store the payload and tag parts.
This still colors outside of the lines a bit because loading or storing e.g. an i72 is going to touch an i128's worth of memory. Baby steps. It'd be nice to be able to load and reconsistute the i72 without having to load and mask together all of the individual bytes.
Swift SVN r9058
LLVM's normal data layout doesn't jive with our own StructLayout's more aggressive use of padding space, and causes problems such as <rdar://problem/14336903>. Because we do our own alignment and stride management, we can safely use LLVM packed struct types with manual padding to get the level of control we need to accurately reflect our desired struct layout.
Swift SVN r9056
If the enum gets laid out with a non-power-of-two payload and an extra tag, such as { i72, i2 }, then LLVM's natural location for the extra tag is going to be different from where we actually want it, so let's do our own byte offset calculation by bitcasting to i8* and gepping instead of trying to gep the struct directly.
Swift SVN r9023
