Building the field type vector is potentially expensive and the vector isn't needed unless we do reflectiony things to a type, so let's use a lazy accessor. Make room for it, but don't populate it yet, so we can deal with fallout from the metadata layout change.
Swift SVN r15194
Focus on the immediate problem of handling arguments. Describe the desired user model followed by the necessary language features to support the user model using library implicit conversions.
Swift SVN r15161
Loosen the restrictions on open_existential_ref to also allow it to
refer to an existential metatype. When it does, open_existential_ref
returns the metatype for the opened archetype.
Swift SVN r15113
This reverts commit r14488, since we're demoting 'type' back to a plain old identifier.
We could consider reallowing 'type' as a contextual keyword here, but from talking to Jordan he was OK with just reverting this functionality.
Swift SVN r14931
This means that we accept type attributes in a much broader
range of places where we previously required a <type>. <type>
was already a production that demanded a grammatically
unconstrained context because of all the possible continuations;
reducing the number of independent productions makes it easier
to choose one and thus not accidentally limit the range of
possible types parsed.
In particular, we want to be able to parse @unchecked T? pretty
much anywhere you can write a type.
Swift SVN r14912
In the short term, we need to be able to emit shared symbols for SILWitnessTables corresponding to Clang-imported modules, and soon, the generic specializer will need to be able to reference *_external witness tables deserialized from library modules.
Swift SVN r14887
alloc_ref_dynamic allocates an instance of a class type based on the
value in its metatype operand. Start emitting these instructions for
the allocating constructor of a complete object initializer (not yet
tested) and for the allocating constructor synthesized for an imported
Objective-C init method.
Still missing:
- IRGen still does the same thing as alloc_ref right now. That
change will follow.
- There are devirtualization opportunities when we know the value of
the metatype that would turn an alloc_ref_dynamic into an alloc_ref;
I'm not planning to do this optimization.
Swift SVN r14560
It's not forming the metatype for the protocol type (exists t: P. t).metatype, it's forming the existential of a metatype of a conforming type, exists t: P. (t.metatype).
Swift SVN r14520
Having one instruction to get the dynamic metatype of a (non-existential) value makes more sense from a generic specialization standpoint and should stave off inevitable crashers when archetype_metatypes get specialized. protocol_metatype remains separate because metatype existentials are more interesting.
Swift SVN r14499
We were wantonly applying 'upcast' to archetypes in some cases, and really, that's OK, since these instructions do the same thing (and generic specialization could turn archetype_ref_to_super into upcast). Make everyone's life easier by folding archetype_to_super into upcast. Fixes <rdar://problem/16192324>.
Swift SVN r14496
Previously this was spelled "import typealias", and that spelling will
continue to be allowed (since someone may specifically be importing a
typealias and want that to match), but now that 'type' is a keyword,
"import type" is the right way to spell the generic "import any type"
scoped import.
Swift SVN r14488
Diagnose a metatype reference that doesn't appear as part of a call or member reference, offering fixits to either default-construct the type or get at the metatype explicitly using '.self'. Also diagnose an attempt to refer to 'T.type' by fixiting it to '.self'.
Swift SVN r14433
A short-term fix to <rdar://problem/16079822> that keeps generic overloads from creating symbol collisions without requiring a larger migration of the debugger or other tools.
Swift SVN r14353
This allows the optimizer to use the type information from loads, stores,
and address projections to disambiguate pointers. This will allow for
significantly more aggressive load/store forwarding of the “owning pointer”
pattern in the std lib by enabling the disambiguation of loads/stores of the
owning pointer that feed into retains/releases from loads/stores of the structs
data. This is a pervasive pattern seen in such important structs as Array,
String, and many others.
Swift SVN r14210
We know that further edits are forthcoming from DevPubs; we just don't
know when. Make sure nobody mistakes this for a DevPubs-approved draft.
Swift SVN r14102
