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.
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
With the unqualified fallback we start to hit this assertion for
`return nil` in failable intializers. We ought to be able to just
skip over literal buckets though.
For hosts that have a swiftly-managed Swift compiler, we could not
bootstrap using those tools, because of some hardcoded assumptions
about where the `/lib` directory lives, relative to the `/bin`
directory that contains the detected `swiftc`.
This patch adds specific support for detecting when the `swiftc`
is coming from a swiftly install and uses the correct paths.
I've tested this patch on my Linux machine that has swiftly 1.0.1,
with the Swift 6.1.2 toolchain.
The sourcekit in proc dynamic library looks up runtimes in a spot
relative to the Swift compiler. Set this location on freebsd, fixing the
sourcekit tests.
Currently, when we jump-to-definition for decls that are macro-expanded
from Clang imported decls (e.g., safe overloads generated by
@_SwiftifyImport), setLocationInfo() emits a bongus location pointing to
a generated buffer, leading the IDE to try to jump to a file that does
not exist.
The root cause here is that setLocationInfo() calls getOriginalRange()
(earlier, getOriginalLocation()), which was not written to account for
such cases where a macro is generated from another generated buffer
whose kind is 'AttributeFromClang'.
This patch fixes setLocationInfo() with some refactoring:
- getOriginalRange() is inlined into setLocationInfo(), so that the
generated buffer-handling logic is localized to that function. This
includes how it handles buffers generated for ReplacedFunctionBody.
- getOriginalLocation() is used in a couple of other places that only
care about macros expanded from the same buffer (so other generated
buffers not not relevant). This "macro-chasing" logic is simplified
and moved from ModuleDecl::getOriginalRange() to a free-standing
function, getMacroUnexpandedRange() (there is no reason for it to be
a method of ModuleDecl).
- GeneratedSourceInfo now carries an extra ClangNode field, which is
populated by getClangSwiftAttrSourceFile() when constructing
a generated buffer for an 'AttributeFromClang'. This could probably
be union'ed with one or more of the other fields in the future.
rdar://151020332
