Jordan Rose e42dd5ac08 [ClangImporter] Protect against re-entrant bridging header loading (#27045) ...

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

2019-09-05 17:00:14 -07:00

..

bridging-header-reentrancy

[ClangImporter] Protect against re-entrant bridging header loading (#27045)

2019-09-05 17:00:14 -07:00

explicit-system-framework-path

…

macros-repeatedly-redefined

…