Derives the address of a member from the address of a fragile value type. SIL extract : SIL element_addr :: LLVM extractvalue : LLVM getelementptr. Also add SILVerifier checks for ExtractInst and ElementAddrInst that they deal only in values and addresses, respectively.
Swift SVN r3391
We'll need some additional instructions to describe initialization of existentials and existential method calls: `alloc_existential` to initialize an existential's witness and substitution table(s) and provide access to its storage, and `existential_method_ref`/`project_existential` to obtain a method handle from an existential and the opaque reference to hand down to the method.
Swift SVN r3348
IBOutlet and IBAction are used by Xcode to support XIB editing, but moreover
there is not an /inherent/ requirement that they imply [objc]. For [IBAction],
it seems unlikely that this will ever change, but [IBOutlet] already tries
several different ways to make its connection, and moreover with outlets for
which we can see the declaration, *the type of the object is known,*, and IB
could in theory know to use the Swift entry points.
IBOutlet and IBAction are currently recognized; my plan is to make them both
alias [objc] internally for now.
Swift SVN r3317
After discussion with John, we decided that we need to be able to deallocate a partially-initialized box during initializer execution, in case an initializer expression ends up unwinding before a value is fully initialized. When optimizing reference type allocations, it would also better to expose the destructor call and release operations directly instead of hiding them inside an instruction.
Swift SVN r3291
Value types should not require destruction beyond `release`-ing their reference type members. `release` for reference types and `destroy_addr` for address-only types should cover all cleanup needs.
Swift SVN r3264
- Tighten up terminology, for instance, define what a "box" actually is
- Describe how operands can have zero, one, or many values
- Describe that only %operands are valid operands and loading constants, ints, and other literals requires distinct insns
- Make releasing a reftype and destroying a value distinct
- Describe how stack allocation of boxes and reftypes work
- Name address-only type operations `destroy_addr` and `copy_addr` to avoid confusion with rvalue operations
- Describe the full set of aggregate manipulation functions
- Clean up instruction notation to avoid ambiguities
- Throw in notes about things we need to design at some point
Swift SVN r3211
non-trivial representation.
This is because subtyping extends infinitely meta-wards
in the metatype hierarchy: the one thing you can do
with a metatype of a metatype is pull the instance
metatype out, but that instance type is still a subtype
of the instance type of the metatype of the base metatype,
so... just trust me on this.
Swift SVN r3178
rdar://12315571
Allow a function to be defined with this syntax:
func doThing(a:Thing) withItem(b:Item) -> Result { ... }
This allows the keyword names in the function type (in this case
`(_:Thing, withItem:Item) -> Result`) to differ from the names bound in the
function body (in this case `(a:Thing, b:Item) -> Result`, which allows
for Cocoa-style `verbingNoun` keyword idioms to be used without requiring
those keywords to also be used as awkward variable names. In addition
to modifying the parser, this patch extends the FuncExpr type by replacing
the former `getParamPatterns` accessor with separate `getArgParamPatterns`
and `getBodyParamPatterns`, which retrieve the argument name patterns and
body parameter binding patterns respectively.
Swift SVN r3098
Most notably, every Swift object will be id-compatible and have an isa.
Swift classes that do not inherit from an Objective-C class will be marked
unavailable in an Objective-C source file, but their instances can be
referred to by protocol ('id <NSApplicationDelegate>') or by plain 'id'.
I've updated some of the "Use Cases" with some "guidelines" that would
eventually make their way into, say, DevPubs articles (a long way down
the line).
Swift SVN r3092
The new section is supposed to discuss the different models for various
pieces of infrastructure (messaging, methods, classes, subclassing, and
overriding) -- basically, how much of Swift is exposed to Objective-C.
I think the big issue right now is actually what I've labeled the
Messaging Model: whether arbitrary Swift-objects are id-compatible. That
basically has repercussions everywhere else.
This doc is kind of a mess right now, I know.
Swift SVN r3072
Introduce a '.metatype' form in the syntax and do some basic
type-checking that I probably haven't done right. Change
IR-generation for that and GetMetatypeExpr to use code that
actually honors the dynamic type of an expression.
Swift SVN r3053
the metadata objects for classes. This is currently only
done for methods defined in the main class body, and it's
(naturally) totally fragile, and it's screwed up in a
couple known ways w.r.t. generic classes: there's no
thunking when the overrider differs by abstraction from
the overridden method, and methods on classes currently
expect to get all the type arguments passed directly
and thus will disagree in signature from members of
non-generic classes. Also, of course, we're not using
any of this in the call infrastructure. But it's progress.
Swift SVN r2901
This isn't quite the design I mentioned on Tuesday; I keep waffling,
but right now I think ?x is a better match-pattern binder than
var x. Compare:
case .cons(?head, ?tail):
case .cons(var head, var tail):
Swift SVN r2830
