in override completions. '_' as a filterName is not something clients
expect. This align with function call completions.
But, unlike call-site completions, we do need '_' in the source text. So
instead of mark the chunk "annotation", make an exception in
'printCodeCompletionResultFilterName()'.
rdar://91892610
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
* "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
`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.
* 'super' in a overriding decl is "common".
* type decl introducers (e.g. 'struct', 'enum') at top-level in library
files are "common"
* type decl introducers in 'protocol' are invalid, hence "rare"
* top-level only decl introducer (e.g. 'import', 'extension') are invalid
at non-top-level, hence "rare"
* nested types in function bodies are "rare"
* member only decls (e.g. 'subscript', 'deinit') are invalid in function
body, hence "rare"
* some modifiers (e.g. 'public', 'private', 'override') are invalid for
local decls, hence "rare"
rdar://77934651
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.
Since the user can now write additional member accesses off of an UnresolvedMemberExpr, we should offer all available completions rather than just those that match the contextual type.
It's treated as a keyword by syntactic highlighting, but wasn't annotated as a
keyword by code completion, cursor info, or doc info.
Resolves rdar://problem/61114942
For exmaple:
func foo(_: Int, _: IntOption)
func foo(_: Float, _: FloatOption)
foo(intVal, .<HERE>)
Previously code completion suggests static member from 'IntOption' and
'FloatOption' without any prioritization. Prioritize members from
'IntOption' because the user probably wants to input them.
In such cases, 'CodeCompletionExpr' at the cursor position is
pre-typechecked to 'IntOption'. So mark results with matching type with
'ExprSpecific'.
rdar://problem/62121221
