Introduces a new kind of function type, GenericFunctionType, that
represents a polymorphic function type with all of its generic
parameters and requirements stored in a more readily canonicalizable
form. It is meant to eventually replace PolymorphicFunctionType, but
for now we build it up in parallel so we can switch over to it
pieacemeal.
Note: this representation is built and then thrown away. We'll start
recording it soon.
Swift SVN r8881
This is more naturally where they belong in the grammar, allows for nice chained transformation calls like 'x.map { ... }.filter { ... }', and lets us remove a bunch of kludgy fixits to try to handle the 'wanted to parse postfix but didn't' case. Fixes <rdar://problem/14098078>. Also fix the special-case handling of "builder pattern" style method chains to parse 'x\n.method{' as a chained method call, like it does 'x\n.method(' or 'x\n.property['. (There's got to be a better way...)
Swift SVN r8828
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
Introduce an EnumCaseDecl for source fidelity to track the 'case' location and ordering of EnumElementDecls. Parse a comma-separated list of EnumElementDecls after a 'case' token.
Swift SVN r8509
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
heuristic than skipUntilAnyOperator() to find the end of a type list
Almost all testcases added in this commit used to skip all the way to EOF.
Swift SVN r7991
Diagnostics that point to the first bad token are marked with this option in
Diagnostics.def. Parser::diagnose treats the source location of such
diagnostics in a special way: if source location points to a token at the
beginning of the line, then it moves the diagnostic to the end of the previous
token.
This behaviour improves experience for "expected token X" diagnostics.
Swift SVN r7965
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
