This patch augments the infinite recursion checker to not warn if a
branch terminates, but still warns if a branch calls into something with
`@_semantics("arc.programtermination_point")`. This way, calling `fatalError`
doesn't disqualify you for the diagnostic, but calling `exit` does.
This also removes the warning workaround in the standard library, and
annotates the internal _assertionFailure functions as
`programtermination_point`s, so they get this treatment too.
With removing of pinning and with addressors, the pattern matching did not work anymore.
The good thing is that the SIL is now much simpler and we can handle the 2D case without pattern matching at all.
This removes a lot of code from COWArrayOpts.
rdar://problem/43863081
NOTE: This is not the final form of how operand ownership restraints will be
represented. This patch is instead an incremental change that extracts out this
functionality from the ownership verifier as a pure refactor.
rdar://44667493
The reason why I am doing this is now that once we have the
OperandOwnershipKindMap I can write this optimization in a more robust,
aggressive manner. My hope is that I can eliminate all copy_value of guaranteed
parameters all of whose uses could accept a guaranteed parameter. This is given
to me by the OperandOwnershipKindMap.
Additionally, I found that the way the analysis was using the OwnershipVerifier
was not sound on non-ownership verified SIL. Rather than fix it, I just turned
it off for that case.
rdar://44667493
There’s a few places where size_t is used for a field/parameter when constructing an array for types. Unfortunately, the Bitfields that were backing the inputs to these at some point after 4.1 grew past 32 bits and are now backed by a uint64_t. Even though the slice of the bitfield is small enough for 32-bit, clang sees these slices as 64-bit and complains if there isn’t a cast involved.
The constraint solver support for the Swift 3 function type behavior
has been removed, so it's no longer possible to pun the same value as
both a function taking multiple parameters and a function taking a
single tuple argument.
This means the entire parameter list is no longer a target for
substitution as a single value, so the most general form of a function
value passes each parameter indirectly instead of passing a single
tuple parameter indirectly.
I believe that these were in SILInstruction for historic reasons. This is a
separate API on top of SILInstruction so it makes sense to pull it out into its
own header.
No functionality change. Unfortunately we still need the flag in
SILModule itself because of the ability to create an empty SILModule
and parse SIL into it incrementally, which can happen before there's
a FileUnit to use as the associated DeclContext instead of a
CompilerInstance's main module.
This was only used by the integrated REPL, and is now a dead option.
The "StartElem" option for performTypeChecking is still used for
reading SIL files, which have AST and SIL blocks alternate.
When compiling with MSVC on Windows, this error among other similar
conflicts with AnyValue occur:
Defined the overloads so it selects the correct one.
This convenience API enables one to iterate over the array of arguments of each
successor of the terminator.
To implement this I needed to implement SILBasicBlock::getPHIArguments(), so I
also implemented SILBasicBlock::getFunctionArguments().
rdar://44667493
I hit this problem while splitting classifying operand ownership from the
ownership verifier itself. There is no reason to allow for this implicit
conversion. Just makes updating code more error prone.
rdar://44667493
Currently there is a bug in the closure specializer that was caused by
BeginApply not being handled correctly. Rather than just fixing that and leaving
the badness, I am instead in this commit introducing enums for apply sites so we
can avoid this problem in the future by using exhaustive switches to guide
developers adding new types of apply sites in the future.
rdar://44612356
SILWitnessTable::Entry already contains a superset of what was supported
by SILDefaultWitnessTable::Entry, the latter of which only had “no entry”
and “method” states. Make SILDefaultWitnessTable::Entry an alias for
SILWitnessTable::Entry, and unify all of the parsing/printing/
(de)serialization logic.
Emit associated type witnesses into resilient conformance tables, so they
can be re-ordered within the protocol without breaking clients. This will
(eventually) permit adding new, defaulted associated types to protocols
resiliently.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
The string-keyed tables don't actually need Identifier keys on the
serialization side -- no reason to persist these in the ASTContext's
string table either.
They should never be dynamically dispatched (unless `required`), so this entry should never be used.
We were accidentally dynamically dispatching to them in convenience-to-convenience `self.init`
delegations; fix that.
When emitting accessor calls for keypaths, make sure that we reference
protocol requirements that introduce witness table entries. Other
protocol requirements don't have the necessary dispatch thunks,
resulting in linker errors.
Fixes rdar://problem/44187969.
A few places around the compiler were checking for this module by its
name. The implementation still checks by name, but at least that only
has to occur in one place.
(Unfortunately I can't eliminate the string constant altogether,
because the implicit import for SwiftOnoneSupport happens by name.)
No functionality change.
I changed all of the places that used end_borrow_argument to use end_borrow.
NOTE: I discovered in the process of this patch that we are not verifying
guaranteed block arguments completely. I disabled the tests here that show this
bad behavior and am going to re-enable them with more tests in a separate PR.
This has not been a problem since SILGen does not emit any such arguments as
guaranteed today. But once I do the SILGenPattern work this will change.
rdar://33440767
