This permits, e.g., extending Array for all Hashable T's. However, it
does not permit extending Array for T == String. Part of
rdar://problem/21142043.
Swift SVN r29107
Now that we don't have generic parameter lists at arbitrary positions
within the extended type of an extension declaration, simplify the
representation of the extended type down to a TypeLoc along with a
(compiler-synthesized) generic parameter list.
On the parsing side, just parse a type for the extended type, rather
than having a special grammar. We still reject anything that is not a
nominal type (of course), but it's simpler just to call it a type.
As a drive-by, fix the crasher when extending a type with module
qualification, rdar://problem/20900870.
Swift SVN r28469
We no longer allow extensions to provide generic parameters, and the
ability to parse the syntax
extension Array<String> { ... }
is causing confusion. Fixes rdar://problem/20873336.
Swift SVN r28468
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
generic parameter 'T' is not used in function signature
func f8<T> (x: Int) {}
This commit takes Jordan't comments on r28181 into account:
- it produces a shorter error message
- it does not change the compiler_crashers_fixed test and add a new expected error instead
Swift SVN r28194
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
There is no way to infer the generic parameter 'T' if it is not used in function signature
func f8<T> (x: Int) {}
^
Swift SVN r28181
The culprit happened to be a type representation cloner for tuple type
representations that didn't actually clone anything. Introduce an
AST-level verifier that makes sure we catch any archetypes that slip
into interface types earlier in the future.
Fixes rdar://problem/18796397 and the three dupes I've found so far.
Swift SVN r28080
in Xcode 6.4 I changed the compiler to start treating properties as rvalues in
initializers when they have an initializer since they cannot be overwritten
in the initializer. This has the unfortunate effect of typing derived member_refs
as rvalues as well, which causes SILGen to load the entire 'self' value instead of
just the member, triggering invalid DI errors in cases like this.
Fix this by always treating properties on self as lvalues in initializers. Invalid
reassignments are already diagnosed by DI anyway, and the QoI of the error is better
from DI than from Sema (as shown by the testsuite change).
Swift SVN r27721
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
