**Overview**:
This PR introduces the basic infrastructure needed to eventually migrate
derived macros generation from hand-crafted AST nodes to macros. No
conformance have been migrated yet.
**Motivation**:
Derived conformances (e.g. `Equatable`, `Hashable`, `Codable`, ...) are
currently implemented as a special case in the compiler, producing
synthetic AST nodes directly. Migrating this to macros will hopefully
unify the code path with the existing macro expansion infrastructure,
make conformance synthesis easier to extend and test as well as reducing
the amount of special cases in the compiler.
**Changes**:
- New experimental feature flag `DeriveConformancesViaMacros`:
Introduces the flag that will eventually gate the new derived
conformance code paths. It does not control any behaviour for the moment
as none have been migrated yet but this enables future changes to be
built incrementally.
- New GeneratedSourceInfo and SourceFile kinds `SyntheticMacro`:
Introduces new GSI and SourceFile kinds named `SyntheticMacro` to
represent macros synthesized by the compiler. Since macros need a real
buffer to expand, this is the kind of source file and GSI associated
with those buffers.
- Conformance derivation via macros API:
Introduces the `deriveRequirementViaMacro` function that produces the
required witness via macro expansion.
See https://github.com/swiftlang/llvm-project/pull/13124 for
llvm-related changes.
**Next steps**:
- Macros do not contain any semantic information, especially regarding
types. Therefore it is necessary to provide them with type information
as an argument so they can eventually derive the conformances. A
separate PR is being created to generate this type information as
strings containing swift-parsable code for easy parsing on the macro
end.
- Implement derived conformance synthesis for individual protocols using
the new infrastructure, like `Equatable` or `Hashable` for starters.
- Wire the experimental flag to gate the new path once an implementation
exists
---------
Co-authored-by: Hamish Knight <hamish_knight@apple.com>
The new request in SourceKit allows to query this JSON format via the
usual SourceKit APIs. We use it here for testing but it can be
integrated in a client as needed.
When a diagnostic belongs to a group that has a parent group (`GROUP_LINK` in `DiagnosticGroups.def`), display the full inheritance chain in the diagnostic output, including documentation hyperlinks and footnotes for each.
For example, a diagnostic in `ExistentialType` (child of `PerformanceHints`) now renders as:
```
warning: ... [#PerformanceHints::ExistentialType]
```
Groups without parents continue to display as before (`[#DeprecatedDeclaration]`).
Resolves rdar://170805800
Calling `setCurrentWorkingDirectory` on `getRealFileSystem` sets the
working directory for the process itself. This is unsafe for clients
such as SourceKit which can process multiple concurrent requests,
and may be used as an in-process library in e.g sourcekit-lsp. Switch
to `createPhysicalFileSystem` instead, where setting the working
directory is done locally on the FileSystem itself.
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.
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
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.
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.
Paul Passeron
Anthony Latsis
Alexis Laferrière
Artem Chikin
Hamish Knight
Tim Kientzle
Ben Barham
Slava Pestov
Alex Hoppen
Becca Royal-Gordon
Allan Shortlidge
Mads Odgaard
Egor Zhdan
swift-ci
Ahmed Mahmoud
Meghana Gupta
Meghana Gupta
Ahmed Elrefaey
Owen Voorhees
Kavon Farvardin