The default template parameter assumes that the iterator type is a pointer,
which it is not for SILInstructionResultArray. Just specify the return
type directly instead of using the default.
I also used this as an opportunity to make SILInstructionResultArray::iterator
not inherit from std::iterator given that std::iterator is now deprecated.
Just slicing code off a larger commit.
rdar://31521023
The goal is to make it more composable to add trailing-objects fields in
a subclass.
While I was doing this, I noticed that the apply instructions provided
redundant getNumArguments() and getNumCallArguments() accessors, so I
went ahead and unified them.
I am doing this for a few different reasons:
1. The code for manipulating successors was partially in TermInst (with
SILBasicBlock delegating to TermInst) and partly in SILBasicBlock itself. It
makes more sense to just be consistent and move all said functionality into
TermInst and just always delegate to SILBasicBlock.
2. I am preparing an API around gathering all critical edges. All of the
critical edge breaking APIs to take a TermInst. I wanted to use some of the
successor APIs, only to discover that we were not delegating to TermInst. By
moving said functionality onto TermInst itself and delegating, we have it in
both places.
rdar://31521023
...as detected by initializing an individual field without having
initialized the whole object (via `self = value`).
This only applies in pre-Swift-5 mode because the next commit will
treat all cross-module struct initializers as delegating in Swift 5.
lldb is not aware of using directives currently so if you try to invoke the
given methods you will get an ambiguous name lookup error from lldb. These are
important methods for debugging in lldb, so instead in this commit we just
redeclare them and delegate to the appropriate parent class.
I am doing this to ensure that parts of the optimizer that have not yet been
updated for such operations do not see said instructions. This will ensure no
surprise perf regressions from this work.
rdar://31521023
The reason that I am doing this is in preparation for adding support for
MultipleValueInstruction. This enables us to avoid type issues and also ensures
that we do not increase the size of SingleValueInstruction while we are doing
it.
The MultipleValueInstruction commit will come soon.
rdar://31521023
This will allow us to remove dynamic_method, emitting objc_method
in its place. It will also allow objc_method to be used for
Objective-C protocol method calls, with witness_method used
for Swift native protocol method calls only.
This replaces the '[volatile]' flag. Now, class_method and
super_method are only used for vtable dispatch.
The witness_method instruction is still overloaded for use
with both ObjC protocol requirements and Swift protocol
requirements; the next step is to make it only mean the
latter, also using objc_method for ObjC protocol calls.
