The changes to the decl/ext/generic test strip out testing of
extensions of nested generics, a feature whose syntax will change and
is fairly broken already.
Swift SVN r21750
We were checking for exact type equality of the DeclContexts, which
will not hold when extensions have their own archetypes. A near-term
fix would be to use interface types, but checking the nominal types is
a better long-term solution.
Swift SVN r20768
Extension binding decides which nominal type declaration is extended
by a given extension, so perform basic validation to ensure that the
generic parameter lists provided in the extension make sense. Note
that we're not checking the actual generic parameters properly in
the nested case, so none of this actually works at all. That will come
next, over in extension validation.
Swift SVN r20724
Extensions must have the same number of generic parameters as the
generic type they extend, and cannot add any additional requirements
beyond those on the extended generic type (yet!). We use requirement
inference to allow one to provide fewer requirements on the extension
than exist on the generic type. The expectation here is that one won't
ever repeat the requirements from the generic type.
Swift SVN r20706
The eventual goal for extensions of generic types is to require them
to specify their generic parameters, e.g.,
extension Array<T> { ... }
rather than today's
extension Array { ... }
Start parsing (optional) generic parameters here, and update the
representation of ExtensionDecl to accomodate this new grammar
production. Aside from the parser changes, there's no intended
functionality change here.
Swift SVN r20682
