What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
Right now 'fileprivate' is parsed as an alias for 'private' (or
perhaps vice versa, since the semantics of 'private' haven't changed
yet). This allows us to migrate code to 'fileprivate' without waiting
for the full implementation.
If a declaration is marked deprecated (but not unavailable) we want to
mark it as "not recommended" so that users know this probably isn't what
you want. We already do something like this in Clang code completions of
deprecated ObjC declarations.
rdar://problem/26335424
Implement code completion support for Objective-C #keyPath
expressions, using semantic analysis of the partially-typed keypath
argument to provide an appropriate set of results (i.e., just
properties and types).
This implements all of the necessary parts of SE-0062 / SR-1237 /
rdar://problem/25710611, although at some point I'd like to follow it
up with some warnings to help migrate existing string literals to
In the new code-completion code path, force any known operators to go
through a fixed sort order. To identify operators unambiguously, add a
new BuiltinOperator code-completion kind to handle non-decl operators
(!, ., ?., and =).
rdar://problem/25994246
rdar://problem/23440367
Remove C-style for loop example from the comment demonstrating the ExpressionSpecific code completion context; C-style have been deprecated and will be removed.
As implied in rdar://24818863, striking through a module name may be an overkill to suggest the module is redundant to import. We try to
fine-grain not-recommended-reason so that proper UI cue can be adopted in the future.
When the LHS is an lvalue/assignable tuple and there is no leading
sequence of binary expressions.
It's a bit hacky right now since we don't have a good way to
differentiate general pattern completions from builtin operators.
rdar://problem/23209683
If there is a type context, hide literal suggesetions that don't match
it, unless they are keywords and we have filtered to their names.
Incidentally fix an output buffering issue when combining filtering with
the -raw flag in complete-test.
Part of rdar://problem/23865118
On a per-request basis. Allows hiding/showing at multiple granularities
* everything
* module
* API by name
* keywords (by uid or all of them)
* literals (by uid or all of them)
With more specific rules overriding less specific ones (so you can hide
everything and then selectively show certain API for example).
rdar://24170060
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
Similar with @keyword, manifesting @recommended and @recommendedover content in code
completion results can help IDE users to choose the right API in the long candidate list.
This commit extract these two attributes from Clang doc comments and insert/cache them in
code completion results.
rdar://23101030 and rdar://23101029
Conventionally, code completion results are matched with user input solely by
names. However, names are limited in expressiveness. From this comments, we start to
decorate code completion results with @keywords fields extracted from Clang doc comments.
These fields are added by API authors to comment the decl with information that
is not manifested clear enough through names. Code completion users' typing of the
keyword leads to the corresponding code completion results being selected as well.
Keywords can be arbitrarily long and can be multiple.
For instance, a function called "index()" has "@keyword find" in its doc comment.
Users' typing of "find" leads to "index()" being selected in the code completion list.
...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 exposes the code completion kind so that SourceKit has more
information about the code completion context.
For rdar://problem/22460026
Swift SVN r31925
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
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
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
When we miss the in-memory (libcache-based) code completion cache, we
can now chain to an on-disk code completion cache. This drastically
improves the time and peak memory usage it takes to do the first code
completion (ie. before the in-memory cache is warm) if we've done the
same lookup before.
The on-disk cache, like the in-memory cache is tied to the specific
compiled swift and clang module files (.swiftmodule and .pcm), and will
consider itself out of date if they are modified. Responsibility for
deleting completely dead/unreachable cache files falls to the client.
Most of this commit is adding a simple serialization and deserialization
for CodeCompletionResults and CodeCompletionStrings. The format is very
simple, using an array of fixed size CodeCompletionResults, with offsets
into two blobs: one for CodeCompletionString::Chunks, and one for
strings. Currently that gives us about 5.8 MB for all the results in
Cocoa, but it's very compressible if we decide we want to reduce it
(gzip'd it is ~1.2 MB for the same data).
Swift SVN r28369
