Start allowing extensions to redeclare type parameters, which will get
different archetypes from the original nominal type. When an extension
does not redeclare type parameters, silently clone the nominal type's
generic type parameters so we still get distinct type parameters.
When deserializing an extension, wire up its generic parameter list so
we get the right archetypes for its members. This doesn't change the
module format (that happened earlier).
When determining the substitutions for an associated type that comes
from a different declaration context from the conformance that will
own the witness, be sure to map into the conformance's
DeclContext. Otherwise, we'll end up with tangled archetypes.
Fixes rdar://problem/16519588.
Swift SVN r26483
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
... now that we have an exquisitely shaved yak.
This provides a simple and uniform model for "let" constants: they are always either
immediately initialized in their declaration, or they are initialized dynamically
exactly once before any use.
This is a simple generalization of our current model for initializers, but enables
the use of let constants in more cases in local context, e.g. patterns like this:
let x : SomeThing
if condition {
x = foo()
} else {
x = bar()
}
use(x)
Previously this would have to be declared a "var" for no good reason: the value is
only ever initialized, never actually mutated.
The implementation of this is reasonably straight-forward now that the infrastructure
is in place: Sema treats 'let' constants as "settable" if they lack an initializer
(either in the declaration or in a non-PBD binding). This exposes them as an lvalue
at the AST level. SILGen then lowers these things to an alloc_stack, and DI enforces
the "initialization only" requirement that it already enforces for uninitialized 'let'
properties in structs/classes.
Swift SVN r23916
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
