In preparation for moving to llvm's opaque pointer representation
replace getPointerElementType and CreateCall/CreateLoad/Store uses that
dependent on the address operand's pointer element type.
This means an `Address` carries the element type and we use
`FunctionPointer` in more places or read the function type off the
`llvm::Function`.
SIL type lowering erases DynamicSelfType, so we generate
incorrect code when casting to DynamicSelfType. Fixing this
requires a fair amount of plumbing, but most of the
changes are mechanical.
Note that the textual SIL syntax for casts has changed
slightly; the target type is now a formal type without a '$',
not a SIL type.
Also, the unconditional_checked_cast_value and
checked_cast_value_br instructions now take the _source_
formal type as well, just like the *_addr forms they are
intended to replace.
We are already doing this for most of the target-swift-frontend ones. In a
subsequent commit, I am going to remove the redundant ones.
NOTE: On Darwin, I have not enabled it on the %target-swift-frontend mock SDK
commands. I ran into an issue with one of the PrintAsObjC tests that I am still
tracking down. I would rather just get this turned on to prevent further
regressions.
I also updated a few tests that needed some small tweaks to pass
this. Specifically:
1. Some parser tests needed some extra ossa insts to pass the verifier. This
doesn't effect what they actually test.
2. IRGen tests that should never have processed ossa directly. Today, we are
working towards a world where IRGen never processes [ossa] directly. Instead we
lower first. If/when that changes, we should add back in specific [ossa] tests.
3. A singular SILOptimizer definite init test case where the ownership verifier
fails due to a case which DI already flags as illegal (we just crash earlier). I
am going to look into fixing that by putting in errors in the typechecker or in
SILGen (not sure yet). I changed it to use target-swiftc_driver which does not
have ownership verification enabled.
Currently ignored, but this will allow future compilers to pass down source location information for cast
failure runtime errors without backward deployment constraints.
These two declarations are now equivalent:
protocol P : SomeClass { ... }
protocol P where Self : SomeClass { ... }
There's a long, complicated story here:
- Swift 4.2 rejected classes in the inheritance clause of a
protocol, but it accepted the 'where' clause form, even
though it didn't always work and would sometimes crash
- Recently we got the inheritance clause form working, and
added a diagnostic to ban the 'where' clause form, because
we thought it would simplify name lookup to not have to
consider the 'where' clause
- However, we already had to support looking at the 'where'
clause from name lookup anyway, because you could write
extension P where Self : SomeClass { ... }
- It turns out that despite the crashes, protocols with
'Self' constraints were already common enough that it was
worth supporting the existing behavior, instead of banning
it
Fixes <rdar://problem/43028442>.
This is how we originally controlled whether or not we printed out ownership
annotations when we printed SIL. Since then, I have changed (a few months ago I
believe) the ownership model eliminator to know how to eliminate these
annotations from the SIL itself. So this hack can be removed.
As an additional benefit, this will let me rename -enable-sil-ownership to
-enable-sil-ownership-verifier. This will I hope eliminate confusion around this
option in the short term while I am preparing to work on semantic sil again.
rdar://42509812
Reimplement protocol descriptors for Swift protocols as a kind of
context descriptor, dropping the Objective-C protocol compatibility
layout. The new protocol descriptors have several advantages over the
current implementation:
* They drop all of the unused fields required for layout-compatibility
with Objective-C protocols.
* They encode the full requirement signature of the protocol. This
maintains more information about the protocol itself, including
(e.g.) correctly encoding superclass requirements.
* They fit within the general scheme of context descriptors, rather than
being their own thing, which allows us to share more code with
nominal type descriptors.
* They only use relative pointers, so they’re smaller and can be placed
in read-only memory
Implements rdar://problem/38815359.
