We generally don't want to override unavailable methods. We already
filter out unavailable decls when completing values, but that's in a
separate visible decl consumer.
rdar://problem/25058233
With the tests updated to account for not having the correct behaviour
for brace-stmt items from after the code-completion point. That part
turns out to be harder to fix.
This reverts commit a5325e6281.
explosion schema rather than from the debug type information and retire
a bunch of heuristics that are no longer necessary.
To enable this, this commit also includes a bugfix to debug info for
opaque data structures with the correct size and alignment information.
<rdar://problem/21470869+22707597>
In many places, we're interested in whether a type with archetypes *might be* a superclass of another type with the right bindings, particularly in the optimizer. Provide a separate Type::isBindableToSuperclassOf method that performs this check. Use it in the devirtualizer to fix rdar://problem/24993618. Using it might unblock other places where the optimizer is conservative, but we can fix those separately.
This change includes an option on how IsLive is defined/computed. the ProjectionTree
can now choose to ignore epilogue releases and mark a node as dead if its only non-debug
user is epilogue release.
It can also mark a node as alive even its only user is epilogue release as before.
Imagine a case where one passes in an array and not access its owner
besides to release it. In such a case, we *do* want to be able to eliminate
that argument even though there is a release in the function epilogue.
This will help to get rid of the retain and release pair at the callsite. i.e.
the guaranteed paramter is elimininated.
rdar://21114206
This is safe because the closure is not allowed to capture the array according
to the documentation of 'withUnsafeMutableBuffer' and the current implementation
makes sure that any such capture would observe an empty array by swapping self
with an empty array.
Users will get "almost guaranteed" stack promotion for small arrays by writing
something like:
func testStackAllocation(p: Proto) {
var a = [p, p, p]
a.withUnsafeMutableBufferPointer {
let array = $0
work(array)
}
}
It is "almost guaranteed" because we need to statically be able to tell the size
required for the array (no unspecialized generics) and the total buffer size
must not exceed 1K.
Teach swift_deallocPartialClassInstance how to deal with classes that
have pure Objective-C classes in their hierarchy. In such cases, we
need to make sure a few things happen:
1) We deallocate via objc_release rather than
swift_deallocClassInstance.
2) We only attempt to find an execute ivar destroyers for
Swift-defined classes in the hierarchy
3) When we hit the most-derived pure Objective-C class, make sure that we
only execute the dealloc of that class and not any of the subclasses
(which would end up trying to destroy ivars again).
Fixes rdar://problem/25023544.
If the copy_addr cannot release the destination then it behaves just like a load
followed by a store.
This allows us to stack promote protocol typed array literals.
protocol Proto { func at() -> Int }
func testStackAllocation(p: Proto) {
var a = [p, p, p]
for e in a {
print(e.at())
}
}
The effect of this tiny change is that local variables will be described
by llvm.dbg.values, which will get lowered into an accurate location list
instead of a stack slot that is valid for the entire scope of the variable.
This means the debugger can now accurately track the liveness of variables
knowing exactly when they are initialized and when there values go away.
Function arguments are still kept in stack slots because (1) they are
already initialized at the function entry and (2) LLDB really needs self
to be available at all times for the expression evaluator.
This was made possible by recent advancements in LLVM such as the live
debug variables pass and various related bugfixes.
<rdar://problem/15746520>
Except for nil literals, we don't want to look at the optional itself,
since the typechecker would implicitly look to the underlying type.
rdar://problem/24707210
We were creating new uses of an argument just prior to erasing it from
the block argument list.
We need to replace references to that value in the side structure we
generate with references to the new value that we're replacing it with.
Fixes SR-884 / rdar://problem/25008398.
correct location for generic parameters that cannot be inferred. The cases that
I thought were incorrectly rejected on first glance were actually correct.
We don't want to prioritize the type name for protocols, since they
can't be used (generally) to construct an instance of the type. Ideally
we would prioritize types that conform to the protocol.
For rdar://problem/24873625
for i in <here> // should *not* show 'i'
for i in ... where <here> // should show 'i'
for i in ... { <here> // should show 'i'
Part of rdar://problem/24873625
Improve when to bail while finding the final releases.
The ConsumedArgToEpilogueReleaseMatcher finds the final releases
in the following way.
1. If an instruction, which is not releaseinst nor releasevalue, that
could decrement reference count is found. bail out. This may well be the
real epilogue release.
2. If a release is found and the release that can not be mapped to any
@owned argument. bail as this release may well be the final release of
an @owned argument, but somehow rc-identity fails to prove that.
3. A release that is mapped to an argument, but we already has a release
that (partially or completely) overlaps with this release. This release
for sure is not the final release.
Once an unsubstituted typeref for a field is built, we substitute
`GenericTypeParameterTypeRef`s with concrete ones built from the generic
arguments of concrete bound generic metadata.
During that process, if we run into a `DependentMemberTypeRef` (e.g.
something of type T.Index), we substitute the base (T) using the current
list of substitutions, and then resolve what `Index` is for the base
using the associated type metadata in the 'assocty' data section.
Similiar to the change to field reflection metadata, don't use the
interface for the key of associated type lookup, because the nominal
type descriptors don't include generics in their mangled name strings.
Nominal type descriptors use declared types for their mangled names,
so we need to use them when scanning the fieldmd section for a
matching record. This is fine because the descriptor can tell us
about the type's generics. Individual field records continue to use
the interface type.
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.
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.
* E101: indentation contains mixed spaces and tabs
* E111: indentation is not a multiple of four
* E128: continuation line under-indented for visual indent
* E302: expected 2 blank lines, found 1
* W191: indentation contains tabs
