This is used when materializing an LValue to share state between
the read and write phases of the access, replacing the 'temporary'
and 'extraInfo' parameters that were previously being passed around.
It adds two new fields, origSelfType and genericSig, which will be
used in an upcoming patch to actually apply the callback with the
current generic signature.
This will finally allow us to make use of materializeForSet
implementations in protocol extensions, which is a prerequisite
for enabling resilient default implementations of property and
subscript requirements.
We don't really need to mangle the AST type of the callback, besides
it doesn't have an AST type at all, because it is polymorphic.
Also, mangle the closure as if it were parented by the requirement
and not the witness, for consistency with witness thunks.
The mangling should still be unique since it includes the conformance.
NFC other than updating tests for new mangling.
I'm planning on changing materializeForSet to return the callback
as a RawPointer, and casting it to the correct polymorphic SILFunctionType
type at the call site.
This will allow us to call it with the right generic signature, which
is currently not possible since it is returned as an optional of an
AST function type, and optionals of SIL function types are not permitted.
Previously we would emit two types of MaterializeForSet implementations
in SILGen:
- materializeForSet for a concrete storage declaration
- materializeForSet witness thunk in a conformance
This refactoring decouples the code from taking a conformance, which is
needed for two new types of materializeForSet that we need:
- materializeForSet witness thunk in a default witness table -- this is
necessary in order to be able to resiliently add storage requirements
with default implementations to protocols
- materializeForSet vtable thunk -- this is necessary to fix a missing
re-abstraction case with overriding storage in a subclass
This patch brings us closer to implementing these two. For default
implementations, we still have an issue in that the materializeForSet
has a different "generic signature abstraction pattern" in concrete
and default witnesses, so default and concrete witnesses for
materializeForSet are currently ABI-incompatible because the type
metadata for the storage is passed differently to the callback.
When we emit calls to getters and setters with emitApply(), the call
emission code ends up re-abstracting the result of a getter or the
parameter to a setter.
As a result, getOrigFormalType() was incorrect for logical path
components. This was worked around by only adding an OrigToSubst
path component to an lvalue if the last path component was physical.
This caused a problem in the following case:
1) There was an abstraction difference between the storage of the
protocol requirement and the storage of the protocol witness
2) There was an abstraction difference between the storage of the
protocol witness, and the fully-substituted type of the witness
An example is when the witness is in a protocol extension, and uses
'Self' or some other associated type which is concrete and loadable
in the conformance.
Fix this properly by splitting up getStorageTypeData() into two
functions, one used when adding physical path components and another
one used for logical.
As a result, we can now give the correct abstraction pattern to
logical path components.
This patch wires up SILGenDefaultWitnessTable to actually emit
thunks and add them to the SILDefaultWitnessTable, using the
new logic in Sema for inferring default implementations.
Note that default witness thunks are mangled like the protocol
requirement itself.
After emitting thunks, SILGen populates a SILDefaultWitnessTable
for consumption by IRGen.
Default witness thunks for properties and subscripts are not
supported yet; a bit more refactoring in MaterializeForSet
emission is necessary.
In this case we do not have a conformance, and the default witness
thunk uses the same signature and context archetypes as the protocol
requirement.
There might still be an abstraction change between the requirement
and witness, though.
Tests are in the next patch that actually adds the ability to emit
these thunks. This is just a refactoring.
Previously SILDefaultWitnessTables only included "resilient" default
implementations, which are currently defined as those that appear at the
end of a protocol, after any requirements without defaults.
However, this was too inflexible. Instead, include all entries in the
SILDefaultWitnessTable, with invalid entries standing in for requirements
without defaults.
Previously, the minimum witness table size was a separate parameter, also
appearing in SIL syntax; now it can be calculated by looking at the entries
themselves. The getResilientDefaultEntries() method of SILDefaultWitnessTable
returns the same result as getEntries() did previously.
This ireapplies commit 255c52de9f.
Original commit message:
Serialize debug scope and location info in the SIL assembler language.
At the moment it is only possible to test the effects that SIL
optimization passes have on debug information by observing the
effects of a full .swift -> LLVM IR compilation. This change enable us
to write targeted testcases for single SIL optimization passes.
The new syntax is as follows:
sil-scope-ref ::= 'scope' [0-9]+
sil-scope ::= 'sil_scope' [0-9]+ '{'
sil-loc
'parent' scope-parent
('inlined_at' sil-scope-ref )?
'}'
scope-parent ::= sil-function-name ':' sil-type
scope-parent ::= sil-scope-ref
sil-loc ::= 'loc' string-literal ':' [0-9]+ ':' [0-9]+
Each instruction may have a debug location and a SIL scope reference
at the end. Debug locations consist of a filename, a line number, and
a column number. If the debug location is omitted, it defaults to the
location in the SIL source file. SIL scopes describe the position
inside the lexical scope structure that the Swift expression a SIL
instruction was generated from had originally. SIL scopes also hold
inlining information.
<rdar://problem/22706994>
At the moment it is only possible to test the effects that SIL
optimization passes have on debug information by observing the
effects of a full .swift -> LLVM IR compilation. This change enable us
to write targeted testcases for single SIL optimization passes.
The new syntax is as follows:
sil-scope-ref ::= 'scope' [0-9]+
sil-scope ::= 'sil_scope' [0-9]+ '{'
sil-loc
'parent' scope-parent
('inlined_at' sil-scope-ref )?
'}'
scope-parent ::= sil-function-name ':' sil-type
scope-parent ::= sil-scope-ref
sil-loc ::= 'loc' string-literal ':' [0-9]+ ':' [0-9]+
Each instruction may have a debug location and a SIL scope reference
at the end. Debug locations consist of a filename, a line number, and
a column number. If the debug location is omitted, it defaults to the
location in the SIL source file. SIL scopes describe the position
inside the lexical scope structure that the Swift expression a SIL
instruction was generated from had originally. SIL scopes also hold
inlining information.
<rdar://problem/22706994>
In IRGen, @autoreleased return values are always converted to +1 by
calling objc_retainAutoreleasedReturnValue(), so a partial application
thunk cannot have a result with @autoreleased convention. Just turn
it into @owned instead, since that's what it is, using similar logic
as the @unowned_inner_pointer => @unowned case.
Fixes <rdar://problem/24805609>.
Parser now accepts multiple patterns in switch cases that contain variables.
Every pattern must contain the same variable names, but can be in arbitrary
positions. New error for variable that doesn't exist in all patterns.
Sema now checks cases with multiple patterns that each occurence of a variable
name is bound to the same type. New error for unexpected types.
SILGen now shares basic blocks for switch cases that contain multiple
patterns. That BB takes incoming arguments from each applicable pattern match
emission with the specific var decls for the pattern that matched.
Added tests for all three of these, and some simple IDE completion
sanity tests.
iterator/pointer comparison issue that yields undefined behavior. This updates
Swift for the landing of this change in swift-llvm/stable.
I am going to cherry-pick the given change into swift-llvm/stable since there is no
reason not to do this now and it will prevent more of these conversions from
creeping into the code base.
We really want to avoid as much undefined behavior as we possibly can.
Fix some interface type/context type confusion in the AST synthesis from the previous patch, add a unique private mangling for behavior protocol conformances, and set up SILGen to emit the conformances when property declarations with behaviors are visited. Disable synthesis of the struct memberwise initializer if any instance properties use behaviors; codegen will need to be redesigned here.
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.
Update our usage of llvm's coverage API and fix the way we lower
instrprof_increment intrinsics.
This keeps us up-to-date with llvm/stable and makes instrumented IR
easier to read.
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.
We need to increment the counter for repeat-while bodies immediately
after the loop body is entered. This allows us to handle "break" and
"return" statements in the repeat-while body correctly.
This also fixes an off-by-one error where we only updated the
repeat-while body counter when the loop condition evaluates to true.
In 2a34b7c6, we introduced an incorrect test case for return statements
within repeat-while loops. Consider this situation:
repeat { // Region 1
return
} while C1 // Should be "zero", not "Region 1"
The fix requires maintaining a stack of active repeat-while loops. This
is an accepted idiom (c.f the clang CoverageMapping implementation). To
see why a stack is needed, consider:
repeat { // Region 1
repeat { // Region 2
if (C1) { // Region 3
return
}
} while C2 // Should be "Region 2 - *Region 3*", not "Region 2"
} while C3 // Should be "Region 1 - *Region 3*", not "Region 1"
rdar://problem/24572268
We do not correctly update the counter expression for conditionals in
repeat-while blocks in the following two situations:
Situation 1:
repeat { // Region 1
if (C1) { // Region 2
break
}
} while C2 // Should be "Region 1 - Region 2", not "Region 1"
Situation 2:
repeat { // Region 1
if (C1) { // Region 2
continue
}
} while C2 // Should be "Region 1", not "Region 1 + Region 2"
Fix both of these problems and add thorough regression tests.
Closes Swift PR #1244, rdar://problem/24572268
_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).
We can re-abstract directly from the requirement signature to the
witness signature, now that re-abstraction thunks take an
abstraction pattern for both the input and the output.
To do this, we need to know the SILFunctionType of the witness
before we begin re-abstraction. Refactor getWitnessFunctionRef()
a bit to make this work.
This will be used to help IRGen record protocol requirements
with resilient default implementations in protocol metadata.
To enable testing before all the Sema support is in place, this
patch adds SIL parser, printer and verifier support for default
witness tables.
For now, SILGen emits empty default witness tables for protocol
declarations in resilient modules, and IRGen ignores them when
emitting protocol metadata.
