If the type check return type from the context has unresolved types, it
can't be used for checking convertibility. Fallback to get
'TypeContextInfo' of the closure position.
rdar://problem/66002497
In -swift-version 5 and earlier, #file will continue to be a synonym for #filePath; in a future -swift-version (“Swift 6 mode”), it will become a synonym for #fileID. #file in libraries will be interpreted according to the language mode the library was compiled in, not the language mode its client uses.
Implement this behavior, tied to a frontend flag instead of a language version. We do so by splitting the old `MagicIdentifierLiteralExprKind::File` into two separate cases, `FileIDSpelledAsFile` and `FilePathSpelledAsFile`, and propagating this distinction throughout the AST. This seems cleaner than looking up the setting for the module the declaration belongs to every time we see `File`.
This doesn’t handle module interfaces yet; we’ll take care of those in a separate commit.
Extracts the list of magic identifier literal kinds into a separate file and updates a lot of code to use macro metaprogramming instead of naming half a dozen cases manually. This is a complicated change, but it should be NFC.
The meaning of EnableConcisePoundFile is going to shift slightly, so it makes sense to always include #filePath in completions. Also, @rintaro confirmed that this should be using KeywordKind::pound_filePath, not KeywordKind::pound_file.
Return type in the closure signature is often redundant when expanding
placeholders, because the type of the clossures are usually inferred
from the context (i.e. calling function), users don't need to write the
return type explicitly.
They are not only redundant, but also sometimes harmful when the return
type is a generic parameter or its requirement. Actually, there is no
correct spelling in such cases.
So omit the return type and the parentheses around the parameter clause.
rdar://problem/63607976
This affects module interfaces, interface generation in sourcekitd, and
diagnostics. Also fixes a fixit that was assuming the 'OSX' spelling when
computing the source range to replace.
Resolves rdar://problem/64667960
After trailing closure, we perform "Labeled trailing closure" completion
and fall back to other completion depending on the position.
If the completion happens at a newline position, it used to fallback to
global expression completion, but in type context, we should do override
completion instead.
Also, we didn't use to propagate 'hasCodeCompletion()' status properly.
rdar://problem/64650782
This makes it easier to specify OptionSet arguments.
Also modify appropriate uses of ModuleDecl::ImportFilter to take
advantage of the new constructor.
Don't insert CodeCompletionExpr at the cursor position in
"conforming method list" or "typecontext" mode. This increase the chance
of successful type checking.
rdar://problem/63781922
In 'protocol', 'Self' is implicitly declared as a generic parameter.
In 'struct' and 'enum', 'Self' is just an alias for the nominal type.
In 'class', 'Self' is a dynamic type and usable only in result types and
inside function bodies.
rdar://problem/61307680
in global completion result. Overly modules have the same name as the
shadowed modules. We should not list both names because they are
identical.
Maintain a set of seen module names to avoid suggesting duplicated
names.
rdar://problem/63370253
When completing a single argument for a trailing closure, pre-expand the
closure expression syntax instead of using a placeholder. It's not valid
to pass a non-closure anyway.
rdar://62189182
func foo() {}
let a: Int = #^HERE^#
Previously, we marked 'foo()' as 'NotRecommented' because 'Void' doesn't
have any member hence it cannot be 'Int'. But it wass confusing with
'deprecated'.
Now that we output 'typerelation' which is 'invalid' in this case. So clients
can deprioritize results, or even filter them out.
rdar://problem/57726512
Protocol extension only members are not customization point. Code
completion should not suggest them in override/conformance completion.
rdar://problem/53591636
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
