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
Also, the extra inhabitant lookup for native Swift no-payload enums is inappropriate for C enums. For now, expose no extra inhabitants from C enums.
Swift SVN r10006
Borrow the scalar type of the raw type as the representation type of C enums, and use the raw values from C as the discriminator values of the cases.
Swift SVN r9988
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
Its job will be a bit more broad for generic structs, where it needs to fill field offsets into the metadata in addition to storing the final size, stride, and alignment information to the value witness table.
Swift SVN r9104
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
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
Introduce an EnumCaseDecl for source fidelity to track the 'case' location and ordering of EnumElementDecls. Parse a comma-separated list of EnumElementDecls after a 'case' token.
Swift SVN r8509
