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
For a GenericFunctionType, use `substGenericArgs`
instead of `subst`, as the latter would form a bad
generic signature if there were UnresolvedTypes
present in the base type, causing the GSB to blow
up when attempting to canonicalize it.
rdar://80635105
`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.
Previously, property names are hidden in the whole range of the
declarations. Now, it's only hidden in its own initializer range.
rdar://problem/49697202
This adds an implicit body so that we can dig out the return type
context the same way as a normal function. For now, we are also treating
the first expression in a multi-statement implicit getter body the same
way; we'll need to refactor how we complete in accessors to
differentiate those cases.
There were 2 functions to output argument list. Consolidate them and
consistently use it from every call like production (i.e. function call,
constructor call, enum with associated values, subscript)
Instead of re-typechecking parsed expression, find typechecked
expression that corresponds to the parsed expression from the
typechecked decl context, because the sub expressions of the parsed
expression can be weirdly mutated/replaced by decl context typechecking.
rdar://problem/48141174
The logic here had diverged from UnqualifiedLookup. One day we'll merge
the two, for now clean it up a bit to match.
Note that all generic parameters now have 'Reason' reported as 'Local'.
I don't believe this really matters.
Fixes <rdar://problem/20530021>.
Add null type check for `Self` type in `UnqualifiedLookup`. It seems this
doesn't happen in normal compilation. But when code-completion happens in
inactive conditional compilation block, since surrounding context hasn't
been typechecked, `Self` type can be null.
rdar://problem/41234606
Other instances of fb9c65e. Consistently use
PrintOption.PrintOptionalAsImplicitlyUnwrapped to print IUO.
rdar://problem/41046225
rdar://problem/42443512
Follow-up to f577578a6a. The same
treatment for ternary expression (IfExpr). Plus, fix a regression
introduced in f577578a where infix operators were disappeard from
results.
foldSequence() may hoist these expression up by mutating their sub
expression. When completing operators, this behavior ruins reusability
of operand. Since these expression doesn't affect completion, we can
strip them out.
rdar://problem/42452085
In getOperatorCompletions(), for each every known operators, temporary
expressions are created and typechecked. In this process, typechecker
may set the type of the parsed expression. That may cause non-accurate
completion results or crash at worst.
rdar://problem/28188259
Validation of the input side of FunctionTypeRepr was previously being done in Sema because of expression folding. If we instead push the invariant that the input TypeRepr should always be a TupleTypeRepr into the AST a number of nice cleanups fall out:
- The SIL Parser no longer accepts Swift 2-style type declarations
- Parse is more cleanly able to reject invalid FunctionTypeReprs
- Clients of the AST can be assured the input type is always a TupleType so we can flush Swift 2 hacks
Before checking any requirements of the binding type, let's look
through @autoclosure and/or non-variable types if source constraint
requires that, otherwise we'd end up creating bindings for types
which later on might end up causing infinite recursion like dependent
member types in result position of @autoclosure parameter.
Resolves: rdar://problem/38272904
They can show up when re-typechecking via diag or code-completion and were
only being sanitized out in one place in CSDiag. Moved that logic into
SanitizeExpr.
Resolves rdar://problem/38149042
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
Constructor call patterns already get a real priority, but because of
the way we do function call patterns we don't have enough information,
and previously we were setting it to "expression specific", which is
unnecessarily high, particularly since functions (unlike inits) have
other better ways to code-complete already.
rdar://31113161
When completing
Foo(<here>
We will now provide
bar: <#value#>
instead of
bar: <#value#>)
Inserting the rparen caused some problems in practice:
* the old behaviour optimized for typing Foo(<complete> instead of
Foo(<complete>), which can conflict with user behaviours or ...
* in editors with automatic brace-matching, we often conflicted with the
editor, leading to extraneous closing parens
And in general, it is much more predictable for tooling to either insert
matching ( and ) or to not insert either. While this change may not be
ideal For users of editors that do not do automatic brace-matching, I
believe it is still better overall to have to type a missing paren than
to have to delete an extraneous one.
rdar://31113161
Even if we don't apply the solution, we still end up writing
types into ParamDecls of closures contained the expression.
Make sure this is idempotent by disabling 'cleanup', which
avoids setting them to ErrorTypes, and teaching ExprCleaner
to clear out types of VarDecls.
This is a hack that will get better once the constraint
system type map stuff is further along.
Fixes <rdar://problem/33219081>.
This doesn't give particularly useful information yet (i.e. Self isn't
listed, see rdar://problem/31981641 ), but it does stop the completion
code from just directly crashing.
Fixes rdar://problem/31981486.
[CodeCompletion] Using the default constraints generator for TupleExpr
when inferring the type of unresolved members. rdar://28991372
When code completing, we used to create a type variable to represent the type
of an entire tuple expression. However, recent improvements on parser make this
step unnecessary and crash-prone. Thus, we use the default constraint
generator to interpret tuple expressions.
This fixes several issues:
- By default parent types of alias types are not printed which results in
- Erroneous fixits, for example when casting to 'Notification.Name' from a string, which ends up adding erroneous cast
as "Name(rawValue: ...)"
- Hard to understand types in code-completion results and diagnostics
- When printing with 'fully-qualified' option typealias types are printed erroneously like this "<PARENT>.Type.<TYPEALIAS>"
The change make typealias printing same as nominal types and addresses the above.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
