When a given class definition has no constructors, the parser was
introducing an implicit-declared default constructor in the class. The
type checker ignored it. SILGen creating something that was completely
broken. Remove all of that and fix the fallout.
Swift SVN r8432
When we import an Objective-C init method into Swift as a constructor,
the Clang importer currently synthesizes both a +alloc call (used by
the allocating constructor) and a body that forwards to the
corresponding init method. Eliminate the body and stop emitting an
initializing constructor at all: instead, the allocating constructor
will invoke the init method through objc_msgSend.
Swift SVN r8420
ObjC methods are already tagged with a special calling convention and have special IRGen handling to keep the _cmd argument abstracted away from SIL. We can use the CC to also abstract away the detail that Swift methods pass 'self' last but ObjC methods pass 'self' first. This eliminates a weird special case from SIL's perspective, and also means that 'partial_apply' can work on objc methods correctly without becoming significantly more complex.
Swift SVN r8091
In SILGenApply, if we have a partially-applied invocation of a class method, make a call to a currying thunk instead of trying to perform dynamic dispatch in-line. Emit the class dynamic dispatch instead as part of the currying thunk itself, and close over the dynamic method pointer as part of the curried closure context.
Swift SVN r8076
Introduce a proper cleanup for the Optional<T> value created by
non-forced dynamic member lookups.
Additionally, properly manage each reference to an OpaqueValue within
an expression, and release the value when the RAII object goes out of
scope. This is the conservative approach to be optimized soon.
Swift SVN r8071
The dynamic_method_br instruction branches depending on whether a
particular object can accept a given message, as determined at
runtime. If the object can accept the message, it branches to the
first basic block, providing the uncurried method as the BB
argument. If the object cannot accept the message, it branches to the
second basic block. Either way, the result is packaged up into an
optional type and passed along to the continuation block, which
provides the optional result.
Note that this instruction is restricted to lookup of Objective-C
methods.
Documentation and IR generation (via -respondsToSelector) to
follow. Review greatly appreciated!
Swift SVN r8065
The dynamic_method instruction handles method lookup on an existential
of type DynamicLookup based on the selector of an [objc] method of a
class or protocol. It is only introduced in the narrow case where we
are forcing a use of the method with '!', e.g.,
class X {
func [objc] f() { println("Dynamic lookup") }
}
var x : DynamicLookup = X()
x.f!()
Swift SVN r8037
Tuple exploding happens during RValue construction, so changed the constructor and addElement() method to take the location parameter. The imploding happens on RValue::forwardAsSingleValue and RValue::getAsSingleValue(). Make sure the right SIL locations are passed to all of these
Also, added some missing locations in pattern matching code.
Swift SVN r7916
Note that this does not actually require the function containing the [auto_closure] parameter to be marked [transparent]. However, if the function is not marked [transparent], then the [transparent] flag on the application of the [auto_closure] will have no effect anyway because the callee of the function will not be visible, so there's no harm in putting the flag on without checking.
Swift SVN r7904
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
This is was a very mechanical patch where I basically first renamed SILNodes.def
and then just kept fixing things until everything compiled, so even though it is
large patch I feel ok(ish) with committing it.
If anyone has any concerns/etc, please email me and I will revert in 1 second.
Swift SVN r7604
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
