Leading paren in constructor patterns should be included in the description
text, but not in the name.
This addresses the first part of <rdar://problem/17004638>.
Swift SVN r19114
LLVM's system_error.h has been changed to forward to the standard
version of the same. Update usage for the minor API changes that this
entails.
Based in part on a patch by Justin Bogner.
Swift SVN r18832
-Hide vars that have a private type.
-Hide functions that have a parameter with private type or a parameter name with leading underscore.
-Minor change in StringUTF16.swift to avoid printing "func generate() -> IndexingGenerator<_StringCore>".
rdar://17027294
Swift SVN r18623
instead, so it picks up substituted types. BodyParamPatterns is now only
used for the local non-api parameter name.
Consolidate the two variations of addFunctionCallPattern() into one function.
Update the tests accordingly.
This addresses <rdar://problem/16956363>.
Swift SVN r18481
This reverts commit r18426.
Per feedback from Jordan this does the wrong thing because it aborts the entire visitation, not just the current visitation path.
Swift SVN r18433
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
We already don't try to detect and filter out shadowed declarations due to performance reasons, so cache the visible declarations contained
in a specific ImportedModule and collect all the results by recursing via calling Module::forAllVisibleModules().
This is more efficient because we avoid doing the work to collect all the global results for both Cocoa and AppKit, and we save on memory usage for the cache.
This also fixes a correctness issue where if you imported a module that was transitively imported by a previous import (e.g. Cocoa and AppKit) you would get duplicate results.
For this test case:
----------
import Cocoa
import AppKit
import Foundation
func foo() {
<ESC>
}
----------
We go from
- 7.05 secs to 1.43 secs to collect the results
- 9.0 secs to 2.4 to ultimately show them in Xcode for first-time invocation.
Swift SVN r18344
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
The leading paren is included for display purposes only, not inserted
in the code if already present. It makes the displayed text in the
code completion list symmetrical with respect to open/close parens.
Add markups when printing annotation chunks so it becomes testable.
Update tests accordingly, and include tests for leading parens.
This addresses <rdar://problem/16918310>.
Swift SVN r18126
right after the left paren if the function or constructor requires a keyword
for the first argument
Should significantly clean up code completion for Cocoa constructors.
Swift SVN r17817
conformances
rdar://16539292
This is a hack in visible decl lookup. The general solution that would also
improve type checker errors would be to make the type checker keep these broken
conformances and syntethize missing declarations to make downstream code type
check. For that, see:
<rdar://problem/16723339> [QoI] Type checker should not be dropping protocol
conformances explicitly spelled in the source
Swift SVN r16818
... at the cost of correctness, see test changes
This change was suggested by Argyrios.
But we still take 10 seconds to compute completion results for Cocoa.
Swift SVN r16599
Use this node to capture the argument name and its source location in
the AST. We're only building these in one place at the moment; the
rest will be updated soon.
Swift SVN r16581
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
class A {
init(a: Int) {}
}
A(#^HERE^#
In its current state, this is a hack that I am not proud of. There is
potential here to provide such completions for all function calls:
class A {
func foo(a: Int) {}
func foo(a: Double) {}
}
A().foo(#^HERE^#
but this requires code completion doing its own name lookup, since the type
checker will give us an error type due to ambiguity of overloaded functions.
Type checker also sometimes gives up in cases like these:
struct A {
func foo() {}
}
A().foo
which is understandable, since we disallow partial applications of functions on
values, but returning the correct type here is useful for code completion.
rdar://16597372
Swift SVN r16367
