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>.
The confusion here was around a test that was testing the behavior when one
/does not/ guard a polymorphic builtin with a _isConcrete. Specifically, without
_isConcrete, one gets weird behavior where in debug we crash, but in release we
may not due to further inlining/specialization. With _isConcrete, we never
crashand get the appropriate behavior.
This commit works by changing the current run of the polymorphic builtin test to
force -Onone and adds an extra -O run that way we validate both behaviors.
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
This commit focuses the basics: setting up the relevant stanzas in
lit.cfg and adding platform conditionals for importing Glibc. Future
commits will deal with other portability fixes.
Without %target-run, DYLD_LIBRARY_PATH won’t apply and the target will try to load OS-supplied libraries rather than the ones we just built even if use_os_stdlib isn’t enabled.
The demangler tolerates arbitrary suffixes on mangled names, and parses them as a Suffix node. When looking up a class by an ObjC mangled name, we don't want such demanglings to succeed, because this will result in false positives. It's expected that NSClassFromString(someClassName + "some suffix") will fail, unless something has actually created a class with that suffix.
rdar://problem/60012296
Regardless of any flags, the stdlib will have its generic metadata
prespecialized.
Temporarily reintroduced the flag to enable the feature flag while
preserving the flag to disable it and changed the default back to off
for the moment.
LLJIT is a simple LLVM IR JIT. Its interface is similar to MCJIT, but its
implementation is based on LLVM's newer ORC APIs. This initial patch does not
make use of any of LLJIT/ORC's advanced features, but will provide better
diagnostics when JIT'd code fails to link. Once LLJIT has proven usable in
this basic configuration we can start experimenting with more advanced
features, including lazy compilation.
* SR-12161 Casting P.self to P.Type regressed in iOS13.4 beta
An earlier fix for certain protocol casts inadvertently disabled
the check for a protocol being cast to its own metatype.
This rearranges the code so that identical types always succeed.
It also updates swift_dynamicCastMetatypeUnconditional to
include recent changes to swift_dynamicCastMetatype.
Note: These fixes only apply to debug/non-optimized builds.
Cast optimizations still break a lot of these cases.
When a specialized usage of a generic enum occurs in the same module
where the enum was defined, directly reference the prespecialized
metadata.
rdar://problem/56994321
Otherwise the code as written miscompiles code like:
```
@inline(never)
func consumeSelf<T>(_ t : __owned T) {
print("Consuming self!")
print(t)
}
class Klass {}
struct S<T> {
let t: T? = (Klass() as! T)
@inline(__always)
__consuming func foo(_ t: T) {
consumeSelf(self)
}
}
public func test<T>(_ t: __owned T) {
let k = S<T>()
let f = k.foo
for _ in 0..<1024 {
f(t)
}
}
test(Klass())
```
As one can tell, without annotations it is hard to create an example like the
above, but there is no reason why we couldn't emit more code like this from the
frontend.
If the parameter is guaranteed though, the current impl is fine for
@in_guaranteed since in the loop, we do not need to retain or release the
value.
rdar://58885352
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
Solutions passed to `diagnoseAmbiguityWithFixes` aren't filtered
so we need to remove all of the solutions with the score worse
than overall "best". Also logic has to account for some fixes being
"warnings".
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
