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
This has been showing up as nondeterministic failures on our Linux
bots in the clang_builtins.swift test, because that test used to
trigger typo correction! Which pulled in macros, which happened to
include some redefinitions, which resulted in this.
rdar://problem/34266952
Besides saving some calls to stat(), this also causes problems when
the user specifies a search path that Clang already adds by default,
like $SDKROOT/Library/Frameworks/. Why? Because Swift adds its search
paths after Clang has already configured its defaults, but Clang
reconfigures its search paths from scratch when compiling a module to
a PCM file to cache. This led to system search paths being found
sooner in the primary Clang instance than in the PCM files, which in
turn resulted in the PCM files being considered out of date.
This isn't likely to affect people much in practice, but it's better
to get right. (We ran into this during Doug's experiments in making
/System/Library/PrivateFrameworks a default search path in Clang
r313317; turns out that's problematic for other reasons as well.)
rdar://problem/34664596
