[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.
The distributed case is distinguishable from the non-distributed case
based on the actor type itself for those rare cases where we care. The
vast majority of code is simplified by treating this identically to
`ActorInstance`.
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.
Opened archetypes can be created in the constraint system, and the
existential type it wraps can contain type variables. This can happen
when the existential type is inferred through a typealias inside a
generic type, and a member reference whose base is the opened existential
gets bound before binding the generic arguments of the parent type.
However, simplifying opened archetypes to replace type variables is
not yet supported, which leads to type variables escaping the constraint
system. We can support cases where the underlying existential type doesn't
depend on the type variables by canonicalizing it when opening the
existential. Cases where the underlying type requires resolved generic
arguments are still unsupported for now.
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`.
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.
"add inits to toplevel" and "call pattern heuristics" are only used in
code completion. Move them from LangOptions to CodeCompletionContext so
that they don't affect compiler arguments.
* "description" for override completion is now annotatable
* "description" doesn't include attributes and decl introducer, but it
includes generic paramters, effects specifiers, result type clause,
and generic where clauses
* "name" now only include the name and the parameter names
* "sourcetext" should be the same
rdar://63835352
Pattern matching in Swift can either be expression pattern matching by comparing two instances using the `~=` operator or using enum matching by matching the enum case and its associated types (+ tuple pattern matching, but that’s not relevant here). We currenlty only consider the expression pattern matching case for code completion. To provide enum pattern matching results, we thus need to have a `~=` operator between the code completion token and the match expression
For example, when we are completing
```swift
enum MyEnum {
case myCase(String)
}
switch x {
case .#^COMPLETE^#
}
```
then we are looking up all overloads of `~=` and try to match it to the call arguments `(<Code Completion Type>, MyEnum)`.
The way we currently get `#^COMPLETE^#` to offer members of `MyEnum`, is that we are trying to make sure that the `~=<T: Equatable>(T, T)` operator defined in the standard library is the best solution even though it has fixes associated with it. For that we need to carefully make sure to ignore other, more favourable overloads of `~=` in `filterSolutions` so that `~=<T: Equatable>(T, T)` has the best score.
This poses several problems:
- If the user defines a custom overload of `~=` that we don't prune when filtering solutions (e.g. `func ~=(pattern: OtherType, value: MyEnum) -> Bool`), it gets a better score than `~=<T: Equatable>(T, T)` and thus we only offer members of `OtherType` instead of members from `MyEnum`
- We are also suggesting static members of `MyEnum`, even though we can't pattern match them due to the lack of the `~=` operator.
If we detect that the completion expression is in a pattern matching position, also suggests all enum members of the matched type. This allows us to remove the hack which deliberately ignores certain overloads of `~=` since we no longer rely on `~=<T: Equatable>(T, T)`. It thus provides correct results in both of the above cases.
Fixes rdar://77263334 [SR-14547]
The various keyword/recommended/etc fields were parsed and added to
completions, but never actually plumbed through SourceKit. Since they're
still unused and the implementation is not particularly lightweight,
just remove for now.
Resolves rdar://82464220
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
Rework Sendable checking to be completely based on "missing"
conformances, so that we can individually diagnose missing Sendable
conformances based on both the module in which the conformance check
happened as well as where the type was declared. The basic rules here
are to only diagnose if either the module where the non-Sendable type
was declared or the module where it was checked was compiled with a
mode that consistently diagnoses `Sendable`, either by virtue of
being Swift 6 or because `-warn-concurrency` was provided on the
command line. And have that diagnostic be an error in Swift 6 or
warning in Swift 5.x.
There is much tuning to be done here.
'available(..., deprecated: <version>)'. If the version is larger than the
current active version, the declaration is "soft deprecated". Emit a
relevant diagnostics for those items. If the version is equal to or
larger than '100000.0', it means the distant future without specifying
the version.
rdar://76122625
* Implement 'getDiagnosticSeverity()' and 'getDiagnosticMessage()' on
'CodeCompletionResult'
* Differentiate 'RedundantImportIndirect' from 'RedundantImport'
* Make non-Sendable check respects '-warn-concurrency'
rdar://76129658
* 'CodeCompletionContext' now has 'requiresSourceFileInfo()' flag
* When 'true', 'SourceFiles' is populated.
* 'SourceFiles' is a list of pairs of a known module source
file path and its up-to-date-ness
* Clients (i.e. 'CodeCompletionConsumer') can retrieve it from
'CodeCompletionContext' in 'handleResults'
* Each completion item now has 'SourceFilePath' property
* C-APIs to get those informations
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
