...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
This will let us implement caching in the client (e.g. SourceKit) at
some point and simplifies adding more levels of caching. Requires a
corresponding SourceKit change.
Swift SVN r28365
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Now get() and set() manage determining whether the results are stale,
and getResults() can just rely on that.
Also drive-by fix a data race where we were inserting our results sink
into the cache before it was finished being modified.
Swift SVN r28175
We want to be able to synthesize new results inside SourceKit. At this
point, the simplest way to do that is to expose the constructors for
CodeCompletionResult and a create() function for CodeCompletionString.
The expectation that any strings are stored properly inside a
CodeCompletionResultSink is documented.
Swift SVN r27822
For decls, we get the most specific submodule from clang modules. For
macros, we don't yet have a way to get this information, since the
mapping from module ID to submodule is burried in the ClangImporter.
Having submodule information for macros would also help reduce the space
cost of storing the module names, since we would hit the single-element
module name cache more often.
There is no special handling of imported headers, which currently come
through with their internal clang module name '__ObjC'. Possibly these
should be treated as part of the current module.
A future commit will add the module name to swift-ide-test's output and update
the tests.
Swift SVN r26260
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
When trying to implement deduplication of results, found and fixed an issue
with loose checks for generic overload checking.
rdar://17995317
Swift SVN r21276
If the completion result is a declaration, it contains the USR of the specified declaration and all overridden declarations.
Additional tests on SourceKit side.
This addresses <rdar://problem/17600891>.
Swift SVN r20877
optional & alias types for closure type parameters.
This allows code completion placeholder expansion to properly expand
closure parameters utilizing a typealias, e.g. dispatch_block_t.
Update and add test for the above.
Work for <rdar://problem/15860693>.
Swift SVN r20206
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
if there's no parameter API name. This is for display purposes only.
Update all relevant tests accordingly.
This addresses <rdar://problem/16768768>.
For example:
class X {
func f(a: Int, b: Int) { }
}
Would previously display like this in code completion in Xcode:
f(<#Int#>, b: <#Int#>)
The local parameter name, while not API, often still conveys meaning
to the user. So it's now included like this:
f(<#a: Int#>, b: <#Int#>)
Swift SVN r18403
A use-after-free could happen in the following scenario:
- code completion caches results from module A;
- code completion returns cached results -- result set 1;
- module is rebuilt;
- another code completion request arrives, cache is invalidated and re-filled.
Old results are freed, even though someone could be still using the result
set.
rdar://16953614
Swift SVN r18329
In order for Xcode to use these completions, we complete "?.member" when the
user has typed "anOptional.", but we also say that in order to apply this
result, N bytes to the left of the cursor should be erased first.
rdar://16579657 rdar://15233283
Swift SVN r16409
