...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
Also make the implicit AssociatedTypeDecl, created for a protocol, to have the
location of its protocol, otherwise the verifier will complain that a decl has no
source range.
Swift SVN r7673
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 is particularly convenient for dealing with generated
code (e.g. as produced by the SIL printer), but it's also
quite defensible as a way for users to logically group
related attributes and split unrelated ones out, should
users find themselves using a lot of verbose attributes
(and prior experience with e.g. user-defined attributes
is that they definitely do sometimes turn into walls of
text...).
Swift SVN r7376
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
