ConstructorDecl::getBody() and DestructorDecl::getBody() return 'BraceStmt *'.
After changing the AST representation for functions, FuncDecl::getBody() will
return 'BraceStmt *' and FuncDecl::getFuncExpr() will be gone.
Swift SVN r8050
This ensures that we parse the next statement we don't see the code completion
token.
Allows to remove an ugly workaround in the code completion engine.
Swift SVN r7598
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
This introduces the required code completion callbacks which pass partially
parsed TypeReprs to code completion. These types can refer to generic function
parameters. Because we need to typecheck these types, we need to typecheck
generic parameters first. Because exposing fine-grained typechecker interface
just for code completion is bad, we create a function declaration based on the
limited information we have (i.e., just the function name and generic
parameters) and pass that to the typechecker. This approach (in theory) should
work uniformly for function decls and nominal type decls, but the nominal type
decl case is not tested yet. Eventually we will also want to use a similar
approach for normal parser recovery as well.
Swift SVN r7313
parameters while parsing the function signature. Generic parameters are not
accessible at that time through the AST node, because the FuncDecl AST node was
not constructed yet.
Swift SVN r7222
addZzz(). The 'Swift' part of the name was added because there was a codepath
for completing swift decls and a different one for completing clang decls. Now
we complete clang decls by first importing them, so the 'Swift' part of the
name is just redundant.
Swift SVN r7195
line after a var decl with initializer would complete based on the initializer
expression.
These are technically valid completions, but confusing. Now this suggests
unqualified completions.
Swift SVN r7188
happen after delayed parsing is finished. This ensures that the AST for
delayed parsed code (for example, function body) is constructed. This is
required for partial type checking of function bodies.
Swift SVN r7010
Because we don't want FooModule.#^A^# to show completion results for other
clang modules, global completion cache was replaced with a per-module cache.
Swift SVN r6951
constructing the MetaTypeType. LValueness of the expression does not matter
for the metatype type. (And it also makes the type annotations very long in
many cases.)
Swift SVN r6857
"IsAnnotation" flag on the Chunk. This flag is also set on the TypeAnnotation
chunk.
This revised design makes it easy for the client to find out if a particular
chunk should be inserted into the editor buffer or not.
Swift SVN r6809
completion token
This is required to handle cases like fooObject.#^A^#.bar where code completion
is invoked inside the ".." token. Previously, the token would not be split and
the lexer would produce an incorrect tokenization for this case. Now we
produce ".", tok::code_complete, ".".
Swift SVN r6635
Documentation comment says that it should return a 0-based offset, but it
actually returns a 1-based offest.
Code completion tests did not catch this bug because the only consequence is
that the code completion token is shifted one character to the right, and in
all code completion tests we had a space after the code completion token.
Swift SVN r6566
importing them
Because going through the import for every code completion request is slow,
Clang code completion results are cached in the CodeCompletionContext. The
cache needs to be invalidated whenever a new Clang module is loaded. In order
to implement this, ModuleLoadListener class was added.
Swift SVN r6505
Removes the boolean IsTypeLookup and OnlyInstanceMembers, which were totally
misleading.
This fixes some bugs in lookupVisibleDecls, which allows us to remove
workarounds in code completion, that were not correct in some corner cases.
Now we also code complete references to instance functions in static contexts,
but code completion results in this case state the type of the resulting object
incorrectly.
Swift SVN r6396
code completion results inside static functions
Referencing an instance function from a static function is allowed by the
language, but the compiler crashes on this right now. (rdar://14432081)
Swift SVN r6390
the containing DeclContext
Fixes a few FIXMEs in code completion where we were providing results that
refer to generic arguments outside of their scope.
Swift SVN r6370
is documented: look up members of a type that are visible from a specific
module. It does not matter much now, but when we have access control, it will.
Before this change, lookupVisibleDecls() tried to guess the *defining* module
of the type, and gave up if it could not. It forced us to duplicate some
lookup logic for some types (archetypes and protocol compositions). Also add a
test that lookup finds members of archetype's superclass, which the original
(duplicated) code did not handle.
Swift SVN r6363
need to unwrap the type sugar.
This was uncovered by the removal of IdentifierType and removal of
getCanonicalType() in code completion, which was working around
lookupVisibleDecls() not working for IdentifierTypes.
Swift SVN r6332
