DI makes the assumption that the type of self in an initializer is always
derived from a nominal type. Now that you can put an initializer body on a
protocol, this isn't true anymore, so teach it about this.
Swift SVN r27714
reference to something of class type. This is required to model
RebindSelfInConstructorExpr correctly to DI, since in the class case,
self.init and super.init *take* a value out of class box so that it
can pass the +1 value without performing an extra retain. Nothing
else in the compiler uninitializes a DI-controlled memory object
like this, so nothing else needs this. DI really doesn't like something
going from initialized to uninitialized.
Yes, I feel super-gross about this and am really unhappy about it. I
may end up reverting this if I can find an alternate solution to this
problem.
Swift SVN r27525
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
For better consistency with other address-only instruction variants, and to open the door to new exciting existential representations (such as a refcounted boxed representation for ErrorType).
Swift SVN r25902
isn't used yet, but will be for modeling the self argument passed to an
address-only witness implementation. NFC since all this code is dead :-)
Swift SVN r23857
them in a more consistent and principled way. Two changes here: MUI is generated
when a vardecl is emitted, not as a separate "MarkPatternUninitialized" pass. Second,
when generating a MUI for self parameters with a temporary alloc_stack (due to the
possibility of superclass remapping of self) emit the MUI on the allocation itself,
not on the incoming argument. This is a lot more consistent (dissolving a bunch of
hacks in DI).
In terms of behavior changes, this only changes the raw sil generated by SILGen and
consumed by DI, so there is no user-visible change. This simply unblocks future work.
Swift SVN r23823
- We switch to a model where let properties may be "initialized", but never
reassigned. Specifically, immutable properties in structs/classes may have
an init value specified in their declaration (but can then never be reset
in any init implementation) or not (in which case they must be initialized
exactly once on all paths through every init. This makes a lot more sense
for immutability, defines several problems away, and provides a path to
supporting things like (rdar://16181314)
- We now *never* default initialize an immutable property. Formerly
we would default initialize optional let properties to nil, but this
isn't actually useful, and allows an error of omission with let
properties.
This resolves: <rdar://problem/19035287> let properties should only be initializable, not reassignable
and possibly other radars.
Swift SVN r23779
without a valid SILDebugScope. An assertion in IRGenSIL prevents future
optimizations from regressing in this regard.
Introducing SILBuilderWithScope and SILBuilderwithPostprocess to ease the
transition.
This patch is large, but mostly mechanical.
<rdar://problem/18494573> Swift: Debugger is not stopping at the set breakpoint
Swift SVN r22978
allowing some cases of "self.dynamicType" in initializers before self is fully
initialized. There is still more to do.
This is part of:
<rdar://problem/17207456> Unable to access dynamicType of an object in a class initializer that isn't done
Swift SVN r22732
Dramatically improve DI diagnostics in initializers fixing rdar://18414728.
As one small example of the improvement, where an initializer like this:
class Foo {
var path:String? {
return "boo"
}
let aaaaa:String
init() {
if let p1 = path {
used to produce the error: "error: variable 'self.aaaaa' used before being initialized" on path,
we now produce:
x.swift:9:21: error: use of 'self' in property access 'path' before all stored properties are initialized
if let p1 = path {
^
x.swift:6:9: note: 'self.aaaaa' not initialized
let aaaaa:String
^
which is more useful.
Swift SVN r22238
As one small example of the improvement, where an initializer like this:
class Foo {
var path:String? {
return "boo"
}
let aaaaa:String
init() {
if let p1 = path {
used to produce the error: "error: variable 'self.aaaaa' used before being initialized" on path,
we now produce:
x.swift:9:21: error: use of 'self' in property access 'path' before all stored properties are initialized
if let p1 = path {
^
x.swift:6:9: note: 'self.aaaaa' not initialized
let aaaaa:String
^
which is more useful.
Swift SVN r22223
When analyzing a super.init call, we have several instructions involved including an upcast
to the parent type and an applyinst to call super.init. DI was using the location of the upcast
as the point at which it modeled the super.init requirement, not at the point of the applyinst. This
meant that code like:
%x = upcast self to basetype
... stuff ...
apply super.init(%x)
would not catch invalid uses of super in the "stuff" range, because DI thought that super.init was
called at the upcast. Fix this by using the apply as the super.init use, not the upcast.
Swift SVN r22101
self box as well as the address result, so that it picks up retains and releases.
Classify releases as interesting usepoints, and ignore the dealloc_stack.
Similarly, teach the logic in DefiniteInit's conditional destruction stuff to handle
the derived self case (basically, teaching it to special case the self box).
Swift SVN r21622
to track the release as something that needs the class reference to be alive at.
This implements the first piece of that: if all elements of the class are uninitialized
at the time of the release, just turn the release into a dealloc_ref. This is correct
because we know that the value would have had to be fully initialized at a retain, and
though careful construction, this only triggers in the init case.
This allows us to compile this:
class RootClassWithNontrivialStoredProperties {
let x, y: SomeClass
init?(failBeforeInitialization: ()) {
return nil
}
}
into:
sil @_TFC1t39RootClassWithNontrivialStoredPropertiesCfMS0_FT24failBeforeInitializationT__GSqS0__ : $@thin (@thick RootClassWithNontrivialStoredProperties.Type) -> @owned Optional<RootClassWithNontrivialStoredProperties> {
bb0(%0 : $@thick RootClassWithNontrivialStoredProperties.Type):
%1 = alloc_ref $RootClassWithNontrivialStoredProperties // user: %2
dealloc_ref %1 : $RootClassWithNontrivialStoredProperties // id: %2
%3 = enum $Optional<RootClassWithNontrivialStoredProperties>, #Optional.None!enumelt // user: %4
return %3 : $Optional<RootClassWithNontrivialStoredProperties> // id: %4
}
Swift SVN r21620
When DI processes a delegating initializer of an address-only value type, make sure to
mark the copy_addr as an initialization (as it was already doing for an assign
instruction) to fix a miscompilation.
The change to DIMemoryUseCollector.cpp is just to facilitate writing testcases.
Swift SVN r21478
destroy_addr's correctly and to generalize the pattern it matches on when
classifying self.init calls. This allows it to handle delegating failable
initializers in value types.
Joe to provide a testcase.
Swift SVN r21474
This makes imported factory initializers (barely) usable from
Swift-defined convenience initializers, which is needed for
<rdar://problem/16509024>.
This is all an egregious hack, because factory initializers should
really be expressible in Swift and should only emit allocating
constructors. Doing this correctly is tracked by <rdar://problem/16884348>.
Swift SVN r17946
Inherited initializers are now functional: one can use an inherited
initializer to construct an object of a subclass type, and we properly
handle delegation to overridden complete object or subobject
initializers as appropriate. See the executable test.
This commit also contains various fixes for the IRGen side of vtable
emission and use. Proper IRGen tests still to come.
For now, we're still performing peer delegation from a subobject
initializer to another subobject initializer, hence the SILGen hack
for identifying when we're in a complete object vs. a subobject
initializer. We'll be banning delegation from subobject initializers,
so this hack---along with the peer_method instruction---will be going
away in the near future.
Swift SVN r14571
Riding off of project_existential[_ref] was convenient, but the
resuls are used quite differently. Note that open_existential[_ref]
still don't print/parse reasonably yet.
Swift SVN r13878
Have SILGen mark all variables bound from pattern bindings without initializers (and *only* ones without initializers) with mark_uninitialized [var] pseudo instructions. On the DI end, *only* consider mark_uninitialized instructions for DI analysis. This has many benefits:
- DI doesn't waste time analyzing locals that are trivially initialized in the original source code.
- DI doesn't try to mangle canonical SIL that has been inlined from transparent functions, which may have been optimized into a form DI isn't written to understand.
While we're here, fix an issue with DCE where it would try to kill unused MarkUninitialized instructions. Although MarkUninitialized has no side effects, it still is semantically important to raw SIL, and can't be killed.
Chris did most of the work here; I just finished updating tests and fixing bugs.
Swift SVN r13247
When we decide to emit a separate ivar initializer method (via the
Objective-C entry point -.cxx_construct), we no longer initialize the
ivars within the initializer. This only happens for derived classes,
so teach DI about uninitialized 'self' values that require a
super.init call but don't require the ivars to be initialized.
Swift SVN r12240
In nongeneric contexts, or contexts where we only care about the indirectness of parameters or have already substituted the generic parameters for a function, the interface types are interchangeable, so just switch over.
Swift SVN r12044
Emphasize the fact that this address is only intended for initialization. When we split destructive_switch_enum_addr, there will be another similar instruction for destructively taking the payload out of an already-initialized enum.
Swift SVN r12000
Introduce the SIL instruction peer_method, which references a method
in the given class or one of its superclasses (but not a subclass). It
IRGen's to objc_msgSendSuper[Stret] (vs. super_method IRGen'ing to
objc_msgSendSuper[Stret]2 for superclass lookup).
Use peer_method for initializer delegation to a foreign initializer
(i.e., an init-family method written in Objective-C) to close the
safety loophole introduced by initializer delegation in r11965. The
loophole still exists, but can only be triggered from Objective-C.
Teach definite initialization that peer_method really isn't a use of
self.
Swift SVN r11992
is no longer an lvalue, since it doesn't make sense to assign to super.
This eliminates a bunch of special cases and simplifies things.
Swift SVN r11803
