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
- Fix a misunderstanding I had about ownership requirements in my previous patch:
now any references to value-promoted self do a retain and use a ManagedValue,
just like the semantic load path used to. This is the change to visitLoadExpr
- Second, change argument lowering to drop the "self" argument of normal class
methods into a constant reference, instead of making a box for it. This
greatly reduces the amount of SIL generated for class methods.
The argument lowering piece is somewhat hacky because initializations really want
to be dealing with memory, but it seemed like the best approach given the current
design. Review appreciated.
Swift SVN r10984
is used for VarDecls that are immutable once defined. This
will eventually be used to model 'val' in SILGen, but for now
we can use it to optimize some 'self' situations.
At present, we use it for class 'self' in destructors and for
init methods of root classes. The init methods of derived
classes need to be able to mutate self when calling super.init
so they can't use this presently. I haven't gotten around to
switching general methods to use it yet.
This introduces two new regressions that don't appear in the
testsuite: we lose debug info for "self" in this case, and
we cannot close over self.
Swift SVN r10962
Existing uses use a "globalvar" kind. Add a new "rootinit" kind which
will be used for root initializers (i.e. init methods of structs, enums,
and root classes).
Swift SVN r10772
If a subclass overrides a declaration from an ObjC class extension, that decl won't have a vtable entry, and we shouldn't expect to override it. Fixes <rdar://problem/15282548>.
Swift SVN r10547
Route global var refs (except for those referencing top-level code vars) through the lazy-initializing global accessor functions for those globals.
Swift SVN r10519
For every global pattern binding, emit a lazy initializer token and function that initializes the global variables in that binding. For each of those vars, create an accessor that Builtin.once's the lazy initializer before producing the address. Hide this all behind a switch till the surrounding serialization and IRGen infrastructure catches up.
Swift SVN r10511
- Enhance SILBuilder::emitStrongRelease to be smarter.
- Start using emitStrongRelease in type lowering, SILGen,
CapturePromotion (replacing its implementation of the
same logic), and MandatoryInlining (one more place)
- Rename the primitive createStrongRetain/ReleaseInst
instructions to lose their suffix.
- Now that createStrongRetain/ReleaseInst are not special
cases from the naming perspective, remove some special cases
from DeserializeSIL and ParseSIL.
Swift SVN r10449
They are the same as createStrongRetainInst and createStrongReleaseInst, but
peephole away FunctionRefInst. It turns out that there is only a couple
places in SILGen where this behavior is necessary, and this tramples on the
general pattern used in SILBuilder.
Swift SVN r10448
For the subset of static properties we're implementing, we can skate by with global static constructors like we do for global variables. Leave some asserts behind so we revisit this when we implement the hard cases.
Swift SVN r10383
In SILGen, when we emit the enum external definition, emit the methods in addition to the case constructors for the enum. Make sure they get thunk linkage.
Swift SVN r10017
If a local function tried to reference a local typealias, we were trying to emit a SIL variable reference and freaking out, causing <rdar://problem/15360605>. For now, don't emit any capture arguments for local typealiases. Any context a local typealias requires should be handled by capturing the external context's generic parameters.
Swift SVN r9865
Whatever kind of Swift decl we cons up for a Clang enum, add it to the externals list so we can pick it up and emit Swift metadata for it in IRGen. Fixes <rdar://problem/15242452>.
Swift SVN r9801
so they can be easily identified by the inout deshadowing pass. This does
not mark the alloc_box as autogenerated though, since it is a user variable
when the variable escapes.
- Fix some wonky indentation in SILLocation.
Swift SVN r9700
Introduces a new flag in SILLocation: InPrologue to mark instructions
that setup the stack and allocate storage for local variables/arguments.
Fixes rdar://problem/15290023: Breakpoint set on prologue - crash ensues.
Swift SVN r9686
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
Rewrite ForEachStmt SILGen to use the Optional intrinsics with the Generator.next method to iterate through sequences, and kill off the Enumerator path in Sema. Cut over 'EnumeratorType.Element' requirements to instead require 'GeneratorType.Element' in the stdlib.
There are a couple of bugs remaining that need follow-up work. There appears to be a bug in nested enum layout (e.g. T??) that's causing test/Interpreter/enum to break; I'll investigate and fix. There's also a lingering type-checker bug with inferred associated types that causes them to fail requirement checks <rdar://problem/15172101>, which I think Doug needs to look into.
Swift SVN r9017
Chris and I want to move toward canonicalizing on more abstract aggregate operations (copy_addr) instead of on the component load/store/copy|destroy_value/retain|release operations, which is easier for early passes like inout deshadowing, NRVO, and move optimization to reason about. As a first step, replace the handful of places where SILGen currently used TypeLowering::emitCopyInto with simple CopyAddrInst insertions. This affects inout initializations and emitSemanticLoadInto, neither of which should disturb early passes that relied on the old behavior.
Swift SVN r8991
preceding copy_addr instruction when totally trivial. Adopt this in SILGen, eliminating
a couple dozen destroy_addr instructions from the stdlib and producing more canonical SIL.
Swift SVN r8968
When we walk a ClassDecl, generate its vtable, first pulling in decls from its ancestor classes, then overlaying overridden or new decls as we discover them.
Swift SVN r8947
Make ApplyInst and PartialApplyInst directly take substitutions for generic functions instead of trying to stage out substitutions separately. The legacy reasons for doing this are gone.
Swift SVN r8747
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
Doug pointed out that 'isObjC' incorrectly excludes C functions, for which we'll also need to be able to independently reference Swift and foreign entries.
Swift SVN r8669
Create a local box for byref arguments that can be closed over. The box receives the value of the byref at function entry, and the value in the box at function exit is written back to the byref. This will allow us to eliminate the no-capture restriction on byrefs, allowing them to be used in auto closures and other HOFs, and doing the right thing in the 99% case where closures are effectively nocapture without requiring user annotation. <rdar://problem/14732389>
There are a couple of loose ends:
- The type-checker can lose its restriction on byref captures. I'll do that next.
- Debug info needs to learn how to represent local byref boxes. Adrian is better qualified to decide how to do that.
- Byref shadow copies completely defeat the copy-on-write optimization for String, making append sequences ridiculously slow. Memory promotion needs to learn to eliminate shadow copies completely when it promotes away byref boxes in order to solve this regression.
Swift SVN r8630
