ASTContexts
This introduces swift::ide::CodeCompletionCache, which is a persistent code
completion result cache.
Right now REPL happens to use it (try importing Cocoa and doing code
completion), and the difference is noticeable. But completion in REPL is
still slow, because Cocoa goes through the AST Verifier on every completion
(for unknown reasons).
This commit does not implement cache invalidation yet, and it does not use
libcache to evict cache entries under memory pressure.
This commit also introduces two regressions:
- We get fewer Cocoa results that expected. Module::isModuleVisible in Clang
does not incorrectly reports that that ObjectiveC.NSObject submodule is not
visible from Cocoa.
- We are not implementing the decl hiding rules correctly. We used to rely on
visible decl lookup to do it for us, but now we have a different data structure
we have real decls from the current module and we have a text-only cache, so we
are forced to reimplement this part of name lookup in code completion.
Swift SVN r9633
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
Now that TypeChecker is being used to check all sorts of things (not all
from a single TU), it's not really correct to have a single top-level TU
that gets used everywhere. Instead, we should be using the TU that's
appropriate for whatever's being checked. This is a small correctness win
for order-independent type-checking, but is critical for multi-file
translation units, which is needed for implicit visibility.
This basically involves passing around DeclContexts much more.
Caveat: we aren't smart about, say, filtering extensions based on the
current context, so we're still not 100% correct here.
Swift SVN r9006
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
There were two overloads of lookupVisibleDecls: one that performed
unqualified lookup from a particular decl context, the other performing
qualified lookup into a given type from a particular decl context.
They don't really behave the same, so let's give them different names.
Swift SVN r8641
Of course, in structs 'self' is a reference to the value, but this is so
obvious and natural, that calling out this [byref] in code completion results
every single time adds nothing but syntactic noise.
We still show [byref] in other cases, for example, when we complete references
to user-written function parameters.
Swift SVN r8464
Implement the new rules for mapping between selector names and
constructors. The selector for a given constructor is formed by
looking at the names of the constructor parameters:
* For the first parameter, prepend "init" to the parameter name and
uppercase the first letter of the parameter name. Append ':' if
there are > 1 parameters or the parameter has non-empty-tuple type.
* For the remaining parameters, the name of each parameter followed
by ':'.
When a parameter doesn't exist, assume that the parameter name is the
empty string.
And, because I failed to commit it separately, support selector-style
declarations of constructor parameters so that we can actually write
constructors nicely, e.g.:
// selector is initWithFoo:bar:
constructor withFoo(foo : Foo) bar(bar : Bar) { ... }
Swift SVN r8361
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
