The autoclosures generated for the keypath-as-function feature were not added to the list of closures that needed captures computed. In top-level code, this caused a crash. Fixes rdar://problem/56055600.
Number the parameters starting at 1 in order to
match other diagnostics such as
diag::missing_argument_positional, and change the
text to make it explicit that we're referring to
the parameter position (rather than argument
position).
Some old circularity-breaking code caused an unexpected null type, which led to crashes in the decl checker when trying to check that an `appendInterpolation` method in a different file would satisfy the informal requirement for one in a StringInterpolationProtocol conformer. This code appears to now be unnecessary, so this commit removes it. Fixes rdar://problem/55864759.
Remove the parent signature from consideration when computing the
generic signature for an extension. This cuts off a series of crashers
that involved nested extensions with trailing where clauses a la
extension Foo {
extension Foo where Self.Undefined == Bar {
}
}
The inner (invalid) extension technically has a parent signature from
Foo itself. Adding that signature to the GSB means when we go to
register the inner extension's generic parameters we crash.
Since extensions have to occur at the top level, just remove the parent
signature from consideration.
Fixes rdar://55502661
Note that while the original crasher in the radar is gone, my reduced test
case triggers an IRGen crash on both 5.1 and master because of an unrelated
bug that appears to be related to protocol requirement signatures and
declaration ordering.
Fixes <rdar://problem/54952911>.
It's likely that these were listed as "REQUIRES: OS=macosx" to not
redundantly run them for iOS et al, but they don't take that long and
so it's more useful for Linux devs to be able to run them locally if
need be. Or to catch something that really is different on non-macOS.
This was causing an exponential amount of time traversing the AST with
deeply chained protocol extension methods, such as in the
TestCodableRouter.swift test in Kitura.
If the OpaqueValueExpr is referenced more than once within the
OpenExistentialExpr it'll still get visited more than once, but that
doesn't seem to happen in practice. If it turns out to be a problem,
we can weaken the assertion I'm adding here.
https://bugs.swift.org/browse/SR-11012
If, while loading a bridging header, we pick up a Clang module that
claims to have an overlay Swift module, and that Swift module turns
out to have a bridging header, we can end up reallocating the array
of modules to process while we're looping over it. Be defensive
against this occurrence.
This just fixes a crash; it does not at all solve the problem of this
being broken in several ways:
- Accidentally naming your module the same as a system module shadows
the latter (if the system module is a Swift module) or *makes your
module into an overlay* (if the system module is a Clang module).
- Bridging headers are only officially supported on executable targets
and unit tests, but this isn't really enforced.
- Implicit inclusion of a bridging header *when you import a Swift
module* is a hack to begin with, and a hack that worsens when the
main module also has a bridging header. (All the bridging headers
get folded together into the "same" module, which leads to more
visibility than desired as well as cycles in the import graph.)
- Combining all of these can result in some pretty bizarre behavior.
rdar://problem/54581756
