This reverts commit e60ae24052 and fix
non-deterministic failures introduced by the commit.
Fix two issues when attempting to testing parallel scanning using
`swift-scan-test` tools:
* Make sure the BumpPtrAllocator in ScanningService is thread-safe so
there are no race condition when a new slab is allocated.
* Make sure the output of `swift-scan-test` only written from one
thread. This prevents some race conditions when writing to the same
raw_fd_ostream.
rdar://167760262
Currently, dependency scanner is not reporting the redirecting files
that are baked inside swift-frontend for platform support. This causes
dependency scanner returns virtual path for those files, and
swift-driver/build-system will not be able to correct validate the files
on incremental build, causing incremental build to be almost clean
builds.
This behavior issue is caused by the dependency scanning file system
layer inside clang dependency scanner that caches stats. If the
redirecting files are created underneath the layer, the real path is
lost. This fixes the issue by moving the redirecting files above the
caching layer using `-ivfsoverlay` option.
In addition to that, this commit also unifies how clang importer and
clang dependency scanner initiate the VFS, making the logic much
simpler.
This updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
Ensure that we account for file system arc separators and extensions by
using the LLVM functions rather than trying to simply do string
matching. This allows us to properly handle inputs on Windows.
Make sure we don't ever try to record semantic tokens for a different
buffer. This works around an ASTWalker issue where it will walk macro
expanded bodies even in non-macro-expansion mode.
rdar://165420658
This removes the C++ interop compat version mechanism. It was added in mid-2023 and was never used. It complicates the testing story, and makes it harder to reason about the compiler's behavior. It also isn't compatible with explicit module builds.
The flag `-cxx-interoperability-mode` is preserved, so projects that use the flag will continue to build normally.
rdar://165919353
Exactly when this happens is still somewhat of a mystery, but given we
allow annotations in either response, it doesn't seem worth asserting
over.
Resolves rdar://139356981.
This change just stages in a few new platform kinds, without fully adding
support for them yet.
- The `Swift` platform represents availability of the Swift runtime across all
platforms that support an ABI stable Swift runtime (see the pitch at
https://forums.swift.org/t/pitch-swift-runtime-availability/82742).
- The `anyAppleOS` platform is an experimental platform that represents all of
Apple's operating systems. This is intended to simplify writing availability
for Apple's platforms by taking advantage of the new unified OS versioning
system announced at WWDC 2025.
- The `DriverKit` platform corresponds to Apple DriverKit which is already
supported by LLVM.
Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
Make sure we avoid adding these to the entity stack entirely, which
avoids hitting the assertion that a top-level entity isn't encountered
with a non-empty stack.
Building Foundation seems to be optional in the Linux build script,
which makes it tricky to link against outside of Darwin platforms. This
removes the dependency on Foundation and calls libc for I/O instead.
This helper utility takes a module interface as input, and emits a Swift
file importing the module and calling every function in the module. It's
intended for testing of safe interop wrappers to make sure they go
through the entire pipeline of the compiler instead of succumbing to
laziness.
We scan the target's initial allocation pool, and all 16kB heap allocations. We check each pointer-aligned offset within those areas, and try to read it as Swift metadata and get a name from it. If that fails, quietly move on. It's very unlikely for some random memory to look enough like Swift metadata for this to produce a name, so this works very well to print the generic metadata instantiated in the remote process without requiring `SWIFT_DEBUG_ENABLE_METADATA_ALLOCATION_ITERATION`.
rdar://161120936
This reverts most of 72050c5385, which led to decreased performance of jump-to-definition.
Instead of re-attempting to generate a module interface with C++ interop enabled, Swift should rely on the IDE to pass the correct `-cxx-interoperability-mode=` value to SourceKit.
rdar://149061322
If these programs crash, we want them to print the Swift bug report
message, not the default LLVM one, which leads to
https://github.com/llvm/llvm-project/issues.
While here, hoist the setting of the bug report message to the
START_PROGRAM macro so that we don't forget to set it in the future.
