This allows makes the distinction between cachable and non-cachable properties cleaner and allows us to more easily compute contextual information (like type relations) for cached items later.
Previously, when creating a `SourceKit::CodeCompletion::Completion`, we needed to copy all fields from the underlying `SwiftResult` (aka `swift::ide::CodeCompletionResult`). The arena in which the `SwiftResult` was allocated still needed to be kept alive for the references stored in the `SwiftResult`.
To avoid this unnecessary copy, make `SourceKit::CodeCompletion::Completion` store a reference to the underlying `SwiftResult`.
Previously the code completion methods just returned an `ArrayRef` that pointed into the result sink that contained the results but no effort was made to actually keep that that result sink alive, e.g. when transforming results in `transformAndForwardResults`.
Instead, return the `CodeCompletionResultSink` from the code compleiton methods now and adopt that sink from the inner results created in `transformAndForwardResults`.
Only declarations in the same module as synthesized extension's target
are placed within a synthesized extension. We should thus not add
"::SYNTHESIZED::" to the USR if the given declaration is in a different
and.
As an example, `Foundation` adds a method `components(separatedBy:)` to
`String` through an extension on `StringProtocol`. But since it is
within `Foundation` and not `Swift` it will *not* be in a synthesized
extension of `String` or `StringProtocol`. So it should not have
"::SYNTHESIZED::" added and should also not being in the `String` group.
Resolves rdar://71355632.
Now that arguments are marked up with whether they have a default or
not, clients may not need the extra call (that has no default
arguments). Add an option to allow not adding this item.
Resolves rdar://85526214.
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
When opening a file for the first time, we don’t store a snapshot for it. This could cause a crash when trying to consult its snapshot to see whether an AST can be reused for cursor info.
Instead of checking that the stdlib can be loaded in a variety of places, check it when setting up the compiler instance. This required a couple more checks to avoid loading the stdlib in cases where it’s not needed.
To be able to differentiate stdlib loading failures from other setup errors, make `CompilerInstance::setup` return an error message on failure via an inout parameter. Consume that error on the call side, replacing a previous, more generic error message, adding error handling where appropriate or ignoring the error message, depending on the context.
Enqueuing `SwiftASTConsumer`s might be expensive because `getBuildOperationForConsumer` consults the file system. Since all results from the AST build are processed asynchronously anyway, there’s no need to perform the enqueuing synchronously.
rdar://86289703
We never need to have two copies of the same `FileContent` object, so we don’t need a copy constructor and can thus pass it on the stack again, instead of storing it on the heap.
MSVC doens't pack diffrent underlying int types into a bitfield. e.g.
struct S {
int a: 1;
char b: 1;
int c: 1;
};
These fields are considered three sparate bitfields.
The switch between compilers causes problems due to new flags being used
for building. This adds a workaround to avoid the search path
re-ordering which breaks the build with a newer CMake.
