Setting the interface type of a variable, just to reset it to a null type is actually really gross. But quite a few methods further down in the generation of code completion results (such as USR generation) need to get a variable’s type and passing them along in a separate map would be really invasive. So this seems like the least bad solution to me.
Before, we were dropping `LeaveClosureBodiesUnchecked` when checking a pattern binding request which caused missing completions inside variables initialized by closures.
rdar://92603748 [#58610]
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
`CodeCompletioString::getName()` was used only as the sorting keys in
`CodeCompletionContext::sortCompletionResults()` which is effectively
deprecated. There's no reason to check them in `swift-ide-test`. Instead,
check `printCodeCompletionResultFilterName()` that is actually used for
filtering.
Parse a completion token as an empty parameter name (just like `_`) to
prevent the parser to parse it as an expression and offer completions
for it.
rdar://78798718
To describe fine grained priorities.
Introduce 'CodeCompletionFlair' that is a set of more descriptive flags for
prioritizing completion items. This aims to replace '
SemanticContextKind::ExpressionSpecific' which was a "catch all"
prioritization flag.
There were some changes to completion results because AST mutations that were
made while diagnosing are no longer happening.
This patch 1) changes expression type checking to allow unresolved types when
solving constraint systems, so we get a solution and apply its types in more
cases, and 2) fixes a parsing issue where we would drop a ternary expression
completely if the code completion point was in its true branch.
We were losing the CurLocalContext state (set when entering the closure's
BraceStmt) through the delaying process, sometimes causing errors when we
got back to parsing a delayed decl.
Resolves rdar://problem/54219186
When completing in the only expression of closure, use the return type
of the closure as the type context for the code-completion. However,
since code-completion may be on an incomplete input, we only use the
return type to improve the quality of the result, not to mark it
invalid, since (a) we may add another statement afterwards, or (b) if
the context type is Void it doesn't need to match the value.
Type may depend on its suffix. Parsing complete expression including its
suffix improves context type info around the CC token.
rdar://problem/44143964
When the scope depth is wrong and we add a name to the hash table we
will skip the redefinition checks and end up hitting an assertion
failure.
rdar://problem/22344218
Swift SVN r31690
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Completely disable the AST transformation for single-expression closures. When
this transformation picks up an incomplete expression, the resulting AST is
almost guaranteed to have type mismatches, and the type checker just marks
everything with error types.
rdar://17193319 rdar://17086137
Swift SVN r20153
