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
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
As with the monadic '?', we treat any left-bound '!' as a postfix
operator. Currently, it extracts the value of its optional
subexpression, failing at run-time if the optional is empty.
Swift SVN r8948
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
SILGen the index of a dynamic subscript in its own context; it's
result doesn't go into the current initialization. As an added bonus,
always evaluate the index, so that side effects occur predictable
regardless of whether the function is available.
Swift SVN r8718
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
There are two major restrictions on this at the moment:
1) It only applies to [objc] properties/subscripts (where we go
through Objective-C dispatch). It still does static dispatch for
non-[objc] properties/subscripts in classes.
2) The Clang importer doesn't mark imported Objective-C properties
and subscript operators as [objc], so this is useless in practice.
Swift SVN r8691
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
This mirrors the behavior of project_existential and simplifies some special cases in SILGen. It unfortunately makes dynamic_lookup sequences a bit noisier because of the need to explicitly cast the projection from DynamicLookup.Self to Builtin.ObjCPointer, but I think this modeling is more solid and will fit better with my planned redesign of archetype_method/protocol_method.
Swift SVN r8572
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
