- Strength reduce the interface to LogicalPathComponent::getMaterialized
to now just return a SILValue for the address. The full "Materialize"
structure hasn't been needed since MaterializeExpr got removed.
- Move 'struct Materialize' out of SILGen.h into SILGenLValues.cpp now
that it is only used for logical property materialization.
- Drop the dead 'loc' argument on DeallocStackCleanup. The location is
already specified when the cleanup is emitted.
Swift SVN r12827
When we produce a physical LValue with an abstraction difference, cap off the LValue with a logical "OrigToSubstComponent", which enacts the abstraction change on load or store, and introduces a writeback for the property when used in an @inout context.
Swift SVN r11498
of having to lower to an RValue.
This is valuable because we can often emit an expression to a
desired abstraction level more efficiently than just emitting
it to minimal abstraction and then generalizing.
Swift SVN r10455
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
