When completing type members, teach the code completion engine to
transform the archetypes appearing in code completion results to the
actual types. NFC
Swift SVN r31628
When users invoke code completion at an argument position, we suggest argument names,
if required however not specified, or a list of argument values. These values are annotated
with their type relation to the expected argument types, so that
Xcode can prioritize those values that apply over those that do not.
This also fixes: rdar://21727063
Swift SVN r31505
The conformance lookup table is responsible for answering queries
about the protocols to which a particular nominal type conforms, so
stop storing (redundant and incorrect) protocol lists on the ASTs for
nominal types. Protocol types still store the list of protocols that
they inherit, however.
As a drive-by, stop lying about the number of bits that ProtocolDecl
uses on top of NominalTypeDecl, and move the overflow bits down into
ProtocolDecl itself so we don't bloat Decl unnecessarily.
Swift SVN r31381
We use an enum to describe the relationship between a code completion result
and the expected type at the code completion site. We can use this relationship
to prioritize candidates on the SourceKit side.
Swift SVN r31371
When users complete the right-hand side of an assignment expression, we only
show the results whose types are convertible to those of the left-hand side.
Swift SVN r31357
For completing unresolved members, if constraint solver does not have solutions, we
look up the function names appearing in the same line of the code completion tokens,
and use their parameters that are of enum/optionset type to deliver the code
completion results.
Swift SVN r31256
Before this commit, for unresolved members, code completion suggests all visible enum elements
and option set types. To refine the results, this commit uses constraint solver to infer
the type of unresolved members by analyzing parental expressions. If the solver has solutions,
we complete the unresolved member, otherwise abort.
rdar://16659653
Swift SVN r31195
This commit completes an unresolved member with all visible enum elements.
We need future work to reduce the list to those that are guaranteed to be
resolved under the current context.
Swift SVN r31063
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
(Undoing revert r30961 of r30957, which just required lockstep commit to
SourceKit -- cwillmore)
Swift SVN r30962
This reverts r30957 because it broke the following tests on Jenkins:
SourceKit :: CodeComplete/complete_open.swift
SourceKit :: CodeComplete/complete_test.swift
<rdar://problem/22120345> swift-incremental-RA #8289 failed to build
Swift SVN r30961
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
Swift SVN r30957
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
First, fix a case of type checking an expression twice, which is against
the design of the type checker. We hit this because we can type check
the "context" in
let x = foo.#^COMPLETE^#
and then type check the "parsed expression", which is contained in the
context here.
Second, make the hack from rdar://20738314 more robust so that if we
*do* double typecheck for some reason we won't just choke on an
AutoClosureExpr. I filed rdar://21466394 to audit for other cases of
double typechecking and remove this hack.
Fixes rdar://21346928
Swift SVN r29527
Completions for calling functions will now show 'throws' in the
description text so that users can differentiate throwing and
non-throwing calls. We don't insert this into the source text, since
it's not part of the call syntax.
rdar://problem/20978869
Swift SVN r28791
