Introduces the new DeclarationsArrayBuilder and adds it to the
EditorConsumer. Declaration info always includes a kind, offset, and
length, and includes a USR where applicable.
As the USR is already available for editor.open.interface type requests,
this doesn't compute any new information, it just exposes more of what's
there already.
Build 'lib/swift/host' libraries and linking binaries as a single
"package" instead of buillding the linking binaries with
"prefer-interface" hack.
This enables CMO between them.
To materialize the object file correctly on a cache hit when MCCAS is
enabled, if lib_InternalSwiftScan.dylib is used to detect the cache hit,
we need to add MCCAS support to the replay code in SwiftCaching.cpp
This makes sure that Swift respects `-Xcc -stdlib=libc++` flags.
Clang already has existing logic to discover the system-wide libc++ installation on Linux. We rely on that logic here.
Importing a Swift module that was built with a different C++ stdlib is not supported and emits an error.
The Cxx module can be imported when compiling with any C++ stdlib. The synthesized conformances, e.g. to CxxRandomAccessCollection also work. However, CxxStdlib currently cannot be imported when compiling with libc++, since on Linux it refers to symbols from libstdc++ which have different mangled names in libc++.
rdar://118357548 / https://github.com/swiftlang/swift/issues/69825
After the C standard library headers are split out of Darwin, DumpConcurrency.swift no longer sees string.h. Explicitly import <string.h>'s new module when it's available.
rdar://127076885
Building the generated interface for WinSDK can overflow the stack.
Treat it as a semantic request to run it on a large stack.
Fixesswiftlang/sourcekit-lsp#1115
rdar://123944504
Don't try to figure out the executable names during replay from
libSwiftScan.dylib. The actual executable path for the process actually
doesn't matter in this case to reconstruct the invocation and might
actually be misleading.
Just use `swift-frontend` as a placeheader executable name for
in-process cache replay.
rdar://132758308
We ran SwiftParser in `handlePrimaryAST` for related identifiers. That function is called on a dispatch queue with reduced stack size and could cause the parser to stack overflow if the program is very nested.
Run `handlePrimaryAST` on a deep stack for this request to fix the issue.
rdar://129960285
