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
Handle the easy bound generic type abstraction difference case, where the original unsubstituted type is address-only, and we just need to emit a loadable substituted type to a temporary buffer or bitcast an already address-only substituted type.
Swift SVN r8265
This breaks the type-canonicalization link between a generic parameter
type and the archetype to which it maps. Generic type parameter types
are now separate entities (that can eventually be canonicalized) from
archetypes (rather than just being sugar).
Most of the front end still traffics in archetypes. As a step away
from this, allow us to type-check the generic parameter list's types
prior to wiring the generic type parameter declarations to archetypes,
using the new "dependent" member type to describe assocaited
types. The archetype builder understands dependent member types and
uses them to map down to associated types when building archetypes.
Once we have assigned archetypes, we revert the dependent identifier
types within the generic parameter list to an un-type-checked state
and do the type checking again in the presence of archetypes, so that
nothing beyond the generic-parameter-list checking code has to deal
with dependent types. We'll creep support out to other dependent types
elsewhere over time.
Swift SVN r7462
the new LoadableTypeInfo refinement interface.
This protects against bugs which would introduce unbalanced
allocations of temporary memory.
Swift SVN r7227
The current implementation of dealloc_stack in IR-gen is a
no-op, but that's very much wrong for types with non-trivial
local allocation requirements, e.g. archetypes. So we need
to be able to do non-trivial code here. However, that means
modeling both the buffer pointer and the allocated address
in SIL.
To make this more type-safe, introduce a SIL-specific
'[local_storage] T' type that represents the required
allocation for locally storing a T. alloc_stack now returns
one of those in additon to a *T, and dealloc_stack expects
the former.
IR-gen still implements dealloc_stack as a no-op, but
that's now easy to fix.
Swift SVN r6937
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
The idea for now is that this is a SIL-only type used for
representing the storage of a weak or unowned reference.
Having it be its own type is pretty vital for reasonable
behavior in SIL and IR-generation, and it's likely that
this will surface into runtime metadata as well (hence
the mangling).
I've implemented a bunch of things that technically I don't
think are necessary if this stays out of the typechecker,
but it's easier to implement half-a-dozen "recurse into
the child type" methods now that it would be to find them
all later if we change our minds.
Swift SVN r6091
Improve our representations of casts in the AST and SIL so that 'as!' and 'is' (and eventually 'as?') can share almost all of the same type-checking, SILGen, and IRGen code.
In the AST, we now represent 'as!' and 'is' as UnconditionalCheckedCastExpr and IsaExpr, respectively, with the semantic variations of cast (downcast, super-to-archetype, archetype-to-concrete, etc.) discriminated by an enum field. This keeps the user-visible syntactic and type behavior differences of the two forms cleanly separated for AST consumers.
At the SIL level, we transpose the representation so that the different cast semantics get their own instructions and the conditional/unconditional cast behavior is indicated by an enum, making it easy for IRGen to discriminate the different code paths for the different semantics. We also add an 'IsNonnull' instruction to cover the conditional-cast-result-to-boolean conversion common to all the forms of 'is'.
The upshot of all this is that 'x is T' now works for all the new archetype and existential cast forms supported by 'as!'.
Swift SVN r5737
Just refer to "class archetypes" and "class protocols". Change 'isClassBounded' methods to 'requiresClass', which is a character shorter.
Swift SVN r5674
If an archetype has a superclass bound, we can assume the superclass's
retain semantics for the type. We can also use the superclass's storage pointer type to cut down on some bitcast IR noise when calling superclass methods on the archetype value.
Swift SVN r5642
Treat archetypes with a superclass bound as class-bounded. Change SILGen and IRGen to use the new SuperToArchetypeRef and ArchetypeRefToSuper cast instructions, and drop the old SuperToArchetype and ArchetypeToSuper instructions, which are unneeded because any archetype with a superclass will be class-bounded.
Note that this patch doesn't implement representation optimization for archetypes with superclass bounds--they're still always represented with a worst-case UnknownRefCountedPtrTy.
Swift SVN r5629
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
Sever the last load-bearing link between SILFunction and SILConstant by naming SILFunctions with their mangled symbol names. Move the core of the mangler up to SIL, and teach SILGen how to use it to mangle a SILConstant.
Swift SVN r4964
seems that this is not a good idea, because it seems statically live from the SIL
SuperToArchetypeInst. However, apparently nothing in the testsuite exercises
this code, so I'll need to discuss and a testcase to know how much logic needs
to be ressurrected from SVN. rdar://13681541
Swift SVN r4800
Introduce a new swift_dynamicCast pair that take in a general metatype
pointer, rather than the more specific class-metatype pointer used for
class downcasts, and grab the class out of that general metatype
pointer, which may actually be an Objective-C wrapper. This is
slightly slower, but it works for the super-to-archetype cases like
T(an_NSObject), where T can have either kind of metadata.
NSTypedArray<T> is actually run-time type checked now, yay!
Swift SVN r3564
protocol witnesses over to the new API. There's some badness
that we're papering over here involving generic types, but
this is a necessary first step.
Swift SVN r3003
