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
This allows us to layout-optimize Optional<T> when T is a struct with an
extra-inhabitant-bearing field anywhere in its definition, not only at
the beginning. rdar://problem/43019427
It is safe to omit the retain/release dance in the reabstraction thunk
because we know we have an aditional reference outstanding for the
is_escaping verification.
The problem with throwing an objc exception inside a noescape closure is
that we verify the reference count of the closure sentinel. The
reabstraction thunk would increase the reference count call the
implementation function that then throws skipping the decrement.
rdar://40857699
(both C enums and Swift enums declared @objc), because of the
"feature" in C of treating a value not declared as a case as a valid
value of an enum. No more undefined behavior here!
This bit can go in separately from all the work on exhaustive/frozen
enums, which is still being discussed and will come later.
rdar://problem/20420436
We can't use global offset variables if we are generic and layout
dependent on a generic parameter because the objective-c layout might
depend on the alignment of the generic stored property ('t' in the
example below).
class Foo<T> : NSFoobar {
var x : AKlass = AKlass()
var y : AKlass = AKlass()
var t : T?
}
SR-4687
rdar://31813495
This allows script mode to pick up the current version of macOS
instead of defaulting to 10.9, making it unnecessary to write #available.
A -target flag can still override this if you're trying to write a
portable script.
The logic is a little tortured to avoid having to actually link to
Foundation.framework or libobjc.
Finishes rdar://problem/29433205.
SIL already does this where necessary, except with foreign throwing
functions; this patch changes Sema and the ClangImporter to give
them an ObjCBool foreign error result type explicitly.
This fixes a problem where calls to functions taking and returning
the C99 _Bool type were miscompiled on Mac OS X x86-64, because
IRGen was conflating the Objective-C BOOL type (which is a signed
char on some platforms) and C99 _Bool (which lowers as the LLVM
i1 type).
Fixes <rdar://problem/26506458> and <rdar://problem/27365520>.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
We're now correctly checking for inheritance, adding @objc methods,
and adding @objc protocols for both CF types and objc_runtime_visible
classes (those without visible symbols). The latter is used for some
of the types in Dispatch, which has exposed some of the classes that
were considered implementation details on past OSs.
We still don't properly implement using 'as?' to check conformance to
a Swift protocol for a CF or objc_runtime_visible type, but we can do
that later.
rdar://problem/26850367
When importing C functions with availability attributes, we don't
properly use that information to decide whether a symbol should be
weak_extern, causing load failures in dylibs that reference these
symbols when deployed to an older OS.
This is a very targeted fix and we need a better architecture for
deciding this.
rdar://problem/26359452
not have access to their type arguments at runtime. Use this to
fix the emission of native thunks for imported ObjC-generic
initializers, since they may need to perform bridging.
For now, pseudo-genericity is all-or-nothing, but we may want to
make it apply only to certain type arguments.
Also, clean up some code that was using dead mangling nodes.
