Similarly to how we've always handled parameter types, we
now recursively expand tuples in result types and separately
determine a result convention for each result.
The most important code-generation change here is that
indirect results are now returned separately from each
other and from any direct results. It is generally far
better, when receiving an indirect result, to receive it
as an independent result; the caller is much more likely
to be able to directly receive the result in the address
they want to initialize, rather than having to receive it
in temporary memory and then copy parts of it into the
target.
The most important conceptual change here that clients and
producers of SIL must be aware of is the new distinction
between a SILFunctionType's *parameters* and its *argument
list*. The former is just the formal parameters, derived
purely from the parameter types of the original function;
indirect results are no longer in this list. The latter
includes the indirect result arguments; as always, all
the indirect results strictly precede the parameters.
Apply instructions and entry block arguments follow the
argument list, not the parameter list.
A relatively minor change is that there can now be multiple
direct results, each with its own result convention.
This is a minor change because I've chosen to leave
return instructions as taking a single operand and
apply instructions as producing a single result; when
the type describes multiple results, they are implicitly
bound up in a tuple. It might make sense to split these
up and allow e.g. return instructions to take a list
of operands; however, it's not clear what to do on the
caller side, and this would be a major change that can
be separated out from this already over-large patch.
Unsurprisingly, the most invasive changes here are in
SILGen; this requires substantial reworking of both call
emission and reabstraction. It also proved important
to switch several SILGen operations over to work with
RValue instead of ManagedValue, since otherwise they
would be forced to spuriously "implode" buffers.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
_BridgedNSError conformances can affect the runtime behavior of
dynamic casts (e.g. 'is'). Unfortunately, the conformance is not
always emitted, in an effort to save space when not used. This change
forces the conformance witness tables to be emitted when we can detect
a dynamic cast to an _BridgedNSError conforming enum.
Test cases included, as well as a note about a potentially erroneous
path that is not currently handled: when the dynamic cast occurs in a
generic function to a generic type (and thus we are unsure which
conformances we need to pull in).
As part of SE-0022, introduce an 'objc_selector' encoding for string
literals that places the UTF-8 string literal into the appropriate
segment for uniquing of Objective-C selector names.
weak copies for capture list variables. Other wise two variables with
identical names will end up in the same scope.
This fixes a crash in the compiler.
rdar://problem/24150188
SR-526
This eliminates some minor overheads, but mostly it eliminates
a lot of conceptual complexity due to the overhead basically
appearing outside of its context.
The main idea here is that we really, really want to be
able to recover the protocol requirement of a conformance
reference even if it's abstract due to the conforming type
being abstract (e.g. an archetype). I've made the conversion
from ProtocolConformance* explicit to discourage casual
contamination of the Ref with a null value.
As part of this change, always make conformance arrays in
Substitutions fully parallel to the requirements, as opposed
to occasionally being empty when the conformances are abstract.
As another part of this, I've tried to proactively fix
prospective bugs with partially-concrete conformances, which I
believe can happen with concretely-bound archetypes.
In addition to just giving us stronger invariants, this is
progress towards the removal of the archetype from Substitution.
Having a separate address and container value returned from alloc_stack is not really needed in SIL.
Even if they differ we have both addresses available during IRGen, because a dealloc_stack is always dominated by the corresponding alloc_stack in the same function.
Although this commit quite large, most changes are trivial. The largest non-trivial change is in IRGenSIL.
This commit is a NFC regarding the generated code. Even the generated SIL is the same (except removed #0, #1 and @local_storage).
mode (take 2)
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
When generating constraints for an iterated sequence of type T, emit
T convertible to $T1
$T1 conforms to SequenceType
instead of
T convertible to SequenceType
This ensures that an untyped placeholder in for-each sequence position
doesn't get inferred to have type SequenceType. (The conversion is still
necessary because the sequence may have IUO type.) The new constraint
system precipitates changes in CSSimplify and CSDiag, and ends up fixing
18741539 along the way.
(NOTE: There is a small regression in diagnosis of issues like the
following:
class C {}
class D: C {}
func f(a: [C]!) { for _: D in a {} }
It complains that [C]! doesn't conform to SequenceType when it should be
complaining that C is not convertible to D.)
<rdar://problem/21167372>
(Originally Swift SVN r31481)
This reverts commit e0b4d55545.
Revert "Include crashing test case"
This reverts commit e5dd189aaf.
Revert "Compare rvalue types in assertion"
This reverts commit 1952739f9d.
This series of commits still was leading to a crash in IRGen.
There is an incorrect ref_to_unmanaged further up in the function
with the wrong input type, so something is weird with preparing
the AutoreleasingUnsafeMutablePointer.
https://bugs.swift.org/browse/SR-87
Because it is possible for the lowering process to change the flags,
this comparison check could trip when the types were, in fact equal,
but SIL lowering had optimized storage for the lowered type.
In the test case given, the SIL type had flags for Object storage while
the lowering type had flags for LocalStorage
Take apart exploded one-element tuples and be more careful with
passing around tuple abstraction patterns.
Also, now we can remove the inputSubstType parameter from
emitOrigToSubstValue() and emitSubstToOrigValue(), making the
signatures of these functions nice and simple once again.
Fixes <rdar://problem/19506347> and <rdar://problem/22502450>.
Previously, SILGen would store a null pointer into the self box upon
encountering a constructor delegation that consumes self. This was a
constant source of bugs. Now, use the new analysis to make this use
DI information instead, emitting an extra bit at runtime if necessary.
Also re-organize the DI tests for initializers, and add CHECK: lines
instead of just asserting we don't crash or diagnose.
Swift SVN r32604
This improves support for promoting to and generating
unchecked_ref_cast so we no longer need unchecked_ref_bit_cast, which
will just go away in the next commit.
Swift SVN r32597
When emitting a RebindSelfInConstructorExpr, the first access of
'self' would take the self value out of the box, since the call
consumes it. This caused a miscompile if we have to load instance
variables to form the call, since then we would try to load from
the box again, dereferencing a null pointer. Now, store the taken
self value and borrow it on subsequent access.
This is a regression from r31141.
Fixes <rdar://problem/22939666>.
Swift SVN r32407
if that's how the opaque l-value is used.
Previously, we emitted the l-value readwrite, causing spurious
writebacks even when just loading the existential.
rdar://22676810
Swift SVN r32293
This removes the partially-correct ABI check in Sema and diagnoses
unsupported conversions in SILGen instead. The new check is more
accurate and correctly diagnoses conversions of DeclRef's to
ABI-incompatible @convention(c) types.
This also fixes two cases where we used to crash but could instead
emit a trivial cast:
- Conversions between ABI-compatible (but not identical)
@convention(c) types
- Conversions of a DeclRef to an ABI-compatible (but not identical)
@convention(c) type
Fixes <rdar://problem/22470105>.
Swift SVN r32163
The CaptureInfo computed by Sema now records if the body of the
function uses any generic parameters from the outer context.
SIL type lowering only adds a generic signature if this is the
case, instead of unconditionally.
This might yield a marginal performance improvement in some cases,
but more interestingly will allow @convention(c) conversions from
generic context.
Swift SVN r32161
We need to be careful to do them in the right order when there's
bridging involved.
This still doesn't completely solve the problem, because of blocks
appearing as function arguments. For example, Sema right now allows
a conversion from @convention(block) (@convention(block) () -> ()) -> ()
to (() -> ()) -> (), but the thunk runs into difficulties because the
bridging thunk only converts the outermost function, and the
re-abstraction thunk hits an assertion on the inner thunk because it
is not able to perform representation changes.
One solution would be to actually unify bridging thunks with
re-abstraction thunks, now that re-abstraction thunks can convert
between AST types.
Progress on <rdar://problem/22470076>.
Swift SVN r31883
Right now, re-abstraction thunks are set up to convert values
as follows, where L is type lowering:
- OrigToSubst: L(origType, substType) -> L(substType)
- SubstToOrig: L(substType) -> L(origType, substType)
This assumes there's no AST-level type conversion, because
when we visit a type in contravariant position, we flip the
direction of the transform but we're still converting *to*
substType -- which will now equal to the type of the input,
not the type of the expected result!
This caused several problems:
- VTable thunk generation had a bunch of special logic to
compute a substOverrideType, and wrap the thunk result
in an optional, duplicating work done in the transform
- Witness thunk generation similarly had to handle the case
of upcasting to a base class to call the witness, and
casting the result of materializeForSet back to the right
type for properties defined on the base.
Now the materializeForSet cast sequence is a bit longer,
we unpack the returned tuple and do a convert_function
on the function, then pack it again -- before we would
unchecked_ref_cast the tuple, which is technically
incorrect since the tuple is not a ref, but IRGen didn't
seem to care...
To handle the conversions correctly, we add a third AST type
parameter to a transform, named inputType. Now, transforms
perform these conversions:
- OrigToSubst: L(origType, inputType) -> L(substType)
- SubstToOrig: L(inputType) -> L(origType, substType)
When we flip the direction of the transform while visiting
types in contravariant position, we also swap substType with
inputType.
Note that this is similar to how bridging thunks work, for
the same reason -- bridging thunks convert between AST types.
This is mostly just a nice cleanup that fixes some obscure
corner cases for now, but this functionality will be used
in a subsequent patch.
Swift SVN r31486
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
<rdar://problem/21167372> transform EditorPlaceholderExpr into fatalError()
Swift SVN r31481
- Generalize::transformFunction() had a couple of little optimizations
for emitting convert_function or thin_to_thick_function instead of
a thunk, if possible -- move this into code shared by all
transforms
- Nuke Generalize since it doesn't do anything special anymore
Swift SVN r31423
We need to be able to introduce and eliminate existentials inside
reabstraction thunks, so make this logic independent of RValue
and Expr emission.
NFC for now.
Swift SVN r31375
