Only introduce it and its dependency when the new Swift parser is being
built, and rely more on existing logic to make sure we get the right
build/link flags.
This includes:
- bumping the SWIFT_SYMBOLGRAPH_FORMAT_MINOR version
- introduction of the "swift.extension" symbol and "extensionTo" relationship
- adding support for ExtensionDecl to the Symbol class
- adding a "typeKind" field to the symbol's extension mixin which indicates what kind
of symbol was extended
- intoduction of the -emit-extension-block-symbols flag, which enables the behavior
outlined below
- adaptions to SymbolGraphASTWalker that ensure a swift.extension symbol is emitted
for each extension to a type that does not exist in the local symbol graph
- adaptions to SymbolGraph and SymbolGraphASTWalker that ensure member and conformance
relationships are correctly associated with the swift.extension symbol instead of
the original type declaration's (extended nominal's) symbol where applicable
- adaptions to SymbolGraphASTWalker that ensure swift.extension symbols are connected
to their respective extended nominal's symbol using an extensionTo relationship
Testing:
- adds SymbolGraph tests that test behavior only relevant in
-emit-extension-block-symbols mode
- adapts some SymbolGraph tests to additionally test similar behavior for
extensions to external types in -emit-extension-block-symbols mode
- adapts some SymbolGraph tests to (additionally or exclusively) test the
behavior with -emit-extension-block-symbols mode enabled
Bugfixes:
- fixes a bug where some conformsTo relationships implicated by the conformances
declared on an extension to an external type were not emitted
(see test/SymbolGraph/Relationships/ConformsTo/Indirect.swift)
Further changes:
- documents the strategy for naming and associating children declared in extensions
to typealiases (see test/SymbolGraph/Relationships/MemberOf/Typealias.swift,
test/SymbolGraph/Symbols/Names.swift)
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
Basic should not be allowed to link Parse, yet it was doing so
to allow Version to provide a constructor that would conveniently
parse a StringRef. This entrypoint also emitted diagnostics, so it
pulled in libAST.
Sink the version parser entrypoint down into Parse where it belongs
and point all the clients to the right place.
Refactor the logic so to have a single target to reference the
compatibility libraries for the host, and use that when needed.
The main driver for this change is supporting the cross-compilation of
x86-64 on Apple Silicon.
Supports rdar://90307965
`typealias` is currently allowed to refer to a protocol without the `any` keyword. This breaks mangling the typealias type into a USR will crash because parameterized protocols are expected to be `any` types.
Implement a SourceKit-specific minimal workaround for that problem by not computing USRs for parameterized protocols.
rdar://98623438
This enables the ability to cancel requests, which aren’t code completion requests, again.
Previous crashes in SILGen are prevented by disabling cancellation during the SIL stages. Instead, we add dedicated cancellation checkpoints before and after SIL.
rdar://98390926
If a 'nil' literal occurs in a swift-case statment, it gets replaced by a reference to 'Optional.none' in the AST. We want to continue highlighting 'nil' as a keyword and not as an enum element.
Resolvesapple/sourcekit-lsp#599
rdar://97961865
When an function has an async alternative, that should be preferred when we are completing in an async context. Thus, the sync method should be marked as not recommended if the current context can handle async methods.
rdar://88354910
Store whether a result is async in the `ContextFreeCodeCompletionResult` and determine whether an async method is used in a sync context when promoting the context free result to a contextual result.
rdar://78317170
PR #41550 changed from using `SmallVector::set_size` to `resize_for_overwrite` and `truncate`, but in `sourcekitd-repl` changing from `reserve` changed the size just prior to getting the `end()` of the output array, leading to retrieving the end of the resized array, rather than the array prior to resizing.
The conversion needs to begin at the original output's end, rather than the resized-to-reserve output size, otherwise the conversion triggers the asserts at lines 101 and 116 (with `res == targetExhausted`).
#58786 (rdar://93030932) was failing because the `swift-frontend` invocations passed a `swiftExecutablePath` to `Invocation.parseArgs`. This caused the `ClangImporter` instance to point to a `clang` binary next to the `swift-frontend` executable while SourceKit used PATH to find `clang`. The clang executable next to `swift-frontend` doesn’t actually exist because `clang` lives in `llvm-linux-aarch64/bin` and `swift-frontend` lives in `swift-linux-aarch64/bin`.
So some checks for a minimum clang verison failed for the normal build (because the executable doesn’t actually exists) while they pass during the SourceKit build (which used `clang` from `PATH`). This in turn caused the `outline-atomics` to be enabled to the SourceKit clang compiler arguments but not the clang compiler arguments for a normal build and thus resulted in two separate module cache directories (which includes the enabled features in the module directory hash).
To fix this issue, also set the swift executable path for compiler invocations created from SourceKit.
Fixes#58786 (rdar://93030932)
A `llvm::raw_string_ostream` is unbuffered, but calling `SetBufferSize`
adds a buffer. Since its destructor doesn't flush (as it assumes it is
unbuffered), this then asserts in the `llvm::raw_ostream` destructor.
Remove the `SetBufferSize` call (the string is the underlying buffer)
and also switch to using `llvm::SmallString` instead.
This fixes a crash in `SourceKit/SyntaxTree/basic.swift` and
`SourceKit/SyntaxTree/pound_if.swift`, which are presumably the only two
tests that actually use this.
When a variable is re-declared using shorthand syntax (`[foo]` closure capture or `if let foo {`), the user doesn’t perceive this as a new variable declaration. Thus, we should return the original declaration as a secondary result.
rdar://91311033
rdar://75455650
Previously, the related idents request wouldn’t look through caputred variables like `[foo]`. Change the logic to consider the captured variable as well as the variable that’s implicitly declared for use inside the closure.
rdar://81628899
We might run into situations where `matchesSourceState` reads `DependencyStamps` while they are being written in `buildASTUnit`, causing a crash.
Guard `DependencyStamps` by a mutex to avoid this problem. We don’t need to provide any ordering guarantees about whether `DependencyStamps` have been computed in are accessed because we already assume that the dependencies shouldn't change (much) in the time between an `ASTBuildOperation` is created and until it produced an AST.
rdar://92748564
