Our recovery is better now, and we don't skip that much. Actually, even if we
would stop at code completion token during recovery, completion results would
be something very generic anyway (because there is no interesting parser state
to observe), and these results can be produced as a fallback separately (not
implemented).
Swift SVN r7754
...unless the functions are declared [transparent], or if we're in an
immediate mode (in which case we won't get a separate chance to link
against the imported TUs).
This is an optimization that will matter more when we start dealing with
Xcode projects with many cross-file dependencies, especially if we have
some kind of implicit import of the other source files in the project.
In the future, we may want to parse more function bodies for the purpose
of inlining, not just the transparent ones, but we weren't taking
advantage of that now, so it's not a regression. (We're still not taking
advantage of it even for [transparent] functions.)
Swift SVN r7698
This increases the amount of noise in diagnostics. But we did not get these
diagnostics before because we were just skipping these brace statements. We
shoud improve recovery in parsing of whatever declaration that precedes the
brace statement so that it is picked up as a body of that declaration.
Swift SVN r7679
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
Now we make the desicion to delay parsing if the parsed production contained a
code completion token, not if we just stopped at the code completion token.
Swift SVN r7442
But the implementation of expression parsing still does not propagate the code
completion bits because it uses NullablePtr for results.
Swift SVN r7425
pass in a vector
This a bit of noise to the diagnostics (see test change); this issue will be
fixed uniformly for all nominal decls in future commits.
Swift SVN r7399
This finally fixes a few code completion test cases.
This also regresses the error message in one parsing testcase because
previously we would just happily skip those tokens, but now error handling path
is a little bit different and these tokens hit different error handling code.
This can be fixed by parsing a tuple for the selector argument and complaining
if the tuple had more than one element.
Swift SVN r7389
This will allow us to do code completion inside lists (e.g., tuples) *and* get
parser recovery instead of stopping at the code completion token immediately.
Swift SVN r7366
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 allows the parser to recover, create an AST node, return it to the caller
*and* signal the caller that there was an error to trigger recovery in the
caller. Until now the error was signalled with a nullptr result (any non-null
result was considered a success and no recovery was done in that case).
This also allows us to signal the caller if there was a code completion token
inside the production we tried to parse to trigger delayed parsing in the
caller while doing recovery in the callee. Until now we could not do recovery
in the callee so that the caller could find the code completion token.
Right now we don't take any advantage of these features. This commit just
replaces some uses of NullablePtr with ParserResult.
Swift SVN r7332
This allows us to show generic parameters in:
struct S<T> {
func f(a: #^A^#
}
And show the type Z in:
struct S {
func f(a: #^A^#
typealias Z = Int
}
Swift SVN r7216
