Now we can handle simple cases like
1 + 1 == 2 <here>
and correctly suggest both + on the 2 and || on the boolean. When the
LHS doesn't type-check we fallback to using only the operand immediately
to the left.
Swift SVN r32489
...into separate prefix, postfix and infix operators. Also incidentally
make the whitespace around operators special so we can decide when to
skip over it. Tested in SourceKit.
Swift SVN r32468
This allows us to start code-completing infix operators in postfix
expressions. As a first step, this patch only handles completing
against the immediate LHS (so for example 1 == 1 <here> doesn't suggest
boolean operators yet).
The next step is to feed the leading sequence expression from the parser
in so we can consider how the operator being completed fits into the
whole sequence expression.
For rdar://problem/22460167
Swift SVN r32465
With this change, TypeReprs no longer contain fully-resolved types for
any parsed code. Rather, they contain unresolved identifiers or the
declarations to which the identifiers have resolved.
As a minor space optimization, collapse the unbound (Identifier)
representation and the bound (ValueDecl *) representation into a
single pointer union.
Swift SVN r32434
This allows us to start code-completing postfix operators (generally !,
++, and --), which lays some of the groundwork for completing the much
more interesting infix operators.
These only show up when in postfix position
x<here>
For rdar://problem/22460167
Swift SVN r32355
For now, just avoid adding the completion since that will assert later
when we try to sort. In the future we could actually complete something
useful here, since we can dig out the names of the parameters even if
the type is invalid.
rdar://problem/22834017
Swift SVN r32211
When completing at the sequence position of for each statment (for i in <HRER> {}),
values of sequence type should have higher priority than the rest.
Swift SVN r32202
Having bound types in TypeReprs causes trouble in several places
(mostly involving type-checking of generics), and doesn't really fit
with TypeReprs being a mostly syntactic construct. Eliminate some code
paths using getBoundType(), and make the others do the same thing for
getBoundDecl() and getBoundType(). As part of the latter, provide
TypeBase::getDirectlyReferencedTypeDecl() to more easily map from type
to the named declaration.
Swift SVN r32018
Global variables from the same source file are more like locals when
writing top-level code, particularly in Playgrounds. Other declarations
(types, global functions, etc.) are unaffected.
rdar://problem/22329905
Swift SVN r31992
We can't afford to walk all the top-level results, which includes every
type and global function in the SDK. Instead, use the usual caching
mechanisms.
This means we never get type relations on top-level SDK symbols, but
this should be fine for most cases because:
1) For ObjC code, we don't generally care about global functions. And
in practice most of the matching global functions for common types are
not high-priority anyway (e.g. alignof for Int).
2) In a previous commit I manually added the names of types so that we
can do later code completions to get initializers and static methods.
E.g. you will still get "CGRect" if you complete inside drawInRect(...).
Top-level results from the current module should be unaffected.
Swift SVN r31961
Since other module results are cache, manually add the type names of
expected nominal types in call arguments so that we can get the type
relationship correct
For rdar://problem/22271094
Swift SVN r31959
This exposes the code completion kind so that SourceKit has more
information about the code completion context.
For rdar://problem/22460026
Swift SVN r31925
By analyzing the context of a member access expression, we can prioritize the member
completion results by the expected type. As the initial step, we support call arguments
as context.
Swift SVN r31837
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
When SourceEntityWalker visits a subscript reference it sometimes needed to visit
both open and close brackets. It used to be implemented as two calls to a regular
visitDeclReference which confused the clients expecting one call per a reference,
for example indexing was recording two references to a subscript.
We add a separate visitSubscriptReference to resolve this problem.
Swift SVN r31494
