There's also a testing option, -serialize-debugging-options, to force this
extra info to be serialized even for library targets. In the long run we'll
probably write out this information for all targets, but strip it out of
the "public module" when a framework is built. (That way it ends up in the
debug info's copy of the module.)
Incidentally, this commit includes the ability to add search paths to the
Clang importer on the fly, which is most of rdar://problem/16347147.
Unfortunately there's no centralized way to add search paths to both Clang
/and/ Swift at the moment.
Part of rdar://problem/17670778
Swift SVN r24545
Previously, we depended on whether or not a serialized module was located
within a framework bundle to consider whether or not it may have a "Clang
half". However, LLDB loads serialized modules from dSYM bundles. Rather
than try to figure out if such a module is "really" a framework, just track
whether the original module was built with -import-underlying-module. If so,
consider the underlying Clang module to be re-exported.
rdar://problem/18099523
Swift SVN r21544
