This doesn't fix the fundamental problem of correctly handling such cases, but
it is better than the "error message" that occurred previously:
Assertion failed: ((bool)typeSig == (bool)extensionSig && "unexpected generic-ness mismatch on conformance").
Fixes the crash rdar://problem/41281406 (that in
https://bugs.swift.org/browse/SR-6569 (rdar://problem/36068136)),
https://bugs.swift.org/browse/SR-8019 (rdar://problem/41216423) and
https://bugs.swift.org/browse/SR-7989 (rdar://problem/41126254).
This will also preserve @escaping and @autoclosure, which were previously
dropped. This could lead to mismatches between expected and actual
canonical types for serialization cross-references.
https://bugs.swift.org/browse/SR-8045, likely others
Cross-references are identified by their containing module, with the
assumption that two modules will never have the same name. However, an
overlay has the same name as its underlying Clang module, which means
that there can be two declarations with the same name, the same type,
and the same module name. This is the underlying cause of the
'UIEdgeInsetsZero' problem, but it also affects the CloudKit overlay.
By tracking a bit that just says "this came from Clang", we're able
to resolve otherwise ambiguous cross-references.
(Why didn't we do it this way all along? Because if a declaration
moves from Clang to Swift or vice versa, that would break the
cross-reference. But that's only interesting if the swiftmodule format
is meant to be persistent across changing dependencies, and it looks
like we're moving away from that anyway. It's also a little weird for
SerializedModuleLoader to have special cases for Clang, but this isn't
the first.)
Note that I'm not reverting the UIEdgeInsetsZero workaround here; the
end state will have that coming just from UIKit as originally
described.
rdar://problem/40839486
This was originally commited in
3d32e89e33, and then backed out in
c40fd3966c due to concern over
behavioral changes.
This version avoids the optimization when there are any optional types
involved in the signatures of the functions.
For these cases, compareDeclarations can return the wrong order at the
moment.
I have another PR in the works that attempts to begin unraveling some
of the issues around fixing the overload comparisons.
Sometimes witness candidates have error type e.g. when re-declaration checking
marks them as `invalid`, so formatting of the diagnostic
should account of potential witnesses not having a valid type.
Resolves: rdar://problem/41141944
Implement TypeChecker::resolveInheritedProtocols() in terms of
"getInheritedType()" queries, instead.
[Sema] Put back resolveInheritedProtocols().
We're still depending on it to update state in some cases.
Wire up the request-evaluator with an instance in ASTContext, and
introduce two request kinds: one to retrieve the superclass of a class
declaration, and one to compute the type of an entry in the
inheritance clause.
Teach ClassDecl::getSuperclass() to go through the request-evaluator,
centralizing the logic to compute and extract the superclass
type.
Fixes the crasher from rdar://problem/26498438.
This mirrors how a bridging header is processed when compiling source
files: before any of the imports. This is important for LLDB to
recreate the source environment as closely as possible to how the
compiler does it; in the test case being added involving a non-modular
header file, failure to do so resulted in a deserialization
cross-reference crash.
Note that Serialization still sorts imports, which normal resolution
of imports in source does not do. So we're still not consistent. But
this is less important than handling textual includes (bridging
headers) before modular imports.
rdar://problem/40471329
* Reject bad string interpolations
String interpolations with multiple comma-separate expressions or argument labels were being incorrectly accepted.
* Tweak error name to match message
* Diagnose empty interpolations more clearly
* Don’t double-diagnose parse errors
Fixes a test at Parse/recovery.swift:799 which the previous commit broke.
* Fix incorrect test RUN: line
A previous version of this test used FileCheck instead of -verify, and the run line wasn’t properly corrected to use -verify.
* Update comment
* Add more argument label tests
Ensures that we don’t get different results from an initializer that doesn’t exist or doesn’t take a String.
* Resolve the SR-7958 crasher test
We now diagnose the error and remove the label before it has an opportunity to crash.
...instead of relying on the one in the overlay in pre-4.2 versions of
Swift. This caused crashes in deserialization, which (deliberately)
doesn't respect availability.
There are three changes here:
- Remove UIEdgeInsets.zero and UIOffset.zero from the UIKit overlay.
- Always use the 4.2 name for UIEdgeInsetsZero and UIOffsetZero from
the underlying UIKit framework. (This is the nested name.)
- Ignore the unavailability messages for those two constants in
pre-4.2 Swift, since we're now relying on them being present.
The latter two, the compiler changes, can go away once UIKit's API
notes no longer specify different pre-4.2 behavior, but meanwhile we
need to keep compatibility with the SDKs released in Xcode 10b1.
https://bugs.swift.org/browse/SR-7879
This failed in Swift 4.1 because of a problem with Substitutions,
but that whole model's been ripped out and redone in Swift 4.2.
https://bugs.swift.org/browse/SR-7978
Trying to use an argument label in an interpolation can cause various crashes. In swiftlang-1000.0.16.7, these are usually in SILGen; in master at 8f6028d, they’re in CSApply.
I think there is something far more narrow we could do here, but I'm
not sure if there is real code that such a hack would benefit from. We
can leave that to consider another day.
Fixes rdar://problem/40819547 (aka https://bugs.swift.org/browse/SR-7884).
We need to make sure they don't end up as "concrete" equivalence
classes, because they behave more like unresolved ones.
Fixes rdar://problem/40009245.
Since member lookup doesn't check requirements
it might sometimes return types which are not
visible in the current context e.g. typealias
defined in constrained extension, substitution
of which might produce error type for base, so
assignement should thead lightly and just fail
if it encounters such types.
Resolves: rdar://problem/39931339
Resolves: SR-5013
When selecting the next disjunction to attempt, try to find one that
is a disjunction of bindings where the type being bound is the
converted-to type in a conversion constraint. Attempting these early
makes it possible to split constraint systems, eliminating exponential
behavior.
Fixes: rdar://problem/40344044
Drop append-related @inlinable annotations for String, StringGuts,
StringStorage, and the Views. Drop several for larger operations, such
as case conversion. Drop as many as we can from StringGuts for now.
With the number of tests Swift does, this had a relatively high chance to fail
regularly somewhere.
Also, rejecting the lower tail means rejecting things that are perfectly
uniform, which I don't think should be the purpose of this test.
