These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
Once we move to a copy-on-write implementation of existential value buffers we
can no longer consume or destroy values of an opened existential unless the
buffer is uniquely owned.
Therefore we need to track the allowed operation on opened values.
Add qualifiers "mutable_access" and "immutable_access" to open_existential_addr
instructions to indicate the allowed access to the opened value.
Once we move to a copy-on-write implementation, an "open_existential_addr
mutable_access" instruction will ensure unique ownership of the value buffer.
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
Rememebering that the verifier ensures that any edge that propagates ownership
along a cond_br can not be critical, we do this by sinking the use by the
cond_br into the destination blocks.
rdar://29791263
This is a small corner case that simplifies the ownership verifier.
Specifically, today the ownership verifier has problems with the control
dependent nature of a cond_br's condition operand on the arguments of the
cond_br. By eliminating the possibility of values with ownership being
propagated along critical edges, the verifier can associate the arguments of the
cond_br with the destination blocks safely.
*NOTE* I ran a full testing run with sil-verify-all and this check did not
trigger once after SILGen. Thus I think it is safe to say that there is no real
effect of this change today. It is change ensuring that we maintain the current
behavior. As part of teaching the optimizer how to handle ownership, this
property will need to be pushed back there as well.
rdar://29791263
There are a few different use cases here:
1. In Raw SIL, no return folding may not have been run yet implying that a call
to a no-return function /can/ have arbitrary control flow after it (consider
mandatory inlined functions). We need to recognize that the region of code that
is strictly post dominated by the no-return function is "transitively
unreachable" and thus leaking is ok from that point. *Footnote 1*.
2. In Canonical and Raw SIL, we must recognize that unreachables and no-return
functions constitute places where we are allowed to leak.
rdar://29791263
----
*Footnote 1*: The reason why this is done is since we want to emit unreachable
code diagnostics when we run no-return folding. By leaving in the relevant code,
we have preserved all of the SILLocations on that code allowing us to create
really nice diagnostics.
If the initializer is in a different file than the original
type, and the original type contains a stored property that
has both an initializer *and* a declared type, then the
initializer expression will not have been type checked.
So we must look at the type of pattern, which should still
be correct.
Fixes <https://bugs.swift.org/browse/SR-3942> and
<rdar://problem/25705157>.
This reverts commit 1b3d29a163, reversing
changes made to b32424953e.
We're seeing a handful of issues from turning on inlining of generics,
so I'm reverting to unblock the bots.
This reverts commit a380855524, reversing
changes made to 66332140f3.
We're seeing a handful of issues from turning on inlining of generics,
so I'm reverting to unblock the bots.
Instead of a global demangleSymbolAsNode, which returns a reference-counted NodePointer, there is now a Context class which owns the nodes.
So now demangleSymbolAsNode is a member of Context and the returned NodePointer is alive as long as the Context is alive.
This is still a NFC: the new ABI still maps to the old functions.
The purpose of this change is to let lldb adapt to the new API and then we can switch to the new implementation.
This just moves a bunch of queries that used information on SILFunction to
determine this property to just call a helper on SILFunctionType itself.
Centralized logic is good.
rdar://29791263
This allows for an unchecked_enum_data to be either a consumed instruction or a
borrowed instruction. The reason why this makes sense in contrast to other value
projection operations like struct_extract and tuple_extract is that an enum
payload is essentially a tuple. This means that we are extracting the entire
value when we perform a struct_extract. So forwarding is viable from a semantic
perspective since if we destroy the payload, there is nothing left to destroy.
This contrasts with struct_extract and tuple_extract where we may have other
parts of the struct/tuple to destroy.
rdar://29791263
This caused a crasher when running the ownership verifier. I don't have a test
case right now, since it happened several weeks ago.
The bug can not happen again since I eliminated the nullptr default argument.
rdar://29791263
This method maps interface types to archetypes, which in general
requires a module for performing conformance lookups, if mapping
a member type of a generic parameter which has been made concrete.
However, in practice the types we are mapping here are all canonical
with respect to the generic signature, because they came from
GenericSignature::getAllDependentTypes(), so we actually don't need
to do conformance lookups.
This allows some code to be simplified.
SubstitutionList is going to be a more compact representation of
a SubstitutionMap, suitable for inline allocation inside another
object.
For now, it's just a typedef for ArrayRef<Substitution>.
There was only one place where we lowered AST types with a non-zero
uncurry level, in SILGenApply.cpp. Add a new overload of the
getSILFunctionType() method that takes an uncurry level. All the
other methods no longer have to thread it through.
I thought this was modeling a value returned at +0. But in reality, the
instruction is created a guaranteed region by performing the following
instruction sequence:
%1 = copy_value %0 : $GuaranteedValue
(%2, %3) = Builtin "unsafeGuaranteed" (%1)
... *STUFF* ...
Builtin "endUnsafeGuaranteed" (%2) : $Token
destroy_value %3 : $GuaranteedValue
rdar://29791263
I implemented the mapping from SILValue -> ValueOwnershipKind for builtins a
long time ago, but did not implement the stub for what ValueOwnershipKind's can
be accepted by builtins. It is a pretty simple mapping (most things are
trivial).
The only interesting cases are:
1. ErrorInMain, UnexpectedError, WillThrow: These take in an @owned error
parameter, but are just normal uses of the value, not lifetime ending uses.
2. UnsafeGuaranteed. This is a bonafide actual +1 lifetime ending use. It is the
only one in the builtins.
rdar://29791263
