SILFunctionType of the method instead of its formal type.
Gives more accurate information to the @encoding, makes
foreign error conventions work implicitly, and allows
IRGen's Swift-to-Clang to avoid duplicating arbitrary
amounts of the bridging logic from SILGen.
Some finagling was required in order to avoid calling
getConstantFunctionType from within other kinds of
lowering, which might have re-entered a generic context.
Also required fixing a bug with the type lowering of
optional DynamicSelfTypes where we would end up with
a substituted type in the lowered type.
Also, for some reason, our @encoding for -dealloc
methods was pretending that there was a formal parameter.
There didn't seem to be any justification for this,
and it's not like Clang does that. Fixed.
Swift SVN r29266
preserve the original method name.
This heuristic is based on the Objective-C selector and therefore
doesn't really handle factory methods that would conflict with
initializers, but we can hope that those simply don't come up in
the wild.
It's not clear that this is the best thing to do --- it tends to
promote the non-throwing API over what's probably a newer, throwing
API --- but it's significantly easier, and it unblocks code without
creating deployment problems.
Swift SVN r28066
results when finding bridged types, rather than reinventing
(well, pre-inventing) the same thing elsewhere.
Doing this apparently forces AbstractionPattern to deal
with ObjC protocol methods for the first time, which are
generic and therefore require even the Clang-based
abstraction patterns to propagate generic signatures.
Use this infrastructure to allow foreign error conventions
to suppress the wrapping of nonnull bridged collection results
in a level of optionality. We can't treat nil results as
an empty collection while simultaneously treating them as
an error signal.
Swift SVN r28022
We still don't actually handle these correctly, but at least
we have sensible information for them now.
Also, remember that we're working with canonical generic
signatures in more places.
Swift SVN r27388
This is necessary for correctly dealing with non-standard
ownership conventions in secondary positions, and it should
also help with non-injective type imports (like BOOL/_Bool).
But right now we aren't doing much with it.
Swift SVN r26954
To do this with complete accuracy requires mapping the dependent types into a context, but isOpaque is currently only used as a sanity check in assertions, and a tuple being matched to a class-constrained archetype is an unlikely enough occurrence that it's probably OK to accept this inaccuracy instead of trying to push generic contexts all the way down into isOpaque's clients.
Swift SVN r11824
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
