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
The scale test says the behavior is exponential, but it should be
linear, given that (1) we provide a contextual type outside and
(2) there is precisely 1 type which has the corresponding cases.
Misaligned indices were fixed in 5.1, but we should disable the test
when testing back deployment.
Adds a shared helper to StdlibUnittest for the run time check.
If a Mach-O image got emitted in just the wrong way, the range of `__TEXT,__swift*` sections to
read could end up starting at an unaligned address (because things like type refs have only one
byte alignment), and this would cause the reflection context to read an unaligned chunk of the
remote memory, causing alignment errors when addresses are mapped to the local copy. Keep the ranges
at least 8-byte-aligned to stave off the alignment issues we might run into with any metadata
structures, which are generally at most pointer aligned. Fixes rdar://problem/54556791
This means that we no longer have the invariant that the extendedType always
contains the generic parameters. So we need to fix the assertions/test cases
for it.
