This the first part for improving source location fidelity for types,
changes to follow:
-The Parser will not create any types, it will just create TypeReprs.
-The type checker will create the types by going through TypeReprs.
-IdentifierType will be removed.
Swift SVN r6112
When the name of a generic type is referenced, without any generic
arguments, within the definition of a generic type (or extensions of
that generic type), use the generic arguments provided by that
context. Thus, within the definition of X<T> below, one can simply use
'X' as a shorthand for 'X<T>':
class X<T> {
func swap(other : X) { /* ... */ } // same as "func swap(other : X<T>)"
}
This resolution provides essentially the same behavior as the
injected class name does in C++. Note that this rule overrides any
inference rules, such that (for example) the following is ill-formed
rather than inferring the generic arguments of 'X':
class X<T> {
func foo() {
var xi : X<Int> = X()
}
}
Note that name binding has changed slightly: when unqualified lookup
finds a type declaration within a nominal type, it is now treated as
a DeclRefExpr (or overloaded variant thereof) rather than as a member
access with an implicit 'this'.
Fixes <rdar://problem/14078437>.
Swift SVN r6049
Because of '~=' lookahead and precedence parsing, we need to be able to parse pattern productions in expression position and validate them after name binding. Add an unresolved Expr node that can hold a subpattern for this purpose.
Swift SVN r5825
We decided to go with 'var' as a distributive pattern introducer which applies to bare identifiers within the subpattern. For example, 'var (a, b)' and '(var a, var b)' would be equivalent patterns. To model this, give 'var' its own AST node with a subpattern and remove the introducer loc from NamedPattern.
Swift SVN r5824
I talked to John about parsing patterns today, and because of the magnitude of name-lookup-dependent ambiguities between patterns and expressions, we agreed that at least for a first-pass implementation it makes sense to parse patterns as extensions of the expr grammar and charge name binding with distinguishing patterns from expressions. This gets us out of needing the concept of an "unresolved pattern", at least in the short term.
Swift SVN r5808
A single case block can have one or more 'case ...:' labels. 'case' labels contain patterns instead of exprs. 'default:' is a funny spelling for 'case _:'. Change the CaseStmt representation and rip out all the parsing, type-checking, and SILGen built off the old representation.
Swift SVN r5795
Introduce Pattern subclasses for the 'is T', 'T(<pattern>)', and '<expr>' pattern syntaxes we'll be introducing for pattern-matching "switch" statements. Also add an 'UnresolvedCalLPattern' to act as an intermediate for name lookup to resolve to a nominal type, oneof element, or function call expression pattern. Since we'll need to be able to rewrite patterns like we do expressions, add setters to AST nodes that contain references to subpatterns. Implement some basic walking logic in places we search patterns for var decls, but punt on any more complex type-checking or SILGen derived from these nodes until we actually use them.
Swift SVN r5780
