- Change the parser to unconditionally reject @mutating and @!mutating with a fixit and
specific diagnostic to rewrite them into the [non]mutating keyword.
- Update tests.
This resolves <rdar://problem/16735619> introduce nonmutating CS keyword and remove the attribute form of mutating all together
Swift SVN r16892
Given base class A and dervied class B, both with member functions f(),
to look for A.f in B's vtable, we should return SILFunction for B.f.
Before this commit, B's vtable will have entry for B.f, A's vtable will
have entry for A.f. When looking for A.f in B's vtable, it returns null.
And devirtualizer will look for A.f in A's vtable and resolve it to
SILFunction for A.f.
When replacing a class_method %1 : $A, #A.f!1 with a function ref to B.f,
we will have type checking issues for the apply instructions. So devirtualizer
will replace the argument of the apply instructions when necessary.
rdar://16681983
Swift SVN r16854
An unsafe cast from a base to a derived class isn't really all that different from one from Builtin.NativeObject to an arbitrary class, so relax this pair of instructions to allow an arbitrary bitcast. This only combines the instructions; it doesn't attempt to simplify any codegen that was emitting round-trip casts before yet.
Swift SVN r16736
This was part of the original weak design that
there was never any particular reason to rush the
implementation for. It's convenient to do this now
so that we can use it to implement Unmanaged<T> for
importing CF types.
Swift SVN r16693
The implied semantics are:
- side-effects can occur any time before the first invocation.
- all calls to the same global_init function have the same side-effects.
- any operation that may observe the initializer's side-effects must be
preceded by a call to the initializer.
This is currently true if the function is an addressor that was lazily
generated from a global variable access. Note that the initialization
function itself does not need this attribute. It is private and only
called within the addressor.
Swift SVN r16683
them with uses of TypeExpr instead. The remaining uses of
MetaTypeExpr (which will be renamed soon) are places where we
are applying the ".dynamicType" virtual property to an expression.
Unadorned uses of types in code, e.g. the Int in "Int.self" are
now represented with TypeExpr.
One unfortunate travesty that doing this work revealed is that we
are extremely sloppy and terrible about maintaining location information
in implicitly generated decls, and our invariants vary quite a bit. This
is really horrible, but I'm not sure whether I'll go fix the hacks or not.
This patch perpetuates the existing crimes, but makes them more visible.
NFC!
Swift SVN r16646
inherited conformances can result in virtual calls to overriding
subclass methods.
Previously given the following swift code:
protocol P {
func x()
}
class B : P {
func x() { ... }
}
class B2 : B {
func x() { ... }
}
func doX<T : P>(t : T) {
t.x()
}
var b2 = B2()
doX(b2)
We would have b2 reference the protocol method for B.x. But since the
protocol method B.x would have a direct function reference to B.x, we
would not get the correct behavior that doX(b2) should invoke B2.x. This
is fixed by changing SILGen to emit class_method calls in protocol
methods for classes.
Swift SVN r16645
Do this the lazy way, just autoreleasing "self" after the call. A future optimization pass may be able to eliminate this autorelease when it recognizes the lifetime of the derived value, but that's not immediately necessary.
Swift SVN r16635
This will represent the return convention of imported __attribute__((objc_returns_inner_pointer)) methods. Leave it unimplemented for now until we can autorelease things sanely.
Swift SVN r16628
when resolving identifiers into types. This will eventually allow us to
solve annoying issues like rdar://15295763&15588967 by better modeling
what we already have.
Swift SVN r16620
Before we create a new initializer, check whether it would collide
with existing initializers. If it's better than the existing
initializer, mark the existing one as unavailable; if it's not better,
don't build it.
In support of this, we tweak a few things w.r.t. unavailble
declarations:
- An unavailable declaration is shadowed by an available one,
- Don't emit SIL unavailable, imported initializers
This fixes the last problem with <rdar://problem/16509024>.
Swift SVN r16611
LabeledStmt that they target: have sema fill this in, and make silgen respect it.
NFC, because this was specifically written to behave the same as before (e.g. no
break out of switches).
Swift SVN r16610
Use this node to capture the argument name and its source location in
the AST. We're only building these in one place at the moment; the
rest will be updated soon.
Swift SVN r16581
These initializers are class methods, so provide them with the
metatype value rather than allocating an object. Moreover, they
generally return autoreleased, so we need to retain them out of the
autorelease pool before returning the produced 'self'.
Finishes the SILGen and IRGen portions of
<rdar://problem/16509024>. We still can't enable this in practice
because we're getting duplicate initializers, as predicated in the
hacky r16531.
Swift SVN r16555
Add an emitIgnoredExpr entrypoint to SILGenFunction that emits an expression, ignoring its result. This isn't an extensive implementation but just tackles the low-hanging fruit of allowing +0 rvalues and not crashing on sudden lvalues, fixing <rdar://problem/16650625>.
Swift SVN r16536
Introduce CtorInitializerKind to describe the kind of an enum, rather
than a bool, to make way for more initializer kinds in the future.
Swift SVN r16525
Teach SILGen to handle function representation changes as part of function conversion instead of needing to be spoonfed a special expr for the purpose. Handle representation changes in both directions to and from blocks using the same logic as the bridging conversions.
Swift SVN r16318
This means that we now synthesize getters and setters a lot more than we used to, so the
implementation work on this shook out a ton of bugs with them.
There is still one failure that I don't understand at all (test/stdlib/NewArray.swift.gyb),
nor do I understand how to diagnose the problem, so I XFAILed it and filed rdar://16604980 to
track fixing it.
Swift SVN r16299
Emit Swift thunk functions to bridge blocks into native function values. On entry into @objc thunks, copy_block blocks to ensure they've been lifted off the stack.
Swift SVN r16177
Set up type lowering to map thick functions to blocks. Stub out the actual codegen for the bridge by just emitting an 'undef' and declaring the feature unimplemented for now.
Swift SVN r16148
We want to generally treat blocks as heap objects until proven stack-able by escape analysis, like we do generally with other heap entities. The only place we should be exposed to stack blocks is when they're passed as arguments, so handle this by copy_block'ing any block arguments we get in the function prolog. Optimization can eliminate them when analysis shows the block doesn't escape or is already on the heap.
Swift SVN r16096
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
