**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>
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.
Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
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
Make `getOriginalLocation` work with source ranges, and adjust the
cursor info logic to map the range into the original buffer. This
fixes the case where we were using bogus range lengths for macro
expansion decls.
rdar://151411756
We need this option for `collectVariableType` (aka inlay type hints) but since I’m at it, I’m adding an option to disable the implicit request cancellation for all requests that have it since we don’t want it in LSP at all.
Prerequisite to fixing https://github.com/swiftlang/sourcekit-lsp/issues/2021 / rdar://145871554, need to adopt this option in SourceKit-LSP.
If a module has the same `public-module-name` as the module being
generated and its import is exported, merge it into the same generated
interface.
Fix various always-imported modules from being printed while here and
update all the tests that checked for them.
Resolves rdar://137887712.
When a function declaration has a body, its source range ends at the
closing curly brace, so it includes the `throws(E)`. However, a
protocol requirement doesn't have a body, and due to an oversight,
getSourceRange() was never updated to include the extra tokens
that appear after `throws` when the function declares a thrown
error type. As a result, unqualified lookup would fail to find a
generic parameter type, if that happened to be the thrown type.
Fixes rdar://problem/143950572.
Resolving cursor info is async and can occur after the request has been
deleted, make sure to take a copy of the `USR` (which is part of that
request).
Resolves rdar://137320169.
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
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
This has two benefits:
1. We can now report ambiguous variable types
2. We are more robust in the generation of results for declarations inside closures. If the closure has an error, we won’t apply the solution to the AST and thus any cursor info that tried to get types out of the AST would fail.
rdar://123845208
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
* Record each IfConfig clause location info in SourceFile
* Update SILProfiler to handle them
* Update SwiftLangSupport::findActiveRegionsInFile() to use the recorded
regions instead of walking into AST to find #if regions
rdar://118082146
SourceKit-LSP currently parses the XML comment to generate Markdown again but round-tripping a (probably markdown) doc comment to XML to Markdown is lossy in many cases and unnecessary work. Include the comment as it is spelled in source in the cursor info response so that sourcekit-lsp can display it.
Part of rdar://120685874
Performing a related identifiers request on `self` returns an empty result because `self` is not an identifier. We thus can’t retrieve the first location to compute the old name.
rdar://121668042
If the file didn’t exist on disk, `fileSystem->getRealPath` returns an empty string, which means we can’t find the `InputBuffer` and thsu won’t run solver-based cursor info. There’s no reason to realpath `PrimaryInputPath`, `getMemoryBuffer` already does that.
rdar://120737244
While we don't want to return non-editable base names for Edit-All-In-Scope, we do want to return them if the related identifiers response is used as the input for find-syntactic-rename-ranges.
This allows building sourcekitd and swift-refactor with `SWIFT_BUILD_SWIFT_SYNTAX=NO`. In these builds, the `relatedidents` and `find-syntactic-rename-ranges` requests will always return an error.
We should (and do) have one new name for the entire rename operation, not a separate new name for different positions at which the renamed symbol occurs.
Paul Passeron
Hamish Knight
Slava Pestov
Becca Royal-Gordon
Anthony Latsis
John Hui
Alex Hoppen
Ben Barham
Allan Shortlidge
swift-ci
Doug Gregor
Alexander Cyon
Rintaro Ishizaki