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
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
This currently doesn't check for inherited docs, ie. either the
imported declaration has docs or it doesn't. There's also a few odd
cases with mixed doc types and when each line is prefixed with '*', but
it's good enough for an initial implementation.
Moves UTF8 sanitisation out of ASTPrinter.h and into Unicode.h so that
it can be used here as well.
Resolves rdar://91388603.
This fixes a race-conditioned deadlock which could occur while cancelling SourceKit AST build request
We have one thread that claimed `CancellationRequestCallbackMtx` in `SwiftASTConsumer::requestCancellation` and wants to claim `ConsumersAndResultMtx` in `ASTBuildOperation::requestConsumerCancellation`
Another thread claimed `ConsumersAndResultMtx` in `ASTBuildOperation::schedule` and now wants to claim `CancellationRequestCallbackMtx` in `SwiftASTConsumer::removeCancellationRequestCallback`.
In both cases we could actually release one lock before claiming the other.
Fixes rdar://90870793
We add a new flag to disable the implicit import of `_StringProcessing`, similar to `-disable-implicit-concurrency-module-import`. We need this to build `_RegexParser` when `-enable-experimental-string-processing` is enabled by default, because `_StringProcessing` currently imports `_RegexParser` publicly (non-implementation-only).
We need to run SILGen for diagnostics (to actually get all diagnostics).
All non-completion requests share an AST and thus they too run SILGen.
Any lazy typechecking run in SILGen assumes that it succeeds.
Cancellation can cause typechecking to fail here though, since we simply
check the flag and error if it's set. This unfortunately has the ability
to cause any any number of crashes since various invariants in SILGen
are then broken.
Disable cancellation of in-flight non-completion requests for now until
we have a proper fix in place.
Resolves rdar://91251017.
Two paths missed setting up overlays:
- `CompletionInstance` when checking files from dependencies
- `SwiftASTManager` when reading in files that it would later replace
all inputs with
(1) would cause the AST context not to be re-used, even though nothing
had changed. (2) caused all non-completion functionality to fail for any
symbols within files only specified by the overlay.
Resolves rdar://85508213.
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
Custom attributes were not printed because they are marked
'UserInaccesible'.
* Make CustomAttr 'RejectByParser' instead of 'UserInaccessible'
* Remove special treatment for Result Builder attributes
* Load implicit modules in module/header interface gen requests
rdar://79927502
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
In the "next" branch, set_size has been made protected. Instead, users
can use resize_for_overwrite, optionally followed by truncate, to
handle the same use cases more safely.
Filter name for completion item is always used. Also, for cached items,
they are used multiple times for filtering. So precomputing and caching
it improves performance.
rdar://84036006
Convert 'ContextFreeCodeCompletionResult' constructor overloads to
'create()' factory methods. This is the consistent interface with
'CodeCompletionString'. NFC
[CodeCompletion] Make ExpectedTypeContext a class with explicit getters/setters
This simplifies debugging because you can break when the possible types are set and you can also search for references to `setPossibleType` to figure out where the expected types are being set.
