Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
This improves run time of this particular function by up to 8x in my
testing. For *really* large sets of code completions (I tested top-level
completion with Cocoa imported) this gives a 30-40% improvement across
the request, not including time spent in the client. The tradeoff is a
slight increase in peak memory usage (I saw 0.7% or 1.2 MB for the
top-level Cocoa case).
<rdar://problem/20355626>
Swift SVN r26748
getImportedModules is the canonical way to get imports, whether private,
public, or both. This is especially true now that we have more flags
for SourceFile imports that really shouldn't be consumed by anyone
outside of SourceFile.
In this same vein, provide addImports instead of setImports, since imports
are always additive.
No visible functionality change.
Swift SVN r26634
Previously, when code completing Optional<T>., we only show
the member functions of T; This fix adds the member functions
of Optional to the code completion list.
rdar://20316534
Swift SVN r26622
When the code completion token appears after throw keyword,
a set of visible decls and instances conforming _ErrorType are
recommended as completion.
Swift SVN r26565
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
This patch also introduces some SILGen infrastructure for
dividing the function into "ordinary" and "postmatter"
sections, with error-handling-like stuff going into the
final section. Currently, this is largely undermined by
SILBuilder, but I'm going to fix that in a follow-up.
Swift SVN r26422
We explicitly whitelist these "stdlib private" decls in interface
generation, because they may contain methods that users are required to
implement. But in code-completion, there's no good reason to show them.
We still show completions for the methods themselves if you complete on
a public protocol that inherits from the private protocol. So,
<complete> => doesn't show _CollectionType
let a: CollectionType = ...
a.<complete> => *does* show startIndex, which comes from _CollectionType
rdar://problem/20086106
Swift SVN r26355
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
When a developer auto-completes an override function,
we collect the keywords that have already been specified
by the developer, so that the code completion strings do
not duplicate them.
rdar://16738036
Swift SVN r26230
When code completing a literal expr, it is likely that code completion engine only collects the expr
that is not fully type checked. Therefore, no members of the literal can be suggested. To address this,
we try to climb up expr hierarchy in AST to find an expr with a nominal type, and use the nominal type
to finish code completion.
rdar://20059173
Swift SVN r26116
auto-completing @attributes. By delaying the handling of code completion token after the entire decl being parsed, we know
what are the targets of the attribute to finishe, thus, only suggesting those applicable attributes.
Swift SVN r25938
context-sensitive. The first step is to recommend parameter-applicable
attributes only when the code completion token is found inside a
param decl.
Swift SVN r25810
step to achieve this goal, this change allows the first parameter of
@availability to be completed with either one of the following four
platforms: *, iOS, iOSApplicationExtension, and OSX.
rdar://19541135
Swift SVN r25703
The previous commit enabled this; now it's just about removing the
restriction in the parser and tightening up code completion.
Using 'super' in a closure where 'self' is captured weak or unowned still
doesn't work; the reference to 'self' within the closure is treated as
strong regardless of how it's declared. Fixing this requires a cascade of
effort, so instead I just cloned rdar://problem/19755221.
rdar://problem/14883824
Swift SVN r25065
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
This affects the MacTypes.h header in the Darwin module as well as the
CarbonCore and OSServices sub-frameworks of the CoreServices framework.
API hidden in this way can still be accessed through qualified lookup
in case it's really needed, but will not appear in the module interface
or in code completion.
This is a hack, and it would be nice to remove it if/when all of this API
is officially marked as deprecated. I did check with Nick for MacTypes.h
and Chris Linn from CoreServices that this was a reasonable action to take.
rdar://problem/16806148
Swift SVN r24424
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
