Some of the tests now depend on features provided by Swift Syntax, and
will fail to pass if building without Swift Syntax support.
This commits marks all the tests I know fail to pass when Swift Syntax
is disabled.
- #70281 modified `ASTGen/verify-parse.swift`
- #70287 created `refactoring/SyntacticRename/operator.swift` and `SourceKit/RelatedIdents/operator.swift`
- #70389 modified `SourceKit/Refactoring/basic.swift` and indirectly
modified all `refactoring/ExtractFunction/*` tests.
The `NameMatcher` implemented in swift-syntax as slightly different semantics because it consideres `(callable.|callAsFunction)(x: 78)` as a reference to `callAsFunction` instead of a call with argument labels `(x: 78)`, which means that one test needs to be updated.
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.
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.
Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
When the target decl is a VarDecl, peer macro should expand at the end
of the pattern binding decl, instead of the end of the VarDecl which
only covers the name.
rdar://117098598
We need this request for semantic highlighting in LSP. Previously, we were getting the semantic tokens using a 0,0 edit after a document update notification but that will no longer be possible if we open the documents in syntactic only mode.
When importing a C++ class template instantiation, Swift translates the template parameter type names from C++ into their Swift equivalent.
For instance, `basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t>>` gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `wchar_t` is imported as `CWideChar`, which is a typealias for `Scalar` on most platforms including Darwin. Notice that Swift goes through the `CWideChar` typealias on the specific platform. Another instantiation `basic_string<uint32_t, char_traits<uint32_t>, allocator<uint32_t>>` also gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `uint32_t` is also imported as `Scalar`. This is problematic because we have two distinct C++ types that have the same name in Swift.
This change makes sure Swift doesn't go through typealiases when emitting names of template parameters, so `wchar_t` would now get printed as `CWideChar`, `int` would get printed as `CInt`, etc.
This also encourages clients to use the correct type (`CInt`, `CWideChar`, etc) instead of relying on platform-specific typealiases.
rdar://115673622
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
The constraint system might produce multiple solutions that all reference the same declaration. We should only report the declaration once in those cases instead of multiple times.
rdar://111814276
