Immutable properties cannot be re-assigned and don't have setters
which means that we cannot use `assign_by_wrapper` instruction to
handle `let` properties, but we can use a direct reference to
`_storage` property instead when immutable property appears as an
assignment destination and let read references go through a getter
still.
Inject a call to $Storage.init(...) which is then used to initialize
type wrapper property `$storage` via `self.$storage = <TypeWrapper>(memberwise: <storage>)`
call at each point where `_storage` becomes fully initialized.
If a stored property would be in a default memberwise initializer
it would be added to the `init` synthesized for a type wrapped type
as well i.e. a `let` property without a default.
Since properties with property wrappers are not supported, default
init synthesis needs to handle them as well by using correct interface
type depending on outer wrapper capabilities and setting correct
default expression.
When generating the completion handler that is passed to ObjC methods
that are being called as async Swift functions, the parameters taken by
the generated completion handler are matched up with the values that are
returned from the async function.
Previously, this process was done by starting at the index into the list
of values expected to be returned, adding 1 if the index matched first
the error index and second the flag index, and finally adding 1 to
account for the fact that the initial parameter to the completion
handler is the block_storage parameter.
That strategy was problematic: it failed to increment indices
appropriately because it did not skip past the block_storage parameter
to begin with; it also failed to increment indices appropriately in
certain cases where the flag and error parameters appeared in an
unexpected order (flag first, then error).
Here, the process is made more robust. Now, the indices which
correspond to the block_storage, flag, and error parameters are filtered
out to begin with. The remaining indices can then be indexed into
using the index into the result tuple (or 0 if the result is not a
tuple).
rdar://80847020
Swift allows a method override to be more visible than the base method.
In practice, this means that since it might be possible for client
code to see the override but not the base method, we have to take
extra care when emitting the override.
Specifically, the override always receives a new vtable entry, and
a vtable thunk is emitted in place of the base method's vtable entry
which re-dispatches via the override's vtable entry.
This allows client code to further override the method without any
knowledge of the base method's vtable entry, which may be inaccessible
to the client.
In order for the above to work, three places in the code perform
co-ordinated checks:
- needsNewVTableEntry() determines whether the override is more
visible than the base, in which case it receives a new vtable
entry
- SILGenModule::emitVTableMethod() performs the same check in order
to emit the re-dispatching vtable thunk in place of the base
method's entry
- in the client, SILVTableVisitor then skips the base method's
vtable entry entirely when emitting the derived class, since no
thunk is to be emitted.
The problem was that the first two used effective access (where
internal declarations become public with -enable-testing), while
the last check used formal access. As a result, it was possible
for the method override vtable entry to never be emitted in the
client.
Consistently using either effective access or formal access would
fix the problem. I fixed the first two to rely on formal access;
the reason is that using effective access makes vtable layout
depend on whether the library was built with -enable-testing or
not, which is undesirable since we do not want -enable-testing to
impact the ABI, even for non-resilient frameworks.
Fixes rdar://problem/74108928.
This commit adds LTO support for handling linker options and LLVM BC
emission. Even for ELF, swift-autolink-extract is unnecessary because
linker options are embeded in LLVM BC content when LTO.
The problem was that HasObjCAncestry was not getting set if
HasResilientAncestry was true, and thus emitFieldOffsetGlobals() was
marking the field offset as const even though the Objective-C
runtime might slide it.
Fixes <rdar://problem/48031465>.
It looks like the only thing that fails is the linkage computation
for the dynamic replacement key of class methods. Even though
methods have hidden linkage to prevent them from being directly
referenced from outside a resilient module, we need to ensure
the dynamic replacement key is visible.
Fixes <rdar://problem/58457716>.
This reverts commit 8247525471. While
correct, it has uncovered several issues in existing code bases that
need to be sorted out before we can land it again.
Fixes rdar://problem/57846390.
getDirectlyInheritedNominalTypeDecls looks for inherited protocols in two places: the actual inheritance clause of a declaration and the trailing where clause. This works fine for normal declarations, but deserialized protocols that have Self constraints have no trailing where clause and appear to have no super-protocol bounds. This means clients can potentially disagree about the structure of the protocol, and any symbols derived from it.
The test case demonstrates this problem directly: We build a hollowed-out SwiftUI preview provider then try to dynamically replace a requirement in a Self-constrained protocol extension. The SwiftUI module sees the where clause, but when we go to deserialize the module in the "Preview" the protocol extension sees the wrong inheritance bounds and mis-mangles the call to Self.view(for:ofType).
The fix is to ask the requirement signature for Self requirements that would normally appear on a trailing where clause.
Resolves rdar://57150777
Today in far more cases we are using mangled strings to look up metadata at
runtime. If we do this for an objc class but for whatever reason we do not have
any other references to the class, the static linker will fail to link in the
relevant framework. The reason why this happens is that autolinking is treated
by the static linker as a hint that a framework may be needed rather than as a
"one must link against the framework". If there aren't any undefined symbols
needed by the app from that framework, the linker just will ignore the hint. Of
course this then causes the class lookup to fail at runtime when we use our
mangled name to try to lookup the class.
I included an Interpreter test as well as IRGen tests to make sure that we do
not regress here in the future.
NOTE: The test modifications here are due to my moving the ObjCClasses framework
out of ./test/Interpreters/Inputs => test/Inputs since I am using it in the
IRGen test along side the interpreter test.
rdar://56136123
Otherwise one TU could only require the type descriptor without metadata
and another TU could require metadata and type descriptor. Whether the
metadata access function is available would then depend on the linking
order of the two TUs.
rdar://56929811
Dynamic replacement can only really get away with replacing opaque return types if a function's
opaque type has never been instantiated in the first place. Meanwhile, repeatedly instantiating
the metadata is too slow for many clients to tolerate. Fixes rdar://problem/53213600.
Don't re-dispatch to the override's vtable slot if the override
is final; there's no vtable slot and this will result in an
infinite loop.
Fixes <rdar://problem/52006394>.
If an override B.f() is more visible than a base method A.f(), it is
possible that an override C.f() of B.f() cannot see the original method
A.f().
In this case, we would encounter linker errors if we referenced the
method descriptor or method dispatch thunk for A.f().
Make this work by treating B.f() as the least derived method in this
case, and ensuring that the vtable thunk for B.f() dispatches through
the vtable again.
Fixes <rdar://problem/48330571>, <https://bugs.swift.org/browse/SR-10648>.
@_dynamicReplacement(for: selfRec(x: acc:))
func selfRec_r(x: Int, acc: Int) -> Int {
if x <= 0 {
return acc
}
// Normally, this will call selfRec(x: acc:)'s implementation.
// With the option, this will call to selfRec_r(x: acc:).
return selfRec(x: x - 1, acc: acc + 1)
}
rdar://51229650
Check the availability of decls that declare an opaque return type to ensure they deploy to a
runtime that supports opaque types.
rdar://problem/50731151
This is to support dynamic function replacement of functions with opaque
result type.
This approach requires that all state is thrown away (that could contain the
old returned type for an opaque type) between replacements.
rdar://48887938
The observer in a dynamic replacement of variables with a observer will
provide the dynamic replacement for the original.
var original : Int = 0 {
didSet {
print("original")
}
}
@_dynamicReplacement(for: original)
var replacement : Int = 0 {
didSet {
print("replacement")
}
}
rdar://48518788
To correctly call designated super class initializers the designated
intializer (and not the allocator) is dynamically replaceable.
Convenience allocators are dynamically replaceable as before.
This is necessary to ensure that we autorelease such values in objc thunks.
Previously, we were returning the value as unowned, leaking it. I added a test
to interpreter that will make sure in the future we do not leak like this
again.
rdar://45543138
