When referring to a DynamicSelf method, treat DynamicSelf as an alias
for the class type in which the method was declared, then perform a
function conversion to a method with the appropriate subclass as the
result result type. This is always a (trivial) subtype conversion on
the method.
Swift SVN r13268
Allow IfStmts and WhileStmts to have as their condition either an expression, as usual, or a pattern binding introduced by 'var' or 'let', which will conditionally bind to the value inside an optional. Unlike normal pattern bindings, these bindings require an in-line initializer, which will be required to be Optional type. Parse variable bindings in this position, and type-check them by requiring an Optional on the right-hand side and unwrapping it to form the pattern type. Extend SILGen's lowering of if and while statements to handle conditionally binding variables.
Swift SVN r13146
When we type check the signature of a method, determine which method
it overrides (if any) at that time. This ensures that we always have
this information for name lookup (per <rdar://problem/15932845>).
As part of this, start to make the overriding rules a little more
sane. John has worked out more of the model here, but this patch:
- Considers an Objective-C method an override of another Objective-C
method if the selectors match and the type vs. instance-ness of the
methods match. The method types are checked for consistency
(subtyping is okay).
- Diagnoses when a method overrides more than one method from a
superclass, and
- Eliminates the "cannot overload method from a superclass"
diagnostic, which is overly pedantic and oddly limiting.
Note that we lose some amount of checking here. Specifically, we don't
have a good place to check that one has not provided two different
methods that override the same superclass method. The older code did
that (somewhat), and it's not a trivial problem to solve efficiently.
This fixes the part of <rdar://problem/15597226> that is needed for
<rdar://problem/15932845>. It still doesn't handle properties,
subscripts, and undoubtedly other issues.
Swift SVN r13108
Since we type-check local variables in statement order in a function, but
resolve names on a whole-scope basis, we can end up with a name that refers
to a local variable before its declaration has been reached. If this happens,
the variable won't have a type.
Checking this correctly may require comparing the order of statements in a
syntactic scope, but for now, just emit an error message if a reference
ever resolves to a variable without a type. (Note that UnqualifiedLookup
will have already tried to validate the decl, so if it's a global we just
haven't seen yet there's not a problem.)
Unfortunately, we won't get this right for top-level variables in script
source files, since those are still stored at global context and can be
validated on demand. They're never uninitialized, but zero-initialization
may not be valid for all global kinds.
<rdar://problem/15912025>
Swift SVN r13003
Take DynamicSelf as a keyword, but parse it as a type-identifier.
Teach function declaration checking to sniff out and validate
DynamicSelf early, with appropriate QoI for references to DynamicSelf
that appear in other places.
As a temporary hack, DynamicSelf resolves to an alias for 'Self' in a
protocol or the enclosing nominal type.
Swift SVN r12708
As part of this, give diagnoseUnknownType() the ability to fix the current component so that we continue as-if the user had written what we wanted. This gives us a hook for various forms of fixes, e.g., typo correction on type references.
Swift SVN r12707
its basic logic in libAST, which both makes it easier to
implement and makes it possible to use in the places that
should care about it, i.e. in IR-gen and SIL-gen.
Per Doug, none of the places that were introducing
trivial-subtype constraints really needed to do so rather
than just using subtype constraints.
Swift SVN r12679
protocol BaseProto {
typealias AssocTy
}
var a: BaseProto.AssocTy // error!
While this could be interpreted to mean "a is an existential bounded by
whatever AssocTy is bounded by", we don't actually support this in any
other contexts; if a protocol has a function that returns an associated type,
it can only be used in a concrete or generic context, not an existential one.
<rdar://problem/15850024>
Swift SVN r12600
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
